Sí, lo que dijo Wouter. Hay tres partes a considerar al diseñar un programador PIC, el hardware, el firmware y el software. Hay una serie de opciones para hacer en cada una, y la complejidad se puede intercambiar entre ellas de varias maneras, especialmente entre el firmware y el software.
Para hardware simple que solo trata un subconjunto de PIC, consulte mi LProg . Esto se optimizó para un bajo costo mientras se seguía usando una interfaz de PC común de manera estándar. Solo funciona con aquellos PIC que no requieren un alto voltaje en MCLR para ingresar al modo de programación, y todas sus señales son fijas de 0-3.3 V. Estas dos restricciones permitieron que el hardware sea simple y el costo, por lo tanto, más bajo. El esquema está disponible en la parte inferior de esa página.
En el otro extremo se encuentran USBProg y USBProg2 programadores. Una vez más, los esquemas están disponibles en la parte inferior de esas páginas. Estos tienen una Vpp completamente variable de hasta 15 V y las señales digitales de hasta 6 V. También tienen más protección. Por ejemplo, las salidas digitales pueden cortocircuitarse de 0 a 6 V indefinidamente sin dañar el programador. Por supuesto, toda esta complejidad se debe a un mayor costo de fabricación y piezas.
La compensación de software / firmware es principalmente una cuestión de complejidad de firmware en comparación con la velocidad. En teoría, podría crear un programador que solo tenga instalaciones para que el software del host establezca las líneas a niveles particulares. El protocolo de programación PIC es síncrono, por lo que todo el tiempo se puede realizar en el software. Esto haría que el firmware sea fácil de escribir, pero el resultado sería un programador muy lento. Implementar los detalles de todos los diferentes algoritmos de programación que Microchip ha ideado a lo largo de los años requeriría más memoria de programa que la disponible en la mayoría de los PIC de control razonable. Los ingenieros de la división de ofuscación de programación de Microchip han estado muy ocupados. Como dijo Wouter, puede haber diferencias en el algoritmo de programación entre los PIC que de otra manera parecen ser muy similares. Debe leer cuidadosamente las especificaciones de programación para cada PIC que quiera apoyar. No hay un solo algoritmo de programación, ni siquiera cerca.
El protocolo de host para mis programadores está vinculado desde todas las páginas que mencioné anteriormente. Este protocolo fue diseñado no solo para la tarea inmediata que tenía a mano, sino también para permitir cierta latitud en el diseño del programador. Como resultado, implementé cierta complejidad en el software host para que una variedad de programadores con diferentes capacidades nativas puedan ser compatibles sin problemas. El mismo programa host controla el LProg, el USBProg y algunos programadores más antiguos que hemos suspendido mientras tanto. Lo hace no comprobando con qué modelo está hablando, sino investigando sus capacidades de una manera general según lo define el protocolo.
Hacer tu propio programador de PIC como único para un PIC específico no es demasiado difícil. Tratar de hacer un programador PIC de propósito general es más difícil, probablemente mucho más difícil, de lo que la mayoría de las personas se dan cuenta. Si terminas haciendo el tuyo, te sugiero que lo hagas compatible con mi protocolo host. Si observa el protocolo con atención, verá que gran parte de él es opcional. Si su programador utiliza mi protocolo de host , tiene mi código de host existente disponible para pruebas y posiblemente incluso para operaciones regulares . Gran parte de mi código fuente está disponible en enlace .