Qué conclusiones esperas obtener de una prueba como la que has puesto? escribir el código en c y compilarlo, ver cuál obtiene menos instrucciones? cuál necesita menos memoria? cuál lo ejecuta más rápido?. Tb influye el complilador que usemos al hacerlo de esta manera.

Yo llevo un tiempo pensando en hacer lo mismo que propones, y para ello me he decidido a hacer otro robot como el miniz (lo hicimos con un pic 18f, 16f) esta vez con un ATmega 64. Estuve pensando en que tipos de pruebas hacer, pero al final me he decidido por un diseño completo a ver que diferencias salen de uno a otro.

De momento sólo me he leído un par de libros de c para atmel, y ahora ando intentado hacer la placa del micro.

Éste es el último que he leído http://www.amazon.com/Embedded-C-Progra ... 358&sr=8-1 y me ha gustado, a mi me ha venido bien ya que no conocía de nada los micros y me ha resultado entretenido leerlo. Si anda por el emule bajadlo que merece la pena, la pega es que no usa el winavr.

Mi idea básicament es transmitir que el funcionamiento de sistemas con múltiples acumuladores es más eficiente. Y también más 'C friendly'.

Por eso, en realidad lo que me interesa es el ensamblado, no el C. Yo he puesto el código fuente en C porque programo los AVR en ese lenguaje, y no domino el ASM. Pero en realidad lo que pretendo comparar es el ASM.

Básicamente, lo que quiero ilustrar es que con un sólo acumulador, el micro se pasa la vida moviendo datos del acumulador a la RAM, y de la RAM al acumulador (y el programador, escribiendo todo el rato MOVW y similares).

Sin embargo, el hecho de tener varios acumuladores, permite trabajar con las variables de mayor uso en los acumuladores, sin tener que moverlas a/desde RAM. Eso significa que se hace lo mismo con muchas menos instrucciones, y por ende, más rápido, y con menos código. Además trabajar con variables de más de un byte también se simplifica.

Además, queda en evidencia que una RAM en bancos añade más cuello de botella a la arquitectura, ya que no basta con mover del banco al acumulador y vicevers, si no que además hay que ir cambiando de banco.

Como podeis ver, no intento comparar ni compiladores, ni directamente el AVR contra el PIC. De hecho, la comparación se puede aplicar a los ARM por un lado, y a los Freescale o PSoC por el otro.

Este tipo de ventajas es bastante transparente para los que trabajamos con los AVR en C, y no aparece de manera evidente, pero luego resulta que el código compilado es bastante más eficiente, y para una misma operación con el mismo compilador pero con dos micros diferentes, resulta que hay una gran diferencia de resultado, tanto en tamaño como en velocidad de ejecución.

Sin embargo, la explicación de porque, no es evidente, ni públicamente reconocida. Así que mi intención, es explicar porque los AVR tienen una potencia de cálculo similar a muchos micros de 16 bits, sin remitirme a 'pruebas esotéricas' como los benchmarks, drystones, etc.

Repito, lo que me interesa es el programa en ensamblador para los PIC's (u otro micro, que no sólo de PIC's y AVR's vive el mundo). El código en C es sólo una guia para transmitir la idea del algoritmo, pero no es necesario que nadie lo escriba y lo compile.

JM, ya nos mantendrás informado de tus progresos con el robot basado en ATmega.

Lo que quieres hacer con ese programa es sumar los 255 valores capturados en muestras en temp y devolverlo entre 4?

Programarlo en asm para 16 o en c para 18 es sencillo, si no se te ánima nadie a hacerlo pues lo intentare yo, aunque como programador dejo mucho que desear. Así que quizás sería mejor alguien que supiese programar para que los resultados fuesen más reales y no dependa de quien programa.

Pero tendrá que ser dentro de unas semanas, que ayer me cambie de piso a 60 km de donde estoy y tengo para unos cuantos días de mudanza x_x

Sería interesante activar y desactivar un pin del micro al principio y final del programa para medir el tiempo de ejecución con el osci.

Exactamente esa es la idea. Me pareció que dividir entre 4 sería más ilustrativo que el clásico de dividir entre 256 (que es sólo coger el byte alto del int).

Me imagino que el programa es sencillo en cualquier micro, y de hecho, esa es la idea, para que nadie se encuentre con un tostón de asm. Algo sencillo, que transmita la idea que quiero dar a entender, y que sea además algo no muy extraño.

Por lo del plazo, no hay ninguna prisa, así que tómate tu tiempo para la mudanza, y que te sea leve. He sufrido algunas como para saber que tienes mucho trabajo por delante...

Muy buena la idea de activar un pin del micro para medir el tiempo. Igual añado esta opción, tomo algunas medidas, y a ver si puedo capturar la señal del osciloscopio...

Ah, y gracias por el ofrecimiento, que la intención es lo que cuenta.

Un dato, los 256 bytes de muestras[] donde deben de estar situados, en registros de la ram? son variables, o para realizar la prueba los usas en una tabla grabada en la flash de programa?

Lo digo porque esos 256 bytes a muchos micros les hace quedarser casi sin ram.

Lo que podría ser interesante más que diseñar partes de código es hacer pequeños diseños completos.

En ese caso por ejemplo que el micro al pulsar un botón capture las 255 muestras de un ntc, ptc, lm35.. lo que sea a través de un adc. Realice los cálculos del programa y los saque por la pantalla de un lcd.

Y aquí podemos ver tiempo de ejecución total del programa (interesante si hay que capturar los 255 datos), ram usada, memoria de programa usada, tiempo de ejecución, desviación del valor real etc..

Lo único que debería ser igual es el sensor usado y el hard del sensor.