Sensor temperatura + PIC18F2550 + comunicación USB

Esta es una aplicación muy sencilla en base al PIC18F2550 usando la comunicación USB para la conexión y transferencia de datos bidireccionales entre la plataforma Linux y un sensor/actuador final.

Consiste de un integrado LM335 como sensor de temperatura, conectado a una puerta de entrada análoga del 2550 y unos diodos leds conectados a una puerta digital de salida. Estos leds cumplen la tarea de verificar la operación del firmware grabado en el PIC.

La comunicación PIC - PC (Linux) se establece por medio de USB 2.0

En el ambiente Linux se pueden ocupar dos programas para leer la información de temperatura del sensor:

a) Un programa para consola, que entrega el dato leido en grados centígrados.

b) Un programa para ambiente gráfico, ocupando GTK + Glade, crea una ventana donde se despliega en forma continua el dato leido en grados centígrados.

Primero veamos el Hardware:



El PIC18F2550 y el sensor LM335 se alimentan de la linea de 5V que se origina en el puerto USB del PC.

El cristal usado es de 20MHz con la red RC de 1M + 2*22pF.

Los capacitores C1 y C4 desacoplan la fuente de alimentación principal y el voltaje USB.

R1 aparece como pull-up de la linea de MCLR, pero es una costumbre de cuando ocupaba el microcontrolador 8031.

R7 y R8 se colocaron para corregir un problema que aparecio en las primeras etapas de implementación, cuando la puerta USB del PC-Linux no mantenía el reconocimiento/enumeración del dispositivo y enviaba todo al limbo y más allá.

El diodo LED D2 se ocupa como señal "heart beat", parpadea rapidamente en la etapa inicial de conexión/reconocimiento/enumeración de la puerta USB y luego permanece con un ciclo de 1 Hz al establecer el canal de comunicación.

Los diodos LED D3 y D4 son testigos del tipo de transferencia ocupada: Feature, Report.

El punto de operación del sensor de temperatura LM335 está dado por el valor de R2, de acuerdo al valor típico de corriente sugerido en la hoja de datos de este integrado.

La señal de voltaje modulada por la temperatura se aplica a la entrada análoga AN0. El sensor se encuentra cerca del PIC y no es necesario blindar o acondicionar esta señal.

Veamos los resultados:

Corriendo sobre Ubuntu Karmic en un notebook Lenovo G450.
La ejecución y respuesta del programa para consola.



La ejecución y respuesta del programa para ambiente gráfico.
Se ocupó GTK y el editor Glade para diseñar la ventana. En esta aplicación la lectura se refresca en forma automática cada segundo. Al picar en el botón "Leer" se invoca una lectura instantanea.



Ahora el Software:

a) El Firmware para el PIC18F2550.

Proviene del firmware de Alexander Enzmann (2005), adaptado a MCC18 por Alberto Maccioni (1/8/09). El código lo volví a re-adaptar a SDCC (22/06/10) para poder ocupar la dupla SDCC+PIKLAB y programar en un Pickit 2 Clone versión "Felixls".

Este firmware establece al PIC como un dispositivo HID.

El código fue modificado para incluir el proceso de conversión analogo-digital y establecer el mecanismo y formato de la entrega de los datos leidos.

b) Los programas para la plataforma Linux.

Inicialmente las pruebas se realizaron con el codigo en C del programa de comunicación de Maccioni para su firmware. Este programa ocupa capacidades del sistema, tales como llamadas a /dev/hiddev , ioctl, etc. junto con estructuras de datos para la entrada y salida.

El código fue resumido para ocupar las funciones mínimas de comunicacion USB y transferencia de datos de acuerdo al firmware de adquisición AD que se programó en el PIC.

Una vez que se logró la comunicación PIC-USB-PCLinux mediante el empleo del programa bajo consola, se escribió un programa para Gnome+GTK que ocupara el ambiente gráfico. En realidad no aporta al objetivo básico del proyecto PIC-USB, pero mejora la presentación y aumenta las posibilidades de otros desarrollos en base a este proyecto.


Ahora tengo que ver donde alojar los programas fuente mencionados, para compartirlos con ustedes.

Voy a eso.


OK.
Aquí, el Esquemático en pdf.

http://www.megaupload.commegaupload.com/?d=85Y5OOP3

Aquí, el Firmware USB PIC.

http://www.megaupload.commegaupload.com/?d=SR55LX5G

Está completo, como un proyecto PIKLAB, con los programas fuente en C, los archivos .h y los productos de la última compilación. Incluye el archivo PICUSBFW.hex para grabarlo en el PIC.

Aquí, los programas para el PC Linux.

El archivo "Makefile" se ocupa para la construcción del programa "leeadcpic" que usa el ambiente gráfico. Se construye en consola con "make all"

El archivo "leeADCPIC.c" es el fuente del programa para consola. Se compila en consola con gcc.

Son versiones de arduo trabajo, así que el código es a lo menos desordenado y faltan mas indicaciones de qué está ocurriendo. En la próxima lo voy a dejar más presentable.

http://www.megaupload.commegaupload.com/?d=ZNPMEPWL


Saludos
EOL

Hola.

Llevo días probando con diferentes códigos de diferentes proyectos de comunicación USB con el SDCC v2.9 en un pic 18f4550 con un cristal de 4MHz. Tome el código que subiste y lo probé. Solo cambié el pll de 5 a 1 para que se ajustara al cristal que estoy utilizando.
Lo compilé de la siguiente manera:

Código:


sdcc -mpic16 -p18f4550 --debug  -c usb.c
sdcc -mpic16 -p18f4550 --debug  -c PICUSBFW.c
sdcc -mpic16 -p18f4550 --debug -Wl-m -Wl-c -o main.hex usb.o PICUSBFW.o libio18f4550.lib libsdcc.lib


Cuando compilo el usb.c el compilador me da el siguiente mensaje:

Código:


usb.c:804: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG


Una ves que programo el pic y lo ejecuto, checkeo el archivo /var/log/messages y me da lo siguiente:

Código:


May  9 21:10:55 El-Shaddai kernel: [115588.584034] usb 2-1: new full speed USB device using uhci_hcd and address 7
May  9 21:10:56 El-Shaddai kernel: [115589.150039] usb 2-1: new full speed USB device using uhci_hcd and address 8
May  9 21:10:56 El-Shaddai kernel: [115589.672059] usb 2-1: new full speed USB device using uhci_hcd and address 9
May  9 21:10:57 El-Shaddai kernel: [115590.196045] usb 2-2: new full speed USB device using uhci_hcd and address 10


y el dmesg me da lo siguiente:

Código:


[116210.977884] usb 2-1: new full speed USB device using uhci_hcd and address 11
[116211.096039] usb 2-1: device descriptor read/64, error -32
[116211.320531] usb 2-1: device descriptor read/64, error -32
[116211.536040] usb 2-1: new full speed USB device using uhci_hcd and address 12
[116211.656537] usb 2-1: device descriptor read/64, error -32
[116211.880061] usb 2-1: device descriptor read/64, error -32
[116212.096050] usb 2-1: new full speed USB device using uhci_hcd and address 13
[116212.504035] usb 2-1: device not accepting address 13, error -32
[116212.616034] usb 2-1: new full speed USB device using uhci_hcd and address 14
[116213.025992] usb 2-1: device not accepting address 14, error -32
[116213.026024] hub 2-0:1.0: unable to enumerate USB device on port 1
[116658.616047] usb 2-1: new full speed USB device using uhci_hcd and address 15
[116658.736540] usb 2-1: device descriptor read/64, error -71
[116658.964541] usb 2-1: device descriptor read/64, error -71
[116659.180752] usb 2-1: new full speed USB device using uhci_hcd and address 16
[116659.300033] usb 2-1: device descriptor read/64, error -71
[116659.528552] usb 2-1: device descriptor read/64, error -71
[116659.744546] usb 2-1: new full speed USB device using uhci_hcd and address 17
[116660.152521] usb 2-1: device not accepting address 17, error -71
[116660.264536] usb 2-1: new full speed USB device using uhci_hcd and address 18
[116660.672538] usb 2-1: device not accepting address 18, error -71
[116660.672572] hub 2-0:1.0: unable to enumerate USB device on port 1


Probé en windows donde tengo instalado el libusb-win32 y lo que me dice es que el sipositivo no tiene VendorId ni ProductId.

Probé con un código para PICC (CCS) que hice para otro proyecto y este funciona perfectamente en el mismo PIC lo cual me indica que no hay ningún problema de hardware interno o de conexiones externas.

Si tienen alguna idea de cual podría ser el problema se los agradesco.

José Pablo:
Recién leí tu mensaje. Voy a probar en mi sistema, con las modificaciones que mencionas para el 4550, a ver que resultados tengo.

Saludos
eol

José Pablo:

Algunos resultados:

Cuando compilo el usb.c el compilador me da el siguiente mensaje:

Código:

usb.c:804: warning 110: conditional flow changed by optimizer: so said EVELYN the modified DOG

Este mensaje tambien me aparece al compilar el codigo fuente en PIKLAB. Indica algun grado de optimizacion en una cadena de if - else, de una seccion de codigo para depuracion que no esta activa.

Otro mas:

Hasta el momento, el compilar para el 2550 o el 4550, produce archivos ".hex" identicos.
Solo difieren en el byte de programacion del fuse "config1L" que cambia de 0x04 a 0x00. El byte en ese archivo ".hex" es el numero 16743.

Lo anterior usando las lineas de comando SDCC que construye PIKLAB, ahora voy a ver si tu metodo de compilacion en consola produce alguna diferencia.

Saludos
eol

p.s. quedo debiendo las tildes de los acentos.

José Pablo:

Mas resultados:

Con tu comando para el PICUSBFW.c

sdcc -mpic16 -p18f4550 --debug -c PICUSBFW.c

obtengo el mismo código objeto ".o" que con el PIKLAB, solo difieren en un byte de "time stamp" que se va alterando en cada compilacion.

Igual comportamiento con el comando para el usb.c

sdcc -mpic16 -p18f4550 --debug -c usb.c

Con el mensaje de EVELYN ...

Veamos la etapa del linker:

sdcc -mpic16 -p18f4550 --debug -Wl-m -Wl-c -o main.hex usb.o PICUSBFW.o libio18f4550.lib libsdcc.lib

Algo ocurre, puesto que genera archivos ".hex" distintos.

root@lenovo-laptop:~/PIC/USB# cmp -b main.hex ./temporal/PICUSBFW.hex
main.hex ./temporal/PICUSBFW.hex son distintos: el byte 595, en la línea 16 es 61 1 62 2

Ahora activando la opcion "verbose"

root@lenovo-laptop:~/PIC/USB# sdcc -mpic16 -p18f4550 -V --debug -Wl-m -Wl-c -omain.hex usb.o PICUSBFW.o libio18f4550.lib libsdcc.lib
+ "/usr/bin/gplink" -I"/usr/bin/../share/sdcc/lib/pic16" -I"/usr/share/sdcc/lib/pic16" -I"/usr/bin/../share/sdcc/lib" -I"/usr/share/sdcc/lib" -m -c -w -r -o main.hex usb.o PICUSBFW.o crt0i.o libio18f4550.lib libsdcc.lib libdev18f4550.lib libsdcc.lib
message: using default linker script "/usr/share/gputils/lkr/18f4550.lkr"
root@lenovo-laptop:~/PIC/USB#
root@lenovo-laptop:~/PIC/USB# cmp -b main.hex ./temporal/PICUSBFW.hex
main.hex ./temporal/PICUSBFW.hex son distintos: el byte 595, en la línea 16 es 61 1 62 2

Da más información de los paths y librerías, pero continua la diferencia.

Voy a reordenar la linea de comando, para que se vea similar a la linea que ocupa PIKLAB:

root@lenovo-laptop:~/PIC/USB# sdcc -mpic16 -p18f4550 -V --debug -Wl-c -Wl-m -omain.hex PICUSBFW.o usb.o libio18f4550.lib libsdcc.lib
+ "/usr/bin/gplink" -I"/usr/bin/../share/sdcc/lib/pic16" -I"/usr/share/sdcc/lib/pic16" -I"/usr/bin/../share/sdcc/lib" -I"/usr/share/sdcc/lib" -c -m -w -r -o main.hex PICUSBFW.o usb.o crt0i.o libio18f4550.lib libsdcc.lib libdev18f4550.lib libsdcc.lib
message: using default linker script "/usr/share/gputils/lkr/18f4550.lkr"
root@lenovo-laptop:~/PIC/USB#
root@lenovo-laptop:~/PIC/USB# cmp -b main.hex ./temporal/PICUSBFW.hex
main.hex ./temporal/PICUSBFW.hex son distintos: el byte 16743, en la línea 384 es 60 0 64 4

Ahora, el ".hex" se parece al original, con solo la diferencia de programacion en el fuse.
Solo con cambiar el orden de los ejecutables para linkear: primero el PICUSBFW.o y despues el usb.o

Tendrias que hacer algo similar en tu sistema y ver si esto sirve para aproximarte a la solucion del inconveniente.

Saludos.
eol

Gracias por la ayuda pero aún asi no funcioná. No tengo idea de cual puede ser el problema ya he probado cuando proyecto de USB con sdcc que he encontrado en internet y en todos es el mismo problema, no es posible enumerarlo. En windows dice que es que no tiene vendorId ni productId pero ni idea de como arreglarlo.

Solo le funcionan los ejemplos en CCS y yo necesito SDCC para migrar un proyecto de CCS a SDCC.

Si alguien tiene algún proyecto FUNCIONANDO EN PIC 18F4550 que me lo pueda pasar y replicar las conexiones externas (incluido cristal) para ver si logro hacerlo funcionar seria de gran ayuda.

Tengo dudas de si será algún problema de la version del compilador, yo tengo la version

Código:


sdcc -v
SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Feb  3 2010) (UNIX)


Con cual version del compilador hay probado algún código para usb que si funcione en el 48F4550??.

Gracias de todos modos.

Mae no lo vas a creer. El problema estaba en el linker, cambie el archivo 18f4550.lkr con uno que baje en otro proyecto que utiliza la clase CDC-ACM y funcionó perfectamente.

Estoy utilizando gputils y la version es:

Código:


gplink -v
gplink-0.13.7 beta


Cual linker utilizas vos??. Para ver si lo pruebo y me dejo de tanto problema.

Gracias

Esta excelente este aporte, vamos a probarlo al rato!
Saludos

Hola JosePablo quería saber cual es el linker que usaste por que yo también tengo un 18f4550 y me compila bien pero la pc no me lo enumera.
Desde ya muchas gracias!

andres53016 escribió:Hola JosePablo quería saber cual es el linker que usaste por que yo también tengo un 18f4550 y me compila bien pero la pc no me lo enumera.
Desde ya muchas gracias!

bueno ya lo solucione , muchimas gracias EOL, use el linker del pinguino.
yo encontraba raro esta línea de script usb.c: #pragma udata usbram5 HIDRxBuffer HIDTxBuffer, el usbram5 se ubicaba en cualquier posición de memoria y no en el bank5