Duda con código que genera el CCS

[cucaracha]

A ver... estoy mirando el código que genera el CCS en una porción de asm que he incluido y vean:

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!!

[cucaracha]

Sigo investigando...

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!!

[cucaracha]

vaya, vaya vaya....
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.....

[Abago]

Cuca... Estás haciendo una auditoría al compilador de CCS????

[MGLSOFT]

Si,Si!!
Quejate despues porque la version currada te anda mal, je..je..

[pikman]

Hola CUCA Y MARCOS, pues yo he tenido una muy mala experiencia con los pic18F y CCS o es lo que dice MARCOS que la version Tool FREE o DEMO no sirve para estos o no sirve directamente, pero que no anda no anda, no solo lo que tu dices los retardos hacen cualquier cosa, pero cualquier cosa eH?:

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

[cucaracha]

Pues no... no recibí nada... Envíalo de nuevo.

Un abrazo!!

[gauchosuizo]

hola Cuca

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

[wqtrp]

hola cuca, creo q con respecto a tu pregunta original, lo q hace el compilador es lo correcto,
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

[cucaracha]

Creo que la cosa no va así...
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!!

[cucaracha]

Vale amigo... levas más razón que un santo
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!!!

[cucaracha]

Ok... todo aclarado...
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!!!