A ver si doy mi opinión, ya que este tema creció mucho y ni siquiera tuve tiempo de sentarme a leer todos los posts.
Antes que nada quisiera aclarar que siempre siempre me parece que todas las opiniones son válidas, siempre que estén bien fundamentadas.
Decir cosas solo por decirlas no aporta nada a la discusión, decirlas con cierto criterio y aportando "argumentos" creo que suma por más que se piense diferente.
Siempre que doy una opinión trato de dar mis argumentos, si no lo hago les pido perdón.
Antes de hablar puntualmente sobre C vs ASM, quisiera ir más allá que creo que el tema en cuestión radica sobre la evaluación previa de un proyecto.
Creo que un desarrollador de sistemas embedidos, debe conocer de muchas cosas antes de poder completar un trabajo. Además debe analizar qué conviene para cada proyecto. Todo en definitiva se reduce a pocos items.
1) Posibilidades técnicas de realmente poder llevar a cabo el proyecto
2) Costo final del producto
3) Costo del desarrollo 1) Uno debe realmente basándose en los conocimientos y experiencia, saber si uno puede hacer realidad el proyecto con las especificaciones requeridas y en qué plazo lo podrá terminar. Esto repito se basa en la experiencia y es común que con falta de experiencia uno considere que un proyecto le llevará menos que lo que le termina llevando. A medida que se van haciendo proyectos esta habilidad de "evaluar" la complejidad y el tiempo se van agudizando.
2) Este punto es el que uno siempre pone incapié, pero además de los costos de los materiales , se debe sumar el costo de armado, de posibilidad de fallas (cuantos mas elementos tenga es más probable que falle), retrabajos, etc. En los materiales no solamente está el microcontrolador, éste es solo un elemento dentro de la gran cantidad de componentes que suele acompañar a un sistema embebido. Está el Circuito Impreso, los demás componentes, cables, conectores, gabinete, etc.
El costo de armado si lo hacemos nosotros es tiempo empleado, si lo hace otro es un costo bien conocido. Si hay que hacer un chequeo del equipo, también se debe tener en cuenta.
3) El costo del desarrollo suele ser, de acuerdo a mi experiencia de lo que he visto en el tema, el punto que gralmente menos en cuenta se tiene y que muchas veces más se debería considerar. Cuánto realmente me costó el proyecto? Hay muchas formas de verlo
. Qué instrumental utilicé, si hubo que comprar alguna herramienta especial, como lo amortizo, etc.
. Gastos como alquiler, luz, teléfono, impuestos, etc
. Sueldos, en el caso de que trabaje uno en relación de dependencia
. Dinero que podriamos ganar haciendo otra cosa, si trabajamos como independiente.
Este costo se debe considerar y a menudo suele ser el item que más se sale de rango y que supera a todos los demás costos. Este costo se debe distribuir en la cantidad de equipos que se vendan.
Una vez expuesto esto, vayamos al tema puntual de ASM vs C. Esta batalla se originó también en las PCs pero ya se habló tanto del tema que ya casi ni lo menciona. Lo mismo ocurrió con CISC o RISC... hasta que Intel ganó por cansancio con una técnica comercial agresiva, una política de reuso del software realmente para sacarse el sombrero. Ellos entendieron que cambiar el software era más engorroso que mejorar un microprocesador o un hardware.
La lucha CISC vs RISC está hoy en día en los microcontroladores también, pero en este ámbito se pueden ver más RISC que CISC, pero quién dice que ocurrirá en el futuro.
Yendo al grano, en los pics 12F, 16F programo en exclusiva en ASM. Las razones son que comencé con el ASM, tengo una gran cantidad de rutinas y macros que me resuelven muchas cosas y el tema de la paginación de RAM y memoria de programa hacía y hace que los soft en C sean algo grandes para los proyectos en que me ví involucrado. En esos tiempos los 18F no existían. El pic más grande era el 16C74. Había que ingeniarselas para meter algunos software ahí adentro.
Con los 18F la decisión ya no fue tan simple y la complejidad de los proyectos en que me vi envuelto hizo que me decantara por el C previo estudio de la architectura y de algunas pruebas en el ensambaldor de los 18F.
Actualmente programo casi con exclusividad en los 18F, casi ni uso los 16F, por costo no se justifica. Acabo de conseguir 25 PIC18f2550 al precio de un 16f876A y encima me ahorro el cristal. Además tiene el doble de todo, memoria ram, eeprom, memoria de prgorama. Estos precios no son inventados, fíjarse sino en
www.digikey.com para ver de qué hablo.
El C que elegí es el C18, es un lenguaje que exige un profundo conocimiento de la arquitectura y se puede programar "como si" fuera ensamblador. Así es, uno define todo como lo haría, al igual que venía haciendo en ensambaldor en los 16F y 18F. Eso me encantó y me da mucha versatilidad.
Hago los software muy rápidamente, tengo rutinas hechas para un montón de cosas y en algunos casos hasta he hecho rutinas en ensamblador las cuales las llamo desde el C. El asm generado , si uno estudia bien las optimizaciones del compilador, es idéntico o casi idéntico a lo que uno haria en asm!!!!
No me imagino haciendo cálculos de ecuaciones expresadas en diferencias, para un algoritmo de control, en asm. No es que no me imagine como sería el código, sino que me parece una pérdida de tiempo impresionante. El tiempo es dinero amigos.
Creo que salvo rara excepción, la poca diferencia en centavos de dólar entre un 16F y un 18F da por ganador siempre a estos últimos, sobre todo en usar un C muy potente como el C18. Encima, prorateando tiempo de desarrollo, costo de todos los componentes (donde el PIC termina siendo un mínimo porcentaje del producto), la elección es aún más obvia.
Vayamos con un ejemplo, si un hardware vale u$s 100, y el pic vale u$s 5 o u$s 6... la diferencia es de un 1% del total, eso sin considerar que probablemente en el pic más chico debamos quemarnos las pestañas. Si encima hablamos de "cantidad" la diferencia costo entre pics se hace aún más pequeña.
Saludos
