Programador de PICs (Solo Enigma)

[f_point]

En vista a la sugerencia de elmasvital de probar el PIC18F2550 y para eliminar posibles errores asociados que se pudieran dar, hice una prueba de caracter mucho mas exhaustivo con el PIC18F2550. He aqui mis resultados:

En general la programacion se realiza bien en el dispositivo, posiblemente la unica
discrepancia observada es que existen 4 bytes en las palabras de configuracion que
no estan implementados en el 2550, y que, cuando el software carga el .hex, los deja
en 0xFF pero al leer el dispositivo son 0x00. Estos bytes estan en las direcciones
300004h, 300007h, 30000Eh y 30000Fh (que corresponderian a CONFIG3L, CONFIG4H,
CONFIG8L y CONFIG8H respectivamente).

Sin embargo estas aparentemente son ignoradas por el software (en todo caso el PIC
debe ignorarlas tambien) y no se genera error alguno a pesar de que son diferentes.
Esto no es mayor problema despues de todo, ya que son palabras no usadas y su valor
realmente no importa. Fue por esta razon que di por bueno el soporte para este
dispositivo, porque funcionalmente todo esta bien.

Quizas debo agregar que, al parecer, el software en su version actual (11/12/07) no
parece hacer verificacion alguna sobre ningun byte de las palabras de configuracion
del 18F2550, y que por las mismas circunstancias este pequeño "glitch" pasa
desapercibido.

Insisto, de acuerdo a mis pruebas el 18F2550 se programa y borra correctamente.

Tambien hice pruebas adicionales con el software unicamente, pero esta vez en vez de
cargar un archivo .hex y verificar que las palabras de configuracion se graben
correctamente en el PIC he decidido ver (con hoja tecnica a la mano) si al seleccionar
las banderas de configuracion desde el software se generan bien los campos de bits.
Esta vez encontre uno que otro glitch menor:

- Las opciones para el "system clock postscaler" o bits <4:3> de CONFIG1L
(300000h) aparecen siempre asumiendo que el PLL esta desactivado. Aqui la
observacion seria que estos bits significan algo diferente cuando se activa el
PLL (hay una tabla adicional indicando los otros significados). Quiza sea bueno
cambiar el contenido de el listbox correspondiente para reflejar las opciones
mas adecuadas segun la configuracion actual del oscilador (segun si se elige
un modo con PLL activado o no).
- La opcion "Stack Full/Underflow Reset" o bit <0> de CONFIG4L (300006h) no
establece el bit 0 de la palabra correspondiente en la columna derecha, sino
mas bien establece el bit 1. Asimismo, la opcion se queda "pegada" y aunque se
seleccione la otra alternativa, el listbox siempre mostrara la alternativa
anterior, posiblemente debido a que no se cambia el bit adecuado.

Esto seria todo de momento. Espero que mis pruebas sean de ayuda para todos y para poder refinar este proyecto.

Saludos.

 

[elmasvital]

Tienes razon en tus observaciones pero debe haber algo que se nos escapa... pq de hecho el chip sigue ok despues de varios intentos de programación. Y hay ejemplos de zif hechos y de venta comercial que usan los pines 14 y 18 (vusb en el 2550 y 4550 respectivamente) y no se han descritos problemas con el usb de esos chips.

http://www.winpic800.com//descargas/REV2/ZIF_10_12_16_18_24_93_rev2.pdf

1 saludo

 

[Eclip-se]

Hola a todos, y sigan adelante con el diseño del programador utilizando el zócalo ZIP.

Les informaciónrmo que ya esta listo la versión para programar algunos AVRs.

Solo estoy tratando de hacer funcionar los 2 PWM al mismo tiempo, obtengo las 2 señales pero todavía no obtengo una frecuencia adecuada. Además leyendo el Data Sheet, creo qué siempre funcionan a la misma frecuencia. En nuestro caso seria a la del PWM que genera la 13V.

Si alguien tiene más experiencia con esto de los PWM, y sabe si es posible trabajar con diferentes frecuencias seria bueno que lo comente.

Por que creo que XTAL1 debe ser de una determinada frecuencia según la configuración del cristal externo.

 

[f_point]

Encuentro esto del Vusb muy pero muy raro... seguro que se nos escapa algo elmasvital. Tengo un amigo que cuenta con el programador que citas en el pdf (que consiguio por un precio, claro esta), y segun él programa toda clase de dispositivos sin problemas. Sin embargo, aun no se si el ha probado programar PICs con USB, asi que no me consta realmente que los PIC18F2550/4550 realmente funcionen.

Lo que si puedo compartir es una experiencia mia, usando el ICD2 y una base ZIF generica como la que estan diseñando para programar el PIC18F4550. De acuerdo al manual de la base ZIF, debes doblar ls patita VUSB del 4550 de tal forma que quede fuera de la base ZIF cuando lo introduces, luego lo programas y doblas la patita de regreso a su posicion original. Obviamente encontre muy poco atractivo tal procedimiento tan inortodoxo, y busque formas alternativas para no tener que doblar la patita y arriesgarme a dañar el PIC, ya que me percate de que si introduces el 4550 y no doblas la patita, el VUSB se conecta a tierra y corres un tremendo riesgo de dañarlo.

Tan tremendo es el riesgo que tuve que verificarlo por mi mismo... por accidente. Hace un par de dias cuando hice multiples pruebas con el programador de Eclip-se, tuve a la mano el ICD2 para poder borrar, verificar, y en general, ayudarme para hacer las pruebas con un programador distinto con la buena intensión de obtener resultados mas confiables. Lamentablemente en una de tantas, introduje accidentalmente el 4550 en la base ZIF del ICD2 sin excluir el VUSB. Para mi sorpresa windows me dijo que el "dispositivo USB no funciona correctamente" refiriendosea al ICD2, y de inmediato procedi a ver que pasaba. Tras unos breves segundos me percate de que el PIC18F4550 bajo programacion estaba excesivamente caliente, asi que desconecte el programador completo del USB para evitar dañar incluso la PC. Luego cai en cuenta que no segui las indicaciones de la base ZIF...

Por fortuna tanto el programador como el PIC y el puerto USB de la PC sobrevivieron al percance (hubiera sido una gran perdida averiar el USB o el programador). Pero me percate de cuan terriblemente peligroso era no tener en cuenta el pin VUSB al programar estos PIC.

Mi base ZIF funciona diferente de todas las otras, y curiosamente tiene abierto el pin 14 cuando la pones en modo de 28-40 pines, asi que el PIC18F2550 se puede programar sin riesgo alguno.

Apuesto a que lo que ocurre es que el PIC se enciende por breves instantes, y a lo mejor el regulador de voltaje esta siempre apagado (por casualidad) cada vez que se programa. Cuando el regulador se apaga, no importa si se aterriza el pin VUSB, y esa salvedad puede estar ayudando a no generar fallas.
Por otra parte, si el PIC se enciende por breves instantes solo para ser programado, a lo mejor no tenga tiempo suficiente para dañarse, ya que en mi caso duro alrededor de 8 segundos hasta que me percate de que se calento en exceso y aun asi, no sufrio daño aparente.

Estare pendiende de que puede ser la causa de este misterio...


Por otra parte, gracias Eclip-se por la nueva version. Acabo de conseguirme un AT90S2313 que fue extraido de un aparatito por ahi. No se si realmente sea compatible de momento, pero vere en otro momento los nuevos modelos soportados.

En cuanto a los PWM, yo he tenido una que otra oportunidad de usarlos. Segun veo en la hoja tecnica, el modulo CCP del PIC18F2550 es casi identico al de la serie 16F salvo una serie de ampliaciónes al circuito de salida por parte del CCP1 ampliado, lo que permite configuraciones en modo puente y su uso en circuitos de potencia.

Sin embargo la base de generacion de tiempo es identica para cualquier modo, y acabo de constatar que tiene las mismas limitaciones de su predecesor: La frecuencia esta determinada para ambos CCP por el modulo Timer2 (seccion 15.1 de la hoja tecnica, tabla 15-2). Sin embargo el ciclo de trabajo para cada CCP esta separado.

Si necesitas excitar dos circuitos separadamente, me temo que tendra que ser a la misma frecuenc¡a (salvo que usaras 2 PICs). Sin embargo no todo esta perdido, ya que se puede controlar individualmente el ciclo de trabajo (duty cycle) de cada PWM. Si conectas dos multiplicadores de voltaje separados por ejemplo, puedes ajustar el voltaje de salida por medio de controlar unicamente el ciclo de trabajo y no necesariamente con la frecuencia del PWM. De hecho en teoria es preferible ajustar el ciclo de trabajo y no la frecuencia, debido a la generacion de armonicos, ya que porciones de tu circuito pueden funcionar como antenas (un cable o una pista muy larga, o una carga inductiva muy pesada como un motor) y si quieres colocar los armonicos en frecuencias no interferentes es mas facil hacerlo con la frecuencia constante y variando el ciclo de trabajo y no al reves.

Por el valor del cristal yo no me preocuparia, siempre y cuando se elija el prescaler del PLL de tal forma que se generen los 48MHz que necesita el modulo USB. Si se elige un modo de oscilador con el PLL activado, tanto el CPU como los perifericos corren a la misma frecuencia sin ningun problema, permitiendo generar las mismas frecuencias de PWM y los mismos retardos (via "nop" por ejemplo) con el CPU. Como comente la vez pasada, esto permitiria usar cristales de 4, 8, 12, 16 y 20MHz indistintamente.

Espero mis comentarios sean de ayuda.

 

[Adriancpc]

Hola a todos...
Tristemente mi programador JDM serie dejo de funcionar en "mi" computadora, por lo que decidi comprarme uno por puerto paralelo cuando magicamente fui a parar con el programador eclipse y me parecio una excelente idea, asi que me puse a investigar y ando con muchas ganas de hacerme uno, pero antes queria hacer unas preguntitas....

La version esquematica mas reciente y comprobada es la que esta en descarga -> Hardware -> PDFs -> Esquematico con fecha 27/10/2007 ?

Lei que no grababa el 16f877 pero que pensabas implementarlo proximamente, la pregunta es si esto sigue en pie y a q tan proximamente te referis (no es mi intensión apurarte ni nada parecido) pero es que tengo varios 16f877 pero ningun 16f877A por eso si pensas que te va a faltar mucho para implementarlo te agradeceria que me lo digas asi me compro un 16f877A y listo.

Saludos y Felicitaciones por el bien que estas haciendo a esta comunidad...

Adrian

 

[elmasvital]

F_point a ti te programa los 2550 el eclipse sin problemas? en mi caso en un gran numero de ocasiones se graban con errores al pic. Si lo grabo con eclipse y luego lo compruebo con el te-20//winpic o icd2/mplab me dan errores de verificación.

Luego haciendo una comparación (por ejemplo con el programa pspad) del hex original y el que se grabó en el pic se ven leves diferencias aleatorias entre si... no siempre estan en los mismos sitios. Y dudo que sean los 2550 que esten estropeados pq cuando grabo con te20 o icd2 siempre verifican perfectos.

Por cierto esto grabando directamente con cables icsp no con el zif que estoy diseñando.

1 saludo.

 

[f_point]

En efecto el PIC18F2550 se programa bien para mi usando el programador de Eclip-se. Salvo por un par de pequeños glitches que mencione la vez pasada (que no afectan en mayor medida el funcionamiento del programador), el contenido del archivo .hex pasa 100% integro a la memoria del PIC. Lo he comprobado correctamente con el ICD2 y todo al parecer marcha muy bien. Incluso he probado en varias ocasiones grabando diferentes programas (incluido el mismo firmware de Eclip-se y uno que otro programa mio) y en todas las ocasiones el PIC18F2550 se ha borrado y re-programado correctamente.

Si algunas localidades generan fallos mientras otras no, y ademas te falla al borrar el dispositivo completo (y siendo que el PIC esta en buen estado), entonces para mi suena como el clasico sintoma de que el voltaje de programacion (VPP) que llega al PIC es insuficiente. Has checado los voltajes que te genera el programador? Pon el software en modo de prueba y sin ningun PIC conectado al programador mira los voltajes entregados en el conector ICSP segun haces click en los checkbox. El programador te permitira controlar cada pin ICSP individualmente asi como los LED. Usa un voltimetro digital de preferencia para hacer las medidas, y recuerda poner tu voltimetro en una escala de arriba de 20V para cuando midas VPP. Verifica que en los siguientes pines hayan los siguientes voltajes:

VDD (VCC): 0 o 5 voltios segun el checkbox.
VPP: 0 o 13V (segun checkbox)
PGD (DAT): 0 o 5V
PGC (CLK): 0 o 5V
VSS (GND): 0V - Naturalmente aqui va el negativo del multimetro para toda medida.

Y una pequeña lista de posibles anomalias si algo va mal:
- Si en VDD obtienes menos de 4.7V (cuando deberia haber 5V) entonces hay un problema con la alimentacion del USB.
- Si en PGC y/o PGD no obtienes un voltaje identico a VDD (cuando deba haber 5V) entonces el puerto del PIC podria estar dañado. Lo mismo si obtienes arriba de 0.2V cuando deba haber 0V.
- Si el VPP esta por debajo de 12.8V entonces tu doblador de voltaje tiene problemas (habria que analizar el caso con mas detalle).

Mi sospecha es que esa ultima anomalia sea la que estes viendo.

Haz tus mediciones, y cuando tengas los resultados, haremos mas diagnosticos.

 

[elmasvital]

Las tensiones las descarto... yo las veo bastante aceptables... 12,85 vpp y vdd en 4,90.Además otrs pics los programa sin aparente problema como el 16f628. Voy a soldarle un condensador de desacoplo a ver si funciona mejor... al icd2clone le hizo falta.

Edito para decir que ahora si "parece" a falta de mayores pruebas... que el problema de grabación del que hablaba ha desaparecido con el condensador de desacoplo de 100nf entre VDD Y GND

1 saludo

 

[f_point]

Que bueno que el problema indica una tendencia a resolverse. Es curioso, pero que no hay de por si un capacitor de 1uF (C7) entre VDD y tierra? Solo curiosidad

A proposito, Eclip-se menciono que la nueva version con soporte de AVR ya estaba lista, pero fui a su sitio web (http://www.eclip-se.es.tl/) y encontre que aun no hay actualizaciones en la seccion de descarga. Sera que esta en otra parte? O a lo mejor entendi mal y aunque esta lista todavia no la ha publicado?

 

[QuimCri]

Que tal camaradas.

Hace un tiempo me interesé en construir el programador que Eclip-se nos brindó.

Como los computadores que hay en mi casa son de última generación, y tienen WinVista, me había surgido la duda de si funcionaría.

Hasta hace poco tuve tiempo, y en estos dias termine un montaje en la protoboard.

Lo he probado en mi laptop y el programador es reconocido, puedo hacer las pruebas de hardware, el reconocimiento y la lectura de datos del dispositivo, en primera instancia.

Sin embargo, cuando me dispongo a programar, vienen los problemas:

El proceso de programación va bien, aparentemente, mientras se graban los datos en el micro (lo he probado hasta ahora con PIC16F84A, PIC16F873A y PIC16F877A, que son los que tengo a mano); pero cuando se procede a la verificación, el programa deja de funcionar, y Windows lo cierra, por seguridad.

Pero después de eso, el programador "se muere". No se que carajos será, pero abro el programa, y al intentar realizar las pruebas de hardware otra vez, aparece que el programador no está conectado.

La verdad hasta ahora lo he probado con la versión de software anterior, porque hasta hoy volví a revisar el foro y me di cuenta que cambió de hosting, y el software. Voy a probar con el nuevo a ver que pasa.

Solo quería contarle lo que me ha pasado, para ver si le sirve de algo esa información y me pudiera ayudar.

Saludos y agradecimientosa todos, y FELIZ AÑO.

 

[f_point]

Que tal QuimCri, te agradecemos mucho que pruebes el programador bajo Windows Vista. Por lo visto el programador no ha sido probado sino hasta ahora en ese OS (salvo que en algun otro foro?), y el hecho de ver señales de vida bajo vista es un excelente indicador de que el programador deberia funcionar bien.

En cuanto a los errores que obtuviste, asegurate de tener la version mas reciente de todo: hardware, software y firmware. A lo mejor haya problemas viejos en las versiones anteriores que Eclip-se ya haya resuelto.

Si todavia tienes problemas en Vista tras actualizar, asegurate de que todo marcha bien con Windows XP, de forma que los problemas que tengas sean asociables unicamente con Vista y no con WinXP. Si aun tienes problemas bajo XP, entonces deberas buscar lo que anda mal y resolverlo. Una vez te funcione al 100% bajo XP, entonces cambiate a Vista y veremos lo que pasa.

Estaremos aqui para ayudarte en caso que tengas problemas. Yo he conseguido armar mi programador y hacerlo funcionar correctamente, ademas los otros amigos del foro han tenido exito tambien, y podremos compartirte un poco de nuestras experiencias.

A proposito elmasvital, tu mencionas algo de que al programador icd2clone le hizo falta un capacitor... existe tal cosa como un clon del ICD2? Serias tan amable de comentarme mas al respecto de ese programador? Se mira muy pero muy interesante

 

[elmasvital]

Que tal QuimCri, te agradecemos mucho que pruebes el programador bajo Windows Vista. Por lo visto el programador no ha sido probado sino hasta ahora en ese OS (salvo que en algun otro foro?), y el hecho de ver señales de vida bajo vista es un excelente indicador de que el programador deberia funcionar bien.

En cuanto a los errores que obtuviste, asegurate de tener la version mas reciente de todo: hardware, software y firmware. A lo mejor haya problemas viejos en las versiones anteriores que Eclip-se ya haya resuelto.

Si todavia tienes problemas en Vista tras actualizar, asegurate de que todo marcha bien con Windows XP, de forma que los problemas que tengas sean asociables unicamente con Vista y no con WinXP. Si aun tienes problemas bajo XP, entonces deberas buscar lo que anda mal y resolverlo. Una vez te funcione al 100% bajo XP, entonces cambiate a Vista y veremos lo que pasa.

Estaremos aqui para ayudarte en caso que tengas problemas. Yo he conseguido armar mi programador y hacerlo funcionar correctamente, ademas los otros amigos del foro han tenido exito tambien, y podremos compartirte un poco de nuestras experiencias.

A proposito elmasvital, tu mencionas algo de que al programador icd2clone le hizo falta un capacitor... existe tal cosa como un clon del ICD2? Serias tan amable de comentarme mas al respecto de ese programador? Se mira muy pero muy interesante

Pues existe tal cosa si... en www.icd2clone.com es un icd2 totalmente funcional como el de microchip pero sin gastarte 100€.

Sobre lo que comentas de los condensadores 1uf y el que he puesto de 100nf. El de 1uf estara pensado para que no caiga la alimentación o muy bajas frecuencias, el de 100nf justo soldado a las patillas de vdd y gnd está pensado para filtrar armonicos de alta frecuencia. Además el primero es electrolitico que en alta frecuencia se comporta casi como una bobina, y desaparece la capacidad, a parte de tener una tolerancia por fabricación de -50% a +20% por lo general.

En definitiva se busca el condensador que haga resonancia con el armónico a eliminar segun el teorema de fourier, que he de confesar tampoco soy un experto en la materia. Los expertos dicen 100nf a todo chip digital y mas con fuentes conmutadas.

1 saludo.

 

[golumx]

Hola a todos, veo que teneis muy desarrollado el tema, pero yo sigo en el mismo punto, no es que no me programe algun tipo de micro, es que no lo detecta, mi programador parece no existir para mis ordenadores, tengo uno con XP y otro con Vista, he vuelto a realizar todo el proceso desde el principo, pero nada, hasta me he hecho la placa nueva por si tenia algun corto y no me habia dado cuenta, pero nada, despues de dar varias vueltas por Madrid en busca del conector USB tipo B que estaba agotado en todos sitios.....lo he encontrado, pero nada de nada. Tambien he cambiado de micro por si estaba dañado, lo he grabado con el art2003 y me lo borra, graba, verifica y detecta correctamente pero el programador no funciona. Haber si algun alma caritativa me hecha una mano y me puede indicar donde cometo el error, por que lo que esta claro es que el esquema funciona, a lo mejor hay que refinarlo un poco, pero funciona correctamente. Aqui os dejo una foto del ultimo montaje realizado. Solo comentar dos cosas, no detecto 13v ni algo parecido en ninguna combianacion de los jumpers ni se enciende ningun led y los puertos USB funcionan correctamente y detectan impresoras y ratones sin problemas. Ya solo queda agradeceros los conocimientos y trabajo aportado.

 

[elmasvital]

Segun veo los puentes de los selectores estarian mal... mira el esquema del pcb y verás que tienes seleccionado para vpp 5v y el control de vdd lo tiene en OFF...

la configuración correcta para los PICS seria segun se ve en la foto tu lo tendrias asi
--00
00--

y la configuracion correcta seria

00-- --> 13v
0--0 --> VDD AUTO si no alimentas el pic de forma externa.

De todas formas este error que te comento no deberia afectarte a que el programador sea detectado por el pc y los test de hardware de las luces deberian funcionar... Si eso no te lo hacia antes tienes algun otro error. Prueba las continuidades de las pistas... a veces se ven bien pero no lo están. Quita el pic y conecta el usb y mira si llegan los 5v entre vcc y masa.


1 saludo

 

[f_point]

Pues existe tal cosa si... en www.icd2clone.com es un icd2 totalmente funcional como el de microchip pero sin gastarte 100€.

Sobre lo que comentas de los condensadores 1uf y el que he puesto de 100nf. El de 1uf estara pensado para que no caiga la alimentación o muy bajas frecuencias, el de 100nf justo soldado a las patillas de vdd y gnd está pensado para filtrar armonicos de alta frecuencia. Además el primero es electrolitico que en alta frecuencia se comporta casi como una bobina, y desaparece la capacidad, a parte de tener una tolerancia por fabricación de -50% a +20% por lo general.

En definitiva se busca el condensador que haga resonancia con el armónico a eliminar segun el teorema de fourier, que he de confesar tampoco soy un experto en la materia. Los expertos dicen 100nf a todo chip digital y mas con fuentes conmutadas.

1 saludo.

De hecho he sabido tambien que el capacitor electrolitico tiene una respuesta no deseada a altas frecuencias, posiblemente debido a que su funcionamiento interno es de caracter mas bien electro-quimico y no electrostatico, como en el capacitor ceramico. Probablemente los portadores de carga tengan que esperar un tiempo para propagarse internamente (de ahi que no supriman las altas frecuencias), y no puedan acumularse y quedar atrapados instantaneamente en el campo electrico, como ocurre en el ceramico (que responde bien a alta frecuencia).

De ahi que se usan normalmente en combinacion para suprimir el ruido en todas las bandas. Que bueno que el capacitor te echo una mano e hizo lo suyo

Gracias por guiarme hacia el icd2clone, dentro de unos dias me movere para hacerme de uno de esos tambien ^_^. Como siempre, debere hacerme de inductores extra. Me cuesta creer que siendo algo tan comun, los inductores sean tan dificiles de conseguir en tiendas al por menor.


En cuanto al programador de golumx, me parece bastante raro que ni siquiera windows detecte el dispositivo... es como si el PIC completo estuviera muerto. Normalmente cuando un PIC es conectado al USB y no funciona bien, como minimo el mismo windows te dice que "el dispositivo no funciona correctamente y no se instalo". Ademas, con el simple hecho de encender el PIC, parece que lo primero que hace el firmware es encender los led verde (programador listo) y rojo (power).

Las sugerencias de elmasvital son muy acertadas, verifica todas las conexiones: no solo que no haya cortocircuitos, sino tambien que no haya desconexiones (pistas rotas).

Si electricamente todo va bien, verifica que el PIC obtenga alimentacion del USB (5V). Si la tiene, entonces probablemente el PIC este averiado y solo funcione bajo modo de programacion (ya he visto unidades que se averian y quedan asi). Si tienes acceso a un osciloscopio de gran velocidad (de unos 100MHz quiza), verifica que en el oscilador de cristal haya señal de clock. A veces el PIC parece muerto y es precisamente porque el oscilador no arranca (y por eso funciona en modo programacion, ya que usa un oscilador interno).

Lo bueno de cuando las cosas no funcionan ni siquiera al minimo es que para arreglarlas los errores son basicos y a menudo muy faciles de observar y reparar. Lo malo es que ni a los mas experimentados se les ocurre a veces que lo que pasa es que olvidaron prender el switch.

Bueno, en tu caso no hay switch de poder, pero sabes a que me refiero.
Buena suerte con tu programador.

 

[Residente]

Hola a todos, tengo el programador ya terminado, el otro dia descubri que se ablaba sobre el programador en este foro, despues de leer las 18 paginas.. tengo algunas dudas aclaradas, aunque sigo teniendo alguns problemas.
el programador al conectarlo al pc (win xp) lo detecta dice que hay un dispositivo aunque da error en la instalacion, el led d estatus se enciende ok y el bicolor se pone en verde.
al abrir el software de programacion de eclipse he intentar hacer las pruebas de hadware dice que no dispositivo conectado.
he medido tensiones y tengo:
vdd: ~4.7 v
vpp: 0.8 v
clk: ~4.7v
dat: ~4.7 v
se que tendria que tener los 13v en vpp. he repasado el circuito y esta bien, tengo continuidad en todas las pistas.
al montarlo he tenido q sustituir el 2N3906 por un BC257 que es equivalente por lo demas todo bien.
que me aconsejais que haga?
gracias a todos.

foto:

http://img211.imageshack.us/my.php?image=programadorhd0.jpg

 

[Eclip-se]

Hola a todos. Gracias por sus comentarios me sirven mucho para mejorar el programador.

Antes de pasar con la corrección de los problemas reportados. Estoy finalizando la versión que permite programar algunos AVRs. Ya lo he probado con el ATMEGA16 y creo que con sus versiones de menor o mayor capacidad también pueden funcionar.

Descarte la posibilidad de usar el PWM para generar la señal XTAL1, como mencionaba f point solo se puede trabajar a una frecuencia fija. Y en nuestro caso seria la del PWM que genera los 13 Voltios.

Entonces decidí utilizar un timer para generar la frecuencia. El problema esta que al cambiar la configuración para utilizar un cristal externo, al usar por ejemplo un cristal 8Mhz, la señal XTAL1 que genero ya no funciona. Eso quiere decir que la frecuencia de XTAL1 debe ser menor a la frecuencia del cristal seleccionado. Por lo que ahí vamos a tener un problema cuando se elija cristales de un valor alto.

La máxima frecuencia que se puede generar con los 20Mhz creo que esta al rededor de 3Mhz.

En ningún lado del Data Sheet del AVR indica que frecuencia del XTAL1 usar, pero creo que lo que estoy asumiendo tienen algo de verdad.

En los primeros días de Enero ahí subo la nueva versión para que lo puedan probar.

Ahora si me dedicare a corregir los errores, y gracias f point por los detalles en los reportes de errores.

También seguiré viendo la forma de adicionar los PIC 16F877 y sus familias.

Y con respecto al error del programador, si no se instala correctamento los DRIVE (proceso que se realiza automaticamente); nada del programador va a funcionar por que no se esta estableciendo una comunicacion USB. Primero asegurate de que se instalen los DRIVE, debe ser una maquina con S.O. Win Xp Profesional, Servi Pack 2.

 

[f_point]

Hola Residente, aparte de lo que Eclipse indico, me gustaria agregar tambien que tuve un problema muy similar al tuyo cuando ensamble mi programador.

Yo obtenia exactamente lo mismo: Conectaba el programador al USB y se prendia el led de "power" (rojo) y el bicolor se prendia en "Listo" (verde). Entendi que el firmware del 2550 lo hace inmediatamente tras el arranque y posiblemente como parte de su inicializacion.

Sin embargo del lado de Windows me decia "Nuevo hardware Encontrado" en el tipico globito que sale al fondo. Y tras unos segundos me decia "Ha ocurrido un error durante la instalacion" (o algo asi). Eso me ocurria cuando lo tenia armado en protoboard, y entendi que ocurria debido al excesivo ruido que habia en la misma. Basicamente era un problema de aterrizado el que habia (consegui eliminarlo de una forma muy poco ortodoxa), y por eso decidi migrarlo a un circuito impreso, acercando el conector USB lo mas posible a los pines del PIC que manejan el USB.

Desde que lo arme en impreso, todos los problemas desaparecieron para mi... aunque veo que en tu caso persisten esos problemas.

Asi que mis consejos son:
- Asegurate de que todas las pistas esten limpias, y que no haya residuos de resina (o pasta) entre las soldaduras (causa #1 de ruido). Si tu programador tiene residuos, puedes usar Thinner con much cuidado para eliminarla. El thinner es tan potente que puede disolver la resina aun cuando se cristaliza, y de paso hasta puede sacar brillo al cobre.
- Verifica que tu conector USB tenga los contactos limpios, tanto en la placa base como el cable (ambos extremos) y el programador. Si los ves sucios, usa contact cleaner para limpiarlos todos (solo asegurate que sea un contact cleaner de secado rapido y que NO deje residuos). Naturalmente todo debera estar apagado cuando lo limpies.
- Finalmente, si la limpieza no funciona, cambia tu cable USB. Ese es el tramo mas largo que esta propenso a ruido. Hay cables que son tan malos que apenas llevan unos hilitos que fingen ser la malla protectora. Cambialo por uno que tenga al menos un "papel de aluminio" como excusa de malla. Los mejores son los que tienen mallas gruesas de puro cable como blindaje por supuesto, de esas que lo cubren al 100%.
- Si no puedes encontrar un mejor cable, entonces mira si puedes encontrar uno mas corto. Un cable corto te genera menos ruido a pesar de ser malo. Y sino, trata de acortarlo tu mismo. En mi pais puedo encotrar cables de refaccion por solo $1.50 (USD) y no da la mas minima lastima arriesgarse a echarlo a perder (mas bien a aprovecharlo de una mejor forma).

Aun cuando no lo creas, a un amigo mio le funciono la cuarta (ultima) alternativa. El corto el cable por enmedio, hizo un empalme provisional (soldado) que cubrio con simple cinta aislante. Como lo dejo de apenas un par de centimetros, el programador le funciono correctamente. Debo agregar que el usa una laptop, y que no le importo realmente dejar el programador a centimetros de la misma (de hecho le gusta mas asi).

Espero mis comentarios sean de ayuda.

 

[Residente]

Muchas gracias por las respuestas, si tengo el xp servi pack 2. y como dice f_point me sale el globito pero diciendo que tiene un problema el dispositivo.
he limpiado todas las pistas de nuevo, estan todas brillantes jeje, ademas no utilizo pasta de soldar, los unicos residuos que tenian eran del insolado, la capa verde sobre el cobre, que sale facil con alcohol.
tambien he estañeado algunas pistas mas finitas que habia aunque todas tiene continuidad.
el conector usb lo recicle de una impresora, los pines estan todos bien, he puesto el cable usb y con el polimetro he comprabado los contactos desde el porgramador al otro extremo donde va al pc, he cambiado de usb y lo mismo, la unica opcion que me queda es cortar el cable, porque el que utilizo esta apantallado.
bueno si ya mañana probare aver que tal.
saludos a todos y gracias de nuevo

 

[f_point]

Olvide mencionar una forma adicional para ver si un cable USB es de mala calidad.

Puedes usar un multimetro (tester) en modo de medicion de resistencia (ohmetro), procura que sea digital, pues son mas exactos y es esa exactitud la que buscamos. Ademas, necesitamos que pueda medir hasta una decima de Ohmio, es decir, menos de 1 Ohmio.

Ahora junta las puntas del ohmetro y mira cuanto mide en la escala mas baja. Si tu ohmetro es de los buenos, probablemente marque como 0.5 Ohm (o cualquier valor entre 0 y quiza unos 2 Ohm). No te alarmes si mide mas de 0 a pesar de que lo cortocircuitas (aunque deberia marcar 0), probablemente sea debido a que la unidad esta un poco vieja y lo que mide es la resistencia total entre los contactos internos de su perilla (si tiene una), los conectores de las puntas, y los cables de las puntas en si.

Puedes hacer medidas muy precisas aunque no marque 0, simplemente anota (o memoriza) el valor que lee cuando unes las puntas. Ahora de todas las mediciones que hagas, restale el valor de que mediste inicialmente. La diferencia, es la resistencia exacta que estamos midiendo.

Con este metodo, mide la resistencia del cable USB entre sus dos conectores, midiendo los pines que deberian estar conectados entre si.

Si el cable te mide exactamente 0.0 Ohm en sus 4 lineas (la diferencia de restar el valor inicial da 0, es decir, da lecturas identicas), entonces tienes un cable que conduce perfectamente.

Si la diferencia es entre 0.1 y 0.2 Ohm, la resistencia es aceptable y el cable es de buena calidad. Si mide mas de 0.3, mejor ve pensando en probar con otro cable. Y si te mide algo exagerado como 1 Ohm, cambialo de inmediato sin dudarlo (y de paso culpar al cable).

Lastima que con este metodo solo podemos medir conductividad... no la inmunidad al ruido, pero bueno, algo es algo no?

A lo mejor este otro tip sea de ayuda.