Diferencia entre revisiones de «Grupo HotPlug»
(→Presentación de nuestro trabajo:) |
|||
Línea 1: | Línea 1: | ||
− | [[Archivo:probando3.jpg|Placa Arduino con 9 conectores disponibles|derecha|300px|thumbnail]] | + | [izq][[Archivo:probando3.jpg|Placa Arduino con 9 conectores disponibles|derecha|300px|thumbnail]][/izq] |
+ | |||
+ | |||
+ | |||
=='''Integrantes:'''== | =='''Integrantes:'''== | ||
* Juan La Cruz | * Juan La Cruz |
Revisión del 17:35 16 feb 2012
[izq][/izq]
Contenido
Integrantes:
- Juan La Cruz
- Sofía Maiolo
- Mathias Battistella
Presentación de nuestro trabajo:
Para ver la presentación de nuestro proyecto:
Tema elegido:
Firmware + Software : soporte HotPlug.
Motivación:
- Nuestra principal motivación fue el poder realizar un proyecto que mejoraría el labor cotidiano con el Butiá y que permitiría un uso aún más sencillo del mismo.
- Por otro lado, nos interesó la idea de trabajar en varios niveles (firmware, bobot, tortugarte) y poder comprender mejor como se relacionan.
Objetivos:
Que la actualización de los módulos de usuario y drivers del Butiá sea "on the fly" es decir, dinámico. Se desea que durante la ejecución del Bobot-Server, podamos conectar y tener disponible para su uso sensores o actuadores.
Desarrollo del problema:
Se detalla a continuación un breve resumen de las etapas por las que pasó nuestro trabajo:
- En primer lugar modificamos el código del módulo butia, incluido en el archivo modulos.pde, para incluir una nueva operación que actualice los dispositivos conectados al Butiá. Esta nueva operacion consta de un for, donde se recorren los conectores, revisando su estado. Anexamos el código añadido
for (k=0; k<NUM_CONNECTORS; k++)
{
if (conector[k].get_type() != 0)
{add_module(k) };
}
- Al anexar esta nueva operación, debemos modificar también los drivers, incluidos en la carpeta bobot. Cambiamos, en particular, el archivo butia.lua, para poder invocar a la nueva función, que llamamos get_hot_plug. Incluimos el código:
api.hot_plug = {}
api.hot_plug.parameters = {} -- no se envian parámetros
api.hot_plug.returns = {} --nos devuelve el estado de los conectores
api.hot_plug.call = function ()
device:send(HOT_PLUG) --envío el código de operación
end
- Luego de realizar varias pruebas (detalladas en la próxima sesión) decidimos cambiar el enfoque y optamos por quitar el FOR agregado inicialmente en el módulo butiá. Lo sustituimos por el siguiente código incluido en el archivo butia_firmware_mega_0_2.pde:
if (time_act-time_last2 >= 5000) { // cada 20ms llamamos a la sample(). Ojo porque esto afecta al "cuentapasos"
// explora los conectores
for (byte f=0; f<NUM_CONNECTORS; f++) {
byte tipoOld = conector[f].get_type();
byte subtipoOld = conector[f].get_subtype();
conector[f].update_config ();
// conecte algo donde no habia nada, o cambie lo que estaba conectado
if (conector[f].get_type() != 0 &&
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))
{
//primero borrar el viejo en la lista de handlers si es que
//el viejo no era el tipo 0 (el caso q no hay nada)
add_module(f);
}else if (conector[f].get_type() == 0 && //desconecte algo
(conector[f].get_type() != tipoOld || conector[f].get_subtype() != subtipoOld))){
//borrar el modulo que se acaba de desconectar
} // si hay algo en el conector, agrega 1 módulo PnP para él
}
time_last2 = time_act;
}
Este código realiza las siguientes acciones:
1)Recorremos los conectores, y guardamos su tipo y sub-tipo anteriores.
2)Si no había un conector en la lista de handlers y además, los tipos y sub-tipos son distintos, agregamos el conector llamando a add_module(f); de PnP.pde
3)Sino, debemos borrar del handler el módulo que acabamos de desconectar. Debemos implementar esta función, a la que llamaremos remove_module.
- Para implementar remove_module, exploramos el handler, buscando el módulo a borrar y lo sustituimos por el módulo que se encuentra en la última posición ocupada del handler. Actualizamos, también, la cantidad de módulos. Incluimos la primera versión de nuestro código:
void remove_module (byte num_conector) {
int i=8; //Comenzamos a recorrer desde el 8 ya que desde el 8 se comienzan a agregar los nuevos conectores.
while ( (i< num_modules) && (handler[i].num_conector != num_conector) ) //Buscamos el conector con "num_conector" en el arreglo.
i++;
if (i< num_modules) //El conector con "num_conector" no es el ultimo.
{
//Hacemos el intercambio, dejando en la posicion i, al conector que se encontraba en la ultima posicion (num_modules).
strcpy (handler[i].nombre, handler[num_modules].nombre);
handler[i].funcion = handler[num_modules].funcion;
handler[i].num_conector = handler[num_modules].num_conector;
}
num_modules--;
}
- Luego de probar el firmware con estas modificaciones, comprobamos que se detecta correctamente cuando se conecta/desconecta un sensor. Sin embargo, cuando conectamos/desconectamos sensores del mismo tipo, los nombres asignados no se actualizan.
Es decir, si conectamos dos sensores del tipo X y listamos los sensores conectados (usando LIST), obviamente veremos conectados: X, X1. Al desconectar uno veremos también un comportamiento correcto. Pero, al conectar nuevamente el sensor, y listar apreciaremos: X, X2.
- Para solucionar este problema, relacionado con la cantidad de instancias de cada conector del handler, optamos por:
1) Crear una nueva estructura (un array de bytes), llamada instancias, en la cual guardaremos las instancias de cada conector, mapeandolos según los siguientes criterios:
byte globaltype = 10*conector[num_conector].get_type() + conector[num_conector].get_subtype();
En cada lugar del array, correspondiente a alguno de estos valores, guardaremos la cantidad de instancias de ese sensor.
SENSOR_DISTANCIA 10
SENSOR_TEMPERATURA 11
SENSOR_LUZ 12
SENSOR_GRISES 13
SENSOR_BOTON 30
SENSOR_CONTACTO 31
SENSOR_TILT 32
SENSOR_VIBRACION 33
SENSOR_MAGNETICO 34
ACTUADOR_LED 53
MAX_CALLBACKS 10
SENSOR_POTE 21
UNKNOWN 15
El objetivo primordial de esta estructura es tener en una variable global el numero de instancias, para poder actualizarlo en el procedimiento remove_module, ya que antes estas variables solo se podían modificar en get_config al agregar un nuevo sensor.
2) Modificamos la estructura H, agregándole un nuevo campo, instancia, que guardará a qué instancia de ese sensor corresponde el dispositivo ubicado en ese lugar del handler. De esta forma podremos acceder al valor de instacias totales para cada tipo de conector (buscando en el array instancias) y a su vez, al valor particular de cada sensor (que corresponde con la nomenclatura de su nombre). Es importante destacar, que cuando existe sólo un sensor conectado, en el array instancias habrá un 1, mientras que el valor de instancia en el handler será 0.
3)Una vez hecho esto, tenemos que actualizar distintas partes del código, para incluir las nuevas estructuras. En particular, hicimos cambios relevantes en los procedimientos get_config, add_module y remove_module.
Pruebas realizadas:
Hemos realizado pruebas en las distintas etapas de nuestro trabajo. Incluimos algunas de ellas.
- En primer instancia, probamos nuestra implementación conectando un boton y un sensor de distancia. Hacemos un LIST y los reconoce bien.
Los desconectamos, llamamos a nuestra operación y al INIT. Sin embargo, al usar el comando LIST, los sensores y el botón siguen apareciendo, lo cual nos hace pensar que la placa no fue reseteada
Probando y consultando con docentes, nos dimos cuenta de que faltaba actualizar el tipo de los conectores, antes de hacer la recorrida en el for. Para ello, usamos una función implementada en conector.cpp, llamada update_config ().
Incluimos el código de dicha función.
void Conector::update_config () {
byte id = digitalRead (pin_id0) + 2*digitalRead (pin_id1);
switch (id) {
case 3: // NADA
pinMode (pin_dig0, INPUT);
pinMode (pin_dig1, INPUT);
type = 0;
subtype = 0;
break;
case 2: // sensor analógico
pinMode (pin_dig0, INPUT);
pinMode (pin_dig1, INPUT);
digitalWrite (pin_dig0, HIGH); // activa los pull-ups
digitalWrite (pin_dig1, HIGH); // activa los pull-ups
type = 1;
subtype = digitalRead (pin_dig0) + 2*digitalRead (pin_dig1);
break;
case 1: // sensor analógico c/pin de control
pinMode (pin_dig0, OUTPUT);
pinMode (pin_dig1, INPUT);
digitalWrite (pin_dig1, HIGH); // activa los pull-ups
type = 2;
subtype = digitalRead (pin_dig1);
break;
case 0: // sensor o actuador digital
{
int analog_id = analogRead (pin_analog);
byte i;
for (i=0; i<NUM_VALORES; i++) {
if (abs(analog_id-values[i]) <= TOLERANCIA) {break;}
}
switch (i) {
case 0: case 1: case 2: case 3: case 4:
pinMode (pin_dig0, INPUT);
pinMode (pin_dig1, INPUT);
type = 3; // sensor digital
subtype = i;
break;
case 5: case 6: case 7: case 8:
pinMode (pin_dig0, OUTPUT);
pinMode (pin_dig1, INPUT);
type = 4;
subtype = i-5;
break;
case 9: case 10: case 11: case 12:
pinMode (pin_dig0, OUTPUT);
pinMode (pin_dig1, OUTPUT);
type = 5; // sensor digital c/pin de control
subtype = i-9;
break;
case NUM_VALORES: // si la red de resistencias no coincide con ningun valor, se deja en modo manual
pinMode (pin_dig0, INPUT);
pinMode (pin_dig1, INPUT);
type = 0;
subtype = 0;
break;
}
}
}
- Usamos ./lua bobot-server.lua DEBUG en la Terminal para ver más información.
- Probando con "Serial monitor" el FOR original de tal forma que repita cada 5 seg sin el init que aparece antes del codigo. Se puede ver el Print indicado mostrando correctamente la lista de dispositivos conectados. Para ello agregamos en butia.lua, linea 35: Print ("tipo leido",devolver); (devolver integer)
Serial.print("conector ");
Serial.print(f,DEC);
Serial.print(" tipo= ");
Serial.print(conector[f].get_type(), DEC);
Serial.print(" subtipo= ");
Serial.println(conector[f].get_subtype(), DEC);
En base a estas pruebas decidimos eliminar el FOR original del modulo butiá (tal como se detalla en la sesión anterior.)
- Haciendo para cada conector update_config: "conector[f].update_config (); funionó, se probó con un boton y un sensor y verificó que el codigo los reconocía correctamente desde Serial Monitor. Pero probando con: ./lua bobot-server.lua DEBUG (Terminal) no funcionó, ahora el sensor de grises no aparece como unknown, sino como "grises", pero se repite como antes.
- Luego de agregar las nuevas estructuras, volvimos a repetir las pruebas y sin embargo, el problema no se solucionó.
Conclusiones:
- Hasta este momento hemos logrado que se detecte correctamente cuando se conecta/desconecta un sensor. Sin embargo, a pesar de todos los cambios hechos, no hemos podido solucionar el problema de la nomenclatura de los conectores.
- El proyecto nos motivó mucho, ya que nos permitió utilizar herramientas que ya teníamos y observar de una forma mucho más práctica a la cual estamos acostumbrados, los cambios introducidos en el código.
- Nuestra idea es culminar el proyecto, tratando de solucionar el problema antes explicado.
Trabajo a futuro:
- Creemos que los cambios introducidos deberían permitirnos completar nuestro proyecto solucionando los problemas ahora existentes. Nuestro trabajo a futuro se centrará en identificar qué estamos haciendo mal, para poder cumplir íntegramente los objetivos planteados.
- Por otro lado, también evaluamos la posibilidad de incluir un "botón refresh" dentro del Tortugarte, para permitir al usuario, actualizar los sensores cuando lo desee.