TODOPIC
Microcontroladores PIC => Almacén del Assembler => Mensaje iniciado por: MLO__ en 16 de Mayo de 2008, 23:14:14
-
Hola muchachosT
Tengo una duda con respecto a pasar de codigo C a ASM.
Uno puede ver el codigo en ASM con el Diassembly Listing despues de haber hecho el programa en C, pero: Es posible compilar en ASM el codigo generado por el Diassembly Listing???
Hice una prueba y me genera un error con el Linker ( Adicione al codigo generado por el Diassembly el p=18F452 y el #include ... y el org 0x00 y el END, ademas de quitar lo que no es ASM )
Necesito ayuda con eso por favor.
Gracias.
Saludos
-
Saludos MLO!
Mira debería funcionarte... sólo que hay algunos detalles que deberías corregir... porque CCS genera un asm pero con una nomenclatura un poco peculiar... por ejemplo, los registros de bancos 1 en adelante los enumera otra vez desde 0...
Y otras cosillas como por ejemplo "btfsc 03.2" que en realidad sería btfsc 03,2...
Bueno seguramente eso ya lo sabías... de todos modos me parece interesante tu planteamiento... si quieres sube el .lst y en lo que tenga un chance lo pruebo...
Ok nos leemos! :mrgreen:
-
Hola firepic y MLO_. El archivo C/ASM es un archivo con formato .lst y no con formato .asm, quiere decir que solo sirve para la lectura. Es muy dificil sino imposible para el compilador volver a armar el C a partir del assembler, pues este solo fue construido para generar bloques frefijados de código assembler a partir de un lenguaje C y cambiar alguna instrucción dentro de esos bloques de assembler conlleva a que el compilador ya no pueda representar al mismo por una instrucción especifica en C. Si, los bloques de código assembler que generan las instrucciones C son muy flexibes y CCS puede adaptarlos a cada programa segun lo requiera, pero siguen siendo una correspondencia no biunivoca y no univoca, es decir, cada instruccion de C representa un conjunto dinámico de lineas en asm, pero no toda instruccion en asm puede representarse por una instrucción en C ni por un conjunto de instrucciones de ese lenguaje. Por lo tanto, la operacion inversa no esta permitida.
Lo que puedes hacer es utilizar el mplab para compilar el C como asm y luego trabajar con el asm para darle los toques finales (No modifiques el asm hasta estar seguro de que ya has programado todo lo posible en C, pues no hay vuelta atras). Otra forma que se utiliza muchisimo y que es la mas legible en cuanto a mantenimiento del código es colocar el código en asm dentro del código en C, esto se puede hacer en CCS mediante la declaración #ASM.
Saludos.
-
Saludos Dr. Gonzalo!
Bueno pues yo nunca quise hablar de pasar ASM a C, si le entendía bien a MLO, creo que eso tampoco es lo que él quiere....como tú bien lo dices es casi que imposible...
Si bien el archivo que genera ccs es .lst y no .asm, éste contiene el código asm por cada instrucción de c... lo que yo pensé es que acomodando ese código asm podría ser compilado por un compilador de assembler (y valga la redundancia), como el mpasm... en lo que tenga un rato de ocio voy a tratar de probarlo con un código sencillo de c.. y a ver qué pasa.
Es decir, pasar de C a ASM; de ASM a C nunca! :shock:
Ok nos leemos! :mrgreen:
-
Hola amigos.
Pues, hice la prueba con un micro 16F en el que enviaba una cadena por el serial y me ha funcionado. Eso si, tuve que incluir algunas cosillas como el list p, el #include, el END, los org respectivos y compilo normal. PERO!!!! (siempre hay un pero en esto) el problema radica en que si adiciono archivos en el LKR, me genera el error en el Linker!!!! Es decir, si no coloco el archivo .lkr del respectivo micro en el proyecto, compila bien, pero si lo adiciono, genera error en el Linker.
No se si tenga que ver con que CCS no es ansiC y tiene sus propios archivos .h para configurar las caracteristicas del PIC.
Si alguien me explica...... gracias.
Saludos :)
-
MLO__ realmente me parece un trabajo aterrador el que mencionas :shock:
imagina mirar todas las SFR en sus direcciones, los saltos , las etiquetas, todos son numeros que enredarian. Sin mencionar que tendrias que reacomodar todo el listado para que al final te compile el código
-
Tienes razón palitroquez...
Un trabajito para tiempos de ocio... :D
Nos leemos! :mrgreen:
-
Si, realmente, opino exactamente igual que palitroquez, no le veo practicidad al metodo, tal vez con un 16F pueda hacerse, pero uno no puede andar modificando el .asm de un 18F, es un trabajo casi insoportable si tienes que hacerlo, hay que trabajarlo en C y si llegado el caso necesitamos hacer alguna operación en particular que CCS no la contemple podemos incluir el pedazo de asm en el archivo .C.
Buen trabajo de todas formas por lograr compilar el .lst.
Saludos.
-
Uno puede ver el codigo en ASM con el Diassembly Listing despues de haber hecho el programa en C, pero: Es posible compilar en ASM el codigo generado por el Diassembly Listing???
Si, es perfectamente posible.
porque CCS genera un asm pero con una nomenclatura un poco peculiar... por ejemplo, los registros de bancos 1 en adelante los enumera otra vez desde 0...
No es peculiar, es así como es el assembly en el micro. Algunos usan por ejemplo 0x80 para direccionar el primer registro del banco1 pero eso carece de efecto al ensamblarlo ya que el registro que contendrá ese valor tiene solo 7 bits, con lo cual poner 0x80 es igual a poner 0x00. Por ello están los bits RP0 y RP1.
No hay forma luego de ensamblar de que al volver para atras, tengas de nuevo el 0x80, no en forma directa, salvo que uses algún código que analice que encendiste los bits RP0 y RP1 antes de esa línea, pero esto puede ser engañoso si es una subrutina que es llamada desde varios lugares :)
PERO!!!! (siempre hay un pero en esto) el problema radica en que si adiciono archivos en el LKR, me genera el error en el Linker!!!! Es decir, si no coloco el archivo .lkr del respectivo micro en el proyecto, compila bien, pero si lo adiciono, genera error en el Linker.
No se si tenga que ver con que CCS no es ansiC y tiene sus propios archivos .h para configurar las caracteristicas del PIC.
No se como será el CCS en esta parte pero tal vez no necesites el .lkr para ese compilador. El MPLAB IDE es una herramienta genérica y sus proyectos también , entonces el hecho de que te deje incluir un archivo .lkr no significa que el compilador y linker que uses, lo vayan a usar.
El C18 sí hace uso del linker file y debes incluirlo.
MLO__ realmente me parece un trabajo aterrador el que mencionas :shock:
imagina mirar todas las SFR en sus direcciones, los saltos , las etiquetas, todos son numeros que enredarian. Sin mencionar que tendrias que reacomodar todo el listado para que al final te compile el código
Jaja, coincido totalmente.
En lo personal a veces suelo analizar el assembly generado pero para ver cómo optimizar mi código en C. Es común que por ejemplo un if ordenado de una forma y de otra no produzcan el mismo código.
MLO__ creo que debes aclarar bien para qué quieres hacer todo esto, ya que tal vez te estes haciendo demasiado problema sin necesidad. Otra forma, es que estando en el MPLAB IDE, si vas a View/Program Memory luego puedes Exportar eso a un archivo de texto. Allí tienes el código también en assembly.
Saludos
Pasar de ASM a C no es imposible, siempre hubo herramientas que hacian cosas por el estilo para PC y es factible que las haya o las pueda haber para microcontroladores PIC . Les dejo un ejempo MicroApl (http://www.microapl.co.uk/Porting/intro.html)
-
Hola
Pues si, deberia indicar porque estoy haciendo todo ese paseo. Pues me han pedido el codigo fuente de una aplicacion que hice y ademas el ASM ( el ing. tec. de la empresa no maneja C ) y me ha tocado arreglar el .list ( que no es tarea facil !!!!) y claro, toca hacer la prueba de que compila!!!!
Pues la prueba con el 16 ha salido bien, pero con el 18 no me fue tan bien, me genera muchos errores y estoy que mando todo para el .... bueeee.
Compare los .hex generados por la compilacion en C y la compilacion en ASM y solo se parecen en los 2 primeros renglones el resto es diferente y no corre en proteus. :( :( .
Gracias por todas las ayudas.
-
Je, que extraño te debiera dar exactamente lo mismo salvo que los amigos de CCS no saquen toda la info al archivo .lst que es necesaria.
Yo que tu no me la complico, si eso es lo que necesitas, porque no generas el archivo .HEX con el compilador y luego desensamblas el .HEX?
El Winpic800 te permite hacer eso, el MPLAB también. Busca en el foro como desensamblar y verás la respuesta! :)
Saludos
-
Saludos!
Maestro Maunix, gracias por tus explicaciones, tan claras como siempre.
Ey MLO, me parece muy bueno eso de desensamblar el .hex generado por el ccs... mucho más fácil! :D
Ok nos leemos! :mrgreen:
-
PD// Solucion: Insistir a que el ing. se apasione por el C y reciba el codigo fuente en C!!! :mrgreen: pero esta muuuy dificil!!!! :D
Ya sabes como dicen las malas lenguas MLO, "el que sabe ... sabe y el que no, es jefe!!!!!!" :D :D
Siempre tuve el presentimiento de que mis empleados la usan muy a menudo :D :D :D por algo será.
Saludos.
-
:D :D :D
Muy buena esa Dr. Gonzalo!
Ese refrán como que es internacional no? :D
-
:-/ :-/ :-/ :-/
Manos a la obra !!! a desensamblar se ha dicho !!!!!
mucho mejor
Y no Gonzalo :D :D !!!! el que sabe sabe y ya ( al menos en tu caso aplica ) :D :D !!!! los jefes son los jefes :roll: jajajaja Menos mal el ing no es mi jefe, si no ya me hubieran hechado!!!!, porque ya llevo mas de una semana y bueeee...... :D :D
Saludos
-
... Pues me han pedido el codigo fuente de una aplicacion que hice y ademas el ASM ( el ing. tec. de la empresa no maneja C ) ...
pero pedido es pedido)
...
haberlo dicho antes MLO__ 8)
De todas formas suerte con el cometido que te has propuesto y velo por el lado positivo: por lo menos agarras práctica a la hora de reconocer los registros de proposito generales
... tal vez con un 16F pueda hacerse, pero uno no puede andar modificando el .asm de un 18F, es un trabajo casi insoportable si tienes que hacerlo, hay que trabajarlo en C y si llegado el caso necesitamos hacer alguna operación en particular que CCS no la contemple podemos incluir el pedazo de asm en el archivo .C.
...
yo creo que sería al contrario, con un 18F seria mas fácil.
siempre he leido que con los 18F es mas dificil progranmar en asm, en mi corta experiencia, no lo he visto así. Pongamos el ejemplo de la posibilidad de omitir el direccionamientos de bancos.
puede que salga un rebuzno, pero el que los 18F traigan mas instrucciones no implica dificultad, esto lo asumo por llamada compatibilidad ascendente, el cúal toma las mismas instrucciones de las serie 16F (de hecho los 18F traen unas instrucciones que son una bendición en comparación con los anteriores).
-
Hola amigos
Pues ha sido mas sencillo con la opcion del MPLAB que propuso maunix. Lo que si hay que hacer es organizar muy bien todo para que compile.
PalitroqueZ, la verdad programe en ASM cuando estaba en la U y era sencillo con los 18 ya que no habia que cambiar de banco a cada rato como en los 16 asi que comparto tu nocion, pero ya estoy tan amanado al C que no lo cambio, aunque esto involucre aumentar en algo el peso del archivo .hex
Saludos y gracias. :-/
-
Interesante punto de vista Palitroquez, la verdad que yo siempre programo los 18F en C y he visto poco el ASM que generan, puede que los halla visto mas complejos por el simple hecho de que en general los programas que hice en los 18F fueron mas complicados que en los 16F. Uno a veces encuentre respuestas realmente utiles cuando no las espera y no cuando las busca :-/ :-/ :-/.
Saludos a todos.
-
Pues ha sido mas sencillo con la opcion del MPLAB que propuso maunix. Lo que si hay que hacer es organizar muy bien todo para que compile.
Pues me alegro que te haya servido,ya veras que este foro es muy participativo , con varios aportando diferentes sugerencias a un mismo tema/problemática y luego tu o quien sea que preguntó elige la que le parece mejor y listo.
La permanencia de las preguntas en el foro permiten que otros usuarios con dudas similares salgan beneficiados de lo mismo incluso a pesar de no haber preguntado del tema, siempre se puede aprender algo, pequeñas cositas, trucos, caminos más cortos para llegar a lo mismo, etc.
En cuanto al ASM del 18F y del 16F, conozco ambos y debo decir que es cierto que el 16F es más fácil de entender, lo cual no significa que hacer programas complejos con el 16F sea más fácil que con el 18F. La arquitectura de los 16F también es más simple, su set de instrucciones más reducidos etc, pero los 18F son muuucho más potentes y de comenzar con los PICs yo comenzaría con los 18F sin dudarlo.
Como bien dió a entender Palitroquez los 18F tienen muchas más opciones y permiten con menos instrucciones lograr lo mismo que con un 16F se deben hacer con varias y desarmándose el cerebro jeje. Pero bueno tantas opciones pueden marear cuando no se las conoce y por ello el iniciarse programando en ASM para los 16F es más simple.
Saludos
-
Bueno ahí tienes la respuesta de Mauricio que ha trabajado el asm mas que yo. :)
.. pero ya estoy tan amanado al C que no lo cambio, aunque esto involucre aumentar en algo el peso del archivo .hex
...
igualito. Soy un adicto al c y a menos que la ocasión me obligue a cambiar, seguiré resteado con el c
resteado: fiel seguidor
-
Saludos!
Ey palitroquez está muy bueno tu definición de las palabras coloquiales venezolanas... :D
Nos leemos! :mrgreen:
-
Hola muchachos.
Pues gracias por todo, ya casi no ha dado problema.... sin embargo el trabajo de organizarlo es muuuuy monotono ( copiar, pegar, copiar, pegar ....... :D ) menos mal esta excel!!!!
Por ahi me entere de que existen programas en pasar de C a ASM y me dieron un nombre: PICC++, he intentado buscarlo en la internet, pero no he encontrado nada de nada :( si alguien lo ha trabajado o sabe algo de este SW avisenme ok?
Y si maunix, es lo bacano de estos foros ( sobre todo de este!!!!! ) que hay muchas respuestas de todo tipo y eso le da la ventaja a uno de poder escoger o probarlas tooodasss!!!!! ademas las respuestas son rapidas y se nota el interes por colaborar.
Saludos amigos
-
No sé si te he entendido bien, pero para pasar de C a ASM lo que se necesita es un compilador :?
-
Por ahi me entere de que existen programas en pasar de C a ASM y me dieron un nombre: PICC++, he intentado buscarlo en la internet, pero no he encontrado nada de nada :( si alguien lo ha trabajado o sabe algo de este SW avisenme ok?
El PICC es el compilador de Hitech (http://www.htsoft.com/)
Es como te dijo Manolo, un compilador generará con el linker el .hex el cual a su vez puedes abrir fácilmente para tomar de ahí el asm generado.
Si usas ccs no necesitas el PICC (aunque este último es mejorcito, al menos desde mi punto de vista).
-
Saludos!
Acabo que el ccs tiene la opción "disassembler"... la acabo de probar y parece funcionar bien, tomando el .hex como dice maunix.
Será que le servirá eso a MLO? :?
Ok nos leemos! :mrgreen:
-
Hola.
Pues tambien lo probe firepic. Pero como acostumbro a trabajar en el IDE del MPLAB entonces lo hago mejor alli.
Entonces, resumiendo ....... me estaba complicando la vida!!!!! :D :D es cuestion de compilar el codigo en C ( ya sea en CCS o C18 .... ) importar el .hex y verificar el Program Memory, luego, anadir el inc del pic, darle la referencia del org y colocar end al final del codigo para poder compilarlo otra vez ( esta vez en ASM ) y verificar que el nuevo .hex generado corresponde al .hex generado por el compilador de C.
Estoy probando con codigos simples antes de meterme a organizar el codigo largo. Ya comentare los resultados.
Manolo: Lo que intento hacer es generar un codigo fuente ASM desde C, para poderlo compilar nuevamente y que genere el mismo .hex generado por la compilacion del codigo en C.
Gracias por la preocupacion amigos!!!!!!! :-/
Saludos
-
Si coges cualquier HEX y lo desensamblas con Winpic800 te dará un código ASM compilable y convertible en el mismo HEX.
-
Hola Senor Nocturno :mrgreen:
Es lo mismo que con el MPLAB tal y como me mensionaron antes cierto?
Yo puedo guardar ese codigo en otro archivo .asm, luego abrir un nuevo proyecto y compilarlo y ya? Porque lo que hago es "adicionarle" algunas cosillas para que se parezca a un codigo fuente en ASM.
Saludos
-
Pues si te digo la verdad no lo he probado, pero estoy seguro que tú lo harás :D
-
:-/ :-/
Pues ha funcionado de maravilla con programas pequenos!!!!! y en pic 16, pero :( :( en el programa largo de un micro 18F442 me salen los siguientes errores:
Executing: "C:\Archivos de programa\Microchip\MPASM Suite\MPAsmWin.exe" /q /p18F442 "main.asm" /l"main.lst" /e"main.err"
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1621 : Argument out of range (FF6E not between FF80 and 007F)
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1627 : Argument out of range (FBD1 not between FC00 and 03FF)
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1665 : Argument out of range (FF62 not between FF80 and 007F)
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1725 : Argument out of range (FF61 not between FF80 and 007F)
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1737 : Argument out of range (FF61 not between FF80 and 007F)
Error[126] D:\ACCES\PIC18\ASM\MAIN.ASM 1780 : Argument out of range (FF69 not between FF80 and 007F)
Halting build on first failure as requested.
BUILD FAILED: Fri May 23 10:18:55 2008
y hacen referencia a las siguientes partes del codigo generado (respectivamente):
BC 0xca8
RCALL 0x57a
BNC 0xd00
BNC 0xd7a
BC 0xd92
BC 0xdf8
No entiendo muy bien el error, traduciendo literalmente implica que el valor que ahi se coloca no esta en el rango, lo raro es que no corresponde el numero asignado al numero que aparece en el error, es decir, tomando como ejemplo el primer error: el numero que debe aparecer en el primer error deberia ser 0xCA8 y no FF6E ???
Gracias por la ayuda.
Saludos
-
BC , RCALL etc. son saltos relativos .
quizas hayas sacado partes del codigo que no existen
-
:shock: :shock: :shock: :shock: :shock:
Que no existen ?????? quede loco!!!!!
Lo que hice fue importar el archivo .hex y abri la ventana del "Program Memory", exporte el codigo a un archivo externo de texto y luego le quite lo que no servia. Como es posible que hallan esas directivas falsas????? no entiendo. Si quito esas lineas ......... sera que funciona??? voy a probar y vemos ... Gracias Sispic
Saludos
-
puedes usar un truco
0x0000 : 0xEF22 goto 0x000044 ; 1st word
0x0002 : 0xF000 ; 2st word
0x0004 : 0x6AEA clrf 0xEA , ACCESS
0x0006 : 0x0E0C movlw 0x0C
0x0008 : 0x6EE9 movwf 0xE9 , ACCESS
0x000A : 0x50EF movf 0xEF , W , ACCESS
0x000C : 0xE00F bz 0x2C
0x000E : 0x0E01 movlw 0x01
0x0010 : 0x6E01 movwf 0x01 , ACCESS
Label_0x0012: clrf 0x00 , ACCESS ************
0x0014 : 0x2E00 decfsz 0x00 , F , ACCESS
0x0016 : 0xD7FE bra 0x14
0x0018 : 0x2E01 decfsz 0x01 , F , ACCESS
0x001A : 0xD7FB bra Label_0x0012 **********
fijate donde estan los asteriscos
Aunque tambien existan otros programas que desasemblen con mas clarida , winpic800 solo es para hecharle un vistazo y es engorroso de copiar y modificar
-
Ok
Gracias Sispic, me pongo en la tarea de probarlo.
Saludos