Creo que no te hicistes un buen momento para leer lss ventajas y xaractetisticas de los DSPICs ...
Bueno, me refiero a los que el núcleo está diseñado íntegramente por Microchip. O al menos a los clásicos. Los PIC32 son en realidad core MIPS por lo que ya sé que puedo esperar de ellos (cosas muy buenas, por supuesto). Me refiero más concretamente desde la serie PIC10 a los PIC18, considerando sobre todo los PIC16 que son los más usados para iniciarse en la programación de microcontroladores junto con los AVR.
por que ? . . Me gustaría una explicación . . . En que muchos aficionados usen quepic no quiere decir que ese ci sea una broma te haré una pregunta.
No he dicho que sea una broma, pero todo el que ha visto la arquitectura de los PIC de 8 bits y la de otros micros de 8 bits, como el legendario 8051, se da cuenta que los PICs tienen una forma "peculiar" de programarse, muchas veces tirando de código escrito "con trucos" para funcionar en PIC cosa que no se necesita en otras arquitecturas, pero yo no estoy discutiendo de eso, sería como comparar un automóvil con cambio de marchas automático a uno de marchas manuales, según para qué cosas, el de cambio de marchas automático se han de hacer "con truco" como por ejemplo la salida en pendiente pronunciada.
Que le da más confianza ?
La marca del chip o el profesional que lo elije ?
Un cordial saludo
Te cuento algo que me pasó hace muchos años. Diseñe un dispositivo que debía realizar ciertas tareas dentro de una máquina, una especie de autómata. El requerimiento es que esas tareas disponían de una configuración que debía permanecer cuando se apagaba el dispositivo y se volvía a encender. La configuración se guardaba en unas pocas variables como contadores, flags, etc. La programación la hice en un 16F84A funcionando a 4MHz.
A pesar de que programé la detección de reset por brownout para hacer un arranque en limpio del sistema, el micro se "colgaba" si el aparato se encendía antes de que la fuente se hubiera apagado del todo. Incluso el watchdog que se supone independiente del micro era invisible para este. Se solucionó aparentemente con un simple circuito que mantenía MCLEAR en estado bajo mientras la alimentación fuera menor de 4V.
Pero lo peor fue la retención de los datos. Los parámetro sólo se modificaban cuando el usuario accionaba cualquier tecla del teclado numérico, por lo que por cada pulsación, las variables se guardaban en la memoria EEPROM del micro, y en cada reset se volvían a leer. Poco tiempo después los operarios se empezaron a quejar de que los dispositivos se volvían inoperativos pasados unos días. La rutina de grabación de datos en EEPROM era la correcta y la de comprobación lo mismo, es decir, hasta que los datos de la EEPROM no fueran los mismos que los de los registros implicados el dispositivo no operaba normalmente o bien se proporcionaba un mensaje de error en display tras varios intentos fallidos de grabar en EEPROM (esto nunca pasó).
Testeando el sistema que tenía para recuperar el micro tras el apagado y encendido de éste, descubro sorprendido que aunque el programa del micro permanecía intacto en la FLASH y aparentemente se ejecutaba, los datos de la EEPROM habían variado, a veces un bit, a veces varios bytes. El glitch de alimentación del micro había corrompido la EEPROM, lo que producía que hubieran valores absurdos en las variables y el micro se colgase (como por ejemplo punteros indexando fuera de las tablas). Cuando pude comprobar que pasaba esto de manera bastante frecuente, consideré dos opciones. O bien usar una eeprom externa vía I2C o SPI para leer y grabar las variables, o insertar una combinación especial del teclado (que reproducía una condición determinada en el puerto de I/O) para que en caso de bloqueo, los valores de las variables pasasen a ser los programados en el código por defecto (volviendo a tener que configurar de nuevo el operario todo el dispositivo). Como era un diseño ya cerrado, es decir, que el hardware ya estaba en uso y sólo cabía una actualización de firmware, opté por lo segundo, conformando al cliente pero no se quedó demasiado contento ya que en no muy pocas veces el dispositivo no respondía como se esperaba que tuviera que responder.
Y me encuentro cómodo como sabeis programando PICs en asm, pero he visto fallar estrepitósamente código infalible en PICs que no fallaría en otros microcontroladores. Si una máquina industrial se bloquea, se puede volver a poner en estado de reset o se pueden implementar ciertas alarmas externas, pero hay sistemas que si paran, sería un desastre, como por ejemplo la refrigeración de la cámara de un reactor nuclear. He visto ascensores funcionando con PIC16F877 pero el sistema de frenado de emergencia era independiente controlado mediante disparo inercial (no estaba controlado por el pic).
Y por supuesto, eso de tener que estar usando truquitos de software o de hardware para que el PIC funcione en condiciones, no debería ser lo normal.
Y mi reflexión no tiene nada que ver con que se use para fines profesionales o amateurs.
