2.6. - Fase de test de sistema
El test de sistema es la validación final del diseño. A partir de los requerimientos identificados al inicio del proceso de diseño se tiene que comprobar que cumplimos todos los requerimientos, o en todo caso, identificar aquellos requerimientos que no cumplimos.
Para un ámbito profesional, es habitual que esta fase de test de sistema esté supervisado por el cliente, de forma que incluso, sea el cliente quien haga la validación final.
Esta es la penúltima fase de diseño y debemos asegurarnos que toda la documentación de diseño queda convenientemente almacenada. Esta documentación será de vital importancia para el mantenimiento del diseño, y para la toma decisión de futuros proyectos.
2.7. - Fase de celebración
No hace falta demasiados detalles, que cada uno la describa para sí mismo...
jueves, 11 de abril de 2013
lunes, 8 de abril de 2013
Proceso de diseño de equipos electrónicos (7/8)
2.5. - Integración del sistema y desarrollo del software
El hardware fue validado en la fase anterior, en la fase de construcción del prototipo, y en esta fase, comprobamos que el software funciona correctamente con el hardware validado.
Programar y validar el software significa desarrollar y testear individualmente cada función del software.
Cuando una función esté validada, escribir otra función adicional y testear de nuevo. Se trata de ir incrementando la funcionalidad de forma progresiva, debugándola, hasta llegar a tener toda la funcionalidad implementada.
El hardware fue validado en la fase anterior, en la fase de construcción del prototipo, y en esta fase, comprobamos que el software funciona correctamente con el hardware validado.
Programar y validar el software significa desarrollar y testear individualmente cada función del software.
Cuando una función esté validada, escribir otra función adicional y testear de nuevo. Se trata de ir incrementando la funcionalidad de forma progresiva, debugándola, hasta llegar a tener toda la funcionalidad implementada.
viernes, 5 de abril de 2013
Proceso de diseño de equipos electrónicos (6/8)
2.4. - Fase de construcción y test del prototipo de hardware
Esta fase se describe en sí misma. En esta fase se tiene que constuir y testear el hardware, a partir de la documentación generada en la fase de diseño. Si se ha hecho bien el trabajo en fases previas, no deben haber sorpresas durante esta fase.
Para validar el diseño, una vez construido el prototipo, hay que simular las entradas y supervisar las salidas de forma que cuando se integre el software, estemos completamente seguros de que el hardware es correcto. Hay que evitar que cuando dispongamos del software no sepamos si los errores de funcionamiento son debidos al hardware.
En esta fase hay que utilizar la estrategia de dividir el test en partes, "divide y vencerás". No hay que pretender validar todo el hardware de una sola vez, hay que subdividir el problema de forma que vayamos validando bloques por separado.
Esta fase se describe en sí misma. En esta fase se tiene que constuir y testear el hardware, a partir de la documentación generada en la fase de diseño. Si se ha hecho bien el trabajo en fases previas, no deben haber sorpresas durante esta fase.
Para validar el diseño, una vez construido el prototipo, hay que simular las entradas y supervisar las salidas de forma que cuando se integre el software, estemos completamente seguros de que el hardware es correcto. Hay que evitar que cuando dispongamos del software no sepamos si los errores de funcionamiento son debidos al hardware.
En esta fase hay que utilizar la estrategia de dividir el test en partes, "divide y vencerás". No hay que pretender validar todo el hardware de una sola vez, hay que subdividir el problema de forma que vayamos validando bloques por separado.
jueves, 4 de abril de 2013
Proceso de diseño de equipos electrónicos (5/8)
2.3. - Fase de definición del Test
Cada uno de los bloques identificados en la fase de diseño tienen que ser testeados. En realidad hay dos tipos de tests:
- Test individual. Se comprueba una parte del diseño a bajo nivel.
- Test final, o test de sistema. Se comprueba todo el equipo en funcionamiento.
El objetivo de esta fase es describir los tests, y los resultados esperados, para cumplir con todos los requerimientos identificados en la fase de definición y diseño.
¿Qué pasa cuando no se comprueba que el equipo cumple con todos los requerimentos?, hay ejemplos dolorosos a lo largo de la historia, algunos de los más sonados:
- Apollo 13. El módulo lunar se quedó sin sistema de ventilación mientra orbitaba la luna.
Un extracto de la wikipedia dice:
La comisión de investigación de las causas del accidente determinó en su conclusión:
Si este tipo de errores ocurren en grandes proyecto aeroespaciales, con enormes esfuerzos de estanderización y gigantescos presupuestos, ¿qué no puede ocurrir en pequeñas organizaciones sin procesos de diseño definidos?...
Cada uno de los bloques identificados en la fase de diseño tienen que ser testeados. En realidad hay dos tipos de tests:
- Test individual. Se comprueba una parte del diseño a bajo nivel.
- Test final, o test de sistema. Se comprueba todo el equipo en funcionamiento.
El objetivo de esta fase es describir los tests, y los resultados esperados, para cumplir con todos los requerimientos identificados en la fase de definición y diseño.
¿Qué pasa cuando no se comprueba que el equipo cumple con todos los requerimentos?, hay ejemplos dolorosos a lo largo de la historia, algunos de los más sonados:
- Apollo 13. El módulo lunar se quedó sin sistema de ventilación mientra orbitaba la luna.
Un extracto de la wikipedia dice:
"The heater and protection thermostats were originally designed for the command module's 28-volt DC bus. The specifications for the heater and thermostat were later changed to allow a 65-volt ground supply, in order to pressurize the tanks more rapidly. Beechcraft, the tank subcontractor, did not upgrade the thermostat to handle the higher voltage. The temperature sensor could not read above the highest operational temperature of the heater, which was approximately 100 °F (38 °C). This was not normally a problem because the thermostat was designed to open at 80 °F(27 °C)."- Space Shuttle Challenger: transbordador espacial que explotó al despegar.
La comisión de investigación de las causas del accidente determinó en su conclusión:
"In view of the findings, the Commission concluded that the cause of the Challenger accident was the failure of the pressure seal in the aft field joint of the right Solid Rocket Booster. The failure was due to a faulty design unacceptably sensitive to a number of factors. These factors were the effects of temperature, physical dimensions, the character of materials, the effects of reusability, processing and the reaction of the joint to dynamic loading."
Si este tipo de errores ocurren en grandes proyecto aeroespaciales, con enormes esfuerzos de estanderización y gigantescos presupuestos, ¿qué no puede ocurrir en pequeñas organizaciones sin procesos de diseño definidos?...
martes, 2 de abril de 2013
Proceso de diseño de equipos electrónicos (4/8)
2.2. - Fase de Diseño
En el próximo post hablaré de la fase de definición del test.
En la fase de definición previa, describimos el sistema con grandes bloques funcionales. Solo hicimos algunos prototipos de aquellas partes más complejas o desconocidas (pruebas de concepto, o proofs of concept (PoC)) para comprobar la viabilidad del proyecto.
En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
Como resultado de esta fase, se tiene que disponer de los diagramas de arquitectura y diagramas de flujo del software, y los esquemáticos, y listas de material, del hardware.En esta fase se trata de entrar en el detalle. Cada uno de los bloques de hardware y software que se definieron previamente tienen que ser analizados y descritos.
Esta es la fase más importante del proyecto, se debe dedicar hasta el 50 % del tiempo total del proyecto. Si se hace correctamente, con el suficiente rigor, se conseguirá mantener controlado el proyecto y tendremos éxito en cuanto al plazo, coste, y cumpliendo los requerimientos de alcance del proyecto.
En cuanto al hardware, en esta fase, a partir de los grandes bloques descritos en la fase de definición, iremos bajando de nivel, desglosándolos en sub-bloques hasta llegar al nivel del esquemático. Utilizaremos herramientas de simulación (PSPICE, Webench, ...) cuando creamos que necesitemos validar el funcionamiento de un circuito, y mantendremos una exhaustiva documentación de todos las simulaciones. También mantendremos una documentación de los criterios que hemos seguido en la selección de los componentes. Es importante mantener un registro de los criterios de las decisiones de diseño, esa información nos puede ser muy útil para futuros proyectos.
En cuanto al software, en esta frase se trata de conseguir la definición en diagramas de bloque del flujo del programa. Hay que tomar decisiones sobre la gestión de las interrupciones, determinar las tareas críticas,...
Durante esta fase el desarrollo del software tiene que ir en paralelo con el desarrollo del hardware. Hay empresas en las que se crean dos grupos de trabajo muy diferenciados entre los desarrolladores del hardware y del firmware. Si no se aseguran canales fluidos de comunicación entre los dos equipos, los problemas de malos entendidos, falta de sincronización, ... no tardan en aparecer.
Esta sigue siendo una fase frustrante para el ingeniero inquieto que prefiere programar, o hackear el hardware, antes que documentar. Creo que hay que hacer una llamada a la profesional, o al gusto por hacer las cosas bien hechas, para evitar caer en la tentación de ir por libre. No se trata de hacer "algo" que funcione, se trata de hacer algo que funcione en el tiempo, coste establecidos, y con la calidad requerida, y para conseguir eso, hay que meditar y documentar previamente en las posibles opciones que se disponen. Desgraciadamente, esto es algo que a menudo no se comprende, y que tiene que ver mucho con la productividad de un departamento de diseño.
En el próximo post hablaré de la fase de definición del test.
jueves, 28 de marzo de 2013
Proceso de diseño de equipos electrónicos (3/8)
2 - Proceso de diseño del proyecto
El proceso de diseño del proyecto se desglosa en varias subfases:
2.1. - Fase de definición
Es una fase teórica, se tata de hacer un estudio de viabilidad, no se empieza a diseñar electrónica aún.
Uno de los principales retos con los que debemos enfrentarnos durante el diseño electrónico, es intentar evitar diseñar demasiado pronto. La tentación nos empuja a ponernos a trastear lo antes posible, es divertido, y no hemos venido a la vida para sufrir... Pues bien, una de las principales causas de fracaso en un diseño es precisamente esa tendencia a empezar a tomar decisiones de diseño sin reflexionar antes sobre la mejor opción sobre la viabilidad funcional del diseño, la viabilidad económica del coste del desarrollo y del coste de producto final, ...
Sólo se bajará a algo de detalle si se ha detectado en el diseño alguna parte de la que nos estamos seguros que vaya a funcionar ya sea por su complejidad, o porque se soluciona con unos componentes que no conocemos. En ese caso, llevaremos a cabo simulaciones, prototipos sin demasiado detalle (a estos prototipos se les llama pruebas de concepto (proof of concept (PoC)).
Recomiendo para esta fase tranquilidad, una hoja en blanco, silencio y reflexión. Ya llegará el momento de trastear con electrónica, por ahora se trata sobretodo "solo" en pensar.
El objetivo de esta fase es escribir unas especificaciones técnicas que demuestren varias cosas:
- Hemos entendido las necesidades iniciales
- Hemos determinado cómo vamos a hacer el diseño con una descripción de grandes bloques y hemos demostramos que es una solución correcta.
- Hemos validado que las nuevas tecnologías, o las soluciones más difíciles, son correctas para este diseño a través de prototipos.
- Demostramos la viabilidad de la solución tanto a nivel funcional como a nivel económico.
De nuevo, dependiendo del ámbito en el que te muevas, se puede exigir una documentación muy exhaustiva. Puede resulta frustrante dedicar tanto tiempo a documentar y no bajar a la arena del diseño, pero es un paso necesario. Aún no he conocido a un ingeniero al que le guste documentar, pero insisto, es necesario pasar por aquí si no queremos eternizar nuestro diseño en un estúpido proceso de "prueba y error" que no suele acabar bien para nadie.
En los próximos posts seguiré hablando del proceso diseño.
El proceso de diseño del proyecto se desglosa en varias subfases:
2.1. - Fase de definición
Es una fase teórica, se tata de hacer un estudio de viabilidad, no se empieza a diseñar electrónica aún.
Uno de los principales retos con los que debemos enfrentarnos durante el diseño electrónico, es intentar evitar diseñar demasiado pronto. La tentación nos empuja a ponernos a trastear lo antes posible, es divertido, y no hemos venido a la vida para sufrir... Pues bien, una de las principales causas de fracaso en un diseño es precisamente esa tendencia a empezar a tomar decisiones de diseño sin reflexionar antes sobre la mejor opción sobre la viabilidad funcional del diseño, la viabilidad económica del coste del desarrollo y del coste de producto final, ...
Sólo se bajará a algo de detalle si se ha detectado en el diseño alguna parte de la que nos estamos seguros que vaya a funcionar ya sea por su complejidad, o porque se soluciona con unos componentes que no conocemos. En ese caso, llevaremos a cabo simulaciones, prototipos sin demasiado detalle (a estos prototipos se les llama pruebas de concepto (proof of concept (PoC)).
Recomiendo para esta fase tranquilidad, una hoja en blanco, silencio y reflexión. Ya llegará el momento de trastear con electrónica, por ahora se trata sobretodo "solo" en pensar.
El objetivo de esta fase es escribir unas especificaciones técnicas que demuestren varias cosas:
- Hemos entendido las necesidades iniciales
- Hemos determinado cómo vamos a hacer el diseño con una descripción de grandes bloques y hemos demostramos que es una solución correcta.
- Hemos validado que las nuevas tecnologías, o las soluciones más difíciles, son correctas para este diseño a través de prototipos.
- Demostramos la viabilidad de la solución tanto a nivel funcional como a nivel económico.
De nuevo, dependiendo del ámbito en el que te muevas, se puede exigir una documentación muy exhaustiva. Puede resulta frustrante dedicar tanto tiempo a documentar y no bajar a la arena del diseño, pero es un paso necesario. Aún no he conocido a un ingeniero al que le guste documentar, pero insisto, es necesario pasar por aquí si no queremos eternizar nuestro diseño en un estúpido proceso de "prueba y error" que no suele acabar bien para nadie.
En los próximos posts seguiré hablando del proceso diseño.
lunes, 25 de marzo de 2013
RFduino
RFduino, un microcontrolador que incorpora el soporte wireless (Bluetooth 4.0), del tamaño de una uña. Y además, se puede programar con el IDE de Arduino:
Proceso de diseño de equipos electrónicos (2/8)
1 - Fase de desarrollo del concepto
En esta fase aparece la necesidad que debe ser satisfecha por un nuevo diseño. ¿De dónde sale esta necesidad?, hay infinidad de posibilidades dependiendo de si se trata de un ámbito profesional, o de un proyecto de hacking doméstico. Algunos ejemplos:
- El departamento de marketing detecta que para cubrir una necesidad de mercado se tendría que crear un nuevo producto con una ciertas características.
- Un producto que está en fabricación, requiere ser modificado porque hay problemas de obsolescencia de componentes.
- Se ha detectado que hay un alto ratio de devolución de producto por parte del cliente por problemas de diseño, el equipo deja de funcionar o al instalarlo se daña. Hay que modificar el diseño para corregir este error.
- Hemos visto un video en youtube que nos ha parecido increíble y queremos hacer algo similar con nuestro Arduion o nuestra Raspberry Pi.
- ...
Esta es la fase de detección de la necesidad. Es interesante en todo caso, plantearse antes de hacer nada, por qué hacemos lo que hacemos, dónde queremos ir.
Obviamente, en un ámbito profesional, en esta fase se tiene que hacer un estudio económico que justifique la inversión necesaria para realizar el diseño.
En futuros posts seguiré explicando las distintas fase del proceso de diseño.
sábado, 23 de marzo de 2013
Proceso de diseño de equipos electrónicos (1/8)
El diseños de equipos electrónicos requiere de un proceso que no deberíamos saltarnos, si queremos diseñar de una manera eficiente.
Hay una relación entre los largos e ineficiente diseños, y la mala calidad del producto final. Ambos efectos, suelen ser consecuencia de no haber seguido un proceso de diseño riguroso.
Como indice general, las fases del proceso de diseño de equipos electrónicos:
1 - Fase de desarrollo del concepto
2 - Proceso de diseño del proyecto
2.1. - Fase de definición
2.5. - Integración del sistema y desarrollo del software
2.6. - Fase de test de sistema
2.7. - Fase de celebración
Hay una relación entre los largos e ineficiente diseños, y la mala calidad del producto final. Ambos efectos, suelen ser consecuencia de no haber seguido un proceso de diseño riguroso.
Como indice general, las fases del proceso de diseño de equipos electrónicos:
1 - Fase de desarrollo del concepto
2 - Proceso de diseño del proyecto
2.1. - Fase de definición
2.2. - Fase de Diseño
2.3. - Fase de Test
2.4. - Fase de construcción y test del prototipo2.5. - Integración del sistema y desarrollo del software
2.6. - Fase de test de sistema
2.7. - Fase de celebración
En futuros posts explicaré, de forma muy general, cada uno de estos paso.
viernes, 14 de diciembre de 2012
domingo, 11 de marzo de 2012
martes, 27 de septiembre de 2011
el secreto de la motivación
¿Por qué la gente se dedica a desarrollar productos tecnológicos en su tiempo libre (Linux, Hardware libre, ...), sin sacar ningun provecho en ello?, ¿solo por el placer de hacerlo?. Supongo que pueden haber diversas teorias, pero estos dos videos dan un explicación que me resulta convincente:
Hasta pronto.
Hasta pronto.
martes, 13 de septiembre de 2011
Funciones ULP para Eagle
Después de batallar un poco con el editor de PCBs Eagle, me he hecho una lista de funciones ULP que utilizo con asiduidad. Recordad que para ejecutar estas funciones, la mayoría ya disponibles por defecto en el directorio ulp, tan sólo tenéis que ejecutar el comando
run nombre_de_la_funcion
Quizás alguna de estas funciones no estén por defecto en ese directorio, tendréis que "googlear" un poco para conseguirlas. Vale la pena el esfuerzo.
Voy a dividir las funciones según se utilicen para hacer el esquemático, o para diseñar el layout del PCB.
ESQUEMÁTICO
función: bom-ex
descripción: genera la lista de material del esquemático
función: bom-partno-mgr
descripción: edita la part list del esquema según una base de datos de componentes. Esta base de datos se determina con la variable global DATABASE. Para modificar esta variable global ir a Edit -> Global Attributes.
Si queremos tener una lista de material profesional, es conveniente mantener esta base de datos, donde podamos poner asignar los campos de valor que nosotros queramos a cada componentes. Es muy interesante tener siempre la misma descripción COMPLETA de un componente, es decir, que la descripción, por ejemplo, de un condensador de 100nF 0603, sea en todos los casos, C_100nF_X7R_SMD0603. O en el caso otros componentes que no sean "comodities" pongamos, no solo el fabricante del integrado, sino también una segunda fuente, e incluso, la referencia de algún distribuidor tipo Farnell, con su referencia y precio.
La base de datos puede ser tan completa como se quiera, pero se buena idea crearla y mantenerla para tener al final del diseño una documentación de montaje completa y profesional.
función: statistic-sch
descripción: muestra estadística del esquemático
función: findfrst
descripción: busca componente, net, ... según selecciones. Vale la pena asignarle a esta función una tecla rápida, en mi caso F12
función findnext
descripción: busca la siguiente referencia del componente, net, ... que se haya seleccionado con findfrst. La tecla rápida que yo le asocio es CTRL+F12
PCB
función: drillinfo
descripción: te muestra el listado de drill, y lo que no cumplen con los estándares (y que acaban costando dinero)
función: exp-project-lbr
descripción: crea una librería de componentes con aquellos que hemos utilizado en nuestro proyecto. La librería coge el nombre del proyecto.
función: zoom-unrouted
descripción: a veces es complicado saber si hemos acabado de enrutar todas las pistas, o hay alguna pista no conectada escondida. Esta función te muestra en zoom las nets aún no conectadas.
función: unrouted2
descripción: te crea un fichero txt donde están listadas las nets no conectadas. Este fichero se llama unrouted.txt y lo pone en el directorio principal del programa Eagle.
función: silk_gen
descripción: corrige la serigrafía
También recordad que si queréis ver una net, está el comando:
show nombre_net
run nombre_de_la_funcion
Quizás alguna de estas funciones no estén por defecto en ese directorio, tendréis que "googlear" un poco para conseguirlas. Vale la pena el esfuerzo.
Voy a dividir las funciones según se utilicen para hacer el esquemático, o para diseñar el layout del PCB.
ESQUEMÁTICO
función: bom-ex
descripción: genera la lista de material del esquemático
función: bom-partno-mgr
descripción: edita la part list del esquema según una base de datos de componentes. Esta base de datos se determina con la variable global DATABASE. Para modificar esta variable global ir a Edit -> Global Attributes.
Si queremos tener una lista de material profesional, es conveniente mantener esta base de datos, donde podamos poner asignar los campos de valor que nosotros queramos a cada componentes. Es muy interesante tener siempre la misma descripción COMPLETA de un componente, es decir, que la descripción, por ejemplo, de un condensador de 100nF 0603, sea en todos los casos, C_100nF_X7R_SMD0603. O en el caso otros componentes que no sean "comodities" pongamos, no solo el fabricante del integrado, sino también una segunda fuente, e incluso, la referencia de algún distribuidor tipo Farnell, con su referencia y precio.
La base de datos puede ser tan completa como se quiera, pero se buena idea crearla y mantenerla para tener al final del diseño una documentación de montaje completa y profesional.
función: statistic-sch
descripción: muestra estadística del esquemático
función: findfrst
descripción: busca componente, net, ... según selecciones. Vale la pena asignarle a esta función una tecla rápida, en mi caso F12
función findnext
descripción: busca la siguiente referencia del componente, net, ... que se haya seleccionado con findfrst. La tecla rápida que yo le asocio es CTRL+F12
PCB
función: drillinfo
descripción: te muestra el listado de drill, y lo que no cumplen con los estándares (y que acaban costando dinero)
función: exp-project-lbr
descripción: crea una librería de componentes con aquellos que hemos utilizado en nuestro proyecto. La librería coge el nombre del proyecto.
función: zoom-unrouted
descripción: a veces es complicado saber si hemos acabado de enrutar todas las pistas, o hay alguna pista no conectada escondida. Esta función te muestra en zoom las nets aún no conectadas.
función: unrouted2
descripción: te crea un fichero txt donde están listadas las nets no conectadas. Este fichero se llama unrouted.txt y lo pone en el directorio principal del programa Eagle.
función: silk_gen
descripción: corrige la serigrafía
También recordad que si queréis ver una net, está el comando:
show nombre_net
El futuro pertenece a los datos
Tim O'Reilly hizo una muy interesante charla sobre su visión del futuro, y de cómo va a condicionar nuestra vida cotidiana una inmensa catidad de nuevos datos que vamos a poder adquirir y procesar con, sobretodo, nuestros teléfonos móviles:
miércoles, 7 de septiembre de 2011
Proyectos open hardware
El open hardware tiene ya un largo recorrido que no se acaba en absoluto en Arduino. Surgen a diario ambiciosos proyectos que siguen la filosofía del open hardware incluso con mayor rigor quenel famoso Arduino. Algunos ejemplos que he descubierto últimamente:
- la camara elphel:
http://wiki.elphel.com/index.php?title=Main_Page
- Mizar32project
http://www.simplemachines.it/index.php?option=com_content&view=article&id=13&Itemid=24
Hasta pronto
- la camara elphel:
http://wiki.elphel.com/index.php?title=Main_Page
- Mizar32project
http://www.simplemachines.it/index.php?option=com_content&view=article&id=13&Itemid=24
Hasta pronto
lunes, 5 de septiembre de 2011
Smart City
IBM está apostando fuertemente por el concepto de la Smart City. Las ciudades prometen crecer en el futuro más próximo, los recursos naturales son limitados, así que las ciudades, si quieren mantener los servicios al mismo nivel que en la actualidad, tendrán que hacer lo que supongo que todos tendremos que hacer a nuestro nivel, tendrán que hacer lo mismo con menos recursos.
La optimización del gasto energético, del uso de los servicios públicos, será un tema que sin duda, dará que hablar durantes los próximos años.
Para más información, aquí va la impresionante web de IBM:
http://www-03.ibm.com/innovation/us/thesmartercity/index_flash.html#/home/
Y algunos videos:
La optimización del gasto energético, del uso de los servicios públicos, será un tema que sin duda, dará que hablar durantes los próximos años.
Para más información, aquí va la impresionante web de IBM:
http://www-03.ibm.com/innovation/us/thesmartercity/index_flash.html#/home/
Y algunos videos:
jueves, 2 de junio de 2011
Reprap
Me encanta la idea de una máquina capaz de reproducirse a sí misma. Reprap es un intento para conseguirlo. Aún le queda mucho, pero es el primer paso:
RepRap from Adrian Bowyer on Vimeo.
RepRap from Adrian Bowyer on Vimeo.
viernes, 18 de marzo de 2011
Arduino programación wireless con Xbee oficial. Sexta parte.
En el siguiente video vemos la implementación del programador wireless en acción:
La música es de Penguin Café Orchestra.
Hasta pronto.
La música es de Penguin Café Orchestra.
Hasta pronto.
lunes, 14 de marzo de 2011
Arduino programación wireless con Xbee oficial. Quinta parte.
8. Puesta en marcha
Una vez tenemos el sistema instalado. Es decir:
- Arduino Master con el Shield Xbee s1, conectado al PC a través del USB.
- La aplicación de sparkfun Screamer v20 corriendo en el PC
- Arduino Slave con el shield Xbee S1
Seguimos los siguientes pasos:
1. Quitamos el jumper "aereo" que habilita el reset por DTR en el Arduino Master
2. Seleccionamos el fichero a cargar en el Slave en la aplicacion Screamer y seleccionamos la opción de download. El programa entra en modo de espera.
3. Reseteamos el Arduino Master con el pulsador de reset del shield Xbee
4. El programa del Arduino Master corre hasta que se provoca el reset remoto y se inicia la transferencia del archivo al arrancar el bootloader remoto.
9. Posibles Mejoras
- Programa en Pynthon para la aplicación de programación de SparkFun, posibilidad de activarlo a través de un comando script.
- Completar la librería SoftSerial Xbee para comprobar la conformidad de la recepción de los mensajes
- Completar el sketch del Arduino Master de forma que inicie el proceso de grabación remota al recibir un comando o al conmutar un interruptor.
- ...
Este proyecto no pretende establecer la comunicación más fiable de la historia de las comunicaciones. Es bastante mejorable. Pero os puede ser útil en proyectos con varios Arduinos donde os queréis ahorrar el tener que trastear constantemente con los cables. Un ejemplo de utilidad podría ser la programación remota de un robot, de forma que vayas debugando con nuevos programas sin necesidad de ni tan siquiera de tocarlo.
Hasta pronto.
- ...
Este proyecto no pretende establecer la comunicación más fiable de la historia de las comunicaciones. Es bastante mejorable. Pero os puede ser útil en proyectos con varios Arduinos donde os queréis ahorrar el tener que trastear constantemente con los cables. Un ejemplo de utilidad podría ser la programación remota de un robot, de forma que vayas debugando con nuevos programas sin necesidad de ni tan siquiera de tocarlo.
Hasta pronto.
Suscribirse a:
Entradas (Atom)