Como siguiente avance, os paso más detalles del firmware de la placa PICHELI, cuando tenga una versión "aceptable" la pondre en el hilo.
El programa se ha hecho siguiendo el esquema que Microchip define es su kit USB, tiene algunas peculiaridades, ya que no usa interrupciones
para manejar el USB, por lo que a la hora de usar las librerias de envio y recepción de datos, hay que tener en cuenta cederle el control
al bucle principal USB.
Por ejemplo para enviar todos los datos del log al PC, via el driver CDC USB, hay que hacerlo con un buffer intermedio que se vaciando en
cada pasada del bucle USB.
La lectura de los sensores se hace en la rutina de interrupción (main_picheli.c), por lo que tampoco puedo quedarme ahí mucho tiempo,
aunque como el PIC va a 48Mhz ( 12 MIPS), creo que no tendré problemas.
- El sensor RPM esta conectado a la INT2, por lo tanto para obtener RPMs , solo tengo que contar las INTs que se producen en un periodo de
tiempo fijo y luego grabar a EEPROM.
- El sensor de tension de bateria está conectado al canal 0 del ADC, aqui es fácil también, leer el ADC y grabar en EEPROM.
- El sensor de PPM, tiene que obtener la longitud del pulso PPM. como no me quedan INTs para hacer esto, lo tengo que hacer de manera
más rudimentaria, luego os cuento ( al final).
Como veis, el esquema general de lectura y registro de sensores es sencillo.
Más adelante, podemos pensar en otro esquema más flexible, que permita definir distintas entradas y tipos de sensores.... y activarlos o no
segun convenga, el objetivo final es registrar los valores de esos sensores...
La gestión de comunicación con el PC se encarga de atender los comandos que llegan via USB ( driver CDC), los comandos se decodifican y ejecutan
en commands.c. Hay comandos de varios tipos:
- Información : Version del firwmware, longitud del registro LOG, valores de los parametros configurables.
- Configuración : Cambio de parametros configurables, borrado del LOG, sincronización del LOG, control LEDs.
- Dump : Descarga de los datos del LOG.
Todos ellos se pueden ejecutar desde un Hyperterminal ( o similar) conectando con el COM virtual que cree Windows.
Por último solo queda la parte que controla los LEDs, el modo es configurable para los 2 LEDS:
- Fijo o Parpadeo
- Frecuencia de parpadeo.
- Activación de aviso de bateria baja, también es configurable este limite.
COMANDOS:
VER : Devuelve Version del firwmare
GETR : Devuelde el perdiodo de grabación del LOG
SETR : Pone el periodo de grabación del LOG.
DUMP n : Descarga de LOG n ( R, V o P)
LEN n : Devuelve numero de registros de LOG n ( R, V o P)
OPEN : Carga indices de las tablas del LOG.
CLEAR : Borra LOG.
LEDMD m f: Activa modo fijo o parapeadnte para led m (f = F/P).
LEDWN m f: Activa/desactiva modo aviso bateria para led m (f = 0/1).
LEDR m p: Pone periodo de parpadeo p para led m.
SETWV v : Pone limite tension (v) para aviso de bateria baja.
GETWV : Devuelve limite tension de aviso de bateria baja.
GETLED m : Devuelve modo (P o F) y aviso activo (0 o 1) para LED m.
SYNC : Guarda indices (usado para pruebas).
STOP : Para el proceso de LOG (usado para pruebas).
START : Arranca el proceso de LOG (usado para pruebas).
Sobre la lectura del pulso PPM que van a los servos.
Como sabeis esta codificación usa pulsos de longitud variable entre 1000 us y 2000 us cada 20ms ( aunque esto rangos pueden variar entre fabricantes),
para medirlo y obtener valores entre 0 y 100 necesito tener una resolución de 10 us. Habia pensado en usar la interrupcion del timer TMR1 ( cada 10us) y contar cuando el la entrada PPM este a nivel alto, lo que no me gusta es que la interrupción se produce cada 10us y no sé si voy a afectar al proceso de comunciación USB o a las grabciones en EEPROM, se os ocurre algún otro metodo SW menos "molesto"????
Podría utilizar el "INT on change" de los port RB4-RB7, pero tendria que cambiar la placa ...
Saludos.
