TODOPIC
Microcontroladores PIC => dsPIC => Mensaje iniciado por: black_flowers en 10 de Febrero de 2007, 21:25:15
-
los dspic se pueden programar en asm? :-)
-
Claro que si! Pero vas a renegar probablemente 10 veces mas programandolo en asm.
Saludos
-
No sólo se puede, sino que es la base de todo lo demás. Los compiladores de C no hacen más que traducir el lenguaje C al lenguaje ASM para programar el micro.
Al igual que Bruno, opino que es mucho mejor programarlos en C porque en ASM currarás mucho más y no merece la pena, a pesar que un amigo mío catalán piensa justo lo contrario :lol:
-
Sera por que mis proyectos no funcionan en C :D , un dsPIC a 50MIPS parece un 16F84
Tardaras un poco mas , pero ten en cuenta que el c30 no optimiza muy bien que digamos y no aprovecha toda
la potencia que tienen estos vichos . Que verguenza .
EN "C" :
if(PORTBbits.RB0)
El C30 da este resultado al ensamblar .
00AF4 BFC2C8 mov.b 0x02c8,0x0000
00AF6 FB8000 ze.b 0x0000,0x0000
00AF8 600061 and.w 0x0000,#1,0x0000
00AFA E00000 cp0.w 0x0000
00AFC 320001 bra z, 0x000b00
Este resultado deveria ser este sin ningun impedimento :
btsc PORTB , #RB0
bra Z , es_cero
Otro ejemplo :
PORTBbits.RB0=!PORTBbits.RB0;
El C30 da este resultado al ensamblar . :D
00B00 EB0000 clr.w 0x0000
00B02 980710 mov.w 0x0000,[0x001c+2]
00B04 BFC2C8 mov.b 0x02c8,0x0000
00B06 FB8000 ze.b 0x0000,0x0000
00B08 600061 and.w 0x0000,#1,0x0000
00B0A E00000 cp0.w 0x0000
00B0C 3A0002 bra nz, 0x000b12
00B0E 200011 mov.w #0x1,0x0002
00B10 980711 mov.w 0x0002,[0x001c+2]
00B12 90402E mov.b [0x001c+2],0x0000
00B14 604161 and.b 0x0000,#1,0x0004
00B16 202C81 mov.w #0x2c8,0x0002
00B18 784091 mov.b [0x0002],0x0002
00B1A B3CFE0 mov.b #0xfe,0x0000
00B1C 60C000 and.b 0x0002,0x0000,0x0000
00B1E 704002 ior.b 0x0000,0x0004,0x0000
00B20 B7E2C8 mov.b 0x0000,0x02c8
Aqui ya es para echarse a llorar
En asm :
btg PORTB , #RB0 ; Bit Toggle f
A mi me gusta el C , pero cuando ves estas cosas pueee. :shock:
Haver si los de CCS pronto nos sorprenden .
suerte.
-
Que barbaridad!!! sabía q los compiladores C de Microchip optimizaban poco.. pero q es eso!?!? jjeje... Sisco estas usando la versión estudiante del C30?? te pego directamente de la página de Microchisss
Student Edition
The MPLAB C30 C Compiler Student Edition is free! It is full-featured for the first 60 days. After 60 days only optimization level 1 can be enabled in the compiler. The compiler will continue to function after 60 days, but code size may increase.
Quizá sea el tema de no aplicarle algún nivel de optimización??? Es que me resulta muy muy raro!
saludos! ;)
-
Esperemos que cuando hagan las revisiones oportunas para la optimización, no pase como el CCS que saquen versiones cada semana del C30.
Suerte!!! ;)
-
Hola, Sisco, hace tiempo que empeze con los DSPIC y uno de los motivos del abandono fue el C30, voy ha hacer algunas pruebas con hi-tech ahora ,creo que alguna razon de que esl status 'coming soon' de CCS con los dsPIC sea porque hay algo que no es sencillo y pretendan no tener los mismos resultados.
-
Bueennas:
Yo empeze hace unos 9 meses con la versión del 1.49 o algo así del c30 y desde entonces ya ha llovido, el primer problema que tuve es que no podía utilizar el modulo de la UART2 con las librerías, pero bueno... todo se soluciona, si no para que están los máquinas de este foro y el soporte tecnico de microchip, en ingles por supuesto. Ahhh se me olvidaba y las nuevas versiones del c30. :D
saludos,
-
Buenas,
Sispic:
Eso pasa sin optimizacion, con la optimizacion no te hace ese codigo (pruebas basicas, porque tambien he visto cosas raras con las optimizaciones en cuanto al uso de punteros y tengo que comprobar muchas cosas...)
El C es la carretera por donde ir, aunque a veces hay que cojer el atajo del asm para que algo funcione correctamente ;)
Un saludo,
-
En lo personal , para estos micros ya grandecitos también sugiero programarlos en C, pero "conocer" el assembler.
Mi experiencia en dspic es 0días, 0 horas, 0 minutos pero tengo basta experiencia con los 18F. Les puedo asegurar , como ya he dicho en algún otro post, que hacer un código que funcione en C18 me llevó unas horas, pero hacerlo óptimo y que se compile como si fuera hecho originalmente en assembler me llevó meses!
Codificar en C nos quita cierta complejidad pero nos obliga a conocer el compilador y la arquitectura si queremos hacer códigos óptimos. Uno viene del mundo de las computadoras personales (en adelante PC) donde sin darse cuenta desaprovecha montones de opciones de optimizar, que por una razón u otra se pierden en la nebulosa del software. Como la PC es rápida, tiene mucha RAM y disco duro y un sistema operativo entonces el programa corre rápido siempre (o al menos eso parece). Las cosas se comienzan a poner feas cuando queremos tirar un cálculo y nos lleva 3 horas hacerlo!! ahí vemos la necesidad de ver cómo hacer para que el proceso se ejecute más velozmente.
Con los pics y dspics pasa lo mismo, mientras que tengamos ram y rom y sin necesidad de velocidad, cualquier código funciona, pero cuando queremos velocidad y que ocupe poco espacio... bueno, ahí hace falta ya conocer la arquitectura, conocer el assembler y conocer cómo funciona el compilador.
Como dije antes, no he usado el C30 pero sí el C18 y según leí en el foro de Microchip son bastante parecidos en muchos aspectos por lo cual tal vez el pequeño consejo sirva para ser aplicado a los dspic.
Cuando tenga mis dspics veré que tan cierto fueron estas palabras :)
-
Opino como tu Maumix.
Y sobre hacer un código que funcione en C18 me llevó unas horas, pero hacerlo óptimo y que se compile como si fuera hecho originalmente en assembler me llevó meses!
Comentario ironico 1 = Entonces hazlo directamente en assembler y te ahorras las primeras horas :o
Comentario ironico 2 =
Ademas no usamos un dsPIC por su cara bonina , lo usamos normalmente por que necesitamos velocidad .
O quizas.. ya see : por que compilamos con c18 y ya nos llena la flash con 4 operaciones con in32.
Entonces nos pasamos al C30 y... boyla , ya nos cave , pero va la misma velocidad que un 18F . umm
Buena tecnica de Microchip para vender micros mas rapidos . :D
Bromas aparte , es que ademas por mucho c optimizado nunca aprovecharemos toda la potencia .
un ejemplo , asi no me hago pesado :
Copiar una zona de memoria a otra . un array a otro
for( a = 0; a < 50; a++) origen[a] = destino[a];
00AF4 EB0000 clr.w 0x0000
00AF6 884040 mov.w 0x0000,0x0808
00AF8 804041 mov.w 0x0808,0x0002
00AFA 200310 mov.w #0x31,0x0000
00AFC 508F80 sub.w 0x0002,0x0000,[0x001e]
00AFE 3E000D bra gtu, 0x000b1a
00B00 804040 mov.w 0x0808,0x0000
00B02 D00000 sl.w 0x0000,0x0000
00B04 2081A2 mov.w #0x81a,0x0004
00B06 400082 add.w 0x0000,0x0004,0x0002
00B08 804040 mov.w 0x0808,0x0000
00B0A D00000 sl.w 0x0000,0x0000
00B0C 2087E2 mov.w #0x87e,0x0004
00B0E 400002 add.w 0x0000,0x0004,0x0000
00B10 780890 mov.w [0x0000],[0x0002]
00B12 804040 mov.w 0x0808,0x0000
00B14 E80000 inc.w 0x0000,0x0000
00B16 884040 mov.w 0x0000,0x0808
00B18 37FFEF bra 0x000af8
852 ciclos
En asm :
mov #_origen , w0
mov #_destino , w1
repeat #50
mov [w0++],[w1++]
53 ciclos
No creo que el C estandard tenga comandos para operar con eso que yo sepa .
togarha , seves como se hace para que optimice ?
-
Lo logree!!!
:-/ :-/ :-/ :-/ :-/
Programe mi primer dsPIC ICSP e hice parpadear un led!!
Gracias especiales a Manolo.
-
Sisco, no eres pesado, creo que tu opinión y aporte ejemplificador vale y mucho, pero creo que hay ciertas cosas en que un compilador no puede 'adivinar' tanto, aunque también es cierto que deben hacerse mejoras. Con adivinar me refiero a que no siempre se puede saber si el código irá en un lado u otro.
Está más que claro tu ejemplo y no lo puedo refutar porque como dije antes no he usado el C30 pero lo que sí puedo decirte es que a veces, algunas operaciones se pueden hacer en una forma u otra. Tal vez si usaras punteros en tu código no tardaría tanto en ejecutarse, lo digo porque me ha pasado en C18, :)
Con decir que hay que saber cómo funciona el compilador, precisamente es para atacar este tipo de problemas. Por ej, solo algunas cositas: las variables si son declaradas como estáticas para que no ocupen lugar en el stack se acelera la ejecución, sobre todo cuando se las usa como parámetro por referencia. También se le puede indicar al compilador en qué banco están las variables y de esa forma el código generado también es menor. Usar punteros siempre que sea posible.
Yo debí cambiar mi forma de codificar para que el código se ejecute más rápido y para que no ocupe tanto espacio en memoria de programa. Donde antes ponía un arreglo, lo cambié por un puntero y cosas por el estilo.
En los IF, por ejemplo, pongo primero siempre la condición que creo que se dará primero como falsa con eso tengo más chances
de que mi código ejecute más rápido.
Y bueno, como ese hay cientos de truquitos.
Es cierto que cada vez hace falta un micro más potente pero también es cierto que de seguro también se hacen cosas más complejas! :)
Además un dspic, por 25 unidades está en unos 7 dólares, tampoco es la gran cosa 8)
Bruno, te felicito! siempre es lindo dar esos primeros pasos. Ya te imagino, poniéndole un microforo :lol:
Yo ansío recibir mis dsPIC que parece los trae la abuela de la tortuga manuelita. :8} :8} :8}
-
Hola, Sisco, hace tiempo que empeze con los DSPIC y uno de los motivos del abandono fue el C30, voy ha hacer algunas pruebas con hi-tech ahora ,creo que alguna razon de que esl status 'coming soon' de CCS con los dsPIC sea porque hay algo que no es sencillo y pretendan no tener los mismos resultados.
coincido con pikman, no importa si pasan uno o dos años mas, la espera será recompensada siempre y cuando los bug´s sean eliminados :)
Salu2
Pedro
-
Me he permitido la libertad de renombrar el tema en vista de la deriva que ha tomado el hilo y que el título original era genérico.
Enhorabuena, Bruno, ya sabía yo que no tardarías en conseguirlo.
-
Buenas,
Tienes razon sispic, yo tambien he puesto que el asm te lleva al atajo (es decir, a hacerlo todo un poco mas facil), pero tambien es verdad que hay que saber como se hacen las cosas de manera un poco mas facil. Por ejemplo, lo mismo que tu has querido hacer es mucho mas sencillo sin necesidad de usar ningun tipo de optimizacion:
Viva la funcion: memcpy
--- c:\pic30-build\build_20061107\src\standardc\sxl\memcpy.c -----------------------------------
00280 780180 mov.w 0x0000,0x0006
00282 E00002 cp0.w 0x0004
00284 320003 bra z, 0x00028c
00288 E90102 dec.w 0x0004,0x0004
0028A 3AFFFD bra nz, 0x000286
00286 7859B1 mov.b [0x0002++],[0x0006++]
0028C 060000 return
Esta en la libreria del C30, tampoco usa demasiados ciclos (esta claro que mas que el asm), pero no esta del todo mal, y no tienes que seguir tanto hilo de programa, que cuando tienes 60k de codigo, pues en asm es MUYYYYY tedioso...
Un saludo,
-
Por cierto, el mismo codigo que has puesto tu, con optimizacion:
17: for( i = 0; i < 5; i++) a = b;
00318 EB4100 clr.b 0x0004
0031A FB8002 ze.b 0x0004,0x0000
0031C D00000 sl.w 0x0000,0x0000
0031E 5780EA sub.w 0x001e,#10,0x0002
00320 788260 mov.w [0x0000+0x0002],0x0008
00322 5001F4 sub.w 0x0000,#20,0x0006
00324 7FB184 mov.w 0x0008,[0x0006+0x001e]
00326 E84102 inc.b 0x0004,0x0004
00328 514FE4 sub.b 0x0004,#4,[0x001e]
0032A 36FFF7 bra leu, 0x00031a
Que sigue sin estar optimizado, pero es menos de la mitad que el anterior...
Siempre que se quiera usar velocidad hay que usar asm, pero un programa no tiene porque necesitar velocidad en todas las funciones. Cuando se quiera hacer cosas criticas es mejor morir a asm siempre, pero cuando la velocidad no sea importante, es mucho mas comodo el C...
Un saludo,
-
Tienes razon mientras funcione . :lol:
Por cierto como haces para que optimice .
-
Buenas,
En las opciones de compilacion del proyecto, en la parte del C30 hay una lista desplegable en que la ultima opcion es optimizacion (es la version comercial, no se si en la version de estudiante tambien existe...)
Un saludo,
-
Ja! Estaba buscando sobre optimización de C30 y encontré estos comentarios. Porque es tan horrible el código generado por C30? :8} No entiendo porque para borrar una variable carga 0 en W0 y luego lo transfiere :shock: Modifico la configuración de la optimización del proyecto y deja de funcionar :shock:
No hay nada como el assembler! :D :D :D
Saludos!
-
ajá entonces el C30 también tiene bugs...
CCS ya puede dormir tranquilo :D