Diferencia entre revisiones de «6 08 2011»
| (No se muestran 2 ediciones intermedias del mismo usuario) | |||
| Línea 14: | Línea 14: | ||
Resúmen: | Resúmen: | ||
| + | Actualmente en USB4all el comando LIST devuelve una lista de módulos que se genera de forma estática a partir de un vector guardado en ROM por cada módulo en tiempo de compilación. | ||
| + | Actualmente surge la necesidad degenerar dicha lista de forma dinámica, en particular para generar varias instancias de un tipo de sensor. | ||
| + | Una alternativa sencilla es generar en tiempo de compilación todas las opciones y en tiempo de ejecución que el comando LIST solo retorne la lista de los que están conectados y tienen firmware cargado en el PIC. De esta manera minimizamos el impacto en el basefirmware.<br> | ||
Los rangos deben estar separados de manera que los dispositivos de entrada no se confundan con los de salida. Idea: de 0 a 450 salida y de 550 a 1024 | Los rangos deben estar separados de manera que los dispositivos de entrada no se confundan con los de salida. Idea: de 0 a 450 salida y de 550 a 1024 | ||
| Línea 20: | Línea 23: | ||
Guille: Implementar una macro para generar las entradas de los vectores de punteros a función y nombre | Guille: Implementar una macro para generar las entradas de los vectores de punteros a función y nombre | ||
Andrew: modificar el base firmware para que en el receive de cada módulo llegue la información del handler involucrado. Módulo PnP que guarde el mapeo port <-> handler, port <-> value_id. | Andrew: modificar el base firmware para que en el receive de cada módulo llegue la información del handler involucrado. Módulo PnP que guarde el mapeo port <-> handler, port <-> value_id. | ||
| − | Fede: | + | Fede: Definir los rangos de cada uno de los sensores/actuadores |
| + | |||
| + | Pendientes para discutir: | ||
| + | |||
| + | - El bobot tiene que mandar pedir periódicamente la lista de dispositivos, calcular las diferencias y ejecutar el close de los módulos que ya no están presentes. | ||
| + | |||
| + | - Pensar si es mejor agendar el mecanismos de hotplug en el timmer o dejar que se mande desde el bobot el comando de refresh | ||
Revisión actual del 11:45 7 ago 2011
Participantes:
Fede, Guille, Andrew
Temas:
Firmware con soporte PnP para el shield usb4all butiá
Agenda:
- Introducir a Fede y Guille a detalles de la implementación USB4all
- Buscar la forma de implementar el PnP dentro del firmware actual
Resúmen:
Actualmente en USB4all el comando LIST devuelve una lista de módulos que se genera de forma estática a partir de un vector guardado en ROM por cada módulo en tiempo de compilación.
Actualmente surge la necesidad degenerar dicha lista de forma dinámica, en particular para generar varias instancias de un tipo de sensor.
Una alternativa sencilla es generar en tiempo de compilación todas las opciones y en tiempo de ejecución que el comando LIST solo retorne la lista de los que están conectados y tienen firmware cargado en el PIC. De esta manera minimizamos el impacto en el basefirmware.
Los rangos deben estar separados de manera que los dispositivos de entrada no se confundan con los de salida. Idea: de 0 a 450 salida y de 550 a 1024
Tareas:
Guille: Implementar una macro para generar las entradas de los vectores de punteros a función y nombre Andrew: modificar el base firmware para que en el receive de cada módulo llegue la información del handler involucrado. Módulo PnP que guarde el mapeo port <-> handler, port <-> value_id. Fede: Definir los rangos de cada uno de los sensores/actuadores
Pendientes para discutir:
- El bobot tiene que mandar pedir periódicamente la lista de dispositivos, calcular las diferencias y ejecutar el close de los módulos que ya no están presentes.
- Pensar si es mejor agendar el mecanismos de hotplug en el timmer o dejar que se mande desde el bobot el comando de refresh
