Proyecto Butiá - Contribuciones del usuario [es]

Archivo:Xevent.png

2015-04-17T20:21:19Z

LOLO58: subió una nueva versión de «Archivo:Xevent.png»

Archivo:Xevent.png

2015-04-17T20:20:14Z

LOLO58: subió una nueva versión de «Archivo:Xevent.png»

Archivo:Xevent.png

2015-04-17T20:18:55Z

LOLO58: subió una nueva versión de «Archivo:Xevent.png»

Archivo:Xevent.png

2015-04-17T20:10:24Z

LOLO58: subió una nueva versión de «Archivo:Xevent.png»

Archivo:Xevent.png

2015-04-17T20:07:12Z

LOLO58: subió una nueva versión de «Archivo:Xevent.png»

Archivo:Xevent.png

2015-04-17T20:04:32Z

LOLO58:

Archivo:Xevents.png

2015-04-17T19:50:10Z

LOLO58: subió una nueva versión de «Archivo:Xevents.png»

Archivo:Xevents.png

2015-04-17T19:48:06Z

LOLO58: subió una nueva versión de «Archivo:Xevents.png»: Revertido a la versión subida el 17 abr 2015 a las 19:39

Archivo:Xevents.png

2015-04-17T19:47:25Z

LOLO58: subió una nueva versión de «Archivo:Xevents.png»

Archivo:Xevents.png

2015-04-17T19:40:36Z

LOLO58: subió una nueva versión de «Archivo:Xevents.png»

Archivo:Xevents.png

2015-04-17T19:39:03Z

LOLO58:

TortuBots

2015-04-17T19:29:17Z

LOLO58:

== TortuBots ==

[http://wiki.sugarlabs.org/go/Activities/TurtleArt TortugArte] es una actividad Sugar inspirada en [http://en.wikipedia.org/wiki/Logo_(programming_language) Logo] la cual pone al alcance de niños conceptos de programación, mediante una interfaz gráfica icónica, donde cada instrucción se mapea como un bloque.
El proyecto butiá realizó modificaciones sobre TortugArte agregando algunos plugins en forma de paletas que permiten controlar diferentes kits robóticos como [http://www.fing.edu.uy/inco/proyectos/butia/ Butiá], [http://en.wikipedia.org/wiki/Lego_Mindstorms_NXT_2.0 Lego NXT],[http://www.legoeducation.us/eng/product/lego_education_wedo_robotics_construction_set/2096 Lego WeDo],[http://activities.sugarlabs.org/es-ES/sugar/addon/4368 FollowMe] y Sumbot). Se puede descargar la actividad TortuBots que contiene todo lo actual de TortugArte más los plugins de robótica mencionados.

[[Archivo:Tb.png|En ésta imagen pueden verse las diferentes paletas agregadas.]] 
Paletas de izq. a der.: Arduino - Butiá - Butiá Extras - FollowMe - Lego NXT (motores) - Lego NXT (sensores) - Marcas - SumBot - Lego WeDo

Pueden descargarse las últimas versiones del siguiente [http://www.fing.edu.uy/inco/proyectos/butia/files/package/ repositorio] o desde el [http://activities.sugarlabs.org/es-ES/sugar/addon/4434 repositorio de actividades Sugar]. En este momento se encuentran disponible para su uso en XO, y computadoras con Ubuntu 10.04 o posterior.

==Instalación==

* Cualquier distribución de GNU/Linux:

Si usted tiene una versión de linux basada en ''debian'' puede descargar la actividad para su arquitectura directamente desde nuestro [http://www.fing.edu.uy/inco/proyectos/butia/files/package/ repositorio]

Sino puede seguir este [[Generando_xo | instructivo]]

* En Sugar:

[[instalacion_XO|XO 1.0 y 1.5]]

== Plugin Butiá ==

El robot Butiá tiene soporte [[plug and play]] y [[plug and play|hotplug]] para los sensores/actuadores que se conectan a él, este aspecto fue utilizado a la hora de implementar el plugin cambiando el color de los bloques correspondientes a los elementos de sensado/actuación según lo que se haya conectado al robot.

[[Archivo:Tb1.png|En ésta imagen puede verse la paleta cuando no hay robot conectado]] 

[[Archivo:Tb2.png|En ésta imagen puede verse la paleta cuando hay robot conectado y un sensor botón]] 

Para comenzar...

* [[Tortugarte_variables|Como manejar variables en TortuBots]]

* [[Modularizando|Como modularizar un programa en TortuBots]]

* [[Transformando_a_cms_el_valor_del_sensor_de_distancia|Transformando a centímetros la salida del sensor de distancia]]

* [[Ejemplos de comportamientos robóticos con TortuBots|Ejemplos de comportamientos que pueden realizarse en TortuBots]]

* [[video_tutoriales|Video Tutoriales]]

== Butiá Extras ==

[[Archivo:Tb3.png|En ésta imagen puede verse la paleta de extras cuando hay robot conectado]] 

La paleta de extras de butiá nos permite profundizar otras funcionalidades de la placa:

* [[HackPoints|Como utilizar los HackPoints]]

* [[Módulo sensor Voltaje | Módulo Voltaje]]

* [[Módulo sensor Resistencia | Módulo Resistencia]]

== Plugin Lego NXT ==

[[Archivo:Lnxt1.png]] 

[[Archivo:Lnxt2.png]] 

Toda la información en: [http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Plugins#LEGO_NxT <big>'''NxT'''</big>]

== Plugin Lego WeDo ==

[[Archivo:Wdo.png]] 

Toda la información en: [http://wiki.sugarlabs.org/go/Activities/Turtle_Art/Plugins#WeDo <big>'''WeDo'''</big>]

== Plugin Lego Fisher ==

[[Archivo:Fisher.png]] 

== Plugin FollowMe ==

[[Archivo:Fm.png]]

La idea detrás de la paleta es retornar posiciones x y y del color de un objeto de manera de mover el robot Butiá de acuerdo a estos valores.

Toda la información en: [[FollowMe | <big>'''FollowMe'''</big>]]

Mas info en la wiki de TurtleArt (en inglés): [http://wiki.sugarlabs.org/go/Activities/Turtle_Art#FollowMe FollowMe]

== Plugin SumBot ==

Este plugin permite comunicarse con el sistema de visión utilizado en la categoría sumbot del evento sumo.uy [http://www.fing.edu.uy/inco/eventos/sumo.uy/].
A partir de la versión 5 de tortugarteButiá viene incluido, puede consultarse más sobre su funcionamiento en la wiki del evento sumo.uy [http://www.fing.edu.uy/inco/eventos/sumo.uy/wiki/index.php/Actividad_Tortugarte].

[[Archivo:SumB.png]]

== Plugin Pattern Detection ==

Este plugin permite detectar señales y patrones con la cámara de la pc. La versión incluida del plugin incluye el reconocimiento de señales de tránsito, pero es posible agregar marcas adicionales como se detalla en la página del plugin: [[Butia_reconocimiento_marcas]]

La paleta trae bloques que permiten detectar la presencia de marcas además de la distancia a las mismas.

[[Archivo:Paleta_reco_marcas.png|700px]]

== Plugin Arduino ==

Requiere tener grabado en la Arduino el firmware Firmata. Usar la última disponible (2.1) disponible en la página (firmata.org).

[[Archivo:Arduino-palette.png|900px]]

== Plugin ArDrone ==

Plugin para programar el drone [http://es.wikipedia.org/wiki/Parrot_AR.Drone Parrot ArDrone]. 
Más información [[Paleta ArDrone]]

[[Archivo:Paleta_ardrone.png]]

Archivo:Fisher.png

2015-04-17T19:10:55Z

LOLO58: subió una nueva versión de «Archivo:Fisher.png»

Archivo:Fisher.png

2015-04-17T18:54:18Z

LOLO58: subió una nueva versión de «Archivo:Fisher.png»

Archivo:Fisher.png

2015-04-17T18:53:19Z

LOLO58: subió una nueva versión de «Archivo:Fisher.png»

Archivo:Fisher.png

2015-04-17T18:48:51Z

LOLO58: subió una nueva versión de «Archivo:Fisher.png»

Archivo:Fisher.png

2015-04-17T18:46:50Z

LOLO58:

Discusiones para las reuniones

2014-12-26T18:36:18Z

LOLO58:

* incluir el trabajo
http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Grupo_5 al master 
Discutir como se usa el relay y hacer algunas pruebas

Usb4all

2014-12-23T21:22:27Z

LOLO58: /* 5. Entorno de desarrollo */

== 1. Motivación ==

La motivación de este proyecto se centra en lograr de una manera sencilla, la comunicación entre un sistema computador y un conjunto de dispositivos electrónicos no necesariamente pensados para interactuar con una computadora.
Durante muchos años la única forma de interactuar con dispositivos externos desde a un computador personal (Personal Computer) (PC) fueron los puertos seriales y paralelos, esto llevo a que se utilizaran ampliamente en multiplicidad de dispositivos. Sus principales características son su simplicidad de manejo vía software y facilidad de inclusión en distintos dispositivos. En la última década han aparecido nuevos medios o canales de comunicación, tales como Bluetooth, Fidelidad Inalámbrica (Wireless Fidelity) (WiFi), FireWire, Bus Universal en Serie (Universal Serial Bus) (USB), etc. Estos permitieron mejorar las velocidades de comunicación y calidad de datos y lentamente tornaron a los puertos paralelos y seriales en obsoletos, hasta llegar al día de hoy en que se obtienen sólo de manera opcional en los nuevos PC.
Dentro de todas estas nuevas tecnologías que aparecieron la que tuvo mayor aceptación y difusión entre los usuarios fue el USB, debido a su facilidad y versatilidad de escenarios de uso. Esta simplicidad desde el punto de vista del usuario de los dispositivos USB tiene como contrapartida una mayor complejidad para los desarrolladores de software y hardware, lo cual es un gran problema al momento de interactuar con dispositivos electrónicos.
Frente a estas adversidades que presenta el entorno actual aparece la necesidad de buscar una forma de reducir el grado de complejidad y conocimientos necesarios para poder desarrollar
software que utilice la tecnología USB. Al mismo tiempo, se requiere una plataforma base que incorpore componentes de hardware reutilizables y que en conjunto formen una solución genérica
para la comunicación con dispositivos electrónicos diversos.
En el contexto de lo antedicho aparecen un conjunto de desafíos como son el desarrollo de controladores (drivers) y construcción de piezas de hardware que brinde una solución genérica
reutilizable, desplazando el manejo de los casos particulares a componentes específicos. Esto proporciona el beneficio de evitar que cada vez que se necesite conectar un nuevo dispositivo,
se comience desde cero. A su vez permite recuperar y potenciar la característica de facilidad de manejo que poseían los puertos seriales y paralelos, explotando todas las capacidades brindadas por USB.

== 2. Arquitectura (Firmware/Hardware)==

La arquitectura está compuesta por diferentes componentes, los cuales van a permitir el funcionamiento del sistema desde lo relativo al hardware como las abstracciones necesarias para manejarlo mediante software. 
Los componentes principales son:

'''2.1 USB4all ''Baseboard'''''

[[Archivo:usb4all2.png|thumb|Fig.2.1.1: USB4all Baseboard 2.0]]
Es una placa de entrada/salida(E/S) configurable que se conecta por USB con un sistema computador. El proyecto USB4all es mucho más que una placa de E/S, en sí es una forma de modelar sistemas embebidos, siendo la placa de E/S un componente que fue necesario construir para desarrollar la solución completa. Para la construcción de esta placa se utilizó un microcontrolador PIC18F4550 de Microchip. Entre las características más destacadas en lo que concierne al proyecto se encuentra el soporte completo del estándar USB, pudiéndose utilizar varias de sus características, como ser diferentes tipos de transferencias y varios canales de comunicación (endpoints). El diseño de hardware de la placa puede descargarse del [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/pcb/ git del proyecto] permitiendo que cualquiera pueda armarse una USB4all ''baseboard'' utilizando el software GPL [http://www.lis.inpg.fr/realise_au_lis/kicad/ Kicad].

'''2.2 USB4all ''base firmware'''''

Es el firmware más estático, brinda servicios a los usermodules para que puedan utilizar los recursos presentes en la baseboard (timmers, puerto USB, conversores A/D, etc) además de brindar las primitivas para el intercambio de mensajes entre el computador y el usermodule y realiza la gestión de los ''usermodules''. Establece las bases para que los usermodules sean independientes del protocolo de comunicación computador/placa y de los detalles de hardware del microcontrolador utilizado. A su vez oferce un entorno de ejecución concurrente que permite instanciar de forma dinámica varios ''usermodules''.

'''2.3 USB4all ''usermodule'''''

Son los componentes intercambiables del sistema que permiten encapsular la lógica de un dispositivo especifico y su protocolo de comunicación con las aplicaciones de usuario. Permite al usuario dar rápidamente soporte a un nuevo dispositivo de forma genérica, expandiendo de esta manera las funcionalidades del USB4all ''basefirmware''. Los ''user modules'' son los bloques principales sobre los que se construye la arquitectura USB4all. Exponen una API uniforme que es utilizada a modo de callbacks por el ''base firmware'' y también exponen los servicios que brindan los dispositivos. Es recomendable modelar cada uno de los dispositivos electrónicos conectados a la ''baseboard'' como un ''usermodule'' donde los servicios a exponer se mapean con las características del mismo, como ejemplo en el caso de un motor, sería esperable que expusiera servicios para moverse, cambiar la velocidad y el sentido.

Del lado del sistema computador se dispone de diferentes formas de interacción: Todas ellas implementan el protocolo USB4all, su objetivo es abstraer al usuario del mismo brindando una forma sencilla de utilizar el sistema, existiendo soporte para diferentes lenguajes de programación. El objetivo principal de las bibliotecas utilizadas en el computador son las de permitir utilizar los servicios de los ''usermodules''. Esta forma de trabajo permite desarrollar la lógica de interacción entre los diferentes dispositivos electrónicos dentro del sistema computador, con lenguajes de mayor abstracción, mejores herramientas de desarrollo, permitiendo generar un código con un nivel de mantenibilidad y abstracción mayor al que se lograría si todo estuviera embebido en el microcontrolador.

Uno de los componentes más usados actualmente es el [[bobot]] que persigue un enfoque genérico al igual que el proyecto USB4all y permite acompañar la extensibilidad de la placa USB4all mediante el uso de ciertos componentes propios de la arquitectura llamados drivers.

== 3. Protocolo de Comunicación ==

El protocolo está formado por un stack de protocolos que permiten abstraer al usuario de los detalles subyacentes de la arquitectura.
El objetivo final del protocolo de comunicación, es direccionar los mensajes provenientes desde la aplicación que se ejecuta en el computador, al ''usermodule'' correspondiente ejecutado en la placa USB4all.
Estos mensajes son solicitudes de ciertos servicios que los módulos exponen, por ejemplo en el caso de un dispositivo sonoro (buzzer) utilizado para una alarma, va a ser de interés poder emitir sonido (Prender el Buzzer) detener la emisión de sonido (Apagar el Buzzer), hacer sonidos cortos pasando por parámetro la cantidad de milisegundos que se desea esté prendido, etc.
Estos mensajes se tienen que codificar de alguna manera, el protocolo especifica que primero se debe indicar el comando que se desea se ejecute y luego en caso que sea necesario (como en el de los sonidos cortos) enviar los parámetros. En algunos casos va a ser necesario obtener respuestas, las cuales se codifican de forma análoga usando el mismo protocolo, enviando en lugar de un parámetro un valor de retorno.
Este protocolo es llamado ''user protocol'' y está enfocado al usuario final, pero para que el sistema funcione correctamente es necesario contar con otros protocolos los cuales transportan el protocolo ''user protocol''. Tal es el caso del handler manager protocol que se encarga de manejar el ruteo de los mensajes al ''user module'' correspondiente. Esto se debe a que en un momento determinado puede haber varios ''user modules'' ejecutando en la placa y el sistema debe permitir notificar del nuevo mensaje al módulo para el cual está destinado el mismo. La tarea fundamental de este protocolo es brindar los mecanismos para comunicar una aplicación con un ''user module''. Otro protocolo involucrado es el ''admin protocol'' el cual se encarga de gestionar el ciclo de vida de los ''user modules'', permitiendo poner a ejecutar un ''user module'', cerrarlo y también algunas funcionalidades como el listar los módulos presentes en la placa, cerrar todos los modulos abiertos o llevar al estado de reset al microcontrolador. Tanto el ''handler protocol'' como el ''admin protocol'' son implementados por las bibliotecas que se utilicen en el computador. Existiendo varias opciones, Java, Python o Lua. Actualmente la opción que se está manteniendo es la de Lua, la cual puede estudiarse en profundidad en la sección [[bobot]].

[[Archivo:protocolo.png|700px|Fig. 3.2 Protocolo USB4all]]

Finalmente los paquetes USB4all se trasmiten por el protocolo de comunicación que disponga el ''baseboard'', para el caso típico del ''baseboard usb4all'' se trasmite mediante USB, pero puede ser trasmitido mediante otras tecnologías utilizadas para comunicarse con un computador, como ser serial o bluetooth (entre otros).

== 4. Grabando el Firmware ==
[[Archivo:usb4all2_top_view.png|thumb|Fig.4.1: USB4all Baseboard 2.0 vista desde arriba]]
Para grabar el firmware se necesita disponer de un programador hardware, como el picdem o el pickit, este último tiene buen soporte dentro de GNU/Linux.
Microchip distribuye un bootloader para la familia de microcontroladores 18F. Un bootloader es un programa que se utiliza para grabar y/o actualizar el firmware. En nuestro caso, va a permitr grabar el firmware del proyecto USB4all sin la necesidad de disponer de un programador por hardware, para realizar esto es necesario dejar presionado el botón de programación como puede verse en la figura 4.1 mientras se resetea la placa con el botón de reset. Esto funciona siempre y cuando el microcontrolador tenga grabado el bootloader.
Una vez que el dispositivo se encuentra en modo programación su identificador de producto cambia de 000c a 000b, esto puede verificarse utilizando el comando ''lsusb'' cuya salida se adjunta para los dos casos a continuación:

Id dispositivo USB4all
Bus 002 Device 002: ID 04d8:000c Microchip Technology, Inc.

id dispositivo Bootloader
Bus 002 Device 003: ID 04d8:000b Microchip Technology, Inc.

Dado que Microchip no distribuye microcontroladores con el bootlader previamente grabado, es necesario utilizar un programador por hardware para grabar el bootloader.
USB4all actualmente utiliza un bootloader modificado que permite actualizar el firmware programáticamente sin necesidad de presionar los botones, útil a la hora de realizar actualizaciones remotas, pero responde a los mismos comandos que el bootloader de Microchip, lo cual permite reutilizar el software ya desarrollado para interactuar con el bootloader.
Los fuentes del bootloader pueden encontrarse en el repositorio en el directorio bootloader del firmware, es un proyecto separado y una vez compilado su grabación se realiza mediante un programador por hardware como picdem o pickit.
Una vez grabado el bootloader ya '''no es necesario utilizar programadores por hardware''' y puede realizarse la grabación del firmware mediante varios programas que implementan el protocolo de grabación de firmware de microchip. Una de esas utilidades es el programa fsusb el cual puede encontrarse en [http://www.internetking.org/fsusb/] y es de código libre. Su uso se realiza de la siguiente forma:

./fsusb --program usb4all2.hex

Donde usb4all2.hex es el binario generado como resultado de compilar el proyecto. Recordar que el hardware debe estar en modo bootloader para poder recibir el firmware.

==== 4.1 Grabando Bootloader + Firmware ====
Una manera rápida, luego que se tiene acceso a un programador, es grabar el bootloader correspondiente y algún firmware (todo junto).
Para eso pueden usar este .hex:

[http://www.fing.edu.uy/inco/proyectos/butia/files/firmware/bootloader_con_admin.hex bootloader_con_admin.hex]

'''Nota.''' Ahora es posible grabar el firmware fácilmente mediante la siguiente actividad [[Grabar Firmware|Grabar Firmware]].

= 5. Entorno de desarrollo =

== 6. Escribiendo un ''usermodule'' ==
Un ''usermodule'' es el bloque sobre el cual se representa una realidad y se modela utilizando la arquitectura ''USB4all'', en esta sección se presentan sus características, estructura necesaria para especificar los servicios que brinda y de que forma se anexa al ''basefirmware''

[[Archivo:user_module.png|thumb|Fig. 6.1: Tabla de referencias a ''user modules'']]

'''6.1 Estructura de un ''usermodule:'' ''' 
Un ''usermodule'' debe cumplir con una API determinada, de esta manera es posible agregar las funcionalidades que el módulo expone, dentro del ''basefirmware''.
Las operaciones principales que se deben implementar son las encargadas de atender los eventos de:
* inicialización
* liberación de recursos
* configuración

Estas operaciones se ejecutan en determinados momentos del ciclo de vida de una aplicación USB4all, siendo la operación registrada al evento de inicialización invocada al abrir desde la aplicación el ''usermodule'' y la de liberación de recursos al cerrarlo, esto permite utilizar los recursos del microcontrolador solo cuando es necesario. La operación de configuración puede invocarse en cualquier momento para cambiar en caliente algún aspecto de configuración del hardware.
Al comenzar un ''usermodule'' se debe declarar cuales van a ser las funciones que van a atender estos eventos y el nombre del módulo para ser identificado desde el computador al listar los módulos presentes en la placa.

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
#pragma code

Donde user es el nombre de la sección y uTab es una estructura para almacenar las posiciones de memoria de las operaciones que exporta el módulo y su nombre. En la sección detalles de implementación en el firmware se puede conocer más sobre el significado de la instrucción #pragma romdata user, podemos por el momento asumir que sirve para almacenar la estructura uTab en un lugar conocido dentro de la memoria de programa.

El ''basefirmware'' se encarga de pasar como argumento a la operación init el número de handler asignado al módulo, este número es utilizado como argumento en otras operaciones como ser ''setHandlerReceiveFunction'' la cual recibe por parámetro el handler y un puntero a la función encargada de manejar la recepción de datos.
Otra operación que necesita el ''handlerID'' es ''getSharedBuffer'' la cual recibe por parámetro el ''handlerID'' del módulo y retorna un buffer por el cual el módulo puede enviar datos a la aplicación que ejecuta en el computador.
Un buen lugar para obtener este buffer y registrar la función de recepción de datos es la operación encargada del evento de inicialización. A continuación puede verse como ejemplo la inicialización de un módulo de usuario para controlar un buzzer:

<syntaxhighlight lang="C"> void UserBuzzerInit(byte i) {
usrBuzzerHandler = i;
// add my receive function to the handler module, to be called automatically when the pc sends data to the user module
setHandlerReceiveFunction(usrBuzzerHandler,&UserBuzzerReceived);
// initialize the send buffer, used to send data to the PC
sendBufferUsrBuzzer = getSharedBuffer(usrBuzzerHandler);
}//end UserBuzzerInit </syntaxhighlight>

La función de recepción de datos es la encargada de implementar el protocolo de comunicación entre el ''usermodule'' y la aplicación, típicamente es una estructura tipo ''case'' en el que se espera por los diferentes comandos que pueden enviarse. La forma de codificar el pedido de servicios es mediante mensajes del tipo < COMANDO [argumento1] [argumento2]...[argumentoN] >. La respuesta debe ser del tipo < COMANDO [resultado1] [resultado2]..[resultadoN] >. El buffer para enviar datos al computador es obtenido como argumento de la función y el buffer para enviar datos fue obtenido previamente en la función de inicialización.

<syntaxhighlight lang="C"> void UserBuzzerReceived(byte* recBuffPtr, byte len){
byte index;
byte j;
byte userBuzzerCounter = 0;
byte tiempo;

switch(((BUZZER_DATA_PACKET*)recBuffPtr)->CMD){
case READ_VERSION:
//dataPacket._byte[1] is len
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[2] = BUZZER_MINOR_VERSION;
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[3] = BUZZER_MAJOR_VERSION;
userBuzzerCounter = 0x04;
break;

case PRENDER:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_on();
userBuzzerCounter = 0x02;
break;

case APAGAR:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_off();
userBuzzerCounter = 0x02;
break;

case BUZZER_TRIPLE:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks1 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1]);
cantTicks2 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[2]);
cantTicks3 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[3]);
boubleBeep(cantTicks1, cantTicks2, cantTicks3);
userBuzzerCounter = 0x02;
break;

case BUZZER_CORTO:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks3 = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
timeOutTicksBuzz = 1; // lo seteo timmer para que venza inmediantamente
buzzerState = DELAY;
registerT0event(0, &buzzEvent);
userBuzzerCounter = 0x02;
break;

case RESET:
Reset();
break;

default:
break;
}//end switch(s)
if(userBuzzerCounter != 0){
j = 255;
while(mUSBGenTxIsBusy() && j-->0); // pruebo un máximo de 255 veces
if(!mUSBGenTxIsBusy())
USBGenWrite2(usrBuzzerHandler, userBuzzerCounter);
}//end if
}//end UserBuzzerReceived</syntaxhighlight>

En este ejemplo se puede apreciar como se reciben los pedidos de comandos desde la aplicación que ejecuta en el computador y como se obtienen los parámetros necesarios para implementar los comandos y se devuelven los datos (en caso de ser requeridos) a la aplicación.

'''6.2 Entrada/Salida en user modules:''' 
Una de las tareas más importantes de los ''usermodules'' es la de realizar entrada/salida con diferentes periféricos electrónicos. Para realizar esta tarea existen dos paradigmas:
 
* Polling
* Interrupciones
 
Dentro de la arquitectura USB4all existen formas de que los módulos implementen entrada/salida utilizando estos paradigmas, para el caso de pooling existe un servicio que permite registrar una función para ser ejecutada cuando el procesador esté disponible.

<syntaxhighlight lang="C">
addPollingFunction(&UserBuzzerProcessIO);
</syntaxhighlight>

Existe soporte para interrupciones mediante el módulo ''DynamicISR'' el cual permite que otros módulos se registren sus rutinas de atención para ser invocadas cuando ocurren interrupciones.

<syntaxhighlight lang="C">
addISRFunction(&timmerISRFunction);
</syntaxhighlight>

Una forma que mantiene alta la cohesión del sistema es registrar módulos que se encarguen de esperar un evento en particular y brinde una interfaz para que los ''usermodules'' se registren para ser notificados de eventos generados por el componente de hardware que esta siendo modelado. Dentro de este módulo además se pueden brindar operaciones con mayor nivel de abstracción relacionadas con el componente a modelar. Hoy día se dispone del módulo T0service que se encarga de brindar servicio de timmers a los ''usermodules''. Al igual que el resto de los componentes funciona registrando funciones que son invocadas por el ''basefirmware''

También existen funciones para desregistrar los ''usermodules'' de las notificaciones, es conveniente realizar la desregistración en la función que implementa el evento de liberación de recursos del módulo.

Por ahora el único componente de hardware del microcontrolador modelado de esta forma es el timmer, pero puede escalarse a otros que requieran ser compartidos por más de un módulo.
Hay que recordar que la concurrencia implementada es puramente colaborativa entre ''usermodules'' por lo cual se debe tener especial cuidado al programar las funciones que atienden estos eventos ya que si se queda "colgada" va a degradar la disponibilidad de todo el sistema.

Para agregar el ''usermodule'' a la placa de entrada/salida ''usb4all baseboard'' se debe agregar al proyecto el módulo (utilizando el IDE preferido) y realizar la compilación del proyecto

== 7. Servicios de Timers - T0Service ==

T0service es un módulo encargado de brindar primitivas a los ''user modules'' para ser notificados de eventos del timmer.
La API expuesta es la siguiente:

<syntaxhighlight lang="C">
/*
Registers a new event callback, to be called t time units in the future.
This function must not be called from a callback handler.
*/
BOOL registerT0event(unsigned int t, void (*callback)(void));

/*
Registers a new event callback, to be called t time units in the future.
This function only can be called from a callback handler.
*/
BOOL registerT0eventInEvent(unsigned int t, void (*callback)(void));

/*
Unregister a event callback. No pending event(s) will invoke it.
*/
BOOL unregisterT0event(void (*callback)(void));

/*
Initialize the service
*/
void initT0Service(void);
</syntaxhighlight>

Estas funciones son implementadas utilizando interrupciones, lo que permite que se interrumpa el código que está ejecutando en los ''usermodules'' para notificarlos de que ocurrió el vencimiento de tiempo que deseaban.

== 8. Detalles de implementación en el firmware ==

El firmware está organizado en diferentes áreas que se mapean en secciones definidas dentro de la memoria ROM correspondiente a la memoria de programa del microcontrolador, para implementar esto se necesita especificar en un archivo llamado linker script dónde están alojadas físicamente (en memoria) estas secciones.
La forma de realizar este mapeo es editando el archivo lrk asociado al proyecto.
Existe la directiva CODEPAGE que es utilizada para trabajar con las secciones de programa, permite inicializar datos, constantes, y realizar referencias a las mismas. Tiene el siguiente formato

CODEPAGE NAME=memName START=addr END=addr [PROTECTED] [FILL=fillvalue]

donde:
memName es un string ASCII utilizado para identificar una CODEPAGE.

También existe la directiva DATABANK que permite realizar un manejo similar pero sobre la memoria de datos.

La directiva #pragma
El estándar ANSI C provee a cada implementación de un método para definir constructores únicos, según sea requerido por la arquitectura del procesador a utilizar. Esto es hecho utilizando la directiva #pragma. La directiva #pragma más común en el compilador utilizado (MPLAB C18) identifica la sección de memoria para ser utilizada en el PIC18XXXX. Por ejemplo #pragma code le indica al compilador MPLAB 18 que compile el código C en la sección de programa de la memoria de programa. La sección de código está definida en el linker script asociado para cada dispositivo PIC18XXXX, especificando en que áreas de la memoria de programa pueden ser ejecutadas instrucciones.
Esta directiva puede ser insertada directamente o puede ser seguida de la dirección en el área de código del procesador destino, permitiendo tener un control total del a memoria de código.
En el contexto del USB4all esto es muy utilizado, debido a que se separan varias áreas de memoria, las más importantes son la del bootloader, y la correspondiente a los módulos de usuario, tanto para la parte de programa (module_sec) como para la información del módulo que se almacena para gestionarlo (user_sec).
Otra directiva #pragma común que se utiliza es #pragma udata, la cual se utiliza cuando se aloja memoria para variables, las variables no inicianlizadas definidas después de esta declaración van a utilizar los registros de proposito general para almacenamiento. La arquitectura del PIC18XXXX, se basa en una arquitectura harvard la que a diferencia de la von neumann almacena las variables y las instrucciones en diferentes espacios de memoria. Por tanto las áreas de memoria deben ser explicitamente identificadas.

Por más información, consultar con el manual del compilador C18 (http://www.kevin.org/frc/C18_3.0_getting_started.pdf) en la sección #pragma DIRECTIVE o SECTIONS.

De la forma que se definieron las secciones en el archivo lkr del proyecto (18f4550.lkr) se debe colocar un #pragma code module al comenzar la declaración de los procedimientos del módulo, de esa forma se almacenan en memoria de programa (code section) dentro de la sección module. Si consultamos el linker script podemos ver que está definida la sección module como un alias del área en ROM llamada module_sec

SECTION NAME=module ROM=module_sec

a su vez module_sec es definida como:

CODEPAGE NAME=module_sec START=0x40AB END=0x8000 PROTECTED

Lo mismo se debe hacer cuando se definen las funciones que utiliza el módulo para atender eventos y su nombre (estructura uTab):

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
Como vimos en el ejemplo presentado en la sección escribiendo un ''user module''.
Hay que tener cuidado de no olvidarse de los #pragmas correspondientes ya que de de lo contrario puede no dar el espacio para compilar el proyecto o no funcionar el mecanismo de callbacks.
Los archivos lkr también especifican otros conceptos, como ser tamaño de memoria de datos y registros que utiliza, como también tamaño del stack

== ANEXO 1 ==

En el enlace [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.c] y [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.h] puede descargarse el código completo del ejemplo presentado como caso de estudio. El mismo puede usarse como esqueleto para desarrollar otros ''user modules''

----

El proyecto USB4all se encuentra disponible bajo licencia GNU/GPL v2 en el [http://sourceforge.net/projects/usb4all/ repositorio sorceforge] 
Este proyecto surge originalmente como un trabajo de [http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb tesis de grado] en Ingeniería en Computación de Aguirre, Fernandez y Grossy.

Usb4all

2014-12-23T21:22:07Z

LOLO58: /* 5. Entorno de desarrollo */

== 1. Motivación ==

La motivación de este proyecto se centra en lograr de una manera sencilla, la comunicación entre un sistema computador y un conjunto de dispositivos electrónicos no necesariamente pensados para interactuar con una computadora.
Durante muchos años la única forma de interactuar con dispositivos externos desde a un computador personal (Personal Computer) (PC) fueron los puertos seriales y paralelos, esto llevo a que se utilizaran ampliamente en multiplicidad de dispositivos. Sus principales características son su simplicidad de manejo vía software y facilidad de inclusión en distintos dispositivos. En la última década han aparecido nuevos medios o canales de comunicación, tales como Bluetooth, Fidelidad Inalámbrica (Wireless Fidelity) (WiFi), FireWire, Bus Universal en Serie (Universal Serial Bus) (USB), etc. Estos permitieron mejorar las velocidades de comunicación y calidad de datos y lentamente tornaron a los puertos paralelos y seriales en obsoletos, hasta llegar al día de hoy en que se obtienen sólo de manera opcional en los nuevos PC.
Dentro de todas estas nuevas tecnologías que aparecieron la que tuvo mayor aceptación y difusión entre los usuarios fue el USB, debido a su facilidad y versatilidad de escenarios de uso. Esta simplicidad desde el punto de vista del usuario de los dispositivos USB tiene como contrapartida una mayor complejidad para los desarrolladores de software y hardware, lo cual es un gran problema al momento de interactuar con dispositivos electrónicos.
Frente a estas adversidades que presenta el entorno actual aparece la necesidad de buscar una forma de reducir el grado de complejidad y conocimientos necesarios para poder desarrollar
software que utilice la tecnología USB. Al mismo tiempo, se requiere una plataforma base que incorpore componentes de hardware reutilizables y que en conjunto formen una solución genérica
para la comunicación con dispositivos electrónicos diversos.
En el contexto de lo antedicho aparecen un conjunto de desafíos como son el desarrollo de controladores (drivers) y construcción de piezas de hardware que brinde una solución genérica
reutilizable, desplazando el manejo de los casos particulares a componentes específicos. Esto proporciona el beneficio de evitar que cada vez que se necesite conectar un nuevo dispositivo,
se comience desde cero. A su vez permite recuperar y potenciar la característica de facilidad de manejo que poseían los puertos seriales y paralelos, explotando todas las capacidades brindadas por USB.

== 2. Arquitectura (Firmware/Hardware)==

La arquitectura está compuesta por diferentes componentes, los cuales van a permitir el funcionamiento del sistema desde lo relativo al hardware como las abstracciones necesarias para manejarlo mediante software. 
Los componentes principales son:

'''2.1 USB4all ''Baseboard'''''

[[Archivo:usb4all2.png|thumb|Fig.2.1.1: USB4all Baseboard 2.0]]
Es una placa de entrada/salida(E/S) configurable que se conecta por USB con un sistema computador. El proyecto USB4all es mucho más que una placa de E/S, en sí es una forma de modelar sistemas embebidos, siendo la placa de E/S un componente que fue necesario construir para desarrollar la solución completa. Para la construcción de esta placa se utilizó un microcontrolador PIC18F4550 de Microchip. Entre las características más destacadas en lo que concierne al proyecto se encuentra el soporte completo del estándar USB, pudiéndose utilizar varias de sus características, como ser diferentes tipos de transferencias y varios canales de comunicación (endpoints). El diseño de hardware de la placa puede descargarse del [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/pcb/ git del proyecto] permitiendo que cualquiera pueda armarse una USB4all ''baseboard'' utilizando el software GPL [http://www.lis.inpg.fr/realise_au_lis/kicad/ Kicad].

'''2.2 USB4all ''base firmware'''''

Es el firmware más estático, brinda servicios a los usermodules para que puedan utilizar los recursos presentes en la baseboard (timmers, puerto USB, conversores A/D, etc) además de brindar las primitivas para el intercambio de mensajes entre el computador y el usermodule y realiza la gestión de los ''usermodules''. Establece las bases para que los usermodules sean independientes del protocolo de comunicación computador/placa y de los detalles de hardware del microcontrolador utilizado. A su vez oferce un entorno de ejecución concurrente que permite instanciar de forma dinámica varios ''usermodules''.

'''2.3 USB4all ''usermodule'''''

Son los componentes intercambiables del sistema que permiten encapsular la lógica de un dispositivo especifico y su protocolo de comunicación con las aplicaciones de usuario. Permite al usuario dar rápidamente soporte a un nuevo dispositivo de forma genérica, expandiendo de esta manera las funcionalidades del USB4all ''basefirmware''. Los ''user modules'' son los bloques principales sobre los que se construye la arquitectura USB4all. Exponen una API uniforme que es utilizada a modo de callbacks por el ''base firmware'' y también exponen los servicios que brindan los dispositivos. Es recomendable modelar cada uno de los dispositivos electrónicos conectados a la ''baseboard'' como un ''usermodule'' donde los servicios a exponer se mapean con las características del mismo, como ejemplo en el caso de un motor, sería esperable que expusiera servicios para moverse, cambiar la velocidad y el sentido.

Del lado del sistema computador se dispone de diferentes formas de interacción: Todas ellas implementan el protocolo USB4all, su objetivo es abstraer al usuario del mismo brindando una forma sencilla de utilizar el sistema, existiendo soporte para diferentes lenguajes de programación. El objetivo principal de las bibliotecas utilizadas en el computador son las de permitir utilizar los servicios de los ''usermodules''. Esta forma de trabajo permite desarrollar la lógica de interacción entre los diferentes dispositivos electrónicos dentro del sistema computador, con lenguajes de mayor abstracción, mejores herramientas de desarrollo, permitiendo generar un código con un nivel de mantenibilidad y abstracción mayor al que se lograría si todo estuviera embebido en el microcontrolador.

Uno de los componentes más usados actualmente es el [[bobot]] que persigue un enfoque genérico al igual que el proyecto USB4all y permite acompañar la extensibilidad de la placa USB4all mediante el uso de ciertos componentes propios de la arquitectura llamados drivers.

== 3. Protocolo de Comunicación ==

El protocolo está formado por un stack de protocolos que permiten abstraer al usuario de los detalles subyacentes de la arquitectura.
El objetivo final del protocolo de comunicación, es direccionar los mensajes provenientes desde la aplicación que se ejecuta en el computador, al ''usermodule'' correspondiente ejecutado en la placa USB4all.
Estos mensajes son solicitudes de ciertos servicios que los módulos exponen, por ejemplo en el caso de un dispositivo sonoro (buzzer) utilizado para una alarma, va a ser de interés poder emitir sonido (Prender el Buzzer) detener la emisión de sonido (Apagar el Buzzer), hacer sonidos cortos pasando por parámetro la cantidad de milisegundos que se desea esté prendido, etc.
Estos mensajes se tienen que codificar de alguna manera, el protocolo especifica que primero se debe indicar el comando que se desea se ejecute y luego en caso que sea necesario (como en el de los sonidos cortos) enviar los parámetros. En algunos casos va a ser necesario obtener respuestas, las cuales se codifican de forma análoga usando el mismo protocolo, enviando en lugar de un parámetro un valor de retorno.
Este protocolo es llamado ''user protocol'' y está enfocado al usuario final, pero para que el sistema funcione correctamente es necesario contar con otros protocolos los cuales transportan el protocolo ''user protocol''. Tal es el caso del handler manager protocol que se encarga de manejar el ruteo de los mensajes al ''user module'' correspondiente. Esto se debe a que en un momento determinado puede haber varios ''user modules'' ejecutando en la placa y el sistema debe permitir notificar del nuevo mensaje al módulo para el cual está destinado el mismo. La tarea fundamental de este protocolo es brindar los mecanismos para comunicar una aplicación con un ''user module''. Otro protocolo involucrado es el ''admin protocol'' el cual se encarga de gestionar el ciclo de vida de los ''user modules'', permitiendo poner a ejecutar un ''user module'', cerrarlo y también algunas funcionalidades como el listar los módulos presentes en la placa, cerrar todos los modulos abiertos o llevar al estado de reset al microcontrolador. Tanto el ''handler protocol'' como el ''admin protocol'' son implementados por las bibliotecas que se utilicen en el computador. Existiendo varias opciones, Java, Python o Lua. Actualmente la opción que se está manteniendo es la de Lua, la cual puede estudiarse en profundidad en la sección [[bobot]].

[[Archivo:protocolo.png|700px|Fig. 3.2 Protocolo USB4all]]

Finalmente los paquetes USB4all se trasmiten por el protocolo de comunicación que disponga el ''baseboard'', para el caso típico del ''baseboard usb4all'' se trasmite mediante USB, pero puede ser trasmitido mediante otras tecnologías utilizadas para comunicarse con un computador, como ser serial o bluetooth (entre otros).

== 4. Grabando el Firmware ==
[[Archivo:usb4all2_top_view.png|thumb|Fig.4.1: USB4all Baseboard 2.0 vista desde arriba]]
Para grabar el firmware se necesita disponer de un programador hardware, como el picdem o el pickit, este último tiene buen soporte dentro de GNU/Linux.
Microchip distribuye un bootloader para la familia de microcontroladores 18F. Un bootloader es un programa que se utiliza para grabar y/o actualizar el firmware. En nuestro caso, va a permitr grabar el firmware del proyecto USB4all sin la necesidad de disponer de un programador por hardware, para realizar esto es necesario dejar presionado el botón de programación como puede verse en la figura 4.1 mientras se resetea la placa con el botón de reset. Esto funciona siempre y cuando el microcontrolador tenga grabado el bootloader.
Una vez que el dispositivo se encuentra en modo programación su identificador de producto cambia de 000c a 000b, esto puede verificarse utilizando el comando ''lsusb'' cuya salida se adjunta para los dos casos a continuación:

Id dispositivo USB4all
Bus 002 Device 002: ID 04d8:000c Microchip Technology, Inc.

id dispositivo Bootloader
Bus 002 Device 003: ID 04d8:000b Microchip Technology, Inc.

Dado que Microchip no distribuye microcontroladores con el bootlader previamente grabado, es necesario utilizar un programador por hardware para grabar el bootloader.
USB4all actualmente utiliza un bootloader modificado que permite actualizar el firmware programáticamente sin necesidad de presionar los botones, útil a la hora de realizar actualizaciones remotas, pero responde a los mismos comandos que el bootloader de Microchip, lo cual permite reutilizar el software ya desarrollado para interactuar con el bootloader.
Los fuentes del bootloader pueden encontrarse en el repositorio en el directorio bootloader del firmware, es un proyecto separado y una vez compilado su grabación se realiza mediante un programador por hardware como picdem o pickit.
Una vez grabado el bootloader ya '''no es necesario utilizar programadores por hardware''' y puede realizarse la grabación del firmware mediante varios programas que implementan el protocolo de grabación de firmware de microchip. Una de esas utilidades es el programa fsusb el cual puede encontrarse en [http://www.internetking.org/fsusb/] y es de código libre. Su uso se realiza de la siguiente forma:

./fsusb --program usb4all2.hex

Donde usb4all2.hex es el binario generado como resultado de compilar el proyecto. Recordar que el hardware debe estar en modo bootloader para poder recibir el firmware.

==== 4.1 Grabando Bootloader + Firmware ====
Una manera rápida, luego que se tiene acceso a un programador, es grabar el bootloader correspondiente y algún firmware (todo junto).
Para eso pueden usar este .hex:

[http://www.fing.edu.uy/inco/proyectos/butia/files/firmware/bootloader_con_admin.hex bootloader_con_admin.hex]

'''Nota.''' Ahora es posible grabar el firmware fácilmente mediante la siguiente actividad [[Grabar Firmware|Grabar Firmware]].

== 5. Entorno de desarrollo ==
[[Archivo:piklab.png|thumb|Fig. 5.1:Entorno de desarrollor con Piklab en GNU/Linux]][[Archivo:mplab.png|thumb|Fig. 5.2: Entorno de desarrollo con MPLab en GNU/Linux]]
El proyecto USB4all está desarrollado para el compilador C18 de Microchip, hoy día se dispone de un buen soporte del mismo para GNU/Linux pudiéndose descargar de [http://ww1.microchip.com/downloads/MPLAB/X_Beta/installer.html] también se dispone de un entorno de desarrollo llamado MPLab el cual también se encuentra disponible para GNU/Linux en la misma dirección.
Hace un tiempo atrás no existía compatibilidad para GNU/Linux de estas herramientas clásicas para los ambientes Windows en GNU/Linux. Debiéndose recurrir a alternativas para trabajar en un ambiente GNU/Linux, una opción era Piklab. Piklab es un entorno de desarrollo para trabajar con microcontroladores PIC similar a lo que es MPLab. Era muy común utilizar la versión de C18 de Windows emulada mediante wine en GNU/Linux debiéndose configurar en las opciones de toolchain de PIKLab correspondientes a C18 para que apunten correctamente a los directorios donde se encuentra el compilador C18. En el repositorio puede encontrarse un proyecto piklab configurado de esta manera. Más información sobre la configuración de c18 con piklab en linux (deprecated) ver: [http://cantareus.com/2009/08/18f4550-and-18f2550-with-piklab-and-ubuntu/]
 Luego de compilar, cargar el binario generado (.hex) en la placa mediante el uso del bootloader que se incluye en el firmware. Esto puede realizarse utilizando la herramienta fsusb como se describe en la sección Grabando el Firmware.

'''Nota.''' Para sistemas de 64 bits se debe tener instalada la librería ia32-libs.

= 5. Entorno de desarrollo =

== 6. Escribiendo un ''usermodule'' ==
Un ''usermodule'' es el bloque sobre el cual se representa una realidad y se modela utilizando la arquitectura ''USB4all'', en esta sección se presentan sus características, estructura necesaria para especificar los servicios que brinda y de que forma se anexa al ''basefirmware''

[[Archivo:user_module.png|thumb|Fig. 6.1: Tabla de referencias a ''user modules'']]

'''6.1 Estructura de un ''usermodule:'' ''' 
Un ''usermodule'' debe cumplir con una API determinada, de esta manera es posible agregar las funcionalidades que el módulo expone, dentro del ''basefirmware''.
Las operaciones principales que se deben implementar son las encargadas de atender los eventos de:
* inicialización
* liberación de recursos
* configuración

Estas operaciones se ejecutan en determinados momentos del ciclo de vida de una aplicación USB4all, siendo la operación registrada al evento de inicialización invocada al abrir desde la aplicación el ''usermodule'' y la de liberación de recursos al cerrarlo, esto permite utilizar los recursos del microcontrolador solo cuando es necesario. La operación de configuración puede invocarse en cualquier momento para cambiar en caliente algún aspecto de configuración del hardware.
Al comenzar un ''usermodule'' se debe declarar cuales van a ser las funciones que van a atender estos eventos y el nombre del módulo para ser identificado desde el computador al listar los módulos presentes en la placa.

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
#pragma code

Donde user es el nombre de la sección y uTab es una estructura para almacenar las posiciones de memoria de las operaciones que exporta el módulo y su nombre. En la sección detalles de implementación en el firmware se puede conocer más sobre el significado de la instrucción #pragma romdata user, podemos por el momento asumir que sirve para almacenar la estructura uTab en un lugar conocido dentro de la memoria de programa.

El ''basefirmware'' se encarga de pasar como argumento a la operación init el número de handler asignado al módulo, este número es utilizado como argumento en otras operaciones como ser ''setHandlerReceiveFunction'' la cual recibe por parámetro el handler y un puntero a la función encargada de manejar la recepción de datos.
Otra operación que necesita el ''handlerID'' es ''getSharedBuffer'' la cual recibe por parámetro el ''handlerID'' del módulo y retorna un buffer por el cual el módulo puede enviar datos a la aplicación que ejecuta en el computador.
Un buen lugar para obtener este buffer y registrar la función de recepción de datos es la operación encargada del evento de inicialización. A continuación puede verse como ejemplo la inicialización de un módulo de usuario para controlar un buzzer:

<syntaxhighlight lang="C"> void UserBuzzerInit(byte i) {
usrBuzzerHandler = i;
// add my receive function to the handler module, to be called automatically when the pc sends data to the user module
setHandlerReceiveFunction(usrBuzzerHandler,&UserBuzzerReceived);
// initialize the send buffer, used to send data to the PC
sendBufferUsrBuzzer = getSharedBuffer(usrBuzzerHandler);
}//end UserBuzzerInit </syntaxhighlight>

La función de recepción de datos es la encargada de implementar el protocolo de comunicación entre el ''usermodule'' y la aplicación, típicamente es una estructura tipo ''case'' en el que se espera por los diferentes comandos que pueden enviarse. La forma de codificar el pedido de servicios es mediante mensajes del tipo < COMANDO [argumento1] [argumento2]...[argumentoN] >. La respuesta debe ser del tipo < COMANDO [resultado1] [resultado2]..[resultadoN] >. El buffer para enviar datos al computador es obtenido como argumento de la función y el buffer para enviar datos fue obtenido previamente en la función de inicialización.

<syntaxhighlight lang="C"> void UserBuzzerReceived(byte* recBuffPtr, byte len){
byte index;
byte j;
byte userBuzzerCounter = 0;
byte tiempo;

switch(((BUZZER_DATA_PACKET*)recBuffPtr)->CMD){
case READ_VERSION:
//dataPacket._byte[1] is len
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[2] = BUZZER_MINOR_VERSION;
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[3] = BUZZER_MAJOR_VERSION;
userBuzzerCounter = 0x04;
break;

case PRENDER:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_on();
userBuzzerCounter = 0x02;
break;

case APAGAR:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_off();
userBuzzerCounter = 0x02;
break;

case BUZZER_TRIPLE:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks1 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1]);
cantTicks2 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[2]);
cantTicks3 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[3]);
boubleBeep(cantTicks1, cantTicks2, cantTicks3);
userBuzzerCounter = 0x02;
break;

case BUZZER_CORTO:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks3 = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
timeOutTicksBuzz = 1; // lo seteo timmer para que venza inmediantamente
buzzerState = DELAY;
registerT0event(0, &buzzEvent);
userBuzzerCounter = 0x02;
break;

case RESET:
Reset();
break;

default:
break;
}//end switch(s)
if(userBuzzerCounter != 0){
j = 255;
while(mUSBGenTxIsBusy() && j-->0); // pruebo un máximo de 255 veces
if(!mUSBGenTxIsBusy())
USBGenWrite2(usrBuzzerHandler, userBuzzerCounter);
}//end if
}//end UserBuzzerReceived</syntaxhighlight>

En este ejemplo se puede apreciar como se reciben los pedidos de comandos desde la aplicación que ejecuta en el computador y como se obtienen los parámetros necesarios para implementar los comandos y se devuelven los datos (en caso de ser requeridos) a la aplicación.

'''6.2 Entrada/Salida en user modules:''' 
Una de las tareas más importantes de los ''usermodules'' es la de realizar entrada/salida con diferentes periféricos electrónicos. Para realizar esta tarea existen dos paradigmas:
 
* Polling
* Interrupciones
 
Dentro de la arquitectura USB4all existen formas de que los módulos implementen entrada/salida utilizando estos paradigmas, para el caso de pooling existe un servicio que permite registrar una función para ser ejecutada cuando el procesador esté disponible.

<syntaxhighlight lang="C">
addPollingFunction(&UserBuzzerProcessIO);
</syntaxhighlight>

Existe soporte para interrupciones mediante el módulo ''DynamicISR'' el cual permite que otros módulos se registren sus rutinas de atención para ser invocadas cuando ocurren interrupciones.

<syntaxhighlight lang="C">
addISRFunction(&timmerISRFunction);
</syntaxhighlight>

Una forma que mantiene alta la cohesión del sistema es registrar módulos que se encarguen de esperar un evento en particular y brinde una interfaz para que los ''usermodules'' se registren para ser notificados de eventos generados por el componente de hardware que esta siendo modelado. Dentro de este módulo además se pueden brindar operaciones con mayor nivel de abstracción relacionadas con el componente a modelar. Hoy día se dispone del módulo T0service que se encarga de brindar servicio de timmers a los ''usermodules''. Al igual que el resto de los componentes funciona registrando funciones que son invocadas por el ''basefirmware''

También existen funciones para desregistrar los ''usermodules'' de las notificaciones, es conveniente realizar la desregistración en la función que implementa el evento de liberación de recursos del módulo.

Por ahora el único componente de hardware del microcontrolador modelado de esta forma es el timmer, pero puede escalarse a otros que requieran ser compartidos por más de un módulo.
Hay que recordar que la concurrencia implementada es puramente colaborativa entre ''usermodules'' por lo cual se debe tener especial cuidado al programar las funciones que atienden estos eventos ya que si se queda "colgada" va a degradar la disponibilidad de todo el sistema.

Para agregar el ''usermodule'' a la placa de entrada/salida ''usb4all baseboard'' se debe agregar al proyecto el módulo (utilizando el IDE preferido) y realizar la compilación del proyecto

== 7. Servicios de Timers - T0Service ==

T0service es un módulo encargado de brindar primitivas a los ''user modules'' para ser notificados de eventos del timmer.
La API expuesta es la siguiente:

<syntaxhighlight lang="C">
/*
Registers a new event callback, to be called t time units in the future.
This function must not be called from a callback handler.
*/
BOOL registerT0event(unsigned int t, void (*callback)(void));

/*
Registers a new event callback, to be called t time units in the future.
This function only can be called from a callback handler.
*/
BOOL registerT0eventInEvent(unsigned int t, void (*callback)(void));

/*
Unregister a event callback. No pending event(s) will invoke it.
*/
BOOL unregisterT0event(void (*callback)(void));

/*
Initialize the service
*/
void initT0Service(void);
</syntaxhighlight>

Estas funciones son implementadas utilizando interrupciones, lo que permite que se interrumpa el código que está ejecutando en los ''usermodules'' para notificarlos de que ocurrió el vencimiento de tiempo que deseaban.

== 8. Detalles de implementación en el firmware ==

El firmware está organizado en diferentes áreas que se mapean en secciones definidas dentro de la memoria ROM correspondiente a la memoria de programa del microcontrolador, para implementar esto se necesita especificar en un archivo llamado linker script dónde están alojadas físicamente (en memoria) estas secciones.
La forma de realizar este mapeo es editando el archivo lrk asociado al proyecto.
Existe la directiva CODEPAGE que es utilizada para trabajar con las secciones de programa, permite inicializar datos, constantes, y realizar referencias a las mismas. Tiene el siguiente formato

CODEPAGE NAME=memName START=addr END=addr [PROTECTED] [FILL=fillvalue]

donde:
memName es un string ASCII utilizado para identificar una CODEPAGE.

También existe la directiva DATABANK que permite realizar un manejo similar pero sobre la memoria de datos.

La directiva #pragma
El estándar ANSI C provee a cada implementación de un método para definir constructores únicos, según sea requerido por la arquitectura del procesador a utilizar. Esto es hecho utilizando la directiva #pragma. La directiva #pragma más común en el compilador utilizado (MPLAB C18) identifica la sección de memoria para ser utilizada en el PIC18XXXX. Por ejemplo #pragma code le indica al compilador MPLAB 18 que compile el código C en la sección de programa de la memoria de programa. La sección de código está definida en el linker script asociado para cada dispositivo PIC18XXXX, especificando en que áreas de la memoria de programa pueden ser ejecutadas instrucciones.
Esta directiva puede ser insertada directamente o puede ser seguida de la dirección en el área de código del procesador destino, permitiendo tener un control total del a memoria de código.
En el contexto del USB4all esto es muy utilizado, debido a que se separan varias áreas de memoria, las más importantes son la del bootloader, y la correspondiente a los módulos de usuario, tanto para la parte de programa (module_sec) como para la información del módulo que se almacena para gestionarlo (user_sec).
Otra directiva #pragma común que se utiliza es #pragma udata, la cual se utiliza cuando se aloja memoria para variables, las variables no inicianlizadas definidas después de esta declaración van a utilizar los registros de proposito general para almacenamiento. La arquitectura del PIC18XXXX, se basa en una arquitectura harvard la que a diferencia de la von neumann almacena las variables y las instrucciones en diferentes espacios de memoria. Por tanto las áreas de memoria deben ser explicitamente identificadas.

Por más información, consultar con el manual del compilador C18 (http://www.kevin.org/frc/C18_3.0_getting_started.pdf) en la sección #pragma DIRECTIVE o SECTIONS.

De la forma que se definieron las secciones en el archivo lkr del proyecto (18f4550.lkr) se debe colocar un #pragma code module al comenzar la declaración de los procedimientos del módulo, de esa forma se almacenan en memoria de programa (code section) dentro de la sección module. Si consultamos el linker script podemos ver que está definida la sección module como un alias del área en ROM llamada module_sec

SECTION NAME=module ROM=module_sec

a su vez module_sec es definida como:

CODEPAGE NAME=module_sec START=0x40AB END=0x8000 PROTECTED

Lo mismo se debe hacer cuando se definen las funciones que utiliza el módulo para atender eventos y su nombre (estructura uTab):

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
Como vimos en el ejemplo presentado en la sección escribiendo un ''user module''.
Hay que tener cuidado de no olvidarse de los #pragmas correspondientes ya que de de lo contrario puede no dar el espacio para compilar el proyecto o no funcionar el mecanismo de callbacks.
Los archivos lkr también especifican otros conceptos, como ser tamaño de memoria de datos y registros que utiliza, como también tamaño del stack

== ANEXO 1 ==

En el enlace [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.c] y [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.h] puede descargarse el código completo del ejemplo presentado como caso de estudio. El mismo puede usarse como esqueleto para desarrollar otros ''user modules''

----

El proyecto USB4all se encuentra disponible bajo licencia GNU/GPL v2 en el [http://sourceforge.net/projects/usb4all/ repositorio sorceforge] 
Este proyecto surge originalmente como un trabajo de [http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb tesis de grado] en Ingeniería en Computación de Aguirre, Fernandez y Grossy.

Usb4all

2014-12-23T21:07:47Z

LOLO58: /* 5. Entorno de desarrollo */

== 1. Motivación ==

La motivación de este proyecto se centra en lograr de una manera sencilla, la comunicación entre un sistema computador y un conjunto de dispositivos electrónicos no necesariamente pensados para interactuar con una computadora.
Durante muchos años la única forma de interactuar con dispositivos externos desde a un computador personal (Personal Computer) (PC) fueron los puertos seriales y paralelos, esto llevo a que se utilizaran ampliamente en multiplicidad de dispositivos. Sus principales características son su simplicidad de manejo vía software y facilidad de inclusión en distintos dispositivos. En la última década han aparecido nuevos medios o canales de comunicación, tales como Bluetooth, Fidelidad Inalámbrica (Wireless Fidelity) (WiFi), FireWire, Bus Universal en Serie (Universal Serial Bus) (USB), etc. Estos permitieron mejorar las velocidades de comunicación y calidad de datos y lentamente tornaron a los puertos paralelos y seriales en obsoletos, hasta llegar al día de hoy en que se obtienen sólo de manera opcional en los nuevos PC.
Dentro de todas estas nuevas tecnologías que aparecieron la que tuvo mayor aceptación y difusión entre los usuarios fue el USB, debido a su facilidad y versatilidad de escenarios de uso. Esta simplicidad desde el punto de vista del usuario de los dispositivos USB tiene como contrapartida una mayor complejidad para los desarrolladores de software y hardware, lo cual es un gran problema al momento de interactuar con dispositivos electrónicos.
Frente a estas adversidades que presenta el entorno actual aparece la necesidad de buscar una forma de reducir el grado de complejidad y conocimientos necesarios para poder desarrollar
software que utilice la tecnología USB. Al mismo tiempo, se requiere una plataforma base que incorpore componentes de hardware reutilizables y que en conjunto formen una solución genérica
para la comunicación con dispositivos electrónicos diversos.
En el contexto de lo antedicho aparecen un conjunto de desafíos como son el desarrollo de controladores (drivers) y construcción de piezas de hardware que brinde una solución genérica
reutilizable, desplazando el manejo de los casos particulares a componentes específicos. Esto proporciona el beneficio de evitar que cada vez que se necesite conectar un nuevo dispositivo,
se comience desde cero. A su vez permite recuperar y potenciar la característica de facilidad de manejo que poseían los puertos seriales y paralelos, explotando todas las capacidades brindadas por USB.

== 2. Arquitectura (Firmware/Hardware)==

La arquitectura está compuesta por diferentes componentes, los cuales van a permitir el funcionamiento del sistema desde lo relativo al hardware como las abstracciones necesarias para manejarlo mediante software. 
Los componentes principales son:

'''2.1 USB4all ''Baseboard'''''

[[Archivo:usb4all2.png|thumb|Fig.2.1.1: USB4all Baseboard 2.0]]
Es una placa de entrada/salida(E/S) configurable que se conecta por USB con un sistema computador. El proyecto USB4all es mucho más que una placa de E/S, en sí es una forma de modelar sistemas embebidos, siendo la placa de E/S un componente que fue necesario construir para desarrollar la solución completa. Para la construcción de esta placa se utilizó un microcontrolador PIC18F4550 de Microchip. Entre las características más destacadas en lo que concierne al proyecto se encuentra el soporte completo del estándar USB, pudiéndose utilizar varias de sus características, como ser diferentes tipos de transferencias y varios canales de comunicación (endpoints). El diseño de hardware de la placa puede descargarse del [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/pcb/ git del proyecto] permitiendo que cualquiera pueda armarse una USB4all ''baseboard'' utilizando el software GPL [http://www.lis.inpg.fr/realise_au_lis/kicad/ Kicad].

'''2.2 USB4all ''base firmware'''''

Es el firmware más estático, brinda servicios a los usermodules para que puedan utilizar los recursos presentes en la baseboard (timmers, puerto USB, conversores A/D, etc) además de brindar las primitivas para el intercambio de mensajes entre el computador y el usermodule y realiza la gestión de los ''usermodules''. Establece las bases para que los usermodules sean independientes del protocolo de comunicación computador/placa y de los detalles de hardware del microcontrolador utilizado. A su vez oferce un entorno de ejecución concurrente que permite instanciar de forma dinámica varios ''usermodules''.

'''2.3 USB4all ''usermodule'''''

Son los componentes intercambiables del sistema que permiten encapsular la lógica de un dispositivo especifico y su protocolo de comunicación con las aplicaciones de usuario. Permite al usuario dar rápidamente soporte a un nuevo dispositivo de forma genérica, expandiendo de esta manera las funcionalidades del USB4all ''basefirmware''. Los ''user modules'' son los bloques principales sobre los que se construye la arquitectura USB4all. Exponen una API uniforme que es utilizada a modo de callbacks por el ''base firmware'' y también exponen los servicios que brindan los dispositivos. Es recomendable modelar cada uno de los dispositivos electrónicos conectados a la ''baseboard'' como un ''usermodule'' donde los servicios a exponer se mapean con las características del mismo, como ejemplo en el caso de un motor, sería esperable que expusiera servicios para moverse, cambiar la velocidad y el sentido.

Del lado del sistema computador se dispone de diferentes formas de interacción: Todas ellas implementan el protocolo USB4all, su objetivo es abstraer al usuario del mismo brindando una forma sencilla de utilizar el sistema, existiendo soporte para diferentes lenguajes de programación. El objetivo principal de las bibliotecas utilizadas en el computador son las de permitir utilizar los servicios de los ''usermodules''. Esta forma de trabajo permite desarrollar la lógica de interacción entre los diferentes dispositivos electrónicos dentro del sistema computador, con lenguajes de mayor abstracción, mejores herramientas de desarrollo, permitiendo generar un código con un nivel de mantenibilidad y abstracción mayor al que se lograría si todo estuviera embebido en el microcontrolador.

Uno de los componentes más usados actualmente es el [[bobot]] que persigue un enfoque genérico al igual que el proyecto USB4all y permite acompañar la extensibilidad de la placa USB4all mediante el uso de ciertos componentes propios de la arquitectura llamados drivers.

== 3. Protocolo de Comunicación ==

El protocolo está formado por un stack de protocolos que permiten abstraer al usuario de los detalles subyacentes de la arquitectura.
El objetivo final del protocolo de comunicación, es direccionar los mensajes provenientes desde la aplicación que se ejecuta en el computador, al ''usermodule'' correspondiente ejecutado en la placa USB4all.
Estos mensajes son solicitudes de ciertos servicios que los módulos exponen, por ejemplo en el caso de un dispositivo sonoro (buzzer) utilizado para una alarma, va a ser de interés poder emitir sonido (Prender el Buzzer) detener la emisión de sonido (Apagar el Buzzer), hacer sonidos cortos pasando por parámetro la cantidad de milisegundos que se desea esté prendido, etc.
Estos mensajes se tienen que codificar de alguna manera, el protocolo especifica que primero se debe indicar el comando que se desea se ejecute y luego en caso que sea necesario (como en el de los sonidos cortos) enviar los parámetros. En algunos casos va a ser necesario obtener respuestas, las cuales se codifican de forma análoga usando el mismo protocolo, enviando en lugar de un parámetro un valor de retorno.
Este protocolo es llamado ''user protocol'' y está enfocado al usuario final, pero para que el sistema funcione correctamente es necesario contar con otros protocolos los cuales transportan el protocolo ''user protocol''. Tal es el caso del handler manager protocol que se encarga de manejar el ruteo de los mensajes al ''user module'' correspondiente. Esto se debe a que en un momento determinado puede haber varios ''user modules'' ejecutando en la placa y el sistema debe permitir notificar del nuevo mensaje al módulo para el cual está destinado el mismo. La tarea fundamental de este protocolo es brindar los mecanismos para comunicar una aplicación con un ''user module''. Otro protocolo involucrado es el ''admin protocol'' el cual se encarga de gestionar el ciclo de vida de los ''user modules'', permitiendo poner a ejecutar un ''user module'', cerrarlo y también algunas funcionalidades como el listar los módulos presentes en la placa, cerrar todos los modulos abiertos o llevar al estado de reset al microcontrolador. Tanto el ''handler protocol'' como el ''admin protocol'' son implementados por las bibliotecas que se utilicen en el computador. Existiendo varias opciones, Java, Python o Lua. Actualmente la opción que se está manteniendo es la de Lua, la cual puede estudiarse en profundidad en la sección [[bobot]].

[[Archivo:protocolo.png|700px|Fig. 3.2 Protocolo USB4all]]

Finalmente los paquetes USB4all se trasmiten por el protocolo de comunicación que disponga el ''baseboard'', para el caso típico del ''baseboard usb4all'' se trasmite mediante USB, pero puede ser trasmitido mediante otras tecnologías utilizadas para comunicarse con un computador, como ser serial o bluetooth (entre otros).

== 4. Grabando el Firmware ==
[[Archivo:usb4all2_top_view.png|thumb|Fig.4.1: USB4all Baseboard 2.0 vista desde arriba]]
Para grabar el firmware se necesita disponer de un programador hardware, como el picdem o el pickit, este último tiene buen soporte dentro de GNU/Linux.
Microchip distribuye un bootloader para la familia de microcontroladores 18F. Un bootloader es un programa que se utiliza para grabar y/o actualizar el firmware. En nuestro caso, va a permitr grabar el firmware del proyecto USB4all sin la necesidad de disponer de un programador por hardware, para realizar esto es necesario dejar presionado el botón de programación como puede verse en la figura 4.1 mientras se resetea la placa con el botón de reset. Esto funciona siempre y cuando el microcontrolador tenga grabado el bootloader.
Una vez que el dispositivo se encuentra en modo programación su identificador de producto cambia de 000c a 000b, esto puede verificarse utilizando el comando ''lsusb'' cuya salida se adjunta para los dos casos a continuación:

Id dispositivo USB4all
Bus 002 Device 002: ID 04d8:000c Microchip Technology, Inc.

id dispositivo Bootloader
Bus 002 Device 003: ID 04d8:000b Microchip Technology, Inc.

Dado que Microchip no distribuye microcontroladores con el bootlader previamente grabado, es necesario utilizar un programador por hardware para grabar el bootloader.
USB4all actualmente utiliza un bootloader modificado que permite actualizar el firmware programáticamente sin necesidad de presionar los botones, útil a la hora de realizar actualizaciones remotas, pero responde a los mismos comandos que el bootloader de Microchip, lo cual permite reutilizar el software ya desarrollado para interactuar con el bootloader.
Los fuentes del bootloader pueden encontrarse en el repositorio en el directorio bootloader del firmware, es un proyecto separado y una vez compilado su grabación se realiza mediante un programador por hardware como picdem o pickit.
Una vez grabado el bootloader ya '''no es necesario utilizar programadores por hardware''' y puede realizarse la grabación del firmware mediante varios programas que implementan el protocolo de grabación de firmware de microchip. Una de esas utilidades es el programa fsusb el cual puede encontrarse en [http://www.internetking.org/fsusb/] y es de código libre. Su uso se realiza de la siguiente forma:

./fsusb --program usb4all2.hex

Donde usb4all2.hex es el binario generado como resultado de compilar el proyecto. Recordar que el hardware debe estar en modo bootloader para poder recibir el firmware.

==== 4.1 Grabando Bootloader + Firmware ====
Una manera rápida, luego que se tiene acceso a un programador, es grabar el bootloader correspondiente y algún firmware (todo junto).
Para eso pueden usar este .hex:

[http://www.fing.edu.uy/inco/proyectos/butia/files/firmware/bootloader_con_admin.hex bootloader_con_admin.hex]

'''Nota.''' Ahora es posible grabar el firmware fácilmente mediante la siguiente actividad [[Grabar Firmware|Grabar Firmware]].

== 5. Entorno de desarrollo ==
[[Archivo:piklab.png|thumb|Fig. 5.1:Entorno de desarrollor con Piklab en GNU/Linux]][[Archivo:mplab.png|thumb|Fig. 5.2: Entorno de desarrollo con MPLab en GNU/Linux]]
El proyecto USB4all está desarrollado para el compilador C18 de Microchip, hoy día se dispone de un buen soporte del mismo para GNU/Linux pudiéndose descargar de [http://ww1.microchip.com/downloads/MPLAB/X_Beta/installer.html] también se dispone de un entorno de desarrollo llamado MPLab el cual también se encuentra disponible para GNU/Linux en la misma dirección.
Hace un tiempo atrás no existía compatibilidad para GNU/Linux de estas herramientas clásicas para los ambientes Windows en GNU/Linux. Debiéndose recurrir a alternativas para trabajar en un ambiente GNU/Linux, una opción era Piklab. Piklab es un entorno de desarrollo para trabajar con microcontroladores PIC similar a lo que es MPLab. Era muy común utilizar la versión de C18 de Windows emulada mediante wine en GNU/Linux debiéndose configurar en las opciones de toolchain de PIKLab correspondientes a C18 para que apunten correctamente a los directorios donde se encuentra el compilador C18. En el repositorio puede encontrarse un proyecto piklab configurado de esta manera. Más información sobre la configuración de c18 con piklab en linux (deprecated) ver: [http://cantareus.com/2009/08/18f4550-and-18f2550-with-piklab-and-ubuntu/]
 Luego de compilar, cargar el binario generado (.hex) en la placa mediante el uso del bootloader que se incluye en el firmware. Esto puede realizarse utilizando la herramienta fsusb como se describe en la sección Grabando el Firmware.

'''Nota.''' Para sistemas de 64 bits se debe tener instalada la librería ia32-libs.
= 5. Entorno de desarrollo =

== 6. Escribiendo un ''usermodule'' ==
Un ''usermodule'' es el bloque sobre el cual se representa una realidad y se modela utilizando la arquitectura ''USB4all'', en esta sección se presentan sus características, estructura necesaria para especificar los servicios que brinda y de que forma se anexa al ''basefirmware''

[[Archivo:user_module.png|thumb|Fig. 6.1: Tabla de referencias a ''user modules'']]

'''6.1 Estructura de un ''usermodule:'' ''' 
Un ''usermodule'' debe cumplir con una API determinada, de esta manera es posible agregar las funcionalidades que el módulo expone, dentro del ''basefirmware''.
Las operaciones principales que se deben implementar son las encargadas de atender los eventos de:
* inicialización
* liberación de recursos
* configuración

Estas operaciones se ejecutan en determinados momentos del ciclo de vida de una aplicación USB4all, siendo la operación registrada al evento de inicialización invocada al abrir desde la aplicación el ''usermodule'' y la de liberación de recursos al cerrarlo, esto permite utilizar los recursos del microcontrolador solo cuando es necesario. La operación de configuración puede invocarse en cualquier momento para cambiar en caliente algún aspecto de configuración del hardware.
Al comenzar un ''usermodule'' se debe declarar cuales van a ser las funciones que van a atender estos eventos y el nombre del módulo para ser identificado desde el computador al listar los módulos presentes en la placa.

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
#pragma code

Donde user es el nombre de la sección y uTab es una estructura para almacenar las posiciones de memoria de las operaciones que exporta el módulo y su nombre. En la sección detalles de implementación en el firmware se puede conocer más sobre el significado de la instrucción #pragma romdata user, podemos por el momento asumir que sirve para almacenar la estructura uTab en un lugar conocido dentro de la memoria de programa.

El ''basefirmware'' se encarga de pasar como argumento a la operación init el número de handler asignado al módulo, este número es utilizado como argumento en otras operaciones como ser ''setHandlerReceiveFunction'' la cual recibe por parámetro el handler y un puntero a la función encargada de manejar la recepción de datos.
Otra operación que necesita el ''handlerID'' es ''getSharedBuffer'' la cual recibe por parámetro el ''handlerID'' del módulo y retorna un buffer por el cual el módulo puede enviar datos a la aplicación que ejecuta en el computador.
Un buen lugar para obtener este buffer y registrar la función de recepción de datos es la operación encargada del evento de inicialización. A continuación puede verse como ejemplo la inicialización de un módulo de usuario para controlar un buzzer:

<syntaxhighlight lang="C"> void UserBuzzerInit(byte i) {
usrBuzzerHandler = i;
// add my receive function to the handler module, to be called automatically when the pc sends data to the user module
setHandlerReceiveFunction(usrBuzzerHandler,&UserBuzzerReceived);
// initialize the send buffer, used to send data to the PC
sendBufferUsrBuzzer = getSharedBuffer(usrBuzzerHandler);
}//end UserBuzzerInit </syntaxhighlight>

La función de recepción de datos es la encargada de implementar el protocolo de comunicación entre el ''usermodule'' y la aplicación, típicamente es una estructura tipo ''case'' en el que se espera por los diferentes comandos que pueden enviarse. La forma de codificar el pedido de servicios es mediante mensajes del tipo < COMANDO [argumento1] [argumento2]...[argumentoN] >. La respuesta debe ser del tipo < COMANDO [resultado1] [resultado2]..[resultadoN] >. El buffer para enviar datos al computador es obtenido como argumento de la función y el buffer para enviar datos fue obtenido previamente en la función de inicialización.

<syntaxhighlight lang="C"> void UserBuzzerReceived(byte* recBuffPtr, byte len){
byte index;
byte j;
byte userBuzzerCounter = 0;
byte tiempo;

switch(((BUZZER_DATA_PACKET*)recBuffPtr)->CMD){
case READ_VERSION:
//dataPacket._byte[1] is len
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[2] = BUZZER_MINOR_VERSION;
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[3] = BUZZER_MAJOR_VERSION;
userBuzzerCounter = 0x04;
break;

case PRENDER:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_on();
userBuzzerCounter = 0x02;
break;

case APAGAR:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
buzzer_off();
userBuzzerCounter = 0x02;
break;

case BUZZER_TRIPLE:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks1 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1]);
cantTicks2 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[2]);
cantTicks3 = (byte)(((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[3]);
boubleBeep(cantTicks1, cantTicks2, cantTicks3);
userBuzzerCounter = 0x02;
break;

case BUZZER_CORTO:
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[0] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[0];
((BUZZER_DATA_PACKET*)sendBufferUsrBuzzer)->_byte[1] = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
cantTicks3 = ((BUZZER_DATA_PACKET*)recBuffPtr)->_byte[1];
timeOutTicksBuzz = 1; // lo seteo timmer para que venza inmediantamente
buzzerState = DELAY;
registerT0event(0, &buzzEvent);
userBuzzerCounter = 0x02;
break;

case RESET:
Reset();
break;

default:
break;
}//end switch(s)
if(userBuzzerCounter != 0){
j = 255;
while(mUSBGenTxIsBusy() && j-->0); // pruebo un máximo de 255 veces
if(!mUSBGenTxIsBusy())
USBGenWrite2(usrBuzzerHandler, userBuzzerCounter);
}//end if
}//end UserBuzzerReceived</syntaxhighlight>

En este ejemplo se puede apreciar como se reciben los pedidos de comandos desde la aplicación que ejecuta en el computador y como se obtienen los parámetros necesarios para implementar los comandos y se devuelven los datos (en caso de ser requeridos) a la aplicación.

'''6.2 Entrada/Salida en user modules:''' 
Una de las tareas más importantes de los ''usermodules'' es la de realizar entrada/salida con diferentes periféricos electrónicos. Para realizar esta tarea existen dos paradigmas:
 
* Polling
* Interrupciones
 
Dentro de la arquitectura USB4all existen formas de que los módulos implementen entrada/salida utilizando estos paradigmas, para el caso de pooling existe un servicio que permite registrar una función para ser ejecutada cuando el procesador esté disponible.

<syntaxhighlight lang="C">
addPollingFunction(&UserBuzzerProcessIO);
</syntaxhighlight>

Existe soporte para interrupciones mediante el módulo ''DynamicISR'' el cual permite que otros módulos se registren sus rutinas de atención para ser invocadas cuando ocurren interrupciones.

<syntaxhighlight lang="C">
addISRFunction(&timmerISRFunction);
</syntaxhighlight>

Una forma que mantiene alta la cohesión del sistema es registrar módulos que se encarguen de esperar un evento en particular y brinde una interfaz para que los ''usermodules'' se registren para ser notificados de eventos generados por el componente de hardware que esta siendo modelado. Dentro de este módulo además se pueden brindar operaciones con mayor nivel de abstracción relacionadas con el componente a modelar. Hoy día se dispone del módulo T0service que se encarga de brindar servicio de timmers a los ''usermodules''. Al igual que el resto de los componentes funciona registrando funciones que son invocadas por el ''basefirmware''

También existen funciones para desregistrar los ''usermodules'' de las notificaciones, es conveniente realizar la desregistración en la función que implementa el evento de liberación de recursos del módulo.

Por ahora el único componente de hardware del microcontrolador modelado de esta forma es el timmer, pero puede escalarse a otros que requieran ser compartidos por más de un módulo.
Hay que recordar que la concurrencia implementada es puramente colaborativa entre ''usermodules'' por lo cual se debe tener especial cuidado al programar las funciones que atienden estos eventos ya que si se queda "colgada" va a degradar la disponibilidad de todo el sistema.

Para agregar el ''usermodule'' a la placa de entrada/salida ''usb4all baseboard'' se debe agregar al proyecto el módulo (utilizando el IDE preferido) y realizar la compilación del proyecto

== 7. Servicios de Timers - T0Service ==

T0service es un módulo encargado de brindar primitivas a los ''user modules'' para ser notificados de eventos del timmer.
La API expuesta es la siguiente:

<syntaxhighlight lang="C">
/*
Registers a new event callback, to be called t time units in the future.
This function must not be called from a callback handler.
*/
BOOL registerT0event(unsigned int t, void (*callback)(void));

/*
Registers a new event callback, to be called t time units in the future.
This function only can be called from a callback handler.
*/
BOOL registerT0eventInEvent(unsigned int t, void (*callback)(void));

/*
Unregister a event callback. No pending event(s) will invoke it.
*/
BOOL unregisterT0event(void (*callback)(void));

/*
Initialize the service
*/
void initT0Service(void);
</syntaxhighlight>

Estas funciones son implementadas utilizando interrupciones, lo que permite que se interrumpa el código que está ejecutando en los ''usermodules'' para notificarlos de que ocurrió el vencimiento de tiempo que deseaban.

== 8. Detalles de implementación en el firmware ==

El firmware está organizado en diferentes áreas que se mapean en secciones definidas dentro de la memoria ROM correspondiente a la memoria de programa del microcontrolador, para implementar esto se necesita especificar en un archivo llamado linker script dónde están alojadas físicamente (en memoria) estas secciones.
La forma de realizar este mapeo es editando el archivo lrk asociado al proyecto.
Existe la directiva CODEPAGE que es utilizada para trabajar con las secciones de programa, permite inicializar datos, constantes, y realizar referencias a las mismas. Tiene el siguiente formato

CODEPAGE NAME=memName START=addr END=addr [PROTECTED] [FILL=fillvalue]

donde:
memName es un string ASCII utilizado para identificar una CODEPAGE.

También existe la directiva DATABANK que permite realizar un manejo similar pero sobre la memoria de datos.

La directiva #pragma
El estándar ANSI C provee a cada implementación de un método para definir constructores únicos, según sea requerido por la arquitectura del procesador a utilizar. Esto es hecho utilizando la directiva #pragma. La directiva #pragma más común en el compilador utilizado (MPLAB C18) identifica la sección de memoria para ser utilizada en el PIC18XXXX. Por ejemplo #pragma code le indica al compilador MPLAB 18 que compile el código C en la sección de programa de la memoria de programa. La sección de código está definida en el linker script asociado para cada dispositivo PIC18XXXX, especificando en que áreas de la memoria de programa pueden ser ejecutadas instrucciones.
Esta directiva puede ser insertada directamente o puede ser seguida de la dirección en el área de código del procesador destino, permitiendo tener un control total del a memoria de código.
En el contexto del USB4all esto es muy utilizado, debido a que se separan varias áreas de memoria, las más importantes son la del bootloader, y la correspondiente a los módulos de usuario, tanto para la parte de programa (module_sec) como para la información del módulo que se almacena para gestionarlo (user_sec).
Otra directiva #pragma común que se utiliza es #pragma udata, la cual se utiliza cuando se aloja memoria para variables, las variables no inicianlizadas definidas después de esta declaración van a utilizar los registros de proposito general para almacenamiento. La arquitectura del PIC18XXXX, se basa en una arquitectura harvard la que a diferencia de la von neumann almacena las variables y las instrucciones en diferentes espacios de memoria. Por tanto las áreas de memoria deben ser explicitamente identificadas.

Por más información, consultar con el manual del compilador C18 (http://www.kevin.org/frc/C18_3.0_getting_started.pdf) en la sección #pragma DIRECTIVE o SECTIONS.

De la forma que se definieron las secciones en el archivo lkr del proyecto (18f4550.lkr) se debe colocar un #pragma code module al comenzar la declaración de los procedimientos del módulo, de esa forma se almacenan en memoria de programa (code section) dentro de la sección module. Si consultamos el linker script podemos ver que está definida la sección module como un alias del área en ROM llamada module_sec

SECTION NAME=module ROM=module_sec

a su vez module_sec es definida como:

CODEPAGE NAME=module_sec START=0x40AB END=0x8000 PROTECTED

Lo mismo se debe hacer cuando se definen las funciones que utiliza el módulo para atender eventos y su nombre (estructura uTab):

#pragma romdata user
uTab userBuzzerModuleTable = {&UserBuzzerInit,&UserBuzzerRelease,&UserBuzzerConfigure,"buzzer"};
Como vimos en el ejemplo presentado en la sección escribiendo un ''user module''.
Hay que tener cuidado de no olvidarse de los #pragmas correspondientes ya que de de lo contrario puede no dar el espacio para compilar el proyecto o no funcionar el mecanismo de callbacks.
Los archivos lkr también especifican otros conceptos, como ser tamaño de memoria de datos y registros que utiliza, como también tamaño del stack

== ANEXO 1 ==

En el enlace [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.c] y [http://sourceforge.net/p/usb4all/code/ci/6ecc2581f50519fe427f7a3947136c2a03108841/tree/firmware/u4a2/user/usr_buzzer.h] puede descargarse el código completo del ejemplo presentado como caso de estudio. El mismo puede usarse como esqueleto para desarrollar otros ''user modules''

----

El proyecto USB4all se encuentra disponible bajo licencia GNU/GPL v2 en el [http://sourceforge.net/projects/usb4all/ repositorio sorceforge] 
Este proyecto surge originalmente como un trabajo de [http://www.fing.edu.uy/inco/grupos/mina/pGrado/pgusb tesis de grado] en Ingeniería en Computación de Aguirre, Fernandez y Grossy.

Grupo 5

2014-12-05T21:34:50Z

LOLO58: /* Código Fuente */

__TOC__

== Integrantes ==

* Agustín Cabral - agucabral@gmail.com
* Gustavo Evovlockas - gevovlockas@gmail.com

==Tutor==
* Federico Andrade - fandrade@fing.edu.uy

==Actas de reuniones==

===30 de Junio 2014===

*Se plantea la investigación varios kits robóticos para hacer un revelamiento de los actuadores que incorpora.
*Uno de los actuadores a incorporar será el motor pasos a paso y para comenzar a trabajar en este tipo de motores debemos discutir varios puntos por lo cual decidimos tratar el tema con la comunidad Butiá para el aporte de opiniones, ideas, críticas.
*Con respecto a los motores paso a paso se analizaran varios aspectos:
#Comunicación de los motores con la USB4Butia.
#Driver del motor.
#Funciones de alto nivel.
*Para la comunicación con la USB4Butia se tienen en principio dos opciones.
#Hack pines (necesitariamos 4)
#Puertos RJ45
*Con respecto al driver (placa del motor) tenemos dos formas de implementarlo.
#Usar Shift Register mas ULN2803
#Usar un microcontrolador mas ULN2803
*Las funciones deseadas pueden ser
#Girar un paso
#Girar constantemente
#Girar velocidad, sentido, grado

===16 de Julio 2014===
*Se decide incorporar al kit Butiá tres nuevos actuadores.
#Relay.
#Buzzer.
#Motor paso a paso unipolar.
*Se envio a la lista de desarrollo el pedido de asignación de espacio de direcciones (valores de resistencias de identificación) para los actuadores a implementar.
*Se decidió comenzar por la implementación de relay y se coordina el comienzo de la misma.
*En lo que respecta al paso a paso, y según lo que se venia hablando en la reunión anterior, se decide usar para su implementación un Shift Register 74HC595 mas un ULN2803.

==Actuadores==

===Relé===

El relé o relevador es un dispositivo electromecánico. Funciona como un interruptor controlado por un circuito eléctrico en el que, por medio de una bobina y un electroimán, se acciona un juego de uno o varios contactos que permiten abrir o cerrar otros circuitos eléctricos independientes.

[[Archivo:relay_circuit.jpg]]
 
====Componentes====
* Conector RJ45 hembra acodado x1
* Rele 5 patas 12v (o menos) x1
* Resistencias 4.7kΩ x1
* Resistencias 120kΩ (Id) x1
* Transistor NPN BC639 x1 ([[Archivo:Transistor-datasheet.pdf]])
* Diodo IN4007 x1 ([[Archivo:Diodo-datasheet.pdf]])
* Terminal x2

 

Una vez que se quema el cobre se procede a soldar cada componente. Los archivos usados para quemar el cobre por transferencia de tóner se encuentran en la [[Grupo_5#Kicad|sección Kicad]]. El porceso de transferencia por tóner se puede ver [[USB4butiá_tutorial|aquí]]. A continuación se muestra un video que indica como soldar cada componente.

 
<youtube>8IetiZDq9so</youtube>
 

===Buzzer===

Es un transductor electroacústico que produce un sonido o zumbido continuo o intermitente de un mismo tono. Sirve como mecanismo de señalización o aviso, y son utilizados en múltiples sistemas como en automóviles o en electrodomésticos, incluidos los despertadores.

[[Archivo:Buzzer2.png‎‎]]
 
====Componentes====
* Conector RJ45 hembra acodado x1
* Resistencia 180 KΩ (Id) x1
* Resistencia 330 Ω x1
* Buzzer 5v x1
 

Una vez que se quema el cobre se procede a soldar cada componente. Los archivos usados para quemar el cobre por transferencia de tóner se encuentran en la [[Grupo_5#Kicad|sección Kicad]]. El porceso de transferencia por tóner se puede ver [[USB4butiá_tutorial|aquí]]. A continuación se muestra un video que indica como soldar cada componente.

 
<youtube>Yz3SdiaS6YY</youtube>
 

==Presetación Sumo 2014==
 

[http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Archivo:Actuadores_Gupo_5.pdf Aquí] se encuentra el archivo de la presentación hecha el día 17 de setiembre de 2014.

 

==Kicad==
[[Archivo:Buzzer.pdf]]
 
[[Archivo:Rele.pdf]]
 
En el siguiente .zip se pueden encontrar los dos proyectos de kicad, los modulos y compontentes creados, y los .ps de los circuitos:
[[Archivo:Actuadores.zip]]
 

==Código Fuente==
[[Archivo:RobEdu2014_grp5.tar.gz]]

Grupo 5

2014-12-05T21:30:58Z

LOLO58: /* Kicad */

Archivo:RobEdu2014 grp5.tar.gz

2014-12-05T21:28:21Z

LOLO58:

USB4butiá

2014-12-04T21:48:19Z

LOLO58:

USB4Butiá es una interfaz de Entrada/Salida (E/S) USB derivada de [[Usb4all]] y un [[usb4all_shield_butia|shield]] realizado para dicha placa. Es de fácil construcción y está especializada en el uso con el robot [[butia2|Butiá 2.0]] intentando simplificar su uso y aumentar su capacidades sensoriales y actuación de manera robusta.
La placa persigue como '''''objetivo general''''':

Un diseño de la placa es abierto y diseñado con el objetivo que su construcción sea posible mediante mecanismos manuales permitiendo su accesibilidad y por lo tanto la libertad del diseño (más info: [http://www.olpcnews.com/use_cases/technology/usb4butia_a_truly_free_as_in_freedom_input_output_board.html USB4butia - A Truly Free (as in Freedom) Input/Output Board] )

Los '''''objetivos particulares''''' son:

* Ser económica
* Utilización de componentes de fácil acceso en el mercado local
* Tener puertos conectores para dispositivos con soporte de [[plug and play]] y [[plug and play| hotplug]]
* Bus para motores AX12
* PWM para manejo de motores servo
* [[HackPoints]] para acceso al bajo nivel

=== Características ===

* 6 puertos para dispositivos con soporte hotplug and play cuya especificación del conector puede verse [[ Especificación conector Rj45 | aquí ]]

=== Construcción ===

'''Versión actual de la placa: 1.9.0''' Para versiones anteriores clic [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/ aquí].

*'''Fuentes:''' Los fuentes fueron realizados en el software GNU/GPL Kicad [http://www.kicad-pcb.org/display/KICAD/KiCad+EDA+Software+Suite]. Estas pueden descargarse del repositorio Github de Butia en Sourceforge [http://sourceforge.net/p/usb4all/code/ci/master/tree/pcb/usb4butia/] [http://www.fing.edu.uy/inco/proyectos/butia/files/usb4butia-Copper.pdf].

*'''Componentes:''' [[Componentes|Lista de componentes USB4butiá]] 

*'''Fabricación:''' Puede fabricar la placa manualmente con el método de la plancha, o alternativamente mandar a fabricar la misma en plaza o al exterior.
**Fabricación manual: [[USB4butiá_tutorial|Tutorial de construcción paso a paso]]
**Mandar a fabricar:
***Archivos gerber para mandar a fabricar: [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/usb4butia.zip pedido]
***Fabricación en el exterior: [http://www.seeedstudio.com/depot/fusion-pcb-service-p-835.html?cPath=185 Seeedstudio]: envíe el [http://www.fing.edu.uy/inco/proyectos/butia/files/hardware/usb4butia.zip pedido] en tamaño de 10x10cm 
***Fabricación en el Uruguay: [http://www.eneka.com.uy/ Eneka]: Empresa de electrónica en Montevideo-Uruguay. 

*'''Instalación de firmware''': Además de hacer la placa como se explica en el tutorial, es necesario cargar el programa que corre en el pic 18F4550 (más conocido como firmware). Cómo realizar esto lo explicaremos en el siguiente link [[Firmware|Tutorial de instalación de firmware]].

[[Archivo:usb4butia1.jpg|300px]]
[[Archivo:usb4butia2.jpg|300px]]
[[Archivo:usb4butia3r.jpg|300px]]
[[Archivo:USB4butia.png|300px]]
[[Archivo:Componentes_pcb.png|300px]]

Archivo:USB4butia.png

2014-12-04T21:47:29Z

LOLO58: subió una nueva versión de «Archivo:USB4butia.png»

Archivo:USB4butia.png

2014-12-04T21:21:53Z

LOLO58: subió una nueva versión de «Archivo:USB4butia.png»

Archivo:USB4butia.png

2014-12-04T21:19:15Z

LOLO58:

Página principal

2014-12-03T20:28:36Z

LOLO58: Redirigiendo a Wiki Butiá

#REDIRECCIÓN [[Wiki Butiá]]

Página principal

2014-12-03T20:27:08Z

LOLO58:

Para acceder a la página principal del proyecto Butiá diríjase a
[http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Wiki_Buti%C3%A1]
#REDIRECCIÓN [[Wiki Butiá]]

Página principal

2014-12-03T19:59:12Z

LOLO58: Redirigiendo a Wiki Butiá

#REDIRECCIÓN [[Wiki Butiá]]

Página principal

2014-12-03T19:51:06Z

LOLO58:

== Sobre este sitio ==
Este sitio es un espacio colaborativo para articular los aportes de la comunidad Butiá. Podrá encontrar información técnica, ideas y propuestas. Si usted está buscando la página principal del Proyecto Butiá debe dirigirse a [http://www.fing.edu.uy/inco/proyectos/butia web institucional del Proyecto Butiá]

== Proyecto Butiá ==

Este proyecto plantea como objetivo crear una plataforma simple, la cual ponga al alcance de estudiantes escolares o liceales las herramientas necesarias para permitirles interiorizarse con la programación de comportamientos para robots.
El proyecto Butiá trata de ampliar las capacidades sensoriales y de actuación de la computadora XO del proyecto OLPC (u otro netbook educativo), transformandola en una plataforma robótica móvil.
Actualmente la implementación 2.0 del proyecto está siendo utilizado en formato de kit, distribuido a más de 100 centros educativos del Uruguay, con un set de sensores y piezas que permiten cambiar la ubicación de los sensores en la plataforma móvil donde se coloca la computadora. 
A su vez el proyecto Butiá fue desarrollado teniendo en mente el hecho que agregar nuevos sensores o actuadores a la plataforma sea muy sencillo, esto abre la posibilidad a que usuarios interesados con el hardware puedan implementar fácilmente sus propios sensores y actuadores. Incluso el [http://es.wikipedia.org/wiki/Dise%C3%B1o_industrial diseño industrial] del robot es abierto lo cual permite realizarlo con materiales reciclados o de bajo costo.

== Desarrollo ==

La plataforma Butiá esta liberada como software libre a la comunidad, tu puedes contribuir con el proyecto como desarrollador uniéndote en [http://sourceforge.net/projects/butia/ Proyecto Butiá en SourceForge] 
El código fuente del software (plugins, toribio, tortubots, etc) está versionado bajo sistema de control [http://git-scm.com/ GIT], para saber más vea [[Git Butia]]. 
El código de firmware y PCBs esta versionado bajo sistema de control [http://git-scm.com/ GIT], en el git de USB4all [http://sourceforge.net/projects/usb4all/ USB4all en SourceForge] 
Actualmente estamos trabajando en una nueva placa ([[usb4butia|USB4butia]]) para el [[Butia2|Butiá 2.0]] que busca bajar costos, ser más robusto al permitir conectar dispositivos y hacer más simple la construcción de la placa de E/S al utilizar la plataforma [[usb4all|USB4all]]. 
Se puede participar a través de la lista de correo de desarrollo [https://www.fing.edu.uy/mailman/listinfo/butia-devel-l butiá-devel-l], también puede ver el [https://www.fing.edu.uy/pipermail/butia-devel-l/ historial] de la misma. 
También puede participar de las reuniones Butiá, las mismas se realizan de forma quincenal los días '''Martes a las 18:30hs en el Laboratorio de Robótica''' [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/index.php/Preguntas_frecuentes (cómo llegar)]. En el [http://www.fing.edu.uy/inco/proyectos/butia/eventos.html calendario Butiá] puede consultar la fecha de las reuniones y otras actividades que realizamos.
Puede ver el desarrollo de las reuniones en [[Actas Reuniones Butia]]. 
Propuestas de discusiones para las reuniones [[Discusiones para las reuniones]]. 
Este proyecto se realiza con el apoyo de [http://www.antel.com.uy ANTel].

== Construcción ==

* [[construcción_Butiá_V1.0|Construyendo un Robot Butiáv1.0 paso a paso]]
* [[construcción_Butiá_V1.8|Construyendo un Robot Butiáv1.8 paso a paso]]
* [[construcción_Butiá_V2.0|Construyendo un Robot Butiáv2.0 paso a paso]]
* [[flashearIdAX12|Como flashear los motores AX12]]
* [[Motores|Información general sobre motores]]
* [[Otros Materiales|Butiá V2.0 en madera]]

== Lenguajes de programación ==

El Robot butiá puede controlarse fácilmente desde cualquier [http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n lenguaje de programación] con soporte de conexiones [http://es.wikipedia.org/wiki/TCP/IP TCP/IP]. De todas maneras damos soporte para algunas plataformas concretas mediante [http://es.wikipedia.org/wiki/Plugin plugins], [http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones API's] o [http://es.wikipedia.org/wiki/Entorno_de_desarrollo_integrado IDEs]. Algunos ejemplos son: 
[[TortuBots]] 
[[Butialo]] (Lua) 
[[Python]] 

== Manuales ==

* [http://www.fing.edu.uy/inco/proyectos/butia/files/docs_butia2/armando_paso_a_paso_ax12_rev1.pdf Manual de armado paso a paso para Butiá con motores AX12]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/docs_butia2/armando_paso_a_paso_motores_CC_rev1.pdf Manual de armado paso a paso para Butiá con motores de corriente continua]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/docs_butia2/cartilla_de_armado_r%C3%A1pido_rev2.pdf Cartilla de armado rápido]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/docs_butia2/manual_de_construccion_rev1.pdf Manual de construcción]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/docs_butia2/manual_de_usuario_rev1.pdf Manual de usuario]

== Tutoriales ==

En esta sección encontrarás información de como programar el comportamiento del robot Butiá.

* [[Ejemplo_recibir_ordenes_con_aplausos| Cómo controlar el robot Butiá mediante aplausos]]
* [[tortugarte_variables|Como almacenar los valores leídos de los sensores utilizando TortugArte con Butiá]]
* [[Evitar_obstaculos|Como evitar obstaculos utilizando TortugArte con Butiá]]
* [[Evitar_caida|Como evitar caer de una mesa]]
* [[Ejemplo_seguidor_de_líneas_sencillo|Como hacer un seguidor de líneas sencillo]]
* [[Ejemplo_seguidor_de_líneas|Como hacer un seguidor de líneas avanzado]]
* [[Ejemplo_sumo|Como hacer un luchador de Sumo]]
* [[Transformando_a_cms_el_valor_del_sensor_de_distancia|Transformando a centímetros la salida del sensor de distancia]]
* [[Butiá_que_habla|Butiá que habla]]
* [[Modularizando|Como modularizar un programa en Tortugarte]]
* [[video_tutoriales|Video Tutoriales]]
* [[Preguntas_frecuentes|Preguntas Frecuentes]]
* [[FollowMe|Utilizar plugin FollowMe]]
* [[USB4butiá| Cómo construir una placa USB4Butià]]
* [[Ejemplos_de_Aplicaciones_en_Butialo|Ejemplos de Lua en Butialo]]
* [[HackPoints|Como utilizar los HackPoints]]
* [[Medir voltaje y resistencia | Como medir voltaje y resistencia]]
* [[Tutorial_de_armado_de_butiá_con_motores_de_corriente_Continua | Tutorial de armado de butiá con motores de corriente Continua]]
* [[Intructivo_para_generar_archivos_gerbers_en_kicad | Instructivo para generar archivos gerbers en Kicad]]
* [[Butiá Cards | Tarjetas de comportamientos básicos]]

== Actividades para realizar con el robot relacionadas con otras ciencias ==

[[Biología y Butiá]]

== ButiArte ==

A puro arte 
[[remeras|Remeras]] 
[[Cuadernolas Butiá y Sumo]] 
[[Logo oficial]]

== Sumo.uy: Desafío aptos para Butiá en evento de SUMO Robótico ==

Son numerosas las instituciones educativas que a nivel mundial desarrollan exposiciones robóticas. 
En nuestro país, la [http://www.fing.edu.uy Facultad de Ingeniería] de la [http://www.udelar.edu.uy Universidad de la República] es pionera. 
Desde 2004, año a año el evento [http://www.fing.edu.uy/sumo.uy sumo.uy] ha cumplido con éxito su misión: hacer que la sociedad sea partícipe, y no mero testigo, de los avances en robótica e inteligencia artificial. 
'''[http://www.fing.edu.uy/sumo.uy sumo.uy]''' ofrece un entorno abierto a todo público, donde universitarios y no universitarios, liceales, adultos y niños, uruguayos y extranjeros pueden interactuar, presentar sus trabajos y plantear sus inquietudes relacionadas con la temática del evento. 
En el marco de la edición 2013 de este evento se podrá participar con el robot Butiá en tres desafíos:

[http://www.fing.edu.uy/inco/eventos/sumo.uy/Documentos/Desaf%C3%ADo%20Escolar_2013_v0.1.pdf Desafío Escolar]

[http://www.fing.edu.uy/inco/eventos/sumo.uy/Documentos/Desaf%C3%ADo%20B%C3%A1sico_2013_v0.1.pdf Desafío Básico]

[http://www.fing.edu.uy/inco/eventos/sumo.uy/Documentos/Desaf%C3%ADo_Avanzado_sumo.uy_2013.pdf_v0.1.pdf Desafío Avanzado]

Para desafíos anteriores mire [[sumo.uy historial desafios Butiá| aquí]]

==Sumo.uy: Experiencias desafíos Butiá==

* Sumo.uy 2011 ( [[Sumo.uy_2011_Resumen_desafío_Butiá|español]] | [[Sumo.uy_2011_Summary_Butiá_challenge|ingles]] )

== Curso Butiá: Robótica educativa ==
{{AP|Proyectos Butiá}}
En esta sección se mantiene un historial de proyectos que se realizan y/o fueron realizados en el curso.

* [[proyectos_abiertos|Proyectos abiertos para realizar en el marco del "Proyecto Butiá"]]

* [[proyectos_electiva_butia_2014|Proyectos electiva Butiá 2014]]

* [[proyectos_electiva_butia_2013|Proyectos electiva Butiá 2013]]

* [[proyectos_electiva_butia_2012|Proyectos electiva Butiá 2012]]

* [[proyectos_mtbutia_2011|Proyectos módulo taller butiá 2011]]

* [[proyectos_mtbutia_2010|Proyectos módulo taller butiá 2010]]

* [[espacio_para_grupos_2011|Espacio de documentación de los grupos 2011]]

* [[espacio_para_grupos_2012|Espacio de documentación de los grupos 2012]]

* [[espacio_para_grupos_2013|Espacio de documentación de los grupos 2013]]

* [[espacio_para_grupos_2014|Espacio de documentación de los grupos 2014]]

* [[laboratorios_2014|Laboratorios 2014]]

== Extensión Universitaria ==

* [[talleres_y_charlas|Talleres y charlas]]

* [[mega_construccion_2010|Construyendo los robots]]

* [[entrega_de_Butiá_V1.0|Entrega de 28 robots Butiá en el evento Sumo.uy 2010]]

* [[espacio_liceos|Experiencias realizadas por nuestro usuarios]]

* [[Robótica_educativa_con_el_robot_Butiá_Proyecto_Estímulo_a_la_Cultura_Científica_y_Tecnológica,_Prociencia,_18-21/07/2012|Prociencia 2012]]

* [[quiero_una_USB4Butia|Proyectos - Quiero una USB4Butia]]

== Publicaciones científicas ==

*Artículo presentado en el congreso Inforedu2013 "Congreso Internacional de Informática en la Educación" [http://www.fing.edu.uy/~aaguirre/papers/inforedu13_robotica_educativa.pdf Robótica educativa de la mano del robot Butiá][http://www.inforedu2013.mes.edu.cu/ponencia/uruguay/rob%C3%B3tica-educativa-en-uruguay-de-la-mano-del-robot-buti%C3%A1 Sitio del evento]

*Artículo presentado en el congreso WEEF 2012 "Engineering Education for Sustainable Development and Social Inclusión" [http://www.weef2012.edu.ar/papersFinal/information.php?doc=227 1 adolescente. 1 computadora. 1 robot]

*Artículo publicado en OLPC, [http://www.olpcnews.com/use_cases/technology/usb4butia_a_truly_free_as_in_freedom_input_output_board.html USB4butia - A Truly Free (as in Freedom) Input/Output Board]

*Poster presentado en el Congreso Argentino de SistemasEmbebidos, Case2012, Buenos Aires, Argentina:
[http://www.sase.com.ar/2012/files/2011/11/case2012_memorias_pp235-end.pdf FollowMe: seguimiento de objetos mediante el uso de webcam y plataforma Butiá] pag. 281

*Poster presentado en el Congreso Argentino de SistemasEmbebidos, Case2012, Buenos Aires, Argentina:
[http://www.sase.com.ar/2012/files/2011/11/case2012_memorias_pp235-end.pdf USB4BUTIA: Interfaz Robótica Educativa de simple fabricación y bajo costo] pag. 282

*Artículo presentado en el evento "apropiación y desarrollo: modelos 1 a 1" 2012 organizado por Flor de Ceibo: [http://www.fing.edu.uy/inco/proyectos/butia/files/butia_edu1a1_v1.4_ponencia_completa.pdf Butiá, transformando tu XO en un robot móvil programable]

*Artículo presentado en el evento "apropiación y desarrollo: modelos 1 a 1" 2012 organizado por Flor de Ceibo: [http://www.fing.edu.uy/inco/proyectos/butia/files/De_tortugarte_a_butia_en_la_escuela_primaria.pdf De la tortuga al robot Butiá, experiencias en el uso de Tortugarte en la escuela primaria]

*Artículo presentado en el Encuentro Desarrolladores Uruguay, eduJAM 2012: [http://wiki.sugarlabs.org/images/1/13/Turtle_sensors.pdf How open hardware and software can empower students and communities]

*Artículo presentado en el Simposio Argentino de Sistemas Embebidos, Sase2011, Buenos Aires, Argentina:
[http://www.sase.com.ar/2011/case/articulos-case/butia-plataforma-robotica-generica-para-la-ensenanza-de-la-informatica/ Butiá: Plataforma robótica genérica para la enseñanza de la informática]

== Material de Presentaciones Butiá ==

[[Archivo:poster_olpc-sf.jpg|thumb|Poster presentado en OLPC - San Francisco / 2011]]
[[Archivo:OLPC - SF 2012.png|thumb|Poster presentado en OLPC - San Francisco / 2012]]
[[Archivo:OLPC - SF 2013.png|thumb|Poster presentado en OLPC - San Francisco / 2013]]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/jiio.pdf JIIO, XIII Jornadas de Informática e Investigación Operativa, Montevideo, Uruguay, 2013]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/Buti%C3%A1-ANTEL-AVANZA_PT%28a.k.a%20consegi%29.pdf CONSEGI 2013, Brasilia, Brasil 2013]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/Buti%C3%A1-ANTEL-AVANZA.pdf ANTEL AVANZA, Montevideo, Uruguay 2013]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/Buti%C3%A1%202.0%20SAM%20edujam%20Paraguay%202013.pdf EDUJAM 2013, Asunción, Paraguay 2013]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/Buti%C3%A1%202.0%20SAM%20sumo.uy%202013.pdf Sumo.uy 2013]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/charlas/Buti%C3%A1%202.0%20SAM%20congreso%20matem%C3%A1ticas.pdf Congreso de matemáticas 2013]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/proyecto_butia_capacitacion_5_2012.pdf Butiá: Sistema robótico constructivo de bajo costo para uso educativo, Encuentro Nacional de Voluntarios 2012, Squeakfest 2012]

* [http://www.fing.edu.uy/inco/proyectos/butia/files/Turtle%20sensors.pdf How open hardware and software can empower students and communities, eduJAM2012]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/de_la_tortuga_al_robot_butia.pdf De la tortuga al robot Butiá, Experiencias en el uso de Tortugarte en la escuela primaria, en el evento apropiación y desarrollo: modelos 1 a 1, organizado por Flor de Ceibo]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/butia-1a1.pdf Butiá: Plataforma robótica genérica para la enseñanza inicial y media, en el evento apropiación y desarrollo: modelos 1 a 1, organizado por Flor de Ceibo]
* [http://www.fing.edu.uy/inco/proyectos/butia/files/butia-seminarioFIERGS_handout.pdf Charla del robot Butiá en el Seminario FIERGS, Porto Alegre, Brasil]

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/public/pres_seMINArios_2011_handouts.pdf Charla del robot Butiá el los seMINArios del Instituto de Computación, UdelaR, Montevideo, Uruguay, 2011]

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/public/presCASE2011HandsOut.pdf Charla del robot Butiá en el congreso argentino de sistemas embebidos, Buenos Aires, 2011]

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/public/butia-jornadasANTel-FIng2011.pdf Charla del robot Butiá en las jornadas de telecomunicaciones realizadas, Rocha, Uruguay, 2011]

* [http://www.fing.edu.uy/inco/proyectos/butia/mediawiki/public/presCPBRASIL.pdf Charla del robot Butiá en el campus party, San Pablo, Brasil, 2011]

== El robot Butiá en los medios ==

[[notas_en_tv|Notas en televisión]] 
[[Notas en Radio]] 
[[notas_en_blogs|Notas en Blogs y la Web]] 
[[congresos_y_seminarios|Congresos y Seminarios]] 
[[notas_revistas|Notas en revistas]] 
[[notas_diarios|Notas en periódicos]]

== Multimedia ==

[[nuestros_videos|Videos]]

[[pistas butiá|Pistas]]

[[banners butiá|Banners]]

== Comunicación ==
* [http://www.facebook.com/group.php?gid=147042805312846 Seguinos en Facebook uniendote al grupo] 
* [https://plus.google.com/u/0/108413393520841902443/posts Seguinos en google+] 
* [https://www.fing.edu.uy/mailman/listinfo/butia-list Lista de correo butia-list] 
* [https://www.fing.edu.uy/mailman/listinfo/butia-devel-l Lista de correo butiá-devel-l para tratar temas relacionados con el desarrollo de la plataforma] 
* [[instructivo_newsgroup|Instructivo para el uso del Newsgroup de fing]] 

== Preguntas Frecuentes (f.a.q) sobre el Butiá ==

Puede encontrarse una lista de preguntas frecuentes y su respuesta en [[preguntas_frecuentes]]

== Empezando a utilizar wiki ==

Consulta la [http://meta.wikimedia.org/wiki/Ayuda:Contenido Guía de usuario] para obtener información sobre el uso del software wiki.
* [http://www.mediawiki.org/wiki/Manual:Configuration_settings Lista de ajustes de configuración]
* [http://www.mediawiki.org/wiki/Manual:FAQ/es FAQ de MediaWiki]

[[Main page (English)]]

Wiki Butiá

2014-12-03T19:46:52Z

LOLO58: Wiki trasladada a Wiki Butiá

Wiki

2014-12-03T19:46:52Z

LOLO58: Wiki trasladada a Wiki Butiá

#REDIRECCIÓN [[Wiki Butiá]]

Página principal

2014-12-03T19:05:16Z

LOLO58: Página principal trasladada a Wiki

#REDIRECCIÓN [[Wiki]]

Wiki Butiá

2014-12-03T19:05:15Z

LOLO58: Página principal trasladada a Wiki

Archivo:Sharp.jpg

2014-11-11T17:56:11Z

LOLO58: subió una nueva versión de «Archivo:Sharp.jpg»

Archivo:Sharp.jpg

2014-11-11T17:54:21Z

LOLO58: subió una nueva versión de «Archivo:Sharp.jpg»

Especificaciones fabricación

2014-11-11T17:50:02Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:Sharp.jpg]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Especificaciones fabricación

2014-11-11T17:49:44Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:Sharp.jpg|500px]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Archivo:Sharp.jpg

2014-11-11T17:49:11Z

LOLO58: subió una nueva versión de «Archivo:Sharp.jpg»

Especificaciones fabricación

2014-11-11T17:44:47Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:20141110_184701.jpg|500px]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Especificaciones fabricación

2014-11-11T17:44:05Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:20141110_184701.jpg]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Especificaciones fabricación

2014-11-11T17:43:06Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:20141110_184701.jpg|200px]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Especificaciones fabricación

2014-11-11T17:42:29Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:20141110_184701.jpg..jpg|200px]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Archivo:20141110 184701.jpg

2014-11-11T17:41:13Z

LOLO58: subió una nueva versión de «Archivo:20141110 184701.jpg»: Revertido a la versión subida el 11 nov 2014 a las 17:37

Versión del sensor Sharp con los cables enverados para mayo seguridad

Archivo:20141110 184701.jpg

2014-11-11T17:40:52Z

LOLO58: subió una nueva versión de «Archivo:20141110 184701.jpg»

Versión del sensor Sharp con los cables enverados para mayo seguridad

Especificaciones fabricación

2014-11-11T17:39:24Z

LOLO58: /* Placa Sensores */

== Placa USB4Butiá ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials USB4Butiá'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/PIC18F4550-I%2FP/PIC18F4550-I%2FP-ND/704580 PIC 18F4550]|| 1 || microcontroller||PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/2-641606-4/A94140-ND/292145 Socket 40pin]||1||socket for the microcontroller||under PIC18F4550
|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||6|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/292304-1/A31725-ND/773785 USB Female Type B]||1||CONN USB RECEPT R/A TYPE B 4POS||USB_B
|-
|[http://www.digikey.com/product-search/en?WT.z_header=search_go&lang=en&keywords=WM18901-ND&x=0&y=0&cur=USD ax12 bus connector] ||1|| CONN HEADER 3POS 2.5MM R/A TIN||AX-12
|-
|Resistor 120Ω||1||resistor 5% tolerance, 1/4w power||120Ω
|-
|Resistor 390Ω||2|| resistor 5% tolerance, 1/4w power||390Ω
|-
|Resistor 1KΩ||2|| resistor 5% tolerance, 1/4w power||1KΩ
|-
|Resistor 10KΩ||11|| resistor 5% tolerance, 1/4w power||10KΩ
|-
|Resistor 1MΩ||1|| resistor 5% tolerance, 1/4w power||1MΩ
|-
|22PF||2||capacitor||22pF
|-
|0.1UF||4||capacitor||0.1uF
|-
|0.47UF||1||capacitor||0.47uF
|-
|[http://www.newark.com/rubycon/25nw710mefc6-3x7/capacitor-alum-elect-10uf-25v-20/dp/54T5342?in_merch=Popular%20Capacitors electrolitic capacitor 10UF, 25V, 20%]||1|| lower than 7mm||10uF
|-
|Led 3mm||1||standar 3mm led color green ||LED
|-
|20MHZ crystal||1||HC49S-20-B-30-30-F-20.000MHz must be with height less than 7mm||Crystal 20MHZ
|-
|switch||2|| 4.3mm microswitch|| RST SW1, PROG SW2
|-
|Female Header||11||Contact spacing 2.54mm (0.1")||h1..h11
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/usb4butia1.9.0.zip USB4Butiá Gerber file]

== Shield para motores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of materials for USB4Butiá motor shield'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-search/en?vendor=0&keywords=L298HN L298HN]|| 1 ||IC BRIDGE DRIVER PAR 15MULTIWATT||U1 L298
|-
|1A7||8||diode type 1N4001 o 1N4007||D1..D8
|-
|male headers pins ||14||Contact spacing 2.54mm (0.1")||P1..P4
|-
|100nF (10V minimum, 20% tolerance)||2||ceramic capacitor||C1, C2
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/shield_l298hn.zip USB4Butiá motor shield Gerber file]

== Placa Sensores ==

{| border="0" style="background:#ffffff" align="top" class="sortable wikitable"
|+ align="center" style="background:DarkSlateBlue; color:white"|<big>'''Bill of Materials allselasercut'''</big>
! width="60 px" style="background:Lavender; color:Black"|Component
! width="20 px" style="background:Lavender; color:Black"|Quantity
! width="100 px" style="background:Lavender; color:Black"|Description
! width="60 px" style="background:Lavender; color:Black"|PCB Identifier

|-
|[http://www.digikey.com/product-detail/en/5555167-1/A31444-ND/769588 RJ45 Female Jack]||5|| CONN MOD JACK R/A 8P8C ||RJ45
|-
|[http://www.digikey.com/product-detail/en/ECA-1EM471B/P10379TB-ND/268464 470uf electronic capacitor]||1|| CAP ALUM 470UF 25V 20% RADIAL || C1 CAPAPOL
|-
|Resistor 10kΩ||4||5% tolerance, 1/4w power||
|-
|Resistor 6.8kΩ||1||5% tolerance, 1/4w power ||
|-
|Resistor 120Ω||2|| 5% tolerance, 1/4w power||
|-
|Resistor 1kΩ||2|| 5% tolerance, 1/4w power||
|-
|Resistor 68kΩ||2|| 5% tolerance, 1/4w power||
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=365-1174-ND Led]||2||HIGH INTENSITY LED 525NM ROUND GREEN 3MM like digikey part 365-1174-ND||LED
|-
|[http://www.aliexpress.com/item/LXD4548-CdS-Photoconductive-cells-CdS-Photoresistor/473940099.html Photoresistor]||3|| 10K-200K OHM 4.20MM Ceramic Substrate(Length x Width x Height):L4.3mm X W3.4mm X H1.8mm like LXD4548||LDR
|-
|[http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-distance-measuring/1967026?k=GP2Y0A21YK0F GP2Y0A21YK0F]||1|| SENSOR DISTANCE MEASURE 80CM ANLG||sharp
|-
|[http://www.digikey.com/product-search/en?x=0&y=0&lang=en&site=us&KeyWords=KS-03Q-02 Pushbutton]||1|| like digkey KS-03Q-02 product||SW_PUSH
|-
|[http://www.digikey.com/product-detail/en/ACC-C17-3/EG4805-ND/2116284 Pushbutton cap]||1|| like digikey ACC-C17-6 product ||
|-
|}

PCB material specification:
* FR4 Material
* 1.6MM Thickness
* HASL Lead Free Surface Finish
* 1oz Copper Thickness
* Green Solder Mask
* White Silkscreen
* [http://www.fing.edu.uy/inco/proyectos/butia/files/PCBenero2014/allsenlasercutV2.zip Sensor kit Gerber file]
* Each module specified in plantilla_allsenV2_lasercut-F_SilkS must be cuted with mouse bite technique or similar
* The sharp sensor must be connected in this way [[Archivo:20141110 184701.jpg|200px]]
* To make more robust the connections please pass the cable througth the holes before doing the soldiering. TODO attach a new picture

Archivo:20141110 184701.jpg

2014-11-11T17:37:57Z

LOLO58: Versión del sensor Sharp con los cables enverados para mayo seguridad

Versión del sensor Sharp con los cables enverados para mayo seguridad

Archivo:Sharp.jpg

2014-11-11T17:35:06Z

LOLO58: subió una nueva versión de «Archivo:Sharp.jpg»: Revertido a la versión subida el 27 ene 2014 a las 19:39