Publicado por: cucaracha en 22 de Octubre de 2004, 06:21:00
Codigo:
coloco en el código esto:
#asm
MOVFF PORTC,lectura[0]
NOP
MOVFF PORTC,lectura[1]
#endasm
Y el el archivo .lst veo esto:
.................... #asm
.................... MOVFF PORTC,lectura[0]
0A9E: MOVFF F82,212
.................... NOP
0AA2: NOP
.................... MOVFF PORTC,lectura[1]
0AA4: MOVFF F82,213
....................
.................... #endasm
Bien... si se fijan, por ejemplo el NOP ocupa la dirección 0AA2 y la siguiente instrucción está en 0AA4, osea, que me a puesto por la cara una posición de más. Osea, que traduciendo, es como si tuviera 2 NOP no?? Me equivoco?
Lo mismo con las instrucciones MOVFF (de los 18F). Estás son de 2 ciclos, sin embargo ahí pueden ver que ocupan 4 posiciones, osea, 4 ciclos.
Pero que pashaaa con esto
A ver que opinan... Tendré que volver al asm para esta aplicación....
Saludos!!
Publicado por: cucaracha en 22 de Octubre de 2004, 06:47:00
Ahora lo que hice fue abrie el hex con el maravillos Winpic800 y me fuí a la posición 0AA2 y... por esos luegares todo está a FFFF.
Vamos, que a partir de 83B ya todo es FFFF.
Ahora aun me lío más... osea, que eso no son posiciones??
Parece algo lioso ese archivo .lst
Vale que oculten porciones de código para proteger sus métodos... pero bueno, esta parte ya no está tan bien...
Sigo mirando...
Saludos!!
Publicado por: cucaracha en 22 de Octubre de 2004, 07:04:00
He abierto un .lst que tenía de un 16F84a, y veo que aquí si ocupa una posición por instrucción.
Luego he abierto el mismo para un 18F458 y aqui ya va 2 por instrucción. El doble en cada instrucción.
Raro, raro, raro...
Aunque luego, si abres el hex, en el 84 si que se corresponden como es lógico las posiciones, sin embargo, en el 458 parece que lo hace bien, aunque en el lst haya ese error.
Bueno, habrá que fiarse.....
Publicado por: Abago en 22 de Octubre de 2004, 09:35:00
Publicado por: MGLSOFT en 22 de Octubre de 2004, 14:25:00
Quejate despues porque la version currada te anda mal, je..je..
Publicado por: pikman en 22 de Octubre de 2004, 16:29:00
Bueno espero comentarios yo de momento no he podido seguir estudiando los problemas.
saludos
ARIEL/PIKMAN
pd CUCA, te envie un mail y no tengo respuesta, habeis recibido algo mio hace unos 15 dias.?
Publicado por: cucaracha en 22 de Octubre de 2004, 19:33:00
Un abrazo!!
Publicado por: gauchosuizo en 23 de Octubre de 2004, 03:14:00
lo que te puedo decir sobre el CCS es que ciertas funciones que trae, hacen un codigo de ASM muy grande o muy malo a diferencia del que harias tu. Por eso les aconsejo a todos a observar bien el codigo ASM que genera el CCS cuando se programa en C. Por ejemplo: Yo programe una interface SPI para un ADC y resulta que la funcion que trae el CCS tiene dos posibilidades de cuatro que existen para ajustar el CLOCK y la DATA line. Dicho rapido: tu puedes empezar con el CLOCK a "0" o a "1", lo mismo con la DATA line. Al final tuve que poner los Flags (banderas) justos a "mano", quiere decir que la funcion que tiene CCS no la utilize mas. Por estos problemas muchos programadores utilizan otros Compilers, que no tienen muchas funciones propias, sino que las tiene que programar uno mismo.
Aloha
Publicado por: wqtrp en 23 de Octubre de 2004, 07:29:00
me parece q la confusion puede venir del hecho de como maneja y/o explican en el manual el tema de la memoria
este es un chip de 16bits , con lo cual cuando hablan de un ciclo, siempre son 2 bytes, y la instruccion MOVFF ocupa dos ciclos que son eso 2 words o sea 4 bytes, el A9e, a9f,aa0 y aa1
luego viene el nop q es un ciclo=2 bytes, q son aa2 y aa3
y luego nuevamente el MOVFF q ocupa otros 4 bytes.
lo q pasa q nadie hace incapie en el "word aligment" q aqui es automatico, pero si te fijas bien veras q nunca una instruccion comienza en un byte impar, pq en realidad lo q tiene por ejemplo un f452 son 16K de flash (y no 32k) solo q son de una word o sea 2 bytes y le es imposible dividirlos.
reviso permanentemente q es lo q genera el CCS porque creo q es una manera de aprender un poco (los q hicieron este compilador seguro sabian un cachitin).
de cualquier manera tengo problemas con el "disasembler listing" del ccs ya q no representa todas las instrucciones y aun no le encuentro la manera de ver todo completo y ordenado.
Suerte
Publicado por: cucaracha en 23 de Octubre de 2004, 08:30:00
Fíjate por ejemplo en el lst que genera un 16F (de 14bits)... por tu regla debe de hacer lo mismo...
La memoria de programa no se organiza a nivel de bytes... sino que es de 14 o 16bits. Imagina una memoria RAM de 9 bit... que es un byte y luego otro del que sólo se toma 1 bit... no, son simplemente 9bits y su bus son de eso, de 9.
En el micro pues igual, y se organizan así, de 16 en 16. Luego el hará lo que vea con cada uno de esos bit... la parte alta será la instrucción y la parte baja el dato
Saludos!!
Publicado por: cucaracha en 23 de Octubre de 2004, 15:21:00
Ya por la duda he mirado el data y lo encontré...
Gracias por el dato... es exactamente eso...
Ahora lo que no entiendo es por qué no hace lo mismo con los 16F??
Saludos!!!
Publicado por: cucaracha en 23 de Octubre de 2004, 15:28:00
En los 16F por contra sí está organizada en 14bits, por eso en el CCS es una posición por instrucción (las de 1 ciclo claro).
Saludos y gracias!!!