Curso “Sistemas Embebidos con Arduino”

Prólogo

Cuando lanzamos la primera edición del curso Arduino con MVDrobotics, en 2012, mi intención siempre fue ayudar a la gente a realizar proyectos concretos. Yo venía trabajando con la placa desde 2006, aprendiendo por mi cuenta, y no había tenido mayor dificultad para concretar mis propias ideas y las de otros. Pero noté que, si bien la plataforma es excelente en cuanto a hacer más fáciles las cosas, aun había muchos “secretos” para poder utilizarla con éxito, o mejor dicho: que realizar un proyecto concreto utilizando Arduino (o cualquier otro microcontrolador) involucraba un montón de conocimientos distintos, que rara vez una única persona pudiera reunir.

curso

Curso “Introducción a la Robótica con Arduino” de MVDrobotics (Uruguay), que arrancó en 2012 y hoy va por su 8va. edición.

Yo comencé haciendo robots por hobby, en mi casa, y pronto me vinculé con otra gente, primero del ambiente artístico, y luego con ingenieros (sobre todo del área de computación de la UdelaR). Trabajé con unos y otros en diversos proyectos que fueron surgiendo, ocupándome casi siempre de la parte electrónica y de programación a bajo nivel. Más tarde fundamos MVDrobotics con algunos de estos compañeros, y seguimos desarrollando proyectos para gente que se contactó con nosotros a través de la web. Recientemente he tenido la oportunidad de trabajar en sistemas de automatización industrial, que es un campo fascinante en el que también se puede aplicar Arduino.

A lo largo de este proceso fui aprendiendo muchas cosas, por supuesto, y, sin serlo formalmente, en los hechos me convertí en una especie de ingeniero en sistemas embebidos. Pero desde el comienzo identifiqué algo que luego seguiría confirmando una y otra vez, y que es, a mi entender, la principal dificultad que esta “especialidad” conlleva: la necesidad de dominar simultáneamente electrónica y programación (y alguna cosita más).

Arduino y los sistemas embebidos

No cabe duda de que Arduino es “la hostia”. Ahora bien, aunque se tiende a creer que todo lo relacionado con Arduino es fácil, en realidad desarrollar un proyecto concreto que involucre Arduino o cualquier otro tipo de microcontrolador o sistema embebido, y lograr que el sistema funcione correctamente, que haga lo que tiene que hacer, que sea estable, etc., es, por el contrario, una tarea bastante complicada.

samsaII

Samsa-II, robot hexápodo de 18 motores, controlado con Arduino (año 2010)

Arduino soluciona el problema de poner a funcionar el microcontrolador. Con Arduino armamos un setup en minutos y ya nos ponemos a trabajar en concreto en la idea que tengamos. Pero una vez que sorteamos este acceso inicial —eso que en otra plataforma podría tomar horas, días o meses— de todas maneras todavía falta mucho para tener nuestro proyecto terminado. Los desafíos técnicos que aun pueden surgir, muchas veces exigen un conocimiento profundo de la tecnología en sí, independiente de la plataforma que se trate, y más allá de que existan o no soluciones “ya hechas”. De hecho, ese conocimiento es lo que nos permitiría, justamente, aprovechar la abundancia insuperable de desarrollos “ya hechos” con que cuenta Arduino, puesto que de otro modo estaríamos simplemente probando cosas a ciegas (siempre imagínense que algo no funciona, porque eso es lo que de hecho va a pasar, y es ahí donde aplicamos el conocimiento).

celebra

Instalación interactiva Celebra (2011), proyecto artístico del que participé.

Imaginemos que dos personajes ficticios intentan utilizar Arduino por primera vez: el señor “E”, electrónico de la vieja escuela, y el señor “P”, programador profesional. Para el señor E, Arduino es realmente la hostia. En poco tiempo, el señor E estará controlando motores, actuadores, sensores, instalaciones de todo tipo. La dificultad del señor E es la programación, pero con un poco de astucia se las ingenia para copiar código de aquí y de allá, y lograr que las cosas más o menos funcionen. Experimentando, cambiando cosas de lugar, de a poco se va familiarizando con el lenguaje. El señor E sabe que con el código se puede experimentar libremente, que difícilmente algo se rompa por cambiar el código, y eso es una gran ventaja a su favor. Lo que le falta al señor E es programar ordenadamente, con buenas prácticas, y la consecuencia de esto es que cada vez que el programa se vuelve algo extenso y complejo, el señor E sucumbe y se ve desbordado.

scada

Interfaz visual del software SCADA, en un sistema industrial en el que trabajé a principios de este año.

La situación del señor P es bastante peor, lamento decirlo. Para el señor P el lenguaje de programación de Arduino no debería ofrecer mayor dificultad. No tendrá problemas para manejar el LED del pin 13, el monitor serial, o incluso periféricos complejos, como un display, módulos RF, Ethernet, GPRS, sensores I²C o SPI… siempre y cuando exista la librería correspondiente (que por lo general existe) y la conexión eléctrica del dispositivo con la placa sea fácil, inequívoca y bien documentada. Pero el señor P va a sucumbir mucho más rápido que el señor E: la primera vez que algo no le funcione, se dará cuenta de que la cantidad de variables involucradas es inmensa, y que es muy difícil hacer debug del hardware. El señor P sabe que con el hardware NO se puede experimentar libremente, y si no lo sabe, no tardará en ver salir humo de aquí y de allá (y eso si tiene suerte, porque mucho peor aun será sospechar que un dispositivo se quemó pero no tener la certeza). También puede pasar lo contrario, que el señor P sea presa de un miedo exagerado a tocar cualquier cosa del hardware, que obviamente le impide avanzar.

techmeetup1 techmeetup2
Taller de Arduino que dimos en el TechMeetup 2014, en la Torre de las Telecomunicaciones.

No quiero extenderme con todas las dificultades que va a tener el señor P, porque sería como contar la historia de mi vida; pero créanme, la electrónica es un mar de frustraciones. Por eso digo “electrónico de la vieja escuela”: el que se formó en electrónica analógica sabe lo complejas que pueden ser las cosas. Comparado con eso, la electrónica de un proyecto Arduino típico es mucho más simple, y es prácticamente tan predecible como el código mismo. Pero la electrónica siempre se puede complicar, incluso para el señor E. Piensen en lo que sería trabajar con dispositivos analógicos y enlaces inalámbricos en una planta industrial, por ejemplo, con altos niveles de interferencia electromagnética. O con cables muy largos, con altas frecuencias, con alta impedancia, con potencia, hay 1000 problemas en realidad.

Lo interesante es que esta complejidad muchas veces termina siendo abordada desde el código (el software), pero para eso hay que conocer bien el fenómeno con que se está tratando, y tener habilidades como programador que van más allá de saber utilizar una librería. En resumen: en cosas que involucran interacción con el mundo físico, sensores, actuadores, electrónica, hacer que las cosas funcionen “de verdad” implica un trabajo inimaginable para los que sólo están acostumbrados a programar. El ejemplo más completo de esto sería la robótica.

3 proyectos en los que trabajé para Tangible Interaction: aparato que permite controlar grandes instalaciones de luces desde una PC (2012); sistema que controla un LED RGB mediante una señal infrarroja (2013); electrónica para pelota luminosa inalámbrica interactiva (2014).
Algunos proyectos de MVD Robotics: tarjeta Urduino (2011); controlador de teclado de máquinas de juego (2012); controlador de máquina expendedora de productos (2013); sistema de seguridad para automóviles (2014); sistema de control inalámbrico centralizado de aires acondicionados (2014).
Proyectos industriales en los que intervine: sistema que muestrea consumo, temperatura y otras variables y envía los datos a un servidor remoto (2014); sistema de calefacción en planta industrial de aserradero (2015); sistema regulador de frecuencia para grupo electrógeno (2015); unidad de monitoreo remoto de procesos industriales (2015).
¿Qué conocimientos se necesitan?

La solución para el señor E y el señor P es venir a los cursos de MVDrobotics (o en su defecto, contratar los servicios de MVDrobotics). El contenido de nuestros cursos se basa en la experiencia de trabajar en nuestros propios proyectos y en los de otros. Es importante destacar esto; nosotros enseñamos Arduino como una herramienta para hacer cosas, porque es lo más accesible y rápido, y porque es la puerta de entrada al mundo de los microcontroladores y sistemas embebidos. Pero aun siendo lo más accesible (y no por ello menos potente), ya vimos que de todas maneras se requieren muchos conocimientos para poder diseñar, construir y programar un sistema que realmente funcione, usando este tipo de tecnologías (microcontroladores, PIC, Arduino, mbed, Raspberry Pi, etc.). Basado en mi experiencia, yo diría que hace falta lo siguiente:

  • Electrónica. Un sistema embebido es una computadora chiquita “empotrada” en un aparato, y generalmente interactuando con cosas electrónicas raw, por ejemplo un LED, un pequeño display, un buzzer, botones, sensores, relés, algún motor, etc., o talvez con otro sistema electrónico a través de un bus o un interfaz de comunicación digital. Pero digo: nos puede tocar diseñar toda la electrónica, nos puede tocar adaptar las entradas o las salidas para determinado dispositivo, que ya es bastante difícil, o, en el mejor de los casos, talvez toda la electrónica y las conexiones estén resueltas, pero casi seguro tendremos que vérnoslas con el tema de la alimentación. Si son 24, 12, 9, 5, 3.3V, si tiene que ser una batería, cómo adaptamos el voltaje, si se desperdicia energía, cómo reducir el consumo, y qué tal si hay que poner un cable largo, qué pasa con el amperaje, o la potencia, por qué se reinicia el chip, por qué tiene ruido ese sensor, para qué sirve ese condensador que dicen que hay que poner, por qué no comunica este bus, esto lleva o no lleva pull-up, qué dice acá de la impedancia, cómo evito todo este cablerío, es normal que esto caliente así, qué valor tiene que tener esta resistencia, etc., etc., etc. Es imposible dedicarse a esto y no toparse con un problema o una duda que tenga que ver con electrónica.

    bondibar

    Bondibar (2013), un circuito electrónico diseñado para controlar “pixeles” de LED RGB de gran potencia.

  • Programación. Bueno, obviamente, para desarrollar el firmware del sistema. Pero programación es lo que la gente más sabe hoy en día (al menos comparado con lo otro) y además creo que se puede aprender fácilmente (también en comparación con “lo otro”). Ahora bien, saber programar no es solamente conocer la sintaxis de un lenguaje. Pasa algo parecido que con el ajedrez: las reglas son sencillas, pero jugarlo medianamente bien lleva años. También se dice que más importante que saber programar, es saber pensar en términos informáticos. Sin entrar en disertaciones que pueden ser interminables, y que además otros ya han hecho, les diría que una buena cosa que podemos hacer, para empezar, es darle bola —valga el tecnicismo— a los manuales de estilo y de “buenas prácticas” de programación que andan por allí. Es síntoma del programador novato (como lo fui yo… hasta hace 10 minutos) subestimar o ignorar todo lo relativo al estilo, puesto que ya la propia palabra “estilo” suena a algo superfluo, y en realidad, en programación, el estilo es casi todo. Por ejemplo: los nombres que se le pone a las variables. Uno se puede dar cuenta de la calidad de un código por cómo luce el conjunto de nombres de sus variables. Encontrar un nombre adecuado para una variable (o para una constante, un objeto, un tipo, una función), que las variables representen cosas a las que se pueda poner nombre, que los nombres tengan forma y que por su forma uno pueda deducir su lugar exacto dentro de la estructura del código, sin ambigüedades ni reglas ad-hoc, todo eso forma parte del arte de programar bien. El código tiene que ser lindo, simplemente. En otro orden de cosas, mucha gente se pregunta qué lenguaje de programación es el que hay que aprender, y sobre esto también hay discusiones interminables. Mi elección: C++, por muchísimas razones que no puedo explicar acá.

    lanera

    Aplicación Java, front-end del regularímetro (instrumento que mide la regularidad de la lana) que desarrollamos para Lanera Piedra Alta en 2012.

  • Programación a bajo nivel. Esto ya es más interesante. Acá se trata de adaptarse a ciertas características que suelen presentar los sistemas embebidos, como por ejemplo:
    1. Escasos recursos. Poquita RAM, poquita flash (de paso mencionamos la arquitectura Harvard, donde hay memoria de programa y memoria de datos), poquitos MHz, todo muy modesto.
    2. No hay Sistema Operativo. No hay threads, pero sí que hay concurrencia de varias tareas simultáneas. A veces hay que resolver eso a mano, usando interrupciones, timers, u otros recursos (en otros casos tenemos un RTOS).
    3. Hay que manejar tiempos exactos, generar señales determinadas para controlar algunos dispositivos, implementar protocolos de comunicación para otros, etc.
    4. Hay que responder en tiempo real a eventos; nuevamente las interrupciones son la gran herramienta.
    5. No hay debug; casi siempre hay que hacer debug “a pedal” escribiendo cosas por un puerto de comunicación, desde el propio programa.
    6. Conviene conocer, al menos someramente, la arquitectura del micro, y hay que acostumbrarse a consultar la datasheet para todo. Manejar los SFR, por ejemplo, donde cada bit es una cosa distinta, y algunos bits se apagan escribiéndoles un 1, o se modifican al leer el propio SFR, etc., etc.
    7. No vendría mal estar familiarizado con el lenguaje assembler del procesador que estemos usando (aunque no es mi caso, por cierto).
    8. También hay que manejar las herramientas específicas para “quemar” el firmware; la toolchain, el bootloader, los fuses, y otros secretos.

      datasheet

      Fragmento de la datasheet del ATMega328P. Precisamente la descripción del registro de estado, SREG, que contiene el bit “I”, el cual habilita o inhibe globalmente las interrupciones.

  • Procesamiento de señal (y otros). Esta es talvez la gran sorpresa. Para empezar, es claro que no alcanza sólo con saber electrónica y saber programar. Un programa informático trata siempre sobre “algo” o interactúa con “algo”, y entonces hay que saber mínimamente de ese “algo” para poder escribirlo. Con “algo” nos podemos estar refiriendo a la función general del sistema (por ejemplo, si es un instrumento médico, parte del sistema de un automóvil, un electrodoméstico, un periférico de computadora, etc.) o a detalles de la implementación misma del programa, como si éste incluye un servidor web, se comunica por bluetooth, utiliza una cámara o tiene que controlar un motor. Para esta segunda categoría de “algos”, existen muchas veces las llamadas bibliotecas (o librerías) (y existe nuevamente la discusión de qué conviene más, si usar ciegamente cualquier biblioteca, o “reinventar la rueda” una y otra vez). Incluso los lenguajes como C y C++ tienen lo que se llama la biblioteca estándar, que incluye una cantidad de estructuras y algoritmos fundamentales que nos sirven para todo y que conviene conocer. Ahora bien, cuando hablamos de sistemas embebidos, y más concretamente cuando hablamos de sistemas que interactúan con el mundo físico y capturan variables analógicas, además de todo lo anterior, existe un conjunto particular de “algos” cuyo denominador común es el DSP.

El DSP (digital signal processing) comprende una serie de algoritmos y técnicas que son especialmente importantes en este tipo de sistemas, empezando por los filtros. Jamás he usado un sensor analógico sin implementar algún tipo de filtro, por ejemplo. Los filtros sirven ni más ni menos que para extraer de una señal la parte que nos interesa, y descartar la parte que no nos interesa (por ejemplo, el ruido). Si nosotros tenemos un sensor, normalmente vamos a tener que procesar la información de alguna manera para extraer el dato que necesitamos. Este dato podría ser el promedio de distancia, la velocidad instantánea, la frecuencia con que aparece cierta perturbación, etc. O por ejemplo, podemos fusionar la información de varios sensores distintos, extrayendo de cada uno una parte, para entre todos reconstruir el dato que nos interesa (ejemplo típico: acelerómetro + giróscopo). El DSP va más allá de los filtros, proporciona las bases para el reconocimiento de patrones, de gestos, visual, auditivo, en definitiva para “darle sentido” a lo que sensamos.

Además del procesamiento de señal, otro tópico importante son los sistemas de control realimentado, entre ellos el algoritmo PID. Muchas veces la función misma de un sistema embebido es controlar una variable física (temperatura, velocidad, etc.); otras veces es algo más complejo, pero que incluye lo anterior. Así como el procesamiento de señal tiene que ver con los sensores, los sistemas de control tienen que ver con los actuadores. Ambos sujetos presuponen, en realidad, un conocimiento básico sobre sensores y actuadores, o sea en definitiva, sobre física.

cv-dsp

Algoritmos relacionados con la visión artificial (computer vision)

PID

Controlador PID (from Wikipedia)

La robótica es un buen ejemplo

Cuando yo le digo a la gente que me dedico a la “robótica”, lo primero que me dicen es algo como esto: “¿por qué no inventás un robot que me traiga el café a la mesa y me lo sirva?” Todos sabemos que eso sería muy difícil, pero… ¿por qué, exactamente? Si dividimos este problema en varios sub-problemas (que es otra de las claves para resolver problemas difíciles), empezamos a ver lo siguiente:

  • El robot debería desplazarse por la casa sin chocarse con las cosas. Para eso necesita sensores que le indiquen dónde están esas cosas. Los simples sensores de distancia podrían ser la primera aproximación, pero en seguida veremos que no proporcionan suficiente información: si los objetos son irregulares, como lo son en la práctica, el sensor puede “ver” algo que realmente no es un obstáculo y puede no ver algo que sí lo es. Un sensor más sofisticado, como por ejemplo un par de cámaras, emulando nuestro propio sistema humano de visión, nos arroja una montaña de información por segundo. Reconocer dentro de esa montaña de información qué es un obstáculo, qué es el piso, qué es el robot mismo, etc., es una tarea harto compleja; es visión artificial (computer vision), y obviamente el procesamiento de señal —procesamiento de imagen— es uno de sus pilares.
  • Si el robot es un bípedo, o cualquier otro tipo que implique mantener el equilibrio, la técnica habitualmente empleada para esto es sensar de alguna manera su propia condición (esto puede requerir, ya de por sí, un procesamiento) y usar esta información como realimentación (feedback) de un sistema que con sus actuadores puede modificar esa condición; es decir: un sistema de control realimentado.
  • Otros tantos sistemas de control realimentado se pueden usar para ajustar el agarre de la cafetera (que no sea tan débil que se le caiga, ni tan fuerte que se le rompa), la inclinación de ésta cuando el robot tenga que servir el café en la taza, y en general, la velocidad y fuerza de cada uno de los motores, donde quiera que los tenga. Si nos ponemos a pensar, los sistemas de control realimentado son como la solución mágica a casi todos los problemas, pero el algoritmo siempre descansa en que nosotros podamos evaluar la variable que queremos controlar. Evaluar esa variable (la presión que estoy haciendo en la taza, si me estoy cayendo, si me estoy por chocar contra algo, si me estoy desviando del objetivo, si mis dedos o pinzas —o lo que sea que uso para agarrar— están centrados en el mango de la cafetera, si el café está cayendo en la taza, a qué velocidad se está llenando ésta, etc., etc., etc.) implica un sofisticado procesamiento de montones de sensores, es decir: DSP y más DSP.

De hecho el DSP es la disciplina que estudia las bases de ese procesamiento; pero sistemas tan complejos como los que estamos considerando (aunque sólo nos detuvimos en los 2 o 3 primeros problemas que aparecieron) van mucho más allá de eso: involucran técnicas de aprendizaje automático (por ejemplo Redes Neuronales Artificiales) y entran en el campo de lo que se denomina Inteligencia Artificial. Nótese además, que si bien existen librerías para muchos de estos algoritmos, su implementación en el contexto de un sistema embebido, con los escasos recursos de que allí se dispone, siempre es un desafío.

Coffee-serving robot by Kawada

Robot japonés que sirve café.

Talvez nos fuimos un poco lejos con este ejemplo, pero mi intención era mostrar cómo el DSP es el fundamento de montones de cosas interesantes que se hacen hoy en día con las computadoras. Volviendo al mundo de los sistemas embebidos, el DSP se usa en la compresión de datos, en las comunicaciones inalámbricas (a muy bajo nivel, para la reducción de ruido), y por supuesto, en el procesamiento de audio, imagen y video (y cualquier tipo de sensor analógico, en definitiva). Los controladores PID se usan extensivamente, sobre todo en el campo industrial, y en la robótica, por supuesto. Un servo implementa internamente un control realimentado, por ejemplo. La teoría del muestreo, uno de los principios básicos del DSP, es algo que conviene conocer para capturar correctamente nuestras señales analógicas y no cometer tantos errores a este respecto. Sinceramente, si sos un electrónico y/o un programador, saber un poco de DSP es la “frutilla en la torta” de tus conocimientos.

Curso “avanzado” de MVDrobotics.

Estas son las diapositivas del nuevo curso avanzado que estrenamos este año. Este curso lo dimos con Alvaro Cassinelli —una institución, permítanme decir— y estuvo muy bueno (en algún momento colgaré las fotos). Como ayudante estuvo Pedro Sales, que es otra institución con sus 15 años. Lo hicimos con todas estas ideas en mente, tratando de abordar aquello que falta en los cursos de Arduino típicos (que hoy se han multiplicado) pero que resulta fundamental a la hora de trabajar realmente con la plataforma. Esto incluye un plan bastante extenso de electrónica (con temas como impedancia, amplificadores operacionales, fuentes conmutadas), estudio a fondo del microcontrolador, protocolos de comunicación al detalle, uso de interrupciones y timers, manejo del tiempo y la concurrencia, programación “C” avanzada (estructuras, punteros, memoria dinámica), programación C++ (orientada a objetos), desarrollar bibliotecas, uso avanzado de sensores, procesamiento de señal, sistemas de control realimentado y PID (todos estos temas se conjugan, por ejemplo, en la práctica del “segway”).

Aquí les dejo los 11 primeros teóricos (son 24 en total) y algunos prácticos muy interesantes (los prácticos también son 24, en el curso). Disfrútenlo.

(Nota: sí, algunas imágenes son “afanadas”. Todo no se puede).




















.

Be Sociable, Share!

6 Comentarios »

  1. avatar MVDrobotics Dice:
  2. avatar Hugo Dice:

    Estimado Sr. Gindel,
    Es muy interesante su artículo sobre “Sistemas Embebidos con Arduino”.
    En lo que no estoy de acuerdo es en la categorización en Electrónicos y Programadores Profesionales. (¿Acaso no hay Electrónicos profesionales?)
    Para categorizar o comparar un grupo de personas hay que definir un dominio. Cuál es el dominio de las personas a las cuales nos estamos haciendo referencia? A Electrónicos y Programadores como son nombrados en el artículo o a estudiantes del curso de Arduino con perfiles previos de Electrónicos y de Programación?
    Tengo algunos años en desarrollo de sistemas. Generalmente el programador está orientado al diseño de programas que sean amigables con el usuario, maneja interfaces complejas con gráficos, base de datos, seguridad, también resuelven problemas complejos. Generalmente en el correr de sus vidas, la han dedicado a distintos desarrollos que lo involucran y adquieren conocimientos en diferentes y variadas actividades. Actualmente, tan compleja se ha vuelto la realidad que ahora no hay programadores, ahora se definen especialistas en áreas diferentes para el diseño de sistemas. Estas actividades refuerzan el concepto de abstracción tan necesario para resolver problemas complejos.
    Soy muy nuevo en esto de la electrónica pero recuerdo muy bien las primeras interfaces de los equipos electrónicos. Inventaban diferentes configuraciones con 2 o 3 botones, que generalmente sin una guía eran imposibles de adivinar o recordar cómo seleccionar una opción. Eso nunca lo hubiera hecho un programador. Aún hoy me surge la duda de quién programó el control remoto de los decodificadores de TV cable. Cuando uno pulsa el botón de lista, aparecen enumerados los canales y con el botón de bajar y subir se puede navegar entre los canales. Cuando se sale de la lista, los mismos botones de navegación van en sentido contrario. Esto otra vez va en contra de “amigabilidad” para el usuario final.
    Porque gracias a su “hostia”, la electrónica se ha acercado mucho a la programación sin distanciarse de sus electrónicos. Además al ser los componentes bastante económicos le ha dado acceso a nuevos utilizadores que lo hacen tan popular. Acompañando este fenómeno se han escrito toneladas de bibliotecas para facilitar la utilización de los componentes. A medida que pase el tiempo, los periféricos o componentes más complejos van a aparecer. ¿Quién esta mas preparado para mayores, los electrónicos o los programadores? No lo tengo muy claro. Lo más probable aumentando la complejidad se va a hacer más difícil en ambos ámbitos y no creo que ninguna de las partes tenga demasiada ventaja. Lo que si estoy seguro que los esfuerzos de programación van a ser más dinámicos que el diseño de nuevas partes electrónicas.
    Pero por otro lado han surgido otros conceptos que han alejado a la programación de la electrónica como ser el concepto de la nube. Concepto en el que considero sus electrónicos pierden por knock-out.
    Como recomendaciones, le sugiero incorporar en el curso herramientas y métodos para allanar el camino de los "programadores" en la detección de fallas o componentes quemados así como hacer énfasis para los “electrónicos” en las mejores prácticas de programación desde el uso de nombres de variables nemotécnicas, pseudocódigo y utilización de objetos con clases(métodos y propiedades) en forma debida por ejemplo.
    Finalmente, considero que lo mejor va surgir del trabajo en equipo de los mundos de electrónicos y programadores. Como estoy seguro que Arduino nació del esfuerzo conjunto de Electrónicos y Programadores.
    Arduino sin programación nunca hubiese llegado a ser más que un conjunto de componentes soldados a un PCB.
    Saludos

  3. avatar Fernando Dice:

    Recibe un cordial saludo, mi motivo y acercamiento es de consulta y espero me pueda explicar adecuadamente para una respuesta de su parte. Agradezco de antemano y comento.
    Con arduino puedo tener una unidad de proceso, donde pueda alogar un programa realizado de visual studio y de ahi correrlo sin una unidad central de poder, (computadora), en donde el prompt de encendido corra esta rutina, lea unos sensores y procese esta informacion. de tal manera que pueda obtener la informacion ahora con una interface de conexion alambrica o inalambrica y asi extraer la informacion del dia. Esto es posible, o si hay algo que no dependa de una computadora fisica como tal. Gracias Espero sus comentario

  4. avatar pabloxid Dice:

    Sí, eso es perfectamente posible, y de hecho es uno de los usos que se le da frecuentemente a la Arduino.

  5. avatar Pascual Gómez del Pino Dice:

    Hola muy buenas. Primero gracias por todo el aporte que haces al mundo de la electrónica y de arduino. En segundo lugar quería pedirte un favor, y es que estoy desarrollando para mis vídeos varias prácticas y he empezado a desarrollar tu Practica 1 ohmetro con Arduino, pero resulta que el código final está mal diseñado en cuanto a que faltan por declarar variables y constantes y hay alguna estructura mal expresada. No soy un gurú de la informática, pero algo entiendo aunque no lo suficiente porque llevo poco estudiando Arduino y su lenguaje de programación. Si hicieras bien a enviarme el código corregido te lo agradecería enormemente y te mencionaría en mis cursos. Gracias por todo.

  6. avatar Pablo Gindel Dice:

    @Pascual:

    El código que aparece en las slides no es un código completo y funcional, es una guía para que tú mismo lo implementes, pero no está “mal” en ningún aspecto, hasta donde yo sé, a menos que tú me indiques dónde están los errores.

    Tengo un repositorio con códigos completos: https://github.com/pabloxid. Subiré las prácticas allí. Puedes mostrarme alguno de tus videos?

    Gracias, saludos.

RSS alimentación de los comentarios de esta entrada. TrackBack URL

Dejar un comentario