TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: planeta9999 en 21 de Mayo de 2015, 11:01:27
-
¿ Alguno sabeis que grado de compatibilidad existe en el ensamblador entre las distintas familias de PIC ?, en concreto entre los PIC18F entre si, y los PIC18F con otras familias superiores como PIC24 o PIC32.
Estoy con un proyecto en el que tengo que rediseñar una placa muy antigua, de principios de los 80, con un procesador RCA CDP1802. En principio iba a dejar el procesador original, pero hoy en día es difícil de localizar y muy caro, si me voy a los chinos todo lo que ofrecen huele a falsificación, remarcado de otros chips que obviamente no van a funcionar, o chips usados sacados de placas viejas que seguramente tampoco funcionarán. Si me voy al mercado americano, son caros, el transporte super caro y me van a crujir en aduanas.
La siguiente opción que barajé es emular el procesador original, bien con un core para FPGA o algún programa para un microcontrolador. Para FPGA encontré algo pero no es de código libre, y finalmente a base de buscar encontré un proyecto que rueda en un PIC18F4620 para emular un sistema COSMAC completo con el CDP1802, una virguería, algún día me gustaría aprender a programar un emulador de un procesador en un microcontrolador o un FPGA, es un tema fascinante.
Aunque en el proyecto para PIC18F dan los fuentes, están en ensamblador para mi desgracia, porque no es un lenguaje que domine, aunque si que hice algo hace muchos años y conozco los fundamentos de la programación en ensamblador. La cuestión es que seguramente necesitaré más flash para guardar los programas que debe de rodar el CDP1802, con el PIC18F4620 tengo solo 64K, y necesitaría al menos 96K o mejor 128K. Estoy pensando en usar el PIC18F4685 que tiene 96K, o alguno de los que tiene 128K, pero tengo mis dudas sobre si el fuente en ensamblador será compatible o puede necesitar modificaciones complicadas. Lo único bueno es que son unos fuentes extraordinariamente bien documentados.
Me voy a pedir unos samples del PIC18F4620 en PDIP y TQFP, y seguramente uno del PIC18F4685 en PDIP para pruebas.
-
En emsamblador no tendrás que hacer grandes modificaciones, quizá tengas que tocar algo de los puertos, pero no creo que ninguna modificación gorda.
Si quieres aprender a emular un micro o un núcleo, yo aprendí ha hacerlo primero en ordenador en C, donde tienes mas facilidad de programación, y los programas que corría los leía de un .hex con el código maquina. Es igual que un micro solo que los pines son variables para emularlos. Cuando lo dómines hay te resultara mucho mas fácil de hacer en otro micro o una FPGA. El que yo eMule fue el nucleo de un 8051
Un saludo.
-
En emsamblador no tendrás que hacer grandes modificaciones, quizá tengas que tocar algo de los puertos, pero no creo que ninguna modificación gorda.
¿ De PIC18 a PIC24 también es compatible el ensamblador ?. Lo único bueno, es que supongo que no habrán limitaciones con el compilador como ocurre con el C de XC32.
Si quieres aprender a emular un micro o un núcleo, yo aprendí ha hacerlo primero en ordenador en C, donde tienes mas facilidad de programación, y los programas que corría los leía de un .hex con el código maquina. Es igual que un micro solo que los pines son variables para emularlos.
Para hacerlo en un PC, no se ni por donde empezar. Solo se me ocurre mirar los fuentes de MAME o Pinmame, que emulan una buena cantidad de procesadores, para ver un poco como manejan el juego de instrucciones, y luego ya me pierdo. Supongo que manejan variables para los registros de trabajo como el W y otros, el contador de programa (PC), la pila para los saltos, la RAM y el estado de cada pin.
-
Hay que separar las familias
Los PIC16/PIC10/PIC12 creo que comparten todo el mismo set de intrucciones.
PIC18 ya posee un set distinto, en realidad se expande del anterior.
PIC24/dsPIC poseen otro set, pero lo comparten estos 2, dsPIC tiene algunas instrucciones mas que involucran al DSP, y hay algunas diferencias en ejecucion entre las familias ( PIC24F y PIC24E, tal ves algun salto lleva 2 y el otro 4 ciclos, en dsPIC ocurre lo mismo)
PIC32 posee el nucleo de MIPS32 M4K, asi que posee su propio set de instrucciones.
Ahi tenes los grupos en los cuales serian intercambiables los codigos, puede que cambie el nombre de algun registro o la posicion en memoria, Tambien el tema de los pines, que microchip no le da mucha importancia que se mantenga ( aunque si rediseñas la placa no deberia haber problema). Y cualquier duda que necesites en ASM veo si puedo ayudar, me gusta asi que con todo gusto.
-
PIC18 ya posee un set distinto, en realidad se expande del anterior.
PIC24/dsPIC poseen otro set, pero lo comparten estos 2, dsPIC tiene algunas instrucciones mas que involucran al DSP, y hay algunas diferencias en ejecucion entre las familias ( PIC24F y PIC24E, tal ves algun salto lleva 2 y el otro 4 ciclos, en dsPIC ocurre lo mismo)
PIC32 posee el nucleo de MIPS32 M4K, asi que posee su propio set de instrucciones.
Ahi tenes los grupos en los cuales serian intercambiables los codigos, puede que cambie el nombre de algun registro o la posicion en memoria, Tambien el tema de los pines, que microchip no le da mucha importancia que se mantenga ( aunque si rediseñas la placa no deberia haber problema). Y cualquier duda que necesites en ASM veo si puedo ayudar, me gusta asi que con todo gusto.
¿ Entre PIC18 y PIC24, hay compatibilidad ?, por ejemplo para llevar los fuentes de PIC18F4620 a un PIC24 o dsPIC.
Me gustaría meterle una rutina para que pueda cargar el programa a rodar desde una tarjeta micro SD, pero hacerlo en ensamblador me resulta muy complicado porque no lo domino. No se si sería posible mezclar C con ensamblador, para meter las rutinas de lectura de la tarjeta y grabación en la flash, usando C, y dejar las rutinas actuales en ensamblador para emular el procesador CDP1802. El caso es que el programa actual está todo en ensamblador, y habría que meterle el C, no se si eso es posible, o lo normal es al revés, desde un programa en C llamar a rutinas en ensamblador.
-
No, como dije hay 4 grupos distintos. Esos 4 grupos no comparten set
PIC18 es mas parecido a PIC16 con algunas instrucciones agregadas, PIC24/dsPIC no tienen nada que ver con las instrucciones del PIC18.
De igual forma se puede portar si es que no es tan complejo. Pero el ASM cambia completamente de uno a otro, directivas, etc.
El caso es que el programa actual está todo en ensamblador, y habría que meterle el C, no se si eso es posible, o lo normal es al revés, desde un programa en C llamar a rutinas en ensamblador.
Si se puede, lo unico es que si tienen argumentos tiene una forma definida para pasarse. Creo que se manjea con el stack y W en el PIC16/18 Mientras que PIC24/dsPIC/PIC32 es a traves de algunos registros + stack. juaperser puede ser de mucha mas utilidad por que yo intente y realmente no pude hacer funcionar un codigo en C con algunos archivos en ASM. (archivos ASM en un codigo C, por si no se entendio)
-
El caso es que el programa actual está todo en ensamblador, y habría que meterle el C, no se si eso es posible, o lo normal es al revés, desde un programa en C llamar a rutinas en ensamblador.
Si se puede, lo unico es que si tienen argumentos tiene una forma definida para pasarse. Creo que se manjea con el stack y W en el PIC16/18 Mientras que PIC24/dsPIC/PIC32 es a traves de algunos registros + stack. juaperser puede ser de mucha mas utilidad por que yo intente y realmente no pude hacer funcionar un codigo en C con algunos archivos en ASM.
Del programa en C al ensamblador no habría que pasar ningún parámetro. La rutina en C serviría para leer un archivo de una tarjeta micro SD y grabar en flash ese archivo binario (como lo hace un bootloader), que es el programa que tendrá que ejecutar el procesador emulado (CDP1802 ).
El caso es que las rutinas en ensamblador, no se si tienen que ir ubicadas en direcciones concretas, y lo que si que tiene que mantenerse en ambos es la dirección de escritura y lectura donde se ubique el programa a rodar por el procesador emulado, que ocupa 4K. Desde C se manejar la flash sin problemas, borrado y escritura.
También me planteo meter varios programas de 4K cada uno, y con un jumper externo conectado el PIC, saber desde las rutinas en ensamblador que bloque de 4K tiene que cargar y ejecutar el procesador, creo que son 8 programas distintos, según en que máquina se vaya a instalar la placa.
Tendré que mirar como se llaman a programas en ensamblador desde C, porque eso no lo he hecho nunca.
-
Tendré que mirar como se llaman a programas en ensamblador desde C, porque eso no lo he hecho nunca.
En la parte de C no es mucho problema. En la parte de ASM algo..
http://ww1.microchip.com/downloads/en/DeviceDoc/MPLAB_XC8_C_Compiler_User_Guide.pdf
Seccion 5.12 - pagina 210
Aun asi yo prbe el ejemplo y no me funciono.
El caso es que las rutinas en ensamblador, no se si tienen que ir ubicadas en direcciones concretas, y lo que si que tiene que mantenerse en ambos es la dirección de escritura y lectura donde se ubique el programa a rodar por el procesador emulado, que ocupa 4K.
Eso se peude ver en el codigo
-
El caso es que las rutinas en ensamblador, no se si tienen que ir ubicadas en direcciones concretas, y lo que si que tiene que mantenerse en ambos es la dirección de escritura y lectura donde se ubique el programa a rodar por el procesador emulado, que ocupa 4K.
Eso se peude ver en el codigo
¿ Le puedes echar un vistazo al fuente ?.
http://0xee.net/Rossin/Rossin/www.tedrossin.net46.net/Electronics/RCA/ElfClone/B1802_18F.asm
Yo diría que con estas directivas, se están definiendo la ubicación de partes del código, donde empiezan las rutinas del emulador y donde se almacena el programa a rodar por el procesador emulado, y eso no se si debe de considerar a la hora de hacer las rutinas en C, o se tiene que indicar en el linker script.
#define EMU_CODE_START 0x0680
#define ROM_SPACE_START 0x4000
-
Hola
Como ya te han contestado... PIC18 (ALU 8 bits) no es compatible con PIC24 (ALU 16 bits). El tamaño de las operaciones no es igual.
Aquí puedes encontrar una lista de las instrucciones...
http://en.wikipedia.org/wiki/PIC_instruction_listings
Los PICs comunes (PIC10, 12, 16) usan lo visto en: Mid-range core devices (14 bits por instrucción).
Los PIC18 usan instrucciones más enfocadas en C: PIC18 high end core devices (16 bits por instrucción).
Los PIC16 mejorados (PIC16F1XXX y PIC12F1XXX) se parecen a los PIC18: Enhanced mid-range core devices (14 bits por instrucción).
Los PIC24 ya con 16 bits de ALU tienen instrucciones que pesan 24 bits: PIC24 and dsPIC 16-bit microcontrollers.
-
#define EMU_CODE_START 0x0680 -- Direccion de flash donde se comienza el codigo de la parte de emulacion,
#define ROM_SPACE_START 0x4000 -- Direccion de flash donde se almacena el codigo a emular
org 0x0800 --- Direccion donde se almacena la tabla con todos las opcode posibles.
Yo me lo imagine tal cual al codigo, leer, una tabla y luego a cada opcode y obviamente trabajarlo de esa manera., pero veo que que le presta muchisima atencion a los ciclos de tiempo. Por todos los nop agregados, se puede achichar un poco si se reemplaza por saltos goto $+1, ahorrandote casi la mitad de nops. por cierto no parece muy complejo, lo mas complejo es respetar los tiempos.
Aunque ahora que veo tiene una maquina de estados
-
buenas planeta9999:
¿ De PIC18 a PIC24 también es compatible el ensamblador ?
quiza no me he explicado bien, queria decir que no ivas a tener grandes modificaciones por que el codigo que tu has encontrado es de un PIC18F4620 y lo quieres meter en un PIC18F4685, que como te han dicho los compañeros, son de la misma familia, si fuera un 24 ya seria otra cosa.
Para hacerlo en un PC, no se ni por donde empezar. Solo se me ocurre mirar los fuentes de MAME o Pinmame, que emulan una buena cantidad de procesadores, para ver un poco como manejan el juego de instrucciones, y luego ya me pierdo. Supongo que manejan variables para los registros de trabajo como el W y otros, el contador de programa (PC), la pila para los saltos, la RAM y el estado de cada pin.
creo recordar que yo empece con un programa gráfico que había desarrollado una universidad (creo que la de Navarra o Sevilla no lo recuerdo), era un nucleo procesador muy simple que podia correr programas y se veia graficamente como se movian los registros, los flag, la memoria etc.
teniendo este programa, lo emule en C y al leer los programas comprobaba que mi codigo en C hiciera lo mismo que el programa gráfico, si encuento algo en mi baul de los recuerdos te lo pasaré.
un saludo.
-
Bueno lo he encontrado,
lo dejo en un post aparte para que lo encuentre la gente que este interesada en emular nucleos o microcontroladores
un saludo y espero que os sirva.
http://www.todopic.com.ar/foros/index.php?topic=44559.msg369677;topicseen#msg369677
-
Bueno lo he encontrado,
lo dejo en un post aparte para que lo encuentre la gente que este interesada en emular nucleos o microcontroladores
un saludo y espero que os sirva.
http://www.todopic.com.ar/foros/index.php?topic=44559.msg369677;topicseen#msg369677
Muy interesante, gracias, le echaré un ojo, aunque se echa en falta algún manual de uso.
Por Youtube me he encontrado con estos videos que explican como hacer un simulador, uno genérico (de 10 capítulos) y otro específico para el Z80 (de 5 capítulos).
-
#define EMU_CODE_START 0x0680 -- Direccion de flash donde se comienza el codigo de la parte de emulacion,
#define ROM_SPACE_START 0x4000 -- Direccion de flash donde se almacena el codigo a emular
org 0x0800 --- Direccion donde se almacena la tabla con todos las opcode posibles.
¿ Y las rutinas que ponga en C, no machacarán esas direcciones ?, es mi duda principal la coexistencia de C y ensamblador a la hora de que el enlazador ubique el código.
Tambien el fuente en ensamblador usa parte de la flash para guardar el programa que debe de rodar el procesador emulado, pero eso lo hace cuando entra en modo Debug y recibe el archivo a grabar por RS232, igual que lo hace un bootloader, entonces borra las páginas de la flash correspondientes y lo graba.
A todo esto un americano me vende el procesador original CDP1802, fabricado por Harris, a 5 dólares la unidad, es un buen precio, pero mejor si lo puedo emular con un PIC, para no depender de futuras compras a USA. También ha creado unos kits para formación, basados en el COSMAC original de los 70, eso si que me puede interesar para comparar el funcionanmiento del emulado con el original.
-
¿ Y las rutinas que ponga en C, no machacarán esas direcciones ?, es mi duda principal la coexistencia de C y ensamblador a la hora de que el enlazador ubique el código.
Ahi ya no sabria como hacerlo, pero imagino que lo debe hacer automatico.
Y dejar el espacio reservado del codigo ROM para que no lo toque nadie o llenarlo de NOPs, otra no se me ocurre realmente. Pero no se como reservarlo sin tener que modificar el archivo del linker.
-
Me leeré en profundidad el manual del Linker Script, porque ahí se pueden hacer muchas cosas. Yo hasta ahora solo lo he utilizado para indicar la dirección de ubicación del código objeto en el firmware de un bootloader, y también para indicar la cantidad de Ram y Flash disponible y sus direcciones de inicio. Creo que también se pueden reservar bloques de memoria.
Otra cosa que se me ocurre es reubicar el ensamblador a partir de la siguiente página libre que deje el código objeto de las rutinas en C. Hago solo el programa en C, compilo, veo en que dirección termina, y reubico el ensamblador al principio de la página siguiente, algo parecido a lo que se hace con un bootloader y el firmware para que no se machaquen.
-
Mirando el manual del XC8 que ya pase creo que esto es lo que necesitas:
6.4.9.3 PSECT
Y copio y pego una parte que habla de eso:
5.12.3.3 ABSOLUTE PSECTS
Some of the information that is extracted from the initial compilation of assembly code, see Section 4.3.4 “Compilation of Assembly Source”, relates to absolute psects, specifically psects defined using the abs and ovrld, PSECT flags, see Section 6.4.9.3 “PSECT” for information on this directive.
MPLAB XC8 is able to determine the address bounds of absolute psects and uses this information to ensure that the code produced from C source by the code generator does not use memory required by the assembly code. The code generator will reserve any memory used by the assembly code prior to compiling C source.
-
Gracias, le echaré un ojo a eso de los PSECT.
Al final no se si necesitaré el C, porque con leer desde el programa principal en ensamblador el estado de tres puertos para ver como están puestos unos jumpers, el programa ya puede decidir que bloque de 4K tiene que usar el emulador como programa a ejecutar. Meteré 8 programas de 4K directos en la flash en el momento de programar el PIC, y con los jumpers que el programa decida cual usar.
El programa actual lo que hace es recibir por RS232 desde el PC, el programa que se quiere cargar, lo graba en la flash, y en el siguiente arranque el programa copia de la flash a una RAM externa, que es la que direccionará el emulador como lo hace el procesador original CDP1802. He contactado con el autor, un tío muy majo, para aclarar algunas dudas.
Lo que siempre me ha atraido bastante es lo de los emuladores de procesadores, tengo circuiterías viejunas que me vendría muy bien poder emular en micros modernos.
-
.
¿ KILLERJC sabes si es complicado llevar el programa originalmente hecho para un PIC18F4620 a un PIC18F67K90 o un PIC18F67K22 ?. Entiendo que necesitaría cambiar el p18f4620.inc por el correspondiente según el PIC que use, y creo que nada más. Bueno también quiero subir la frecuencia del oscilador, ese es uno de los motivos para cambiar de PIC, también disponer de más flash y tener más puertos.
Necesito cambiar el PIC por uno que tenga más de 40 pines, porque el diseño original tiene usados todos los puertos y quiero añadir unos jumpers para que el programa seleccione programas distintos de 4K a ejecutar por el procesador emulado, de esa manera podré tener varios programas en la misma flash, sin necesidad de actualizarla por RS232 o con una tarjeta SD.
Otra cosa, aunque supongo que si, pero como el ensamblador no es lo mío, ¿ a un programa en ensamblador para PIC18 (u otros PIC) se le puede hacer Debug ?, y que muestre los breakpoints sobre el fuente comentado.
-
No veo diferencias de set de intrucciones, asi que es posible.
Lo que si habria que verificar:
Registros si estan en las mismas posiciones. En caso que sea un dissasembler de un .hex
En caso que tengas el ASM, deberias cambiar el .inc y fijarte que no cambie ningun nombre de algun registro, si cambia te va a tirar error el compilador. Ademas tenes casi 78 registros mas de los que ya posee el PIC18, asi que puede que cambie las configuraciones de cada modulo tambien.
Tal ves agregar algo de configuracion si es que existe algun modulo que influya en el programa.
El tema de interrupciones, que puedan variar y que no admitan alta prioridad algunos y solo baja prioridad en un PIC y en otro. Eso hay que verlo. Tambien hay distintos registro para las interupciones parece.
Y fuses, oscilador si es que se tiene que configurar.
Si los modulos no varian no hay problema, si son distintos habra que adecuar el codigo al PIC nuevo.
Y Creo que otra cosa no deberia haber. Al menos son las que se me ocurren ahora xD
Otra cosa, aunque supongo que si, pero como el ensamblador no es lo mío, ¿ a un programa en ensamblador para PIC18 (u otros PIC) se le puede hacer Debug ?, y que muestre los breakpoints sobre el fuente comentado.
Si, asi como uno simula en C, en ASM se puede tambien, y va instruccion a instruccion y podes ver los registros del PIC, estos se ponen en rojo cada ves que cambia el valor. Doble click para poner un breakpoint sobre los numeros de linea.
Es igual igual a C.
Necesito cambiar el PIC por uno que tenga más de 40 pines, porque el diseño original tiene usados todos los puertos y quiero añadir unos jumpers para que el programa seleccione programas distintos de 4K a ejecutar por el procesador emulado, de esa manera podré tener varios programas en la misma flash, sin necesidad de actualizarla por RS232 o con una tarjeta SD.
Mi pregunta es.... tenes hecho en ASM como manejar la SD + FAT o directamente RAW? o lo tenes en C, compilado, es decir un .hex , ya no tenes mas el archivo fuente y por eso estas buscando hacerlo en ASM ?.
-
Mi pregunta es.... tenes hecho en ASM como manejar la SD + FAT o directamente RAW? o lo tenes en C, compilado, es decir un .hex , ya no tenes mas el archivo fuente y por eso estas buscando hacerlo en ASM ?.
Al final no voy a utilizar tarjetas SD, quiero que todos los programas queden almacenados en la flash del PIC, son programas de 4K, y creo que en total seran 8 como máximo.
Y como esa cantidad de programas nunca se van a ampliar, porque es para una tarjeta que va en máquinas fabricadas en los años 80, no tiene sentido crear un sistema de actualización bien por SD o RS232. Por eso descarto la necesidad de usar el C, solo tendré que modificar el ensamblador, para que lea los jumpers de 3 puertos, y según el estado de esos puertos cargue un programa concreto de 4K en una RAM externa para que el PIC ya emulando un procesador CDP1802 lo ejecute.
Al final me interesa poder cambiar a un PIC18 con más puertos para añadir jumpers de configuración, y no usar multiplexación con un par de flags del procesador original, con más memoria flash para cargar todos los programas y no tener que usar tarjetas SD o RS232, y con más velocidad para poder usar un cuarzo de 3Mhz que me permitirá que el emulador ruede a la misma velocidad que el procesador original. Según me comenta el autor del fuente en ensamblador del emulador, la frecuencia de reloj es cuatro veces la frecuencia a emular, eso lo dejaría en un máximo de 2.5Mhz x 4 = 10Mhz, y aplicando el PLL x4, quedan los 40Mhz máximo del PIC18F4620, pero como necesito que emule al procesador funcionando a casi 3Mhz (2,95Mhz), no me valdría ese micro, por eso he pensado en usar el PIC18F67K22 o K90, que llegan a 64Mhz.
En "fin Serafín", me tendré que liar con el ensamblador, me da una pereza terrible, desde el año 2001 que no lo toco.
-
.
He creado el proyecto en MPLAB-X y lo he compilado sin tocar nada, y me da estos errores, ¿ que el ensamblador tiene limitaciones en los nombres de etiquetas ?.
El caso es que el fuente se corresponde con un HEX que facilita el autor, por lo que entiendo que él lo compiló sin problemas.
¿ a que pueden ser debidos estos errores ?, son todos errores 151 Operand contains unresolvable labels or is too complex referido a las etiquetas RomImageStart y EmulationVersion. Lo que me extraña es que sin haber tocado todavía nada, de errores de compilación, no creo que sea porque falte el archivo inc, porque en ese caso tendría que dar un error sobre archivo no localizado a algo así.
(http://i1121.photobucket.com/albums/l518/xmen4001/ScreenHunter_005_zps2vodm54q.jpg)
(http://i1121.photobucket.com/albums/l518/xmen4001/ScreenHunter_006_zpsb88kct9x.jpg)
-
.
Ahora si que no entiendo ni "papa", lo compilo en MPLAB y no da errores, pero compilado desde MPLAB-X da los errores de etiquetas.
¿ alguna sugerencia de porqué compila en MPLAB y falla en MPLABX ?, me gustaría trabajar el proyecto con MPLAB-X, porque supongo que tendrá sus ventajas a la hora de hacer Debug.
(http://i1121.photobucket.com/albums/l518/xmen4001/ScreenHunter_008_zpshvcdgz1d.jpg)
-
.
Resolví el enigma en parte, gracias a este post del foro de Microchip, pero no entiendo todavía el porqué:
http://www.microchip.com/forums/m648727.aspx
Es algo relacionado con el modo en el que el ensamblador y el linkador ubican el objeto (relocalizable o absoluto), lo he cambiado a "Absolute Mode" en la configuración del proyecto y me ha compilado".
(http://i1121.photobucket.com/albums/l518/xmen4001/ScreenHunter_010_zpswvulyj8k.jpg)
-
Perdon por llegar tarde, ya veo que solucionaste el error
Creo que el primer paso seria modificar el codigo para que haga lo que queres con el PIC que ya esta hecho el programa, luego que lo simules, y si ves que anda todo bien, procedes a portarlo al otro PIC.
Al menos es lo que haria yo xD.
-
.
Tendré que ver como funciona eso de la simulación, porque no lo he utilizado nunca, siempre he trabajado con el Debug y el PIC real para depurar errores.
Modificar el código para el PIC original del proyecto no creo que pueda, porque me faltan puertos, esa es una de las causas de migrar a otro PIC, para tener más puertos a los que poder conectar unos jumpers para que el PIC cargue el programa a ejecutar por el emulador.
-
Fijate en las propiedades del proyecto, ahi tenes la opcion de ponerlo en Simulator
Entonces cuando pones debug el programa comienza a correr, ahi lo podes parar, dar pasos, etc, asegurate de ponerle aunque sea un breakpoint al comienzo en la parte de configuracion, asi cuando arranca para ahi nomas.
-
.
¿ Pero si el comportamiento del programa depende de señales exteriores que entran por los puertos, como se contempla eso en la simulación para que el programa haga lo que tiene que hacer ?.
-
En la simulacion o podes cargar los registros a mano, o podes modificar los pines (o puertos ya no recuerdo) con el panel de "Stimulus" o creo que tambien el Stimulus permite que incluyas archivos de texto con los valores que queres que entren a los registros.
Un poco complejo el tema para simularlo :P, Sino a ojo y debugearlo en fisico
-
.
Puede que la simulación me sirva para probar algunas cosillas, que no dependen de las señales externas que entran por los puertos, como por ejemplo la rutina inicial que lee la flash y graba a una RAM externa, si puedo tocar a mano el estado de algunos puertos para simular la configuración de unos jumpers.
He estado jugando un poco con la simulación, y no está mal, puede que me sea útil. Ahora me va a tocar leerme bien el manual del micro y algún manual de referencia de asembler, porque hace mil años que no lo toco, recuerdo cosas, pero la mitad me suenan a chino. Lo que si recuerdo es el famoso registro W, que vale para todo, o actua de intermediario en todas las operaciones.
El problema será como hayan cosas muy diferentes entre el PIC18F4620 y el que quiero usar para migrar, que sería el PIC18F67K22 o K90. Espero que en ese caso los errores salgan en tiempo de compilación, porque sino si que puede ser complicado.
-
.
Sigo con los inventos.
He intentado compilar el programa para un PIC18F46K20, tiene la ventaja sobre el origignal PIC18F4620, que el oscilador puede rodar más rápido, así podré poner un cuarzo de 3Mhz, que multiplicado x4 y otra vez x4, me da 48Mhz de señal de reloj que si admite el 46K20.
Cambio en el fuente el #include "p18f4620.inc" por #include "p18f46k20.inc", le doy a compilar y me da 3 errores, sobre estos 3 parámetros de la configuración, identifico el del oscilador y el del watchdog
CONFIG OSC = HSPLL
CONFIG BORV = 3
CONFIG WDT = OFF
Edito los archivos p18f4620.inc y p18f46k20.inc, y me encuentro que OSC lo cambian por FOSC, y WDT por WDTEN, ya son ganas de tocar los huevos, no podían haber dejado los nombres iguales, bueno los cambio y compilo ya sin los errores del oscilador y el watchdog.
Lo que desconozco por el momento es para que sirve BORV y que valor debo de poner, leyendo el contenido de p18f46k20.inc, me encuentro con esto, entiendo que en vez de 3, debo de poner 30, 27, 22 o 18, pero no se aún cual debo de elegir y porque
; Brown Out Reset Voltage bits:
; BORV = 30 VBOR set to 3.0 V nominal
; BORV = 27 VBOR set to 2.7 V nominal
; BORV = 22 VBOR set to 2.2 V nominal
; BORV = 18 VBOR set to 1.8 V nominal
En el INC del PIC18F4620, ponía esto, y en el fuente está seleccionado a 3:
; Brown Out Reset Voltage bits:
; BORV = 0 Maximum setting
; BORV = 1
; BORV = 2
; BORV = 3 Minimum setting
Sigo con el tema, a ver si consigo migrar el fuente del original PIC18F4620, a un PIC18 con más pines y más señal de reloj, de momento solo tengo por aquí un PIC18F46K20 para hacer pruebas, con este solo resolvería el problema de la señal de reloj, para poder trabajar con una señal de reloj más alta, imprescindible para poder emular al procesador CDP1802 en la placa original que lleva un cuarzo de 2.95Mhz.
-
El Brown Out es cuando por si algun motivo la tension de alimentacion baja mas del umbral que le das por un tiempo minimo (200us), por ejemplo 2.7V este ejecuta un Reset interno al PIC. El valor que vos creas necesario xD
Mientras que el 18f4620 eso no lo tiene, sino que no es "programable", solo revisando la parte de caracteristicas electricas aparecen los valores
BOREN1:BOREN0: Brown-out Reset Enable bits(2)
11 = Brown-out Reset enabled in hardware only (SBOREN is disabled) (2.1V)
10 = Brown-out Reset enabled in hardware only and disabled in Sleep mode (SBOREN is disabled) (2.79V)
01 = Brown-out Reset enabled and controlled by software (SBOREN is enabled) (4.33V)
00 = Brown-out Reset disabled in hardware and software (4.59V)
Mientras que el 18F46K20 si ya ademas de las opciones de arriba podes elegir el voltaje
-
.
Ok, gracias, ya entiendo, lo dejaré programado a 3 voltios.
Ahora lo que no me deja es hacer DEBUG, ¿ puede que sea porque el programa está usando todos los puertos, incluidos MCLR, y los puertos que llevan asignados PGC y PGD ?. Creo que PGC y PGD son necesarios para hacer Debug, y si el programa los utiliza como puertos RB7 y RB6, supongo que no será posible, MCLR no se si es imprescindible para el Debug
-
Yo estoy igual que vos de perdido con el debug, jamas lo hice en un PIC. Pero si, deberia tener un camino para hacerlo y creo que son los pines que vos mismo estas nombrando.
-
.
Le preguntaré al autor del software a ver si sabe algo, sino trataré de migrar el programa a un PIC con más pines y dejaré PGC, PGD y MCLR libres para hacer debug y programar con ICSP, porque el Debug si que lo necesito para ver que hace el programa cuando vaya añadiendo cosas, sino es ir a ciegas.
Yo creo que no será muy complicado migrar el código a un PIC18 con más pines, desconozco si el PIC18F67k22 tiene muchos más registros y si eso supone tener que hacer muchos cambios al fuente, o se mantiene la compatibilidad, me refiero al programa en tiempo de ejecución, porque en tiempo de compilación veo los errores y los puedo corregir, pero si compila bien y al rodar el programa empieza a hacer cosas raras, si que se puede complicar, sobre todo sin debug.
Ahora quiero ver como meto las roms dentro del PIC, si las paso usando el RS232 que tiene implementado el diseño original, si las meto en tablas en el fuente, o si grabo primero el HEX original, y luego grabo las ROM sin borrar la programación inicial, eso lo he hecho cuando traté el tema del bootloader.
-
.
El autor me ha respondido que él no ha hecho debug por hardware, ha empleado simulador y unos plugins que ha programado él mismo, ahora entiendo que no haya dejado libres PGC y PGD, que pienso son imprescindibles para hacer debug. Yo desde luego que prefiero el debug por hardware para probar cualquier diseño, no hay nada mejor y más fiable.
No importa, voy a migrarlo todo a un PIC18F67K22 o K90, paso de 40 pines a 64 pines y reloj de 40Mhz a 64Mhz, con eso ya puedo emular el CDP1802 como lo necesito, y habilitar el debug por hardware.
Como el 67K22 es TQFP, voy a diseñar la placa, aún a riesgo que de no funcione, porque es barata en los chinos y me resultará mucho más cómodo que andar con inventos raros llenos de cables.
El esquema ya lo tengo casi acabado, solo necesito cambiar unos CMOS 4013 y 4020 por chips TTL 74xx, porque el esquema original es todo compatible CMOS.
A veremos si me aclaro con el ensamblador, sobre todo con el tema de meter las rom en tablas en el fuente. Para monitorizar las señales de acceso a la RAM externa utilizaré el analizador lógico. Lo único malo es que pensaba que los PIC18 eran más baratos, juer si cuestan lo mismo que un PIC32, me sale más barato comprar el procesador original CDP1802 que emularlo en un PIC18, aunque emularlo tiene la ventaja de no tener que hacer pedidos a Estados Unidos, y no quedarme colgado el día en que se agoten los stocks de ese procesador prehistórico de los años 80.
Muy entretenido el ensamblador, pero es un auténtico tostón cuando has programado en C.
-
Muy entretenido el ensamblador, pero es un auténtico tostón cuando has programado en C.
Si es la desventaja que tiene. A mi me encanta el ASM, tambien me parece divertido, pero si me pongo a pensar en si alguien necesita ASM y ahi se me termino la emocion xD.. Todo lo haces con C y listo, no es suficientemente rapido? Usas otro micro mas rapido y en C, es mas barato que hacerlo en ASM y romperse la cabeza, ademas portable ( o portable con minimos cambios).
Y bueno, cualquier cosa que pueda ser de ayuda, por aca ando.
-
.
Me llegaron las muestras de Microchip, de todos los que he recibido voy a optar por usar el PIC18F67K90 en TQFP64, con 128K de flash y reloj a 64Mhz, duplico la flash y subo el reloj de 40 a 64Mhz, para poder emular el CD1802 a la señal de reloj original.
Va a ser entretenido esto del ensamblador, creo que si no hay diferencias en el juego de instrucciones y en los registros, no será nada dificil, lo único que me han parecido bastante caros estos PIC18. Va a quedar un plaquita muy maja para reemplazar a la original de los años 80 que está llena de chips raros que hace años que no se fabrican.
Y muy interesante lo de emular un procesador viejo usado un microcontrolador, a ver si del fuente aprendo algo sobre esto de la emulación. He visto por ahí que alguien ha emulado un Z80 con un PIC32, me interesa.