Con respecto a las observaciones que puso Lupin, tengo entendido que si falla un pin del puerto falla todo el puerto. sobre la falla en la programación del pic debiste probarlo en otra pc con otro puerto haber como iba, a mi me pasó con mi JDM que no grababa a veces hasta que puse el Hacker y hasta ahora sin problemas, asegúrate que tengas el antivirus actualizado. Y sobre la falla en la memoria, no sería que te estabas apresurando en grabar los datos en la eeprom ya que estas tienen un tiempo mínimo que hay que esperar para grabarla.
Saludos.
Renatox:
Cada pin de salida de un pic es individual, se puede quemar una y seguir funcionando perfectamente el resto, incluso se puede quemar una (a medias) y quedar funcionando como salida y no como entrada (o viceversa).
Con respecto a la programacion lo probe en varias pc y con distintos programadores (por puerto paralelo y serie) incluso con el picstartplus de microchip (que es muy robusto 0% fallas), ademas cambiaba el pic fallado por uno bueno, y el bueno programaba perfecto. (todabia tengo los pic con falla, funcionan, pero no se los puede reprogramar ni leer - por si se les ocurre alguna prueba para hacerles-).
Con respecto a la eeprom, todos los tiempos respetados.
Yo no descartaría una falla en el programador, es más te diría que con casi seguridad se te dañó en algún momento en que lo estabas programando. Se dañó el microcircuito de programación del pic, también me pasó con algunos programadores JDM.
Me parece muy raro que el picstarplus arruine un pic.
¿Todos estos pics tenían el mismo código y funcionaban con un cristal de igualse MHz? Si es así, te comento que tu problema podría ser de soft. Que tu pic arranque/no arranque por alguna razón eléctrica y que se te borre cuando tu hacías una lectura de la posición de la eeprom, que probablemente lo hacías al iniciar el software.
Esta operacion de lectura de la eeprom sumado a un reinició involuntario del pic puede hacer que una operación de lectura se convierta en una de escritura (esto es una pregunta frecuente en los foros de Microchip). De hecho, me pasó incluso con algunos códigos cuando lo estaba programando! Al grabarlo se grababa bien , pero cuando el programador 'verificaba' en realidad el pic arranca el software y ahí le llega el pulso para entrar en modo programación para ser verificado. En ese momento se me borraba SIEMPRE la misma posición de EEPROM. Si cambiaba un delay al inicio de mi software esa posición cambiaba pero era fjia para un delay fijo.
Descubrí entonces que la falla estaba en el programador y no en el pic. De hecho eso me pasaba con un programador en particular (no Microchip) y no con el ICD2 de Microchip.
Tenian por lo menos 5 versiones distintas de soft, con distintos delay al inicio, pero ningun soft leia ni grababa la EEPROM antes de hacer una serie de chequeos de arranque (verifica conexion con el LCD, espera a que la impresora termica le responda, se fija si hay perifericos conectados, lee la tension de la fuente antes del regulador para ver si está en valores aceptables y estable, etc) estos chequeos tardan siempre mas de 5 segundos, despues de los cuales comienza el programa popiamente dicho. Igualmente una lectura convertida en escritura hace que pierda un dato, pero puede arruinar la celda de memoria?.
Tengo que aclarar que en el mensaje anterior me equivoque de pic, la falla en la eeprom me ocurrio en una tanda de 18F452 y no en los 16F877A (ademas escribi 16F887A en lugar de 877A).
Cuando un pic tiene una falla siempre comienzo suponiendo que la falla es humana, ya sea del soft o de la placa. Y siempre fue asi, pudiendo encontrar la rutina donde me mande "el moco", pero con lo de la EEPROM y lo de los pics que se "resisten" a las actualizaciones de soft no encontre ninguna respuesta racional (excepto la falla del pic).
Estoy a la espera de cualquier sugerencia.
Saludos
