Posts filed under 'Electrónica'
Para mi proyecto he decidido cambiar el 16F84 por un 16F628, que segun todo el mundo son iguales, compatibles, y de hecho uno es el heredero del otro. El 16F628 tiene USART hardware como ya he comentado anteriormente, tiene comparadores analógicos, un reloj interno medio decente, el doble de memoria y puede convertir, si es necesario, en entradas o salidas 16 de sus 18 patillas.
Lo que me costó comprender es que una de sus nuevas caracteristicas, la programación a bajo voltaje (LVP), inhabilita una de las patillas del puerto B.
No comprendía por que este chip, que se supone compatible con el 16F84, no funcionaba correctamente en mi circuito entrenador cuando le conectaba el LCD. Todo era por el LVP.
Esto se arregló poniendo en la directiva #fuses el parámetro NOLVP para que no usase la programación a bajo voltaje.
La otra decepción me ha surgido al comprobar que la USART hardware siempre usa las patillas B1 y B2 para la transmisión y recepción serie. Alguien me había comentado que se podian definir otras patillas, pero no es cierto. Si redefines las patillas el compilador se pone en modo USART por software y entonces dejan de funcionar las interrupciones que se generan cuando se reciben datos o cuando el buffer de salida está vacío.
Esto me impide usar el LCD de mi entrenador para probar el circuito de enlace por infrarrojos con la USART hardware ya que B1 y B2 se usan para manejar el LCD.
En fin, que tendré que rediseñar el circuito con el nuevo patillaje y ponerme a montar el circuito final rezando para que me funcione bien a la primera y sin contar con la inestimable ayuda debugeadora que proporciona el LCD.
Además, el hecho de que las 8 patillas de salida que necesito se dividan en diferentes puertos me van a complicar un poco la programación, pero supongo que los problemas de software siempre serán lo mas sencillo de solucionar para mi.
Diciembre 22nd, 2004
Demostrando una vez mas lo paquete que soy, he tardado casi un mes en poner en práctica el circuito que me sugerian en las news de electronica para hacer un enlace de datos por infrarrojos. Pero al fin puedo decir que ha funcionado.
Primero tuve que hacer funcionar un LCD con el PIC para poder ver los resultados de la conexión. El display de 7 segmentos no era suficiente 
. Usando las librerías del CCS C me fabriqué un cable segun las especificaciones, 4 bits de transmisión, uno para el estrobe, otro para el RS y uno mas para el RW. Como eran 7, decidí añadirle uno mas para completar las líneas del puerto B que es el que iba a controlar el LCD. El Backlight del LCD se controlaría mediante la línea 3. Algo así:
| B0 |
B1 |
B2 |
B3 |
B4 |
B5 |
B6 |
B7 |
| Enable |
RS |
RW |
Backlight |
Data4 |
Data5 |
Data6 |
Data7 |
Al hacer las pruebas de este circuito, quemé un LCD por conectarle por error 12V en lugar de los 5 que soporta. En fin, solo era el principio de mis problemas. Una vez logré hacer funcionar el LCD me tocó hacerme con un fotoreceptor para la comunicación por infrarrojos.
Al ir a la tienda y pedir un fotorreceptor el dependiente me dijo que no me lo daba si no le llevaba el nombre del componente.. menudo capullo. Me hice una lista con todos los fotorreceptores que encontré por internet que me podian valer en orden de idoneidad.
- TEMT1000 o TEMT3700, ambos con filtro IR y de 3mm de diámetro
- BPW85 o BPW42, espectro visible 3mm de diámetro
- BPW96 o BPW40, espectro visible 5mm de diámetro
Me acerque a otra tienda distinta, no tenian ninguno de estos pero me dieron uno que se parecia al BPW40, era como un LED de alta luminosidad, transparente y de 5mm. Estuve 3 dias probandolo en un circuito hasta que gracias a Root, de es.ciencia.electronica, y a la camara de fotos, comprobé que no era un fotodetector sino un simple LED IR (los leds IR se pueden ver como lucen a traves de la pantalla de una cámara digital).
Volvi a Conectrol con mi lista de fotoreceptores, y los muy mamones me dicen que solo tienen el BPW40. ¿para eso me hacen confeccionar la lista? Encima el único que tienen es el peor de los que tenía en mi lista. En fin.
Unos dias mas tarde y muchas pruebas después (un LED IR quemado incluido) probé por fin el circuito emisor y luego el receptor.
El emisor lo saqué de la página de Lirc (Linux IR Control) y es el mas sencillo de los que presentan. El receptor me lo “diseñó” pepitof de es.ciencia.electronica (el del programador PIPO2) y es casi mas sencillo aún.
El conjunto es tal que así:
No voy a entrar en los detalles del funcionamiento. Simplemente diré que funciona y ya está.
Con el Hyperterm de windows me conecté por el puerto serie con los siguientes parámetros: 8 bits, Paridad Par, 1 bit de parada.
Eso si, no he conseguido que vaya a mas de 1200 baudios, ya que cualquier tipo de luz, tal y como lo tengo montado ahora, le afecta y provoca errores. Si me hubiesen dado un TEMT1000 las cosas serían distintas, ya que este solo es sensible al infrarrojo.
De hecho, en la prueba de la foto del LCD, hay un caracter raro al final de la frase “Hola Mundo”. Es por culpa del flash de la cámara en el disparo anterior.
El código en C para hacer funcionar el programa es muy sencillo y lo teneis en la captura de pantalla de arriba. Como el post ya es muy largo no me detendré mas en el. Si alguien lo quiere por alguna razón que me lo pida, pero vamos, es una tontería.
Diciembre 7th, 2004
Mis peripecias continúan, ultimamente con no demasiada fortuna. He tratado de instalar un precioso LCD azul que tenía por aquí, en una placa de pruebas para conectarlo al 16F84, pero utilicé un adaptador de molex para alimentarlo que me sacaba el voltaje de la línea de 12V de la fuente de alimentación y lo hacía con hilos de color rojo y negro. Eso me hizo confiar en que se trataba de 5V y la consecuencia nefasta es que ahora tengo un precioso LCD azul que no funciona, aunque si se enciende
Por otro lado me tome la libertad de poner en marcha una práctica muy habitual entre los electrónicos caseros (y de otros no tan caseros) de pedir muestras gratuitas a los fabricantes de integrados, que gentilmente las donan con la intención de que tus prototipos se conviertan en aparatos de producción masiva que lleven sus chips dentro. Le pedí a Microchip samples de 3 de sus PICs, el ya conocido 16F84A, su sucesor el 16F628A y otro con mas entradas y salidas el 16F873A. Y aqui están, me han llegado, gastos de envio incluidos, tan solo 4 días despues de pedirlos. ¡Mis primeros samples! A ver cuanto tardo en quemarlos.
Entre tanto he seguido empapandome de información y he descubierto que una de las tareas que necesito realizar para mi proyecto no es tan trivial como creia al principio. Esa tarea es la de enviar datos por el puerto serie del ordenador al PIC para que este los reciba y los represente. Para realizarlo se necesita lo que en los PCs conocemos como una USART (Universal Synchronous/Asynchronous Receiver Transmitter) y para conseguir una podemos optar por una de estas 3 vias:
- Programarla por software en el PIC para que con el timing adecuado sea capaz de decodificar los pulsos y convertirlos en bytes mediante técnicas llamadas de bit-banging o 1/3rd bit polling. (O bien usar la librería de USART virtual del compilador CCS, que ya trae el trabajo hecho).
- Hacernos con un integrado que realice esta taréa y nos entregue los bytes en paralelo, como el 8251.
- Usar un PIC que lleve incorporada una USART.
Dado que el 16F84 no tiene USART, y como era lo que yo tenía, en principio pensé en usar el método software para decodificar la señal serie. Este método presenta varios inconvenientes, y es que no solo te deja mucho menos espacio en la memoria de programa para tu propio software, sino que ademas es un proceso que demanda mucho tiempo y al PIC le queda muy poco para atender al resto de tareas que queramos tratar de ordenarle.
Conseguir una USART externa tampoco era una opción, demasiados chips para lo que trato de hacer.
Por eso mi pedido de samples incluia un 16F628, por que el sucesor del F84 SI lleva una USART incorporada, aunque desgraciadamente la linea RX de recepción de datos coincide con la misma patilla que el bit 2 del puerto de salida B (RB2), y necesito los 8 bits del puerto B para salida. Pero esto es algo que se puede arreglar.
Si alguien que entienda un poco de esto que estoy hablando me lee, que no me golpee, por favor. Ya se que necesito un MAX232 o 233 o similar para convertir a niveles TTL que usa el PIC lo que saca el puerto serie (TIA/EIA-232-F) o una alternativa mas engorrosa aunque mas barata. Pero no, no me golpeeis aún, que el enlace lo voy a hacer por infrarrojos 
Noviembre 16th, 2004
Seguimos con las tribulaciones electrónicas de un chispas novatillo, después de que hace unos dias aprendiese a base de leches (calentitas, eso si) que no se debe descuidar la posición de un pic en un zocalo.
Si lo alimentas al revés, se ¡¡QUEMA!!.. con olorcillo a torrefacto y todo 
Hoy hablaré de los displays de 7 segmentos, una cosa de lo mas antigua pero que aún se usa bastante para aplicaciones sencillas y para que los principiantes hagamos ejercicios tan inútiles como estúpidos, pero que tienen su terenguendengue (R).
Todos los que hayais tenido un 286, un 386 (sx o normal), o un 486, recordareis el botón de ‘turbo’ que tenía el ordenador. Era como lo que se viene ahora a llamar un ‘overclocking’ pero que venia de serie. Simplemente le dabas al botón y el ordenador iba el doble de rápido, a 8 o 16 Mhz, a 16 o 33Mhz, a 33 o 66Mhz, la velocidad se representaba en la caja mediante el equivalente prehistórico al moderno LCD. Un display de 7 segmentos de 2 dígitos.
Como tengo varios de esos vestigios del pasado en mi chatarrería personal, he decidido hacer algo con ellos ahora que estoy aprendiendo a programar PICs.
Lo primero que he descubierto es, aparte de que su nombre es debido a que se componen de 7 leds y que cada uno de ellos se nombra con una letra, que los hay de dos tipos. Los de ánodo común y los de cátodo común.
Se diferencian en que en los primeros, una sola línea de entrada alimenta a todos los leds que configuran el display y son los cátodos, la patilla negativa, los que salen en número de 7 (8 si contamos el punto decimal). En los segundos es justamente al revés, cada led es alimentado por separado mediante 7 u 8 líneas y es el cátodo el que junta a todos y sale uno solo.
Parece una diferencia tonta, pero a la hora de conectarlos al circuito hay que hacerlo todo al revés, por eso, como yo me estaba fijando en un circuito que usaba un display de cátodo común, lo primero que hice fué comprobar de que tipo era el mio.. en efecto, justo lo contrario de lo que necesitaba, era de ánodo común.
Me fabriqué un cable a partir de uno de disquetera de PC que conectaba mi minientrenador de PIC al display con las conexiones correctas. No solo activo las lineas del display, también le paso por ese cable la corriente necesaria para el ánodo común mediante la activación de RB7 (la patilla 8 del puerto B, el cable verde que se ve en la foto).
Ahora, ya pasandome al C, que el ensamblador sigue dandome sarpullido, escribí lo siguiente:
// Miniprograma “Aprendiendo a contar”
// Usa un display de 7 segmentos anodo comun para contar del 0 al 9
// de manera indefinida
// El display está conectado al PORTB
//
#include <16F84.h>
#USE DELAY( CLOCK=4000000 ) /* Usamos un reloj a 4 Mhz */
#FUSES XT,NOWDT,NOPROTECT,NOPUT
/* Usamos XT mode, No Watch Dog, No Code Protect, No Power-up Timer */
#byte port_b=6 /* define la posicion del registro port_b */
#byte port_a=5 /* define la posicion del registro port_a */
// Mi display es de ánodo comun y recibe la alimentacion por el RB7 (1on 0off)
// Para activar un led el bit se debe poner a 0, con 1 se desactiva
// Así que este es el mapa de leds para cada dígito del 0 al 9
byte CONST LED_MAP[10] = {0xC0,0xF9,0xA4,0xB0,0×99,0×92,0×82,0xF8,0×80,0×98};
//byte CONST LED_MAP[10] = {0×3f,0×06,0×5b,0×4f,0×66,0×6d,0×7d,0×07,0×7f,0×6f};
//
main()
{
byte cnt, right,num ;
set_tris_b(0); /* Pone el port_b de salida */
set_tris_a(0); /* Pone el port_a de salida */
port_b = 0xFF; /* FF port_b = alimento el LCD & port_b */
port_a = 0×00;
// Lo repito hasta que me aburra
while(1)
{
// Aprendamos a contar con coco
for (cnt=0;cnt<10;cnt++)
{
port_b = LED_MAP[cnt];
DELAY_MS(1000); /* Un segundo entre numeros */
}
}
}
Ale, a compilar, al programador y de ahí, el chip al entrenador.
¡Ya se contar en PIC!
Noviembre 7th, 2004
Ha costado mas de lo que pensaba. He tardado bastante en encontrar algun sitio donde me dijeran como podía montar un circuito simple con un 16F84 para hacer pruebas, lo que se llama un “entrenador”.
Lo único que tenía claro es que el chip se alimenta con entre 3 y 6 voltios, por lo que tenía que buscar una fuente de alimentación que me diera alrededor de 5V. Me he apañado una fuente de alimentación de PC que uso para pruebas y que entrega 5 y 12V y le he puesto un conector para poder enchufarle corriente a la protoboard.
Tambien sabía el patillaje, gracias al datasheet de Microchip, el fabricante.
Luego un poco a lo bestia he colocado en la protoboard el zocalo, 3 leds y me he puesto a cablear las salidas del puerto A (el 16F84 tiene 2 puertos de salida, el A, de 5 bits, y el B, de 8 ) a los leds y la alimentación y masa del chip (pata 13 y 5).
Para probarlo, y harto de que el CCS me diese continuamente un error de “Unknown device type” sin motivo aparente, me remangué y me puse a compilar un ejemplo en ensamblador muy simple, que activaba todas las líneas de los puertos de salida. Como yo tenía conectados 3 leds a las líneas de menor peso del puerto A, deberían encenderse los 3 leds.
Ensamblé el programa con el MPASM directamente (en efecto, el MPLAB TAMPOCO me funcionaba bien) y subí el programa al PIC con el IC-Prog y mi recien creado PIPO2.
Monté el PIC sobre la proto board y encendí la fuente de alimentación, con gran desilusión.. allí no pasaba nada de nada. Podía ser cualquier cosa, el programa, el circuito, yo que se.. pero me acordé de un montaje con un PIC que vi hace poco y miré el esquema que tenía.
Basicamente me faltaba un cuarzo entre CLKIN y CLKOUT y conectar el master clear MCLR a la alimentación mediante una resistencia de 10k. ¡Que suerte! ¡El cuarzo y las resistencias las compré el otro día!
Lo puse y.. ohhhhhhh, que bonito, los leds se encendían. Probé otro par de códigos, leds parpadeando, leds en relevos y ya, convencido de que esto funciona, lo dejé para dormir un poco, que si me meto a hacer modificaciones en los programas no me acuesto en toda la noche.
Cuando lo monte en serio ya pondré todos los condensadores y resistores que se supone que tengo que poner en el circuito de pruebas. De momento, a dormir, que me lo he ganado.
Noviembre 1st, 2004
Como no tengo suficientes cosas que hacer , voy a aprovechar este largo fin de semana para aprender todo lo posible sobre microcontroladores (PIC), que es algo que me ha llamado siempre la atención pero que se me antojaba demasiado difícil.
El empujón definitivo me lo ha dado el hecho de que mi próximo proyecto de modding va a necesitar un PIC, entre otras muchas cosas, para funcionar como quiero.
Para ello lo primero que necesito es un programador de PICs, que es un circuito que se conecta a un puerto del ordenador, en mi caso he elegido uno serie, y que permite trasladar los programas al chip, que luego los ejecutará autonomamente sobre el circuito en el que los pongamos.
Me he fabricado uno que se llama PIPO2, diseñado por Jose Manuel García y que es compatible con el JDM, uno de los mas usuales. PIPO2 permite programar muchos tipos de pics, aunque yo de momento solo tengo un par de 16F84. He usado una placa board y no puedo decir que me han costado los componentes por que el despistado que me atendió en la tienda se olvidó de cobrarme el conector DB9, el transistor BC547 y ¡LOS DOS PICS!. Espero que siempre sea así . De todos modos no llegó a los 3 Euros.
Ni el PIPO2, ni ningun JDM, funcionan en portátiles ya que la alimentación la toman directamente del puerto serie y en los portatiles este no da mas de 6V, y se necesitan al menos 7.5v. Esto me ha fastidiado un poco por que ya me parecía ver una utilidad a este portatil HP que tengo muerto de risa por que la batería no le funciona.
Bueno, construí el circuito y funcionó a la primera, leí el chip, lo borré y lo verifiqué. Todo perfecto, siempre que uno se acuerde de apretar bien el integrado dentro del zócalo (al principio no me funcionaba por eso).
Para programar un PIC hacen falta dos pasos, en primer lugar crear el código ensamblador y pasarlo a binario (en un fichero .BIN o .HEX) que puede ser generado a partir de un programa en C (compilado) y en segundo lugar hace falta guardar ese código en el chip, lo que se hace con un programa como icprog en Windows o prog84 en Linux, aunque este último no me ha funcionado bien con el PIPO2.
Ahora que ya tengo el programador hecho y el icprog lo reconoce, me queda aprender a programar el pic. Me parece que voy a ir directamente al C que es lo que conozco, usando el CCS C (nada que ver con las hojas de estilo chicos ) , y voy a pasar bastante del ensamblador, que nunca me ha gustado.
Seguiré contando..
Octubre 31st, 2004
Next Posts
