PDA

Ver la versión completa : Grabador-entrenador de pics



navegante 420
27/04/2010, 01:49
Hace tiempo me lie con esto y poco a poco voy acabando todos mis proyectos......

Buscando por internet encontre este bloc y me parecio mut interesante este conjuntito.

Felixls: Pickit 2 Clone - Reloaded (http://sergiols.blogspot.com/2009/02/pickit-2-clone-reloaded.html)

Felixls: Multiboard-PIC-Trainer-2.0 (http://sergiols.blogspot.com/search/label/Multiboard-PIC-Trainer-2.0)

Y dicho y hecho a falta de 4 componentes he aquí mi grabador pickit clone 2.


https://anterior.webcampista.com/foro/attachment.php?attachmentid=28574&stc=1&d=1272318260

Y la entrenadora.


https://anterior.webcampista.com/foro/attachment.php?attachmentid=28575&stc=1&d=1272318335

https://anterior.webcampista.com/foro/attachment.php?attachmentid=28576&stc=1&d=1272318351

Y aquí el conjuntito.


https://anterior.webcampista.com/foro/attachment.php?attachmentid=28577&stc=1&d=1272318430


Quisiera desde aquí agradecer a felixsls por compartir toda la documentación, y hacer posible que este muy cerquita de tener mi entrenador.....

Aunolose
27/04/2010, 18:37
Muy interesante, si señor.

Parece una placa con varios interfaces al que se puede conectar "cualquier" PIC ¿no?

navegante 420
27/04/2010, 18:45
exacto, cambiando la plataforma superior puedes poner cualquier pic.

Gerard-2
09/05/2011, 18:52
Felicidades por el proyecto! (que envidia)
y la parte que corresponda a felixls, por cierto que hace tiempo se rebotó por problemas de plagio de su doc, encima de que la cede hay caraduras que se la hacen pasar por suya.

navegante 420
10/05/2011, 18:13
la parte toda, es el que se curro el tema, yo solo he copiado, jejeje y no me escondo, es mas, el grabador lo he modificado recientemente, por uno que he hecho en la cnc de clase y sigo manteniendo su nombre en la placa.

Pues si es una lastima que por culpa de unos, pagemos todos, porque tiene una fuente de alimentación que es una pasada.

Gerard-2
10/05/2011, 21:28
Buffff, me esta entrando el mono...a ver si repaso a conciencia la web de felixls y desenpolvo la isoladora, liquidos, chips etc

navegante 420
11/05/2011, 20:05
venga gerard animate, que contra más seamos, mas nos reiremos.... jejejeje

Gerard-2
11/05/2011, 22:51
primer problema, he mirado los enlaces de felixls y me manda a buscar el firm de microchip, todo parece correcto.

Advertencia de no se que de una version anterior, supongo que se ha modificado el sch y seria lo normal.

Sigo, me miro el intel.hex, supongo que se ajusta a este estandar y me encuentro que al final parece que se contradice con unas lineas del principio, vale que el programador va a 'quemar' las ultimas o como minimo las va a 'requemar' sobre la marcha, por lo que van a quedar esas ultimas lineas, pero .... eso funciona?

Navegante, tu has usado ese fichero intel.hex con el nombre PK2V023200.zip???


PICkit 2 Firmware v2.32.00 ReadMe file

Release Notes:
v2.32.00, along with PICkit 2 Programmer software v2.52.00, PK2CMD v1.12, and
MPLAB IDE 8.15 fixes problems with simultaneous use of multiple PICkit 2 units.

Sigo mirando y se me ocurre que el tercer campo de un byte (oo para datos mem y 01 final fichero), si pone 04 puede ser de tipo modal, es decir que lo siguiente puede ser contenido de la eeprom por que se repiten los 100h bytes iniciales con otros valores ¿?

Vuelve a aparecer el codigo 04 misterioso en el tercer campo, nueva linea direccionada a la 0000h con otros 14 bytes ¿?

Llegais a controlar este tema? algun doc oficial sobre esto?

Aunolose
11/05/2011, 23:17
Decirte que yo al final lo compré, bueno, el departamento http://l.yimg.com/us.yimg.com/i/mesg/emoticons7/65.gif

Pero también te digo que lo pruebes, los de microchip hacen cosas raras muchas veces, sobre todo en ensamblador, tal vez por que programan en C y el compilador es un poco especial (eso hay que reconocerlo...)

navegante 420
12/05/2011, 12:01
primer problema, he mirado los enlaces de felixls y me manda a buscar el firm de microchip, todo parece correcto.

Advertencia de no se que de una version anterior, supongo que se ha modificado el sch y seria lo normal.

Sigo, me miro el intel.hex, supongo que se ajusta a este estandar y me encuentro que al final parece que se contradice con unas lineas del principio, vale que el programador va a 'quemar' las ultimas o como minimo las va a 'requemar' sobre la marcha, por lo que van a quedar esas ultimas lineas, pero .... eso funciona?

Navegante, tu has usado ese fichero intel.hex con el nombre PK2V023200.zip???



Sigo mirando y se me ocurre que el tercer campo de un byte (oo para datos mem y 01 final fichero), si pone 04 puede ser de tipo modal, es decir que lo siguiente puede ser contenido de la eeprom por que se repiten los 100h bytes iniciales con otros valores ¿?

Vuelve a aparecer el codigo 04 misterioso en el tercer campo, nueva linea direccionada a la 0000h con otros 14 bytes ¿?

Llegais a controlar este tema? algun doc oficial sobre esto?

??????? Me acabas de matar...... codigo, campo, nueva linea direccionada????? ande has visto tu eso?????? Joer lo que me queda por aprender....... Mas acojonado.......

Si yo me vaje ese archivo y fue el que queme directamente en el pic18f2550 y hasta ahora nos va perfectamente a los tres que nos hicimos el quemador.

Gerard-2
12/05/2011, 18:41
Son detalles que pueden o no ser importantes, depende del problema, en todo caso son de "bajo nivel" :)
Los listados ".bin" suponen un lio presentarlos en una consola o imprimirlos por tanto se traducen a un listado ASCII, facil de presentar, donde ademas se reflejan las direcciones de memoria asociadas a cada byte.

Antes mira como es un volcado hexadecimal+ ascii del fichero prova.txt, queda algo despeinado por el editor, a la izquierda posiciones de mem, a la derecha los bytes en hexa y despues el equivalente en ascii.

localhost:~/Desktop # hexdump prova.txt -C

00000000 68 6f 6c 61 2c 20 65 73 74 6f 20 65 73 20 75 6e |hola, esto es un|
00000010 61 20 70 72 75 65 62 61 20 64 65 20 76 6f 6c 63 |a prueba de volc|
00000020 61 64 6f 20 68 65 78 61 64 65 63 69 6d 61 6c 2e |ado hexadecimal.|
00000030 0a |.|
00000031

para los ficheros a programar muy a menudo se usa el formato intel.hex, tambien hay otros formatos, te dejo el enlace de la wiki Intel HEX - Wikipedia, la enciclopedia libre (http://es.wikipedia.org/wiki/Intel_HEX)
y un pdf http://ecee.colorado.edu/~mcclurel/hexrecords.pdf (http://ecee.colorado.edu/%7Emcclurel/hexrecords.pdf)

Volviendo a microchip, cada uno usa como quiere el campo de tipo de registro 02-03-04-05, me parece que el 04 lo estan usando para diferenciar distintos campos de registro en el interior del pic, mem-code, fuses o eeprom.

Si alguien lo controla que nos lo explique, siempre viene bien.

Aunolose
12/05/2011, 21:23
Puff... esto del volcado hexadecimal me recuerda cuando intentábamos traducir los juegos conversacionales de ingles a español... anda que no ha llovido... :D cuando más me he divertido con esto fue cuando cambiábamos el mensaje de bienvenida de las placas 486 y derivados, sacábamos la EEPROM (o peor, la EPROM) y a investigar...

Pero esto ya es muy avanzado, si no quieres hacerte tu propio compilador, o cambiar algo a muy bajo nivel, no tiene mucha utilidad, se puede cambiar prácticamente todo en ensamblador, incluso en C con directivas, que algunas también son avanzadas.

Gerard-2
12/05/2011, 21:47
Nooooo, que solo era para ayudar a entender mas facilmente lo que es un formato intel.hex a navegante (para mi esto es importante manejando ficheros de codigo)

Solo preguntaba por el campo de tipo de registro, por que veia cosas raras en el fichero de firm.

Aunolose
12/05/2011, 21:58
Elucubración: ten en cuenta que con el bootloader el chip se programa solo, es decir, desde el programa se cambia la memoria del programa, algo que no es habitual, quizá por ahí vayan los tiros.

____
No es habitual cambiar la memoria de programa "en marcha" porque corres el riesgo de cambiar tu programa y por lo tanto dejarlo inservible, es lo que pasa cuando no pones bien la directiva de las direcciones, (y te pasa muchas veces hasta que le pillas el truco...) en estos "cacharros" no pasa na, lo vuelves a programar y listo, pero ¿os imaginais cambiar un programa tipo-Word mientras estás escribiendo un documento? pues eso, no es habitual "auto.reprogramarse" en tiempo de ejecución (mientras el programa está en marcha)

Gerard-2
12/05/2011, 23:00
Si, pero "todo empezó" cuando vi posibles incoherencias en el fichero del firm :)

Me gusta ver donde programo, que programo y si me "hace caso" la maquinita, es que me gusta saber y comprobar !!! sobre todo cuando hay problemas, luego a la decima vez que ya va bien es mas comodo darle al boton y que rulle solo.

Quiero ver donde programa el main, donde siguen las isr si no caben en su posicion de hard vectorizado, donde guarda las matrices, si las puedo situar yo mismo y cosas por el estilo.

Por cierto en el P89C52Rd se podia programar que se reprogramar en mem de codigo llamando rutinas internas en shadow de fabrica, el atmel tambien.

Aunolose
12/05/2011, 23:13
Si, si, pero no es lo habitual, el bootloader se suele usar pocas veces, no es habitual que un programa "genere código de programa", en ningún microcontrolador ni en ningún procesador, bueno, de hecho el bootloader no genera código, se limita a copiar el que le manda.

No estoy seguro de explicarme. A ver... ¿que programa "normal" genera código y se autoprograma para después ejecutar ese código generado? suena inteligencia artificial de la gorda... :D

Gerard-2
13/05/2011, 02:02
supongo que lo normal seria modificarse datos, cadenas o ctes de config o calibracion, no tanto reprogramarse codigo, de hecho tanto el philips P89C51 como el AT89C52 no tenian mem. e2prom de datos por lo que tenian que tirar de tablas en mem. de codigo, que te voy a explicar :) . Lo digo en pasado porque todo esto va que vuela.

Quiza sea la explicacion por la que microchip no ha implementado estas funciones, añadiendo una minima zona de datos no volatil.
Pero es que solo con el hyperterminal de win o cualquier otro, podias programar un 89C51 virgen, hacer volcados hex de zonas de memoria de codigo o variar bytes del codigo aleatoriamente. Bueno, que parece que sea comercial de intel :)

Aunolose
13/05/2011, 22:14
Claro, pero eso lo puedes hacer también con los PIC y el bootloader, solo tienes que prepararlo a tu gusto.

Comparado con el 8051 el PIC maneja las tablas de p. pena... en cualquier memoria :( pero no hablamos de cambiar los datos, eso lo entendería, hablamos de cambiar código, y eso son palabras mayores, ya digo que los bootloader no cambian nada, se limitan a copiar lo que viene vía serie (232, USB, CAN, I2C, SPI...) y copiarlo en el sitio "correcto".




Bueno Gerard, resumiendo, que me suena a escusa para no montar el PICkit... :laughing6:

Gerard-2
14/05/2011, 14:17
Nooo, es añoranza :sad11:

No estoy seguro si el pic mismo puede modificar su mem de code, o solo lo puede hacer desde el control exterior de las lineas RB0 y 1 (creo) desde el exterior ¿? en todo caso es suficiente por que tiene tambien e2prom de datos.

El pickit seguro que lo monto, ya hace tiempo que tengo varios xips, el arduino me distrae un poco , igual DESPUES, miro algo, en inet hay placas por 4€ para montar, es un sucedaneo del arduino compatible, o el original que sale por unos 30€, ya se verá.

Aunolose
15/05/2011, 18:55
Si el bootloader puede programar el pic, seguro que se puede modificar la memoria de programa, pero la pregunta que yo hago es ¿para que? aunque lo de las tablas no se me había ocurrido... supongo que la gestión sería todavía peor... todo esto hablando en ensamblador claro, por que en C, pues ya se encarga él, y "desde fuera" es transparente.

Lo que hay que tener en cuenta es que mientras la eeprom se puede borrar y grabar en general decenas de miles de veces, la memoria de programa no son tantas... hay que tenerlo en cuenta, porque reprogramar no es lo mismo que leer y cambiar tablas.

Gerard-2
15/05/2011, 22:20
Es que necesito hacer un bootloader auto-actualizable jaja , todo esto es rizar el rizo.

Segun microchip se puede reescribir el codigo 100.000 veces y la zona de datos eeprom 10⁶ veces con retencion para 40 años, eso con permiso de la tormenta solar del 2012 :) que llegará anteeeessss.

Aunolose
16/05/2011, 18:29
Joe, ¿ya han llegado a las 100.000? el que tiene que actualizarse soy yo...