Hola. ¿Hay alguna lista a la mano de qué PICs programa el pickit2?
Mira por aquí:
Readme for PICkit 2 V2.61
Viendo que algunos de los enlaces con esa información ya no son válidos, adjunto el archivo.
Ok. Entonces entiendo que el valor de OSCCAL está escrito en la dirección que indica el archivo donde se declara, lo de 005.
Se puede decir que sí, pero debe leerse el valor escrito en la dirección 0x1FF y asignarse a OSCCAL.
En lenguaje ensamblador sería así:
call 0x1FF
movwf OSCCAL
Como la dirección 0x1FF contiene movlw 0xXX, W contendrá el valor de OSCCAL. (0xXX)
Posteriormente se asigna con movwf OSCCAL.
Cada lenguaje de programación tiene su sintaxis para realizar lo anterior, o en C se incorpora con #asm.
Me parece que algunos IDE de alto nivel lo hacen automáticamente, y si no, cuentan con instrucciones para tal efecto.
Por ejemplo, el Basic de Proton IDE, cuenta con una instrucción que se llama: Set_OSCCAL
Pero una cosilla que no entiendo, si no cambias el valor mediante una declaración en el programa
Yo tampoco entendí qué trataste de decir.
Después de tu edición ya comprendí.
pero una cosilla que no entiendo, si nunca has cambiado el valor mediante una asignación en el programa que le cargas al PIC, entiendo que todos los micros nuevos del mismo modelo llevan el mismo valor y este será invariable hasta que tú lo cambies.
No, cada PIC tiene un valor de calibración diferente para OSCCAL y es asignado desde la fábrica.
Obviamente algunos PICs tienen el mismo valor por coincidencia. (Lo he comprobado)
Pero tomemos como referencia básica que el valor de OSCCAL no siempre debe ser el mismo para cualquier PIC de la misma familia.
Entonces, si yo no lo he cambiado, no puede ser que no sea el que lleva de fábrica.
Como mencioné anteriormente, el valor está asignado en la dirección 0x1FF y al borrar el PIC también se borrará ese valor.
Por eso siempre debe de leerse antes de borrarlo o programarlo.
Ya que también se puede sobreescribir si el programa llegara a ocupar todo la memoria Flash.
Ahora, otra cosa importante, el registro OSCCAL es de lectura y escritura, o sea que podemos modificar por software el valor de OSCCAL, pero eso no sobreescribe el valor asignado en la dirección 0x1FF, a menos de que esa dirección sea escrita intencionalmente.
Además, precisamente lo que no puedo hacer es cargar ningún programa.
Tengo los micros nuevos de trinca, los reconoce con la verificación, pero cuando intento grabarlos con el archivo .h es cuando me da ese error de OSCCAL.
Un detalle, como tengo varios micros programados y funcionando perfectamente (los grabé hace varios años y estaban en un cajón, pero funcionan y ejecutan el programa)
Quizá podría leerlo en uno de esos. ¿No?
Por supuesto que los podrás leer, pero mientras no sepas qué valor de fábrica se asignó para OSCCAL en el PIC que no puedes grabar, no le debes poner cualquier otro valor.
Independientemente de todo, no entiendo que no pueda cargar exactamente el mismo archivo .h en el mismo modelo de PIC y con el mismo programador.
Lo único que he cambiado es el PC, que en aquel entonces tenía uno con windows 7 y ahora estoy usando uno con más velocidad y memoria, y windows 10.
En Windows 10 hay que proporcionarle derechos de administrador al IDE para que pueda modificar archivos.
Por ejemplo, cuando tenía Windows 7 no necesitaba darle derechos de administrador.
Ahora que uso Windows 10 x64, tengo que proporcionarle esos derechos para que el IDE pueda realizar cambios a los archivos instalados. (Los .h proporcionados por el entorno)
Muy rara vez llego a modificar las librerías del entorno, ya que la mayoría tiene parámetros que permiten modificarse externamente.
