TODOPIC
Microcontroladores PIC => Programadores => Mensaje iniciado por: manuelroin24 en 22 de Noviembre de 2006, 02:28:20
-
Hola amigos quisiera saber si alguien del foro sabe como se crean los software de grabacion como el famoso WINPIC800 y tambien como es que se envia los datos por el USB me interesaria poder o al menos tratar de elaborar un software de grabacion para al menos aprender como es que estos funcionan muchisimas gracias.
-
Hola! Yo intento buscar la misma información que tú, parece que es dificil pero poco a poco , más o menos, se consique.... lo que deberias hacer es leer las "programming specifications" en www.microchip.com (estoy dando por hecho que quieres saber como se programan PICs...) ahí te explican en perfecto inglés(de ese que apenas yo no entiendo :D) como funciona el protocolo ICSP para cada dispositivo. Esto creo que más o menos lo entiendo, si quieres preguntar algo en particular te animo a ello... De lo que voy más "cojo" es de como tratar con el formato Intel Hex que es el formato de código maquina de los micros. Esperemos que alguien que esté más al tanto nos ayude un poco. Saludos!
-
Esperemos amigo mio, ese tema me interesa mucho ya c q es muy dificil imitar al maestro SISPIC pero nada se pierde intentandolo no??'
-
Hola, yo llevo un par de meses desarrollando un programador usb, y una aplicación desarrollada en delphi para manejarlo, lo tengo casi acabado, a falta de algunos retoques sobretodo al programa de pc. Asi, que si os hace falta una ayudita, solo teneis que pedirlo y encantado os echaré una mano.
Saludos.
-
Hola omix! Yo estoy intentando desarrollar mi propio programador ... no es con vistas comerciales, es para mi proyecto final de carrera... El que intento construir también funciona bajo USB, pero de forma autónoma, es decir, no se necesita un PC; mi idea es que guardes los .HEX en una memoria usb o en una MMC/SD y puedas programar los PICs donde tu quieras(sin tener un PC al lado).... además de poder programar directamente desde el PC(espero que tambien mediante USB pero creo que con un conversor USB-Serie, porque creo que los PICs con USB esclavo están por ahora fuera de mi alcance...).
Hasta ahora he conseguido implementar el sistema de archivos de la parte autonoma(leer y escribir en las memorias usb,mmc-sd), pero me he quedado estancado aquí, por ahora, porque estoy de examenes(todavia me queda una... :D).
He estado leyendo acerca de implementar el protocolo ICSP pero todavía voy bastante perdido.... sobre todo con el tema de leer de los archivos Intel Hex(ya me ayudaste en otro post.... gracias de nuevo 8)). Si puedes ayudarnos(hablo por mi, por manuelroin24 que abrió el post y por el resto del foreros) sería genial!!! Yo me comprometo a informaros de todo lo que sé(tampoco es demasiado :D) sobre controladores Master Usb y controladores FAT para poder realizar vuestras aplicaciones autonomas...Si te interesa añadir está funcionalidad a tu programador, omix, no tienes más que decirlo XD.
Saludos a todos!!!
-
Un consejo solo... si planteais cuestiones tratad de ser lo más conciso posible... segmentar mucho en las preguntas porque si alguien sabe algo igual le da pereza tener que explicar todo un proceso. Y aportad progresos si los conseguiis... y links o documentos o incluso código... eso anima mucho a la gente.
Manwenwe por qué dices que los pics usb esclavo se te van de tu alcance? Porque no puedes conseguirlos? POrque no sabes programarlos? porque tienes que abarcarlos en ensamblador?
Por lo demás animo y al toro.
1 saludo.
-
Hola más bien lo digo porque no se programarlos y me da bastente pereza ponerme :D... y no es por la programación del pic en si, sino por tener que hacer alguna aplicación para PC. El problema es que lo único gráfico que se programar para PC es en Java y es bastante "pesado". He visto que la gente programa sus aplicaciones gráficas en Visual C o Visual Basic pero no he tocado nada de estos leguajes... Saludos!
-
Manwenwe, si sabes Java no deberia de resultarte mucho mas complicado el programar en otro lenguaje como C++, Visual C, Delphi, etc. De todas formas si lo deseas tambien puedes hacer tu aplicación para manejo del usb en java, ya que si no recuerdo mal hay por la red una serie de clases para menejo del usb mediante java. Por ejemplo aqui puedes ver uno: http://jusb.sourceforge.net/?selected=types
Un saludo y animo.
-
Hola a todos! Tengo un par de dudas sobre los .Hex... pondré un ejemplo para que podais entender mejor las preguntas; esta es la primera linea de archivo .Hex de un programa para un 16f877a:
:1000000000308A00072900000A108A100A100A118207AE .... si lo separamos en bytes tenemos(los numeros son hexadecimales...):
10 (nº bytes datos,)
0000 (direccion,doblada, del PC)
00 (los datos son para grabar)
00 30 8A 00 07 29 00 00 0A 10 8A 10 0A 11 82 07 (son los 16 bytes de datos)
AE (checksum)
La siguiente linea del archivo es: 10 0010..... lo que quiere decir que apunta a la dirección 0x08 ( 8 ) pues, como ya he comentado, las direcciones están dobladas. Con esto tenemos que los 16 bytes de datos de la primera linea representan 8 palabras de la memoria de programa del PIC, con lo que cada 2bytes representan una palabra de la memoria de programa. Mi duda es:
¿Si la longitud de palabra(memoria de programa) para el 16f877a es de 14bits.. cuales de los 16 bits/palabra que obtengo del .Hex se corresponden con los que tengo que grabar?
También tengo uns segunda duda :-); he visto que en los .hex compilados con CCS, al final del archivo, incluyen una linea con el modelo al que corresponde el código(ej.: PIC16F877). Me gustaría saber si hay alguna opción en MPLAB para que el linkador haga lo mismo, pues no la he encontrado y es algo que me parece muy util a la hora de verificar que el código se corresponde con el dispositivo físico...
Gracias a todos y saludos!
-
Como q se nos va el tema no amigos la idea es tratar todas nuestras inquietudes acerca de como hacer un grabador a nuestras medidas y comodidades para poder entenderlo lo mejor posibe y asi cada vez q se presente un error poder entender pq es que este se genera sin tener q llamar a nadie ni consultar. Esperemops retornar al tema, muchas gracias
-
Hola manuelroin24! No entiendo muy bien lo que expresas en tu "reply"... pero si te refieres a que las preguntas que hice no tienen nada que ver con el tema, lo siento pero no estoy de acuero. Si intentas "crear software de grabación" tendrás que empezar por entender como el linkador expresa las instrucciones en el archivo .HEX para poder seguidamente empezar a plantearte como grabar estas instrucciones en la memoria de programa de los micros. Que conste que lo digo sin ningún ánimo de ofender :-)
He estado de examenes y ya terminé asi que me toca ponerme de nuevo con mi proyecto de grabador... Me he estado empapando algunas "programming specifications" de Microchip y ya estoy dispuesto a ponerme a pelearme con ICSP asi que en cuanto consiga algo prometo poneros al tanto y subir código...
Si todavía a alguien le interesa... conseguí descifrar lo referente a la representación de la palabra de un 16fXXX en .HEX. Es simplemente que los dos bits de más peso no se tienen en cuenta, de hecho el compilador/linkador los deja simpre a 0. Para saber cuales son estos dos bits hay que tener en cuenta que los bytes en este formato están en little-endian dentro de una misma palabra(de 2 bytes), es decir, AF2E(.HEX) ===>>2EAF(para grabar en el pic).
Bueno saludos a todos!
-
Hay varios software de grabación de Código Abierto, uno de ellos es Winpic (creo que fué el padre de Winpic800 de Sisco;)), los vas a encontrar sin problemas en Google, como punto de partida te dejo esto:
http://www.hamradioindia.org/circuits/winpic.php
saludos!
-
Gracias por tu ayuda J1M... ya he encontrado los fuentes... para quien los necesite:
http://www.qsl.net/dl4yhf/winpicpr.html
Saludos!
-
normalmente con software se echan a programar para hacer el software de grabacion?? es pascal ???
-
Hola, yo uso delphi porque desde mi punto de vista es uno de los lenguajes mas sencillos de usar y bastante rapido de desarrollar aplicaciones para windows o linux (con kylix). Pero vamos se puede hacer con cualquier lenguaje, ya puede ser, C++, C#, Visual Basic, java, etc.
Saludos y Feliz Navidad.
-
gracias a ver q consigo antes del año nuevo jejejejeje
-
Hola compañeros, todavia ando liao con ICSP y la cosa va lenta... :( Tengo un problema con el q llevo varios dias y no le saco punta; espero que podais ayudarme, sobre todo tú omix que veo que "controlas" mucho en ICSP. El caso es que no consigo grabar bien las IDs de la memoria de configuración, intento lo siguiente que creo que es lo que he podido sacar de un diagrama de flujo de las "programming specifications" de los 16f87X(antes de todo esto envio el comando "chip erase" para borrar memorias de programa, datos y palabra de configuración):
void grabarMemoriaConfiguracionPIC16_2(void){
enviarComando(loadConfiguration);//salto a memoria de configuración 0x2000
datoEscribirPIC16.palabra14 = 0x3f87;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(incrementAdress);
//0x2001
datoEscribirPIC16.palabra14 = 0x3f88;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(incrementAdress);
//0x2002
datoEscribirPIC16.palabra14 = 0x3f89;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(incrementAdress);
//0x2003
datoEscribirPIC16.palabra14 = 0x3f8A;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginEraseProgrammingCycle); // borro y grabo las 4 IDs
enviarComando(incrementAdress);
//0x2004
enviarComando(incrementAdress);
enviarComando(incrementAdress);
enviarComando(incrementAdress);
//0x2007
datoEscribirPIC16.palabra14 = 0x3f3A;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginEraseProgrammingCycle); //borro y grabo la palabra de configuración
initICSP(); //reinicio el modo maestro
}
La palabra de configuración se graba bien pero no las IDs, se borran pero despues no graba los valores esperados(0x789A) simplemente se quedan a 0xFFFF.
También he intentado lo siguiente:
enviarComando(loadConfiguration);
datoEscribirPIC16.palabra14 = 0x3f87;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginProgrammingOnlyCycle);
enviarComando(endProgramming); //grabo ID0
enviarComando(incrementAdress);
datoEscribirPIC16.palabra14 = 0x3f88;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginProgrammingOnlyCycle);
enviarComando(endProgramming); // grabo ID1
enviarComando(incrementAdress);
datoEscribirPIC16.palabra14 = 0x3f89;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginProgrammingOnlyCycle);
enviarComando(endProgramming);//grabo ID2
enviarComando(incrementAdress);
datoEscribirPIC16.palabra14 = 0x3f8A;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginProgrammingOnlyCycle);
enviarComando(endProgramming); //grabo ID3
enviarComando(incrementAdress);
enviarComando(incrementAdress);
enviarComando(incrementAdress);
enviarComando(incrementAdress);
datoEscribirPIC16.palabra14 = 0x3f3A;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(beginEraseProgrammingCycle); // borro y grabo la palabra de configuración
initICSP(); reinicio el modo maestro
}
En este caso la palabra de configuración se graba bien de nuevo(algo de esperar)... el problema es que como borré la memoria con "chip erase"(comando que no borra las IDs) tengo que borrar "a mano" (con WinPic800) el PIC para que despues se graben las IDs y aún así la primera(0x2000) no se graba permanece a 0xF :(.
He visto que el único comando que borra las IDs es "bulk erase program memory" y además para que éste borre la palabra de configuración el PC debe estar en esta dirección(0x2007)... con esto probé a borrar la memoria, en vez de con "chip erase", así:
int8 i;
enviarComando(loadConfiguration);
for(i=0;i<7;i++)
enviarComando(incrementAdress);
enviarComando(bulkEraseProgramMemory);//0x2007
enviarComando(beginEraseProgrammingCycle);
initICSP();
... pero igualmente, las celdas donde están las IDs no se borran. Con todo esto, la verdad es que no encuentro ninguna solución porque creo que el primer algoritmo que mostré debería funcionar(creo que he pasado bien el diagrama de flujo que explica como grabar la memoria de configuración) pues los comandos están bien, los tiempos de retraso también y la tensión de alimentación es de 4.7(está dentro del rango 4.5-5.5) pues ya he programado la memoria de programa sin problemas.
Despues de todo esto, esperar que alguien me pueda orientar sobre lo que estoy haciendo mal y dar las gracias de antemano!
Saludos y felices fiestas!
-
Hola, parece que he solucionado todos los problemas que tenía :-/ Voy a intentar explicar lo que he aprendido para quien le pueda ser util.
La forma de borrar las ID locations es la siguiente:
void borrarDispositivoPIC16(void){
enviarComando(loadConfiguration);
datoEscribirPIC16.palabra14 = 0x3fff;
enviarComando(loadDataForProgramMemory);
enviarDato();
enviarComando(bulkEraseProgramMemory);
enviarComando(beginEraseProgrammingCycle);
}
Lo que dicen las "programming specifications" de los PIC16f87X es lo siguiente:
2.5.1.1 Bulk Erase Program Memory
When this command is performed, and is followed by
a ‘Begin Erase/Programming’ command, the entire
program memory will be erased.
If the address is pointing to user memory, only the user
memory will be erased.
If the address is pointing to the test program memory
(2000h - 201Fh), then both the user memory and the
test memory will be erased. The configuration word
will not be erased, even if the address is pointing to
location 2007h.
Previously, a load data with 0FFh command was recommended
before any Bulk Erase. On these devices,
this will not be required.
The Bulk Erase command is disabled when the CP bit
is programmed to ‘0’ enabling code protect.
A timing diagram for this command is shown in
Figure 6-8.
Comento:
1."Previously, a load data with 0FFh command was recommended before any Bulk Erase. On these devices, this will not be required.On these devices,this will not be required."
... de esto básicamente me rio :D... si no lo haces no se borra la memoria. No sé en que estaban pensando los señores de Microchip cuando lo escribieron.
2. No se comenta nada sobre la memoria de datos(EEPROM) que también se borra al ejecutar el comando...
En cuanto al problema que tenía con "la no grabación" de la primera de las IDs... parece ser que al entrar en la memoria de configuración, se ha de enviar un dato "dummy" tras el comando "load configuration" y este dato no es tenido en cuenta para nada. A partir de este momento se puede trabajar en esta parte de la memoria sin más problemas.
En definitiva, seguiré peleandome con la documentación ICSP que nos ofrece Microchip... ciertamente creo que se podrían esforzar un poco más en hacer más claras sus "programming specifications"...
Saludos a todos y felices fiestas!
-
Hola manwenwe, me alegro que hayas conseguido solucionar tu problema y siento haber llegado tarde para contestarte.
Un saludo y suerte con el proyecto.
-
Hola omix, gracias por tu solidaridad! :D Quería pedirte consejo, sobre tu experiencia diseñando tu software de grabación... Hasta ahora he implementado(casi terminado) la grabación de los PIC16F87X; no se si estás desarrollando sólo tu propio software o también el hardware, no se si lo comenté pero yo hago esto y estoy teniendo bastantes problemas(creo que con el hardware). El caso es que mi algoritmo de programación/verificación parece que funciona pero no lo hace siempre: esto es lo que me "mosquea". Con esto pienso que la culpa es del circuito, pues lo tengo todo montado(LCD, buttons, 2 zocalos pic, controladors usb, etc) en una placa microperforada con todos los cables "bastante cruzados"; al menos espero que cuando pase el proyecto a PCB todo funcione bien, pero por ahora no se que efectos de diafonía se pueden dar entre las diferentes líneas porque no tengo ni idea de la corriente que pasa por cada una de ellas...
Como no estoy seguro si tu también diseñas tu hardware, sólo queria preguntarte si crees que es posible que tenga algun fallo en mis algoritmos que haga que a veces se lea bien y otras no( el problema lo tengo siempre verificando)¿? Dejo aquí la función para leer cada palabra de memoria de programa:
void leerDato(void){
TPGD = 1; // ponemos la linea datos ICSP del pic(programador) como entrada
PGC = 1; //PGC = linea de reloj
Nop(); // Nop() = 1us de retraso
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit0 = PGD; //PGD = linea de datos
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit1 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit2 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit3 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit4 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit5 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit6 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit7 = PGD;
PGC = 0;
Nop();
Nop();
PGC = 1;
datoLeerPIC16.bit8 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit9 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit10 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit11 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit12 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
datoLeerPIC16.bit13 = PGD;
PGC = 0;
Nop();
PGC = 1;
Nop();
PGC = 0;
Nop();
TPGD = 0;
}
Bueno omix, espero que puedas darme algún consejo sobre los errores que estoy teniendo... si no es así, te agradezco igualmente toda la ayuda que me has prestado hasta el momento.
Saludos y felices fiestas a todos!
-
La verdad que de programacion de PC poco. PERO les envio mucho Animo. ! :-/
-
Hola PICmouse, creo que omix está haciendo su software de programación para PC, pero el mio es para PIC: es decir, PIC graba PIC.
Por cierto omix, se me olvidó comentar estos son algunos de los ejemplos de errores que tengo:
Escribo 0x3000, leo 0x7000...
Escribo 0x3000, leo 0xF000...
... realmente es algo que me extraña muchísimo porque lo que leo lo pongo en datoLeerPIC16 que es una union de un int16(datoLeerPIC16.palabra14), 4 nibbles(datoLeerPIC16.nibble0,...) y 14 bits(datoLeerPIC16.bit0,....); con esto quiero decir: los bits que leo los coloco en los campos de la estructura de bits, que son 14 campos y por tanto no se puede dar un valor como 0x7000 o 0xF000(que utilizan los dos MSB de los 16 de la union) a no ser que de antemano los dos MSB de la union se hayan tocado...(sólo se puede hacer desde datoLeerPIC16.palabra14 que es un int16, pero no lo he hecho en ningun momento...).
Saludos!
-
Hola saludos, me quedo alguna duda al leer un poco de esto, aca va:
el ICSP es distinto para pics 16f y 18f?? me refiero a qeu si la forma de grabacion ICSP cambia con el tiempo?; me explico mejor, tengo un grabador ICSP que es de hace mucho tiempo, y grababa como ultima novedad el 16f877a, y despues vi sus avances y ya grababa algunos 18f sin necesidad de incrementar ni hardware ni software, tons concluí que el ICSP no cambiaba y que serviria para adelante, si no es para todos para la mayoria de los pics que soporten ICSP.
sera correcto lo que pienso??
y que me dicen de lso ICSP de los dspic y otros?
-
Hola Cryn, lo que comentas no es asi... ICSP(In circuit serial programming) es el protocolo de grabación para los microcontroladores(DSPs, PIC24, etc.) de microchip. Pero en si no es un único protocolo para todos los dispositivos; es decir, es muy parecido para en la mayoria de dispositivos pero no igual... por lo que con un software de grabación que tenga implementado,unicamente, ICSP para PIC16F877A no puedes grabar pics de la familia 18. Espero haberte aclarado tu duda :lol:.
Continuando con lo anterior... creo que solucioné mi problema(eso espero); borré de antemano las dos uniones(la de escribir y la de leer) y parece que ahora funciona.
Esto es una pregunta genérica que no tiene nada que ver con ICSP y supongo que me podreis contestar facil: ¿Cuando se arranca un PIC, los valores que se encuentran dentro de cada variable(o delda de ram) son aleatorios(inesperados) o se inicializan a 0 por defecto (aunque no se haya hecho esto en el programa) ?...Creo que este fue mi problema.... :-)
Saludos!
-
Hola manwenwe, respecto a tu pregunta de si las variables se incializan por defecto a 0, normalmente si tu no le dices que se inicialize a 0, contendra el valor aleatorio que haya en la dirección de ram que ocupa tu variable, ahora si la inicializas en el código esta tendra el valor que le hayas puesto.
Con respecto al lo de mi programador, te comento que he diseñado tanto el hardware como el software de PC. El hardware esta basado en el GTP-USB+ de Sisco, con algunas modificaciones, aunque tengo pensado para la version 2.0 del hardware hacerlo con el 18F4550, para disponer de más lineas de datos, con vista a que pueda soportar más dispositivos a parte de los de microchip.
El diseño de mi programador esta hecho de forma que pic del programador reciba del software del PC, los comandos necesarios para hacer la programación del dispositivo a programar, es decir, lo unico que hace es recibir los comandos de pc y serializarlos correctamente para enviarselos al dispositivo que vamos a programar. Con esto lo que pretendo conseguir es que el programador sea lo mas rapido posible y que permita con el mismo firmware programar muchos dispositivos, ya que del trabajo "pesado" se encarga el software de pc (Por ejemplo el ICD2 de microchip cada vez que cambias de dispositivo tiene que meterle un firmware que entienda la programación de ese dispositivo y esto la verdad no me gusta pq se pierde bastante tiempo, sobre todo cuando tienes que estar programando todo el dia distintos micros).
Respecto al tema de si puede influir que te falle la verificación por tener el programador montado en una placa perforada, pues la verdad no se que decirte, pero no creo que para las señales que se manejan sea muy critico el que este unido con cablecitos, pero podria ser una de las causas.
En cuanto a la rutina que usas para la lectura, en principio la veo bien, pero yo no lo haria asi tal cual lo has puesto, usaria un bucle for para leer los 14bits (ahorrarias algo de código), pero vamos solamente es una sugerencia. De todas formas no tengo mucha experiencia con la programación de la serie 16F, ya que yo empece con la programación de la serie 18F que es la que más uso. Ahora que ya acabe con la serie 18F (bueno tengo sorportados 60 micros de esta serie) estoy empezando con la serie 16F.
Saludos.
PD: Perdón por el ladrillo de respuesta.
-
Hola omix,
PD: Perdón por el ladrillo de respuesta.
Nada más lejos de la realidad, realmente todo lo que escribes siempre es de gran ayuda! Lo que comentas sobre mi rutina para leer(la de escribir es similar): tienes razón hubiese ahorrado código si en vez de utilizar unsigneds de 1 bit, hubiese usado un array de enteros por ejemplo(porque está claro que no se puede utilizar un array de bits) pero lo he hecho simplemente por ahorrar ram(prefiero esto a ahorrar código) y porque el código sea más facil de leer...
En cuanto a lo que comentas sobre el tiempo de grabación... a mi también me parece algo crucial, pero por ahora mi proyecto de programador no tira demasiado: estoy comunicandome con un modulo maestro USB a 1.25Mhz y el PIC trabaja a 4 Mhz(aunque pienso subir ambas frecuencias a 10 y 40 Mhz respectivamente) y con esto lo más que consigo es grabar un PIC16F877 completo(flash y eeprom llenas) y verificado(los errores de grabación, lectura del USB, adaptación del .Hex, etc) en 38 segundos, que es más o menos el doble de lo que me tarda en grabar WinPic800 desde el PC.
Prové a grabar la memoria entera del PIC con datos dummy y tarda más o menos 14 segundos, por lo que se ve claramente que la carga de tiempo se la lleva el PIC tratando los datos(el modulo USB es capaz de entregar 64kbps) y contra eso no puedo luchar porque no se pueden comparar un PIC y un PC a la hora de procesar. Espero ganar algunos segundos más pero poca cosa...
Por último, yo estoy terminando con los 16F87X y por lo que he visto el resto de dispositivos flash de las series 16F, 14F y 12F se graban de forma muy muy parecida. Quiero empezar en una semana con los PIC18, he estado mirando algún datasheet(por encima) y veo que hay muchas diferencia: creo que es más dificil. Bueno, si te pones con los 16 y tienes alguna duda(por lo que sabes, no lo creo) estoy aquí para lo que haga falta.
Saludos y perdón igualmente por mi tostón.
-
Esto es una pregunta genérica que no tiene nada que ver con ICSP y supongo que me podreis contestar facil: ¿Cuando se arranca un PIC, los valores que se encuentran dentro de cada variable(o delda de ram) son aleatorios(inesperados) o se inicializan a 0 por defecto (aunque no se haya hecho esto en el programa) ?...Creo que este fue mi problema.... :-)
La RAM del pic se inicializa con 'basura' siempre que lo enciendes. Incluso con un reset también se puede cargar basura en la memoria RAM.
Ahora bien, cabe una aclaración. Los registros del PIC tienen un estado por defecto en el power on reset, y está indicado en el datasheet. Algunos bits estarán en 1, otros en 0 y otros "sin cuidado" o dicho de otra forma, se inicializarán como cualquier otra posición de memoria es decir en forma aleatoria.
Esta parte de inicialización de los registros del PIC es realizada por una microelectrónica interna del PIC que funciona cuando se hace un power on.
Hola manwenwe, respecto a tu pregunta de si las variables se incializan por defecto a 0, normalmente si tu no le dices que se inicialize a 0, contendra el valor aleatorio que haya en la dirección de ram que ocupa tu variable, ahora si la inicializas en el código esta tendra el valor que le hayas puesto.
omix disiento contigo. La memoria siempre se inicializa en valores aleatorios y es la microelectrónica del pic la que hace que algunos registros específicos se cambien a un estado de power on conocido.
Es por ello que podemos estar tranquilos que el Program Counter se inicializará en la posición 0x000 , que el status apuntará a la página 0, que el puntero del stack apuntará a la posición 0 (es decir que el stack estará vacío) , que los puertos estarán como entradas y como ello muchas otras cosas.
El que tu hagas por código una inicialización de algunas variables no significa que las mismas se inicialicen a 0, lo haces tú mismo "a mano" por decirlo de una forma. Es decir que es tu software el que lo hace posible pero no el pic.
-
omix disiento contigo. La memoria siempre se inicializa en valores aleatorios y es la microelectrónica del pic la que hace que algunos registros específicos se cambien a un estado de power on conocido.
Es por ello que podemos estar tranquilos que el Program Counter se inicializará en la posición 0x000 , que el status apuntará a la página 0, que el puntero del stack apuntará a la posición 0 (es decir que el stack estará vacío) , que los puertos estarán como entradas y como ello muchas otras cosas.
El que tu hagas por código una inicialización de algunas variables no significa que las mismas se inicialicen a 0, lo haces tú mismo "a mano" por decirlo de una forma. Es decir que es tu software el que lo hace posible pero no el pic.
Quiza me exprese mal, no queria decir que el pic inicializase automaticamente al valor que tu le pusieras a la variable, sino que si en el código pones por ejemplo :
int variable = 0x46;
El compilador va a generar el código necesario para que esa variable se incialice cuando comience la ejecución del programa (siempre que la variable sea global, de lo contrario se inicializara cuando se ejecute la función donde este declarada).
Un saludo.
-
Hola omix,
PD: Perdón por el ladrillo de respuesta.
Nada más lejos de la realidad, realmente todo lo que escribes siempre es de gran ayuda! Lo que comentas sobre mi rutina para leer(la de escribir es similar): tienes razón hubiese ahorrado código si en vez de utilizar unsigneds de 1 bit, hubiese usado un array de enteros por ejemplo(porque está claro que no se puede utilizar un array de bits) pero lo he hecho simplemente por ahorrar ram(prefiero esto a ahorrar código) y porque el código sea más facil de leer...
Hola de nuevo, te explico la forma en que leo yo los bytes cuando programo un micro de la serie 18F, por si te puede ayudar a mejorar tu algoritmo de lectura:
unsigned char Read(){
int8 i;
unsigned char data = 0;
TRISPGD = 1; //pin de datos como entrada
for(i = 8; i > 0; i--){
PGC = 1;
delay_us(DELAY_CLK);
data = data >> 1; //desplazamos para meter el siguiente bit en su posición correcta
if(PGD){ //Si es un 1 lo añadimos al byte
data = data | 0x80;
}
PGC = 0;
delay_us(DELAY_CLK);
}
DELAY_P5A;
return data;
}
Basicamente lo que hace esta función es para cada bit a leer (en mi caso 8bits), desplazo una variable incializada a 0 hacia la derecha (ya el pic envia los datos en formato LSB..MSB) y si el pin de entrada de datos es 1, entonces coloco un 1 en la posición correcta ( data = data | 0x80), si era un 0 no hace falta hacer nada puesto que la variable ya estaba inicializada a 0. Esto se repite para cada uno de los bits a leer y al final tendremos en la variable data el valor leido.
Una forma mas facil de ver el proceso:
Inicialmente: data = 0b00000000; i = 8; y supongamos que el valor que vamos a leer es 0b10111010 (0xBA)
Paso 1: i = 8; data = data >>1; //bit a leer 0b10111010
data = 0b00000000;
Paso 2: i = 7; data = data >> 1 //bit a leer 0b10111010
data = data | 0x80; //el bit es un 1 añadir a data
data = 0b10000000;
Paso 3: i = 6; data = data >> 1; //bit a leer 0b10111010
data = 0b01000000;
Paso 4: i = 5; data = data >> 1; //bit a leer 0b10111010
data = data | 0x80; //el bit es un 1 añadir a data
data = 0b10100000; //estado de data
....
Paso 8: i = 1; data = data >> 1; //bit a leer 0b10111010
data = data | 0x80; //el bit es un 1 añadir a data
data = 0b10111010; //estado de data
//salida del bucle
Espero que se vea claro el proceso.
Un saludo.
-
Ánimo omix y manwenwe se ve que le estais dando fuerte... lamento no poder echarte una mano ni entrar en la discusión por tener tiempo = 0
-
Gracias por tu consejo omix, veo que la función que has escogido es bastante más simple que la mia pero, hay algo que no entiendo: ¿no deberías usar un int16 en vez de un int8? Lo digo porque la palabra de un PIC18 es de 16 bits...
La verdad es que a conforme voy avanzando me doy cuenta de cosas que podía haber hecho mejor; por ejemlo, escribir de forma predictiva: si en vez de borrar el PIC y grabarlo entero, vas borrando y grabando("begin erase programming cycle" en vez de "chip erase" + ciclos de "begin programming only cycle") puedes ahorrar mucho tiempo, pues tienes la posibilidad de leer antes de escribir y si el valor es el mismo no escribes nada(leer siempre es más rápido que escribir :-/); de esta forma consigues que cuando se graba siempre el mismo código(ligeramente modificado) el tiempo de grabación sea mucho menor.... ¿Tú lo haces así?
En fin, queda claro que la primera vez que haces las cosas no salen como deberian... pero, al menos en mi caso, como se trata de mi PFC dejaré las mejoras para un futuro pues si no veo que no termino nunca :D.
Saludos
-
Permitanme Felicitarlos. Su trabajo, enrriquece mucho al foro.
FELICITACIONES y mucho ANIMO. :-/
Creo que ya ven el FIN.
-
Gracias por tu consejo omix, veo que la función que has escogido es bastante más simple que la mia pero, hay algo que no entiendo: ¿no deberías usar un int16 en vez de un int8? Lo digo porque la palabra de un PIC18 es de 16 bits...
Efectivamente un PIC18 tiene una palabra de 16bits, pero en el caso de la serie 18F se lee un byte por cada comando de lectura enviado, es decir, el pic no te devuelve directamente un dato de 16bits sino que para leerlo tienes que hacer dos lecturas de 8 bits: comando lectura + dato 8bits (0) y devuelve dato 8 bits + comando lectura + dato 8 bits (0) y devuelve dato 8 bits.
La verdad es que a conforme voy avanzando me doy cuenta de cosas que podía haber hecho mejor; por ejemlo, escribir de forma predictiva: si en vez de borrar el PIC y grabarlo entero, vas borrando y grabando("begin erase programming cycle" en vez de "chip erase" + ciclos de "begin programming only cycle") puedes ahorrar mucho tiempo, pues tienes la posibilidad de leer antes de escribir y si el valor es el mismo no escribes nada(leer siempre es más rápido que escribir :-/); de esta forma consigues que cuando se graba siempre el mismo código(ligeramente modificado) el tiempo de grabación sea mucho menor.... ¿Tú lo haces así?
Yo tampoco lo hago asi, yo borro el micro y luego lo programo. No se el ahorro de tiempo que se conseguira (seria cuestión de probarlo), pero tal cual tengo hecho el programador, grabo un 18F6722 al completo (128KB flash + 1KB eeprom + fuses + IDs), en un tiempo de 37s y la lectura completa me tarda unos 19s. Desde mi punto de vista creo que es un tiempo bastante bueno, de todas formas estaria bien probar la otra forma de grabación a ver si se consigue algo de mejora.
En fin, queda claro que la primera vez que haces las cosas no salen como deberian... pero, al menos en mi caso, como se trata de mi PFC dejaré las mejoras para un futuro pues si no veo que no termino nunca :D.
Saludos
Si, como solemos decir los informaticos, lo primero que funcione bien, luego ya vendran las mejoras.
Saludos.
-
Gracias por tu consejo omix, veo que la función que has escogido es bastante más simple que la mia pero, hay algo que no entiendo: ¿no deberías usar un int16 en vez de un int8? Lo digo porque la palabra de un PIC18 es de 16 bits...
Efectivamente un PIC18 tiene una palabra de 16bits, pero en el caso de la serie 18F se lee un byte por cada comando de lectura enviado, es decir, el pic no te devuelve directamente un dato de 16bits sino que para leerlo tienes que hacer dos lecturas de 8 bits: comando lectura + dato 8bits (0) y devuelve dato 8 bits + comando lectura + dato 8 bits (0) y devuelve dato 8 bits.
La verdad es que a conforme voy avanzando me doy cuenta de cosas que podía haber hecho mejor; por ejemlo, escribir de forma predictiva: si en vez de borrar el PIC y grabarlo entero, vas borrando y grabando("begin erase programming cycle" en vez de "chip erase" + ciclos de "begin programming only cycle") puedes ahorrar mucho tiempo, pues tienes la posibilidad de leer antes de escribir y si el valor es el mismo no escribes nada(leer siempre es más rápido que escribir :-/); de esta forma consigues que cuando se graba siempre el mismo código(ligeramente modificado) el tiempo de grabación sea mucho menor.... ¿Tú lo haces así?
Yo tampoco lo hago asi, yo borro el micro y luego lo programo. No se el ahorro de tiempo que se conseguira (seria cuestión de probarlo), pero tal cual tengo hecho el programador, grabo un 18F6722 al completo (128KB flash + 1KB eeprom + fuses + IDs), en un tiempo de 37s y la lectura completa me tarda unos 19s. Desde mi punto de vista creo que es un tiempo bastante bueno, de todas formas estaria bien probar la otra forma de grabación a ver si se consigue algo de mejora.
En fin, queda claro que la primera vez que haces las cosas no salen como deberian... pero, al menos en mi caso, como se trata de mi PFC dejaré las mejoras para un futuro pues si no veo que no termino nunca :D.
Saludos
Si, como solemos decir los informaticos, lo primero que funcione bien, luego ya vendran las mejoras.
Saludos.
Si no es molestia podran poner el codigo que estan haciendo para grabar??
O al menos enviarmelo al privado??
Me interesa para el proyecto del PLC con PIC, por eso los molesto con esta pregunta... :mrgreen: :mrgreen: :mrgreen: :mrgreen:
-
Sin problemas... llo que llevo hecho(que tampoco es mucho :D) no estará terminado del todo hasta como minimo una semana más. Ahora mismo está por terminar, sin comentar y muy desordenado... cuando lo ordene en librerias te lo mando por el privado(tampoco es cuestión de colgar en el post 3000 lineas de código...).
Saludos
-
Gracias!!! :-/ :-/ :-/ :mrgreen:
-
Con lo de modificar solo los valores cambiados no se gana mucho ya que tambien hay que leer todo el pic .
Aqui esta el codigo fuente del PICkit 2 que puede ayudar .
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1960
-
Con lo de modificar solo los valores cambiados no se gana mucho ya que tambien hay que leer todo el pic .
Hola Sispic, lo acabo de pensar mejor y la verdad es que tienes razón. Ejemplo, en un 16F87X, si utlizas el commando "begin programming only cycle" puedes progamar 8 palabras en un 1ms... si tuvieses un código lleno de 8000 palabras donde sólo cambiase la última palabra, leerias las 8000 palabras(yo tardo en leer unos 80us/palabra) y sólo escribirias 1 con lo que mas o menos ahorrarias: 8000*125us = 1 seg (sin tener en cuenta los tiempos para leer cada palabra y para poner otra en los latches, que se compensan).... es decir NADA!
Como ya comenté antes, mi programador tarda en grabar un PIC más o menos el doble que WinPic800 pero igualmente comenté que no es lo mismo que un PIC a 4Mhz se coma todo el trabajo a que lo haga un Pentium a 3Ghz :D... Creo que no tengo mucho que ganar intentado modificar mi algoritmo...
Saludos y gracias por el link.
-
Hola mis queridos compañeros.
Yo hase tiempo queria haser un software de programacion de pic, cuando no eran gratuitos y habia que comprarlos, investigue lo nesesario para darme cuenta que no era capas y encontre el icprog y listo para que mas jaja.
Pero encontre una pagina con una aplicacion en delphi con los codigos fuente y e estado esperando para saber lo suficiente para lograrlo, pero ya que no pude creo que a ustedes si les podra servir el archivo es el famoso nopp bajo windows, esta ecaha en DELPHI y compila con el Delphi 5 la direccion de descarga es:
http://www.lsis.com.ar/files/nopppw.zip
LA pagina del autor es:
http://www.covingtoninnovations.com/noppp/index.html
Bueno espero les halla servido bye :-/