Compatibilidad ensamblador entre familias de PIC

[KILLERJC]

¿ 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.

[planeta9999]

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.

[KILLERJC]

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.

[planeta9999]

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.

[planeta9999]

.

¿ 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.

[KILLERJC]

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 ?.

[planeta9999]

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.

[planeta9999]

.

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í.

[planeta9999]

.


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.

[planeta9999]

.

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".

[KILLERJC]

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.

[planeta9999]

.

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.

[KILLERJC]

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.

[planeta9999]

.

¿ 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 ?.

[KILLERJC]

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 , Sino a ojo y debugearlo en fisico