jump to navigation

Cartel de la Conferencia Internacional de Software Libre 3.0 23 febrero, 2007

Posted by pjmicrocontroladores in Documentación.
add a comment

Para todos aquellos que no pudieron asistir a la conferencia de SW libre, adjunto el cartel que fue presentando en la misma.

Cartel “Porting de GCC a PIC16f877″

Documento: Programar un PIC con el programador por puerto paralelo desde Windows. 13 diciembre, 2006

Posted by pjmicrocontroladores in Documentación.
8 comments

El programa elegido para la programación de los microcontroladores es IC-prog, disponible sin cargo en www.ic-prog.com. Una vez descargado, nada más descomprimirlo obtenemos el ejecutable. Lo ideal es almacenarlo en una carpeta en la rama del árbol de directorios que se prefiera y dejar un acceso directo en inicio o en el escritorio.

La primera vez que arranca el programa nos preguntará por nuestro programador. Seleccionamos el perfil “Propic 2 Programmer”, seleccionamos el puerto en el que esté el programador y activamos todas las casillas de inversión. El retraso podemos colocarlo hasta el valor de 4 o menos, si no funciona deberemos subir este valor.

Una vez configurado con debemos ir dentro del menú del programa a la opción Settings(ajustes) y dentro elegir options(opciones) para seleccionar el panel language (lenguajes) y terminar escogiendo el español. Si usamos Windows XP, NT o 2000 debemos ir al panel Misc y activar la casilla “Enable NT/2000/XP Driver” para evitar varios problemas en estos sistemas. Tras esto aceptamos y tenemos el entorno de programación de PIC listo, pero tenemos la posibilidad de probar el programador en la opción del menú ajustes, prueba hardware. Esta opción es muy aconsejada para comprobar la buena comunicación del software con el hardware y no arriesgar ningún microcontrolador. Deberemos comprobar los niveles de tensión ofrecidos a la salida del bus ICSP con un tester o un simple led (con su resistencia correspondiente).

La utilización de Ic-prog es muy intuitiva. Abrimos el fichero .hex conseguido tras el paso por el ensamblador y una vez corregidos (si es necesario) los bits de configuración, pulsamos el icono “programar todo” (o la tecla F5 o desde el menú acciones). Por defecto, tras escribir el código, lo verificará. Si todo ha ido bien tendremos nuestro programa escrito en la memoria del microcontrolador. Los principales errores que pueden ocurrir suelen ser debidos a un mal contacto en los distintos conectores o el olvido de la alimentación externa, por lo que de no haberlo hecho durante la preparación del entorno deberemos realizar la prueba del hardware para descartar el fallo del microcontrolador.

Entre las muchas opciones de ICProg podremos leer el contenido del chip si no está protegido, verificarlo o borrar totalmente la memoria.

Saludos, espero comentarios.

Documento: Programar un PIC con el programador por puerto paralelo desde Linux. 3 diciembre, 2006

Posted by pjmicrocontroladores in Documentación.
10 comments

Vimos en un artículo anterior (1) como se podía construir el hardware para programar un microcontrolador usando un puerto paralelo. Construimos el programador (en sitios latinos podemos ver como lo llaman entrenador) basado en la simplicidad de desarrollo y en el bajo coste, sin renunciar con ello a la generalidad. Pero lo explicado no permite a los iniciados en el tema de los microcontroladores PIC conseguir escribir un programa en la memoria Flash del micro. Pasamos en este artículo a describir la otra pieza que nos hace falta para conseguirlo, el software.

Comenzamos por Linux, y próximamente lo explicaré para Windows. En primer lugar debemos descargarnos e instalar el programa necesario para comandar el programador por puerto paralelo. El elegido es Odyssey, por su simplicidad y ser código abierto. Está disponible en el enlace (2), pese a que recientemente se ha movido a (3).

Una vez descargado se descomprime, se configura, se compila y se instala.

tar xvf odyssey-0.4
cd odyssey-0.4
./configure
make
make install

Con esto tenemos el programa odyssey instalado en la ruta /usr/local/bin/. Si la ruta no esta en la variable PATH es recomendable ponerla. Queda configurar el programa odyssey para utilizar nuestro programador paralelo. Para ello editamos el fichero /usr/local/etc/odyssey.conf, allí modificamos la sección nombrada con [io] con la siguiente información:

[io]
driver=linuxppdev
port=0
clkpin=-3
rdatapin=-10
wdatapin=-2
vpppin=-6
pwrpin=4

Con esto indicamos los pines del puerto paralelo que harán la función deseada, y con el signo la polaridad. En linux, con el programa odyssey no hace falta usar el switch que se mostraba en la placa, basta dejarlo conectado al pin 6. También indicamos el puerto con el parametro port, donde 0 es LPT1, 1 para LPT2 y así.

Odyssey trabaja de dos formas según que valor pongamos al parámetro driver del fichero odyssey.conf. Si como anteriormente se elige linuxppdev se usará el driver ppdev para acceder al puerto paralelo. El único problema es que no debe haber otro programa que este accediendo al puerto paralelo de forma bloqueante y que hemos de tener el driver ppdev. Para cargar el driver podemos usar:

modprobe ppdev

y para comprobar que módulos están usando el puerto podemos teclear

lsmod

y ver qué módulos usan parport a parte de ppdev. Después ejecutamos

odyssey test

y si el programa accede a modo interactivo todo esta listo. En caso contrario tendremos que descargar los módulos distintos a ppdev que puedan bloquear el puerto paralelo, de la lista de módulos que usan parport. Por poner un ejemplo el módulo lp esta cargado doblemente por lo que necesitaremos hacer un doble

rmmod lp

para poder usar odyssey test. La otra forma de configurar odyssey es con un acceso directo al puerto, pero necesitamos permisos de root y anular por completo el uso de los drivers parport (parport y partport_pc). Como mejora, no hay que cargar el driver ppdev.

Una vez odyssey entra en modo interactivo veremos que nos informa de las señales de salida del programador. Debemos jugar activando y desactivando las señales del bus ICSP comprobándolas eléctricamente con diodos o con un tester, para ver que se consigue el resultado esperado. Para activar una señal usamos + seguido de v para VPP, c para CLK (señal de reloj) y d para DATA (o señal de datos). Cuando activamos la salida de datos, la entrada también debe activarse. Si tras probarlo todo está correcto, tenemos listo el programa odyssey y nuestro programador por puerto paralelo para programar los PIC.

Para grabar un programa a.hex conseguido con las gputils de la forma habitual:

gpasm a.s
gplink a.o (más librerías necesarias)

tenemos que usar el programa odyssey de la forma adecuada al objetivo a conseguir. Para escribir el programa en el microcontrolador (queda claro que el PIC debe estar en el programador o con la interfaz ICSP correctamente y el programador conectado tanto al PC como al alimentador externo), usamos:

odyssey PIC16F877 write a.hex

Para comprobar que el programa se escribió correctamente usamos:

odyssey PIC16F877 verify a.hex

Para leer el programa (si no está protegido):

odyssey PIC16F877 read a.hex

y para borrarlo podemos usar:

odyssey PIC16F877 erase

Al instalar odyssey también instalamos su manual por lo que un “man odyssey” nos arrogará luz para los otros parámetros que admite el programa.

Visto lo más importante, en la próxima entrega mostraré la forma de usar el programador en windows.

1) https://pjmicrocontroladores.wordpress.com/2006/11/20/documento-programador-por-puerto-paralelo-para-pic/
2) http://www.desert.cx/odyssey/downloads.php
3) http://gforge.enseeiht.fr/frs/?group_id=10

PD: Agradezco comentarios de corrección o petición de ayuda que intentaré responder aquí mismo, pero no dejéis vuestro e-mail dado que no respondo privados, y solo conseguiréis que los recolectores de spam os acribillen.

Documento: Programador por puerto paralelo para PIC 20 noviembre, 2006

Posted by pjmicrocontroladores in Documentación.
104 comments

Recapitulando un poco los documentos de orientación del proyecto, la primera falta que podemos encontrarnos es la imposibilidad de grabar código ensamblador en el microcontrolador. Bien, si tenemos código ensamblador con ayuda de las gputils y de uno de sus programas, el gpasm, podemos obtener el código hexadecimal listo para grabar en el microcontrolador. Pero para grabarlo necesitamos dos cosas, un dispositivo hardware y otro software. El software puede ser odissey (1) para linux o icprog (2) para windows, entre otros muchos, pero el hardware es el mismo para todos los sistemas operativos.

Hay mucha diversidad de hardware para grabar los microcontroladores PIC pero el más fácil de crear es el programador por puerto paralelo. Por ahora veremos éste pero podemos encontrar propuestas que usan tanto el puerto serie como el puerto USB (ver 3). El principal problema de los que usan USB es su precio, y personalmente el problema del puerto serie es que mi portátil no tiene : ).

El principio de funcionamiento de del programador se basa en la programación usando el protocolo ICSP de Michochip. Por ello se puede usar pinchando el PIC en un zócalo convenientemente dispuesto en el programador o con el microcontrolador soldado a la placa definitiva. Para la segunda opción tendremos que haber considerado esa opción en el desarrollo de la placa.

La programación según el modelo ICSP usa cinco líneas. Tres de alimentación y dos para la programación en si. Las líneas de programación son DATA y CLOCK, las cuales no nos es difícil adivinar que se usan para datos y reloj. Las líneas de alimentación son VPP para la tensión de programación de 13,2 voltios, y VCC y GND para 5 y 0 voltios. Los microcontroladores que admiten ICSP tienen pines que corresponden con estas cinco entradas, estando algunas veces duplicadas algunas de las mismas como es el caso de nuestro micro donde se usan dos entradas de GND. No tiene mayor misterio que puentearlas.

El principio de funcionamiento de ICSP es, alimentar el microcontrolador normalmente, pero elevar la tensión en el pin MCLR a VPP, la tensión de programación. El microcontrolador entrará con ésta acción en el modo programación y los pines marcados como DT y CK funcionarán como datos y reloj para, a través del protocolo indicado por la especificación ICSP, escribir o incluso leer (en caso de que no este protegido) la memoria de nuestro PIC.

El modelo de programación por puerto paralelo se basa en escribir directamente los unos y ceros en pines del puerto paralelo conectados a los pines adecuados del microcontrolador. La alimentación se ha de conseguir de forma externa al programador. La línea DATA puede no solo escribir datos, sino también leerlos, por lo que usaremos dos pines uno de entrada y otro de salida según la utilización del puerto. Usaremos otro pin del puerto paralelo para controlar la entrada de 13,2 voltios, activándola o no, para entrar al modo programación del chip.

Con esto en mente cualquiera puede realizar este programador que es una simple prolongación del puerto paralelo a la interface ICSP del micro. Sin embargo hay ciertas recomendaciones, que cuando las sigamos, nos ahorraremos muchos problemas en la programación. Para ir más rápidos primero observemos la figura siguiente:

 

Lo primero que no hemos comentado y que resulta la parte más llamativa del programador es el integrado 74LS04N. Este contiene seis inversores, de los que hemos usado tres, dos para la línea DATA y uno para CLOCK. A nivel lógico hemos invertido las líneas, pero en el software lo indicaremos así y no habrá diferencia en la operación, pero sin embargo a nivel eléctrico, asegura que pese a que el nivel de intensidad en el puerto paralelo sea bajo, entregamos suficiente potencia para que la comunicación sea efectiva. Además protegemos al puerto paralelo de posibles malas conexiones, dejando el posible daño en este integrado. Hay otros muchos circuitos que se podían haber usado en su lugar, pero el 74LS04 es barato, fácil de encontrar y funciona.

Como anunciamos la tensión de programación se controla con un simple pin del puerto paralelo gracias al transistor 2N3904. La configuración muestra que funciona como inversor de la señal de entrada, con lo que si introducimos un nivel alto a la base del transistor este conducirá entre emisor y receptor y llevará la entrada MCLR a cero. Con un nivel bajo, introducimos la tensión dada por VPP, estableciendo el micro en estado de programación.

Pese a decir que un simple pin realiza la entrada no estamos ni mintiendo ni nos hemos equivocado de figura. Vemos que la entrada a la base de transistor puede venir de dos pines distintos del puerto paralelo. La elección de cual escoger la da el dispositivo a programar, dado que si tiene 28 pines o más, el programador debe usar el pin 6 y en caso contrario usará el pin 5. La distinción en estos dos estados es la diferencia de distribución encontrada entre estos dos grupos. En un programador con un solo zócalo, se pueden duplicar el transistor y conducir las otras líneas a todas las posibilidades. En este caso se ha decidido usar un mismo conector ICSP que puede usarse con varios zócalos, localizando en los mismos las posiciones deseadas.

Tenemos cuatro clases de zócalos que cubren la mayoría de los dispositivos PIC y se clasifican según el número de pines del integrado a programar. Se muestran en la figura siguiente. Los dispositivos que no se anexan a ninguna clase, nos obligaran a o bien crear el zócalo oportuno o usarlo desde el circuito con las restricciones normales.

El programador no esta completo sin una fuente de alimentación de la que podamos tomar 0, 5 y 13.2 voltios. Una posible es la que se presenta en el esquema de la figura siguiente.

Básicamente esta fuente de alimentación toma un voltaje de al menos 15 Voltios, y nos entrega 5 y 13,2. Con el condensador C1 estabilizamos la entrada. El integrado 78L12 consigue a su salida 12 voltios, por lo que usando las resistencias R1 y R2 introducimos 1,2 como referencia de tierra del integrado, consiguiendo que este entrege 12 voltios sobre 1.2, resultando los 13.2 necesarios para la tensión de programación. Con el integrado 78L05 conseguimos los 5 voltios para VCC. El condensador C2 simplemente estabiliza aún más la señal. Para la entrada de 15 voltios (o más) podemos usar cualquier transformador de alterna a continua de 12 voltios no regulado o 15 regulados. Lo único a tener en cuenta es que el máximo voltaje es de 35 voltios.

Como contras o desventajas de este programador nos encontramos con la necesidad de usar un alimentador externo, con el consiguiente aumento de volumen del programador e incapacidad de usarlo de forma portátil, sino es en conjunción de pilas externas de alto voltaje, pero en todo caso incomodo.

Como ventajas es más fácil de crear y depurar para iniciados y una vez conectado siempre funciona. Por ejemplo podemos sustituir las salidas ICSP con diodos led con sus resistencias adecuadas para comprobar el funcionamiento correcto del programador antes de arriesgarnos a pinchar un chip. Además no tiene problemas con puertos de baja intensidad.

La idea inicial está basada en el programador “Pablin 2”, basado éste a su vez en el programador “propic 2”. El original, el “propic 2”, estaba pensado para usar con un solo zócalo ZIF (inserción de fuerza cero) por lo que triplicaba los transistores para seleccionar tres configuraciones distintas. También controlaba el VCC activando y desactivando éste para limitar su operación. En el programador “Pablin 2” se duplican las puertas inversoras en las tres líneas para evitar la inversión de la señal, y se usan cuatro zócalos para los distintos chips soportados.

El principal problema del programador “Pablin 2” es que no regula la entrada de 13.2 voltios, sino que supone que una entrada de 12 voltios no regulada o 15 regulados unidos a un diodo led, llevarían a un rango válido para el voltaje VPP. Esta presunción podría funcionar en microcontroladores permisivos, pero no en la gran mayoría de ellos. Un transformador de 12 voltios no regulados entrega unos 16,97 voltios. La caída de tensión en un led verde (de los led normales el de mayor caída) es de unos 2.4 voltios, dando 14.57 voltios, superior a los 14 máximos aconsejados y con una fuente de 15 regulada, obtenemos 12.6 V insuficiente para el voltaje de programación. No solo no conseguiríamos programar un PIC sino que lo pondríamos en peligro. La razón de su extendido uso es que sí es acto para el 16F84 chip famoso por su precio, su benevolencia ante errores de diseño y ser generoso en rango.

Estos problemas quedan solucionados con el uso del integrado 78L12 y el divisor de tensión visto en el programador presentado con lo que conseguimos la generalidad y operatividad buscada sin incrementar apenas el coste.

1) http://www.desert.cx/odyssey/downloads.php
2) http://www.ic-prog.com/
3) http://www.hobbypic.com/index.php?option=com_content&task=view&id=12&Itemid=34

Documento: Compilar Porting de GCC a 16F877 15 noviembre, 2006

Posted by pjmicrocontroladores in Documentación.
11 comments

Para poder compilar GCC con la arquitectura PIC necesitamos obviamente las fuentes de GCC (1) y las fuentes del porting de PIC (2). La versión de GCC utilizada es 4.0.2. Podría funcionar en otras versiones pero puede requerirse pequeñas modificaciones. Además necesitamos las GPUTILS (3) para poder compilar el código ensamblador generado. Empezamos descargando todas las fuentes desde los enlaces a pie de noticia o utilizando paquetes preparados para las distribuciones empleadas.

Para instalar GPUTILS desde el código fuente, descomprimimos el archivo descargado:

tar xvf gputils-0.13.4.tar.gz

Una vez descomprimido, cambiamos a la carpeta creada gputils-0.13.4 y configuramos:

./configure

Creamos los ejecutables:

make

Y una vez compilado podemos bien ejecutarlos desde sus subdirectorios gpasm/gpasm, gplink/gplink y gputils/gplib o instalarlos y ejecutarlos sin miramientos, opción preferida (la ruta por defecto es /usr/bin si se cambia se deberá cambiar también en el archivo pic.h del parche para el porting GCC). Para instalarlo, usamos

make install

Con lo que ya podemos ensamblar código PIC a código hex para poder grabarlo en un microcontrolador.

Seguimos con GCC. Descomprimimos GCC,

tar xvf gcc-4.0.2.tar.bz2

Descomprimimos el parche de la arquitectura PIC (la versión más reciente)

tar xvf csl-pic-gcc-16f877-0.0.5.tar.gz

Con esto tenemos un directorio llamado gcc-4.0.2 que contiene las fuentes de GCC preparadas para la arquitectura PIC. Pero esta vez no usaremos este directorio para compilar GCC sino que creamos otro

mkdir pic-gcc

y desde dentro lo configuramos

cd pic-gcc
../gcc-4.0.2/configure -target=pic -enable-languages=c

Una vez configurado lo creamos y esperamos un rato (en un Celeron 2400 con 192Mg unos 10-15 minutos).

make

Cuando acabe (por ahora fallando con un AQUÍ) se habrá creado varios ejecutables en pic-gcc/gcc/ . Por ahora solo importa cc1 que compilará código C simple de un byte (es decir con tipos short o char y una sola función main). Poco a poco se conseguirá compilar todo el ANSI C. El código complicado (y por ahora todo lo que se salga de lo muy básico) fallará pero se puede ir comprobando el aumento de características del porting poco a poco.

Nos vemos.

1) ftp://ftp.gnu.org/gnu/gcc/gcc-4.0.2/gcc-4.0.2.tar.bz2
2) http://forja.rediris.es/frs/?group_id=101
3) http://sourceforge.net/project/showfiles.php?group_id=41924

Documento: Archivos de un porting 12 noviembre, 2006

Posted by pjmicrocontroladores in Documentación.
add a comment

Cuando nos enfrentamos al porting de GCC a una nueva arquitectura, el primer paso es modificar convenientemente el fichero “config.sub” de la raíz de directorios de GCC. El fichero “config.sub” es la base de datos de gcc de arquitecturas y sistemas operativos soportados. Por lo tanto debemos unir nuestra arquitectura `pic’ a la lista de máquinas básicas. Lo dicho se traduce en sumar, dentro del fichero, los siguientes datos:

case $basic_machine in

| pdp10 | pdp11 \
| pic \
| pj | pjl \

Con esto le decimos a GCC a la arquitectura PIC existe y es válida dentro de algún producto GNU. Para conseguir que el mismo GCC lo soporte, debemos modificar otro fichero, el de configuración. Para ello tenemos dos maneras de hacerlo, modificar el fichero configure.in y ejecutar posteriormente autoconf para regenerar el ejecutable configure o modificar éste directamente. Elegir una opción u otra no influye si seguimos los pasos adecuados al compilar, es decir, no olvidar ejecutar autoconf si elegimos modificar configure.in. En ambos casos para encontrar la sección adecuada podemos buscar la arquitectura avr e introducir los siguientes datos a continuación de ella:

avr-*-*)
noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 ${libgcj}"
;;
pic-*-*)
noconfigdirs="$noconfigdirs target-libiberty target-libstdc++-v3 ${libgcj}"
;;

Modificados estos dos ficheros, GCC conoce la arquitectura PIC y podrá compilarla. La definición de la arquitectura estará en un directorio llamado pic dentro del subdirectorio gcc/config. Allí no solo podemos crear la nueva arquitectura sino examinar las otras ya existentes. Como ejemplo podemos ver la simplicidad de la arquitectura stormy16 o la complejidad de la arquitectura i386.

Los ficheros principales que describen la arquitectura y que serán el centro de trabajo fundamental durante el transcurso de este proyecto son:

  • pic.md
  • pic.h
  • pic.c

El primer fichero, pic.md, contiene la descripción de la máquina (Machine Description). Allí encontraremos como GCC tiene que traducir las instrucciones del lenguaje intermedio de registros RTL a código ensamblador funcional para nuestra arquitectura. Este fichero a su vez puede contener inclusiones de otros ficheros que contendrán el mismo tipo de datos. El objetivo de usar estos ficheros incluidos es la claridad en la presentación, ya que no imponen ningún cambio funcional.

El fichero pic.h contiene la especificación de la máquina. El objetivo es especificar macros de describen a GCC como funciona interiormente la máquina. Entre otras informaciones indica el número de registros, su uso y nombre, la alineación requerida para los datos o como nombrar las distintas sección dentro del código ensamblador. Para algunas macros no nos bastará un descripción corta en linea o esta sería muy compleja, por lo que podemos usar funciones C externas y que serán definidas en el fichero pic.c. Este último fichero puede contener también funciones C llamadas desde pic.md para aquellas instrucciones RTL que no sean fácil de pasar a código ensamblador o necesiten ciertas comprobaciones. GCC usa la información de pic.h para crear el código RTL adecuado a la máquina y saber como optimizarlo.

A parte de estos ficheros existen otros que sirven de apoyo a la descripción de la máquina. Por ejemplo con la pareja t-pic y libgcc.S podemos definir rutinas directamente en ensamblador que servirán para crear la librería libgcc, que contiene todas las operaciones matemáticas que no sean soportadas directamente por la arquitectura y si por el estándar ANSI C. En estos ficheros podemos incluir rutinas de apoyo para otras operaciones. Pensemos por ejemplo que una operación de división, esta es muy costosa espacialmente, y si la usamos varias veces a lo largo del código C tendremos un gasto excesivo de memoria de programa. Si en lugar de usarla directamente la incluimos en la librería como una rutina y en cada uso de la división simplemente realizamos una llamada a la rutina de librería, conseguiremos un recorte en el tamaño del código sin demasiado gasto temporal.

Conocidos los ficheros que forman la descripción de la arquitectura PIC para GCC, ya solo falta rellenarlos. Para la próxima entrega de documentación explicaré la idea que se desarrollará a partir de ahora, salvos futuros (y más que probables) cambios.

¿Que es un microcontrolador? 6 noviembre, 2006

Posted by pjmicrocontroladores in Documentación.
26 comments

Un microcontrolador es un circuito integrado que nos ofrece las posibilidades de un pequeño computador. En su interior encontramos un procesador, memoria, y varios periféricos. El secreto de los microcontroladores lo encontramos en su tamaño, su precio y su diversidad. Su valor medio de seis euros, y su tamaño se reduce a unos pocos centímetros cuadrados. 

El párrafo anterior es la forma correcta de definirlos, o al menos la forma más generalizada, dado que a través de Internet, es la manera principal que encontramos, con distintos matices, de explicar que es un microcontrolador. Pero en este texto, presumiblemente orientado a entendidos en el tema como mínimo, usaremos una definición alternativa por dos motivos, uno por que los que sepan algo de microcontroladores no van a leer esta sección y dos por que los que no saben, con la definición anterior, no entenderán la idea que rodea a un microcontrolador. 

Un microcontrolador es una máquina tonta, un objeto sin razonamiento ninguno, un cubo negro con patitas metálicas que se suelda a una placa con más o menos componentes electrónicos. Su misión al igual que cualquier ordenador personal es la misma que una calculadora. Frente a datos de entrada, sigue un programa, un algoritmo dado por un programador y cambia su estado interior. Como objetos o dispositivos de entrada  o salida podemos encontrar diversos periféricos, desde simples líneas de entrada digital que pueden estar a cero o a uno, hasta complejos puertos usados en ordenadores que permiten comunicar con otros dispositivos externos como microcontroladores o PC. 

Con esta idea en la cabeza nos encontramos que existen varios fabricantes que ponen a disposición de los desarrolladores miles de modelos distintos en características, tamaños, consumo, periféricos, memoria, etc. La diversidad tiene un objetivo fundamental, reducir costes. No podemos querer un dispositivo totalmente completo y equipado que funcione bien en cualquier diseño y que sea barato. El espacio en un microcontrolador es dinero.  Mientras más características o más memoria, más espacio necesita y por tanto más caro será de fabricar y con ello de adquirir. Por tanto el truco es diseños sencillos y con características limitadas. Con diversos modelos cada diseño tendrá el adecuado, aquel que cumpla con todas las características de las especificaciones del producto a desarrollar y a la vez sea el más económico. 

¿Para que se usan?

La limitación en la aplicación de los microcontroladores a un desarrollo de ingeniería tiene su límite en la imaginación del desarrollador. Con los diversos modelos disponibles podemos afrontar multitud de diseños distintos desde los más simples hasta los más complejos. 

Por nombrar varios ejemplos de aplicaciones, tenemos mandos a distancia, termómetros digitales, controles de acceso por puertas de seguridad, los sistemas ABS o EPS de los coches, control y sensórica de maquinaria, domótica del hogar, microrobótica, monederos electrónicos … De seguir pensando duplicaríamos la lista con poco esfuerzo, pero con esto tenemos una idea del uso actual de los microcontroladores.

Realmente la dificultad no está en usar un microcontrolador para afrontar un proyecto hardware, sino en elegir el fabricante y el modelo adecuado para la aplicación. Con esto lo que tenemos que tener presente es que los microcontroladores nos solucionarán la vida en todos los temas, pero el objetivo es usar el mínimo número de ellos y con el menor coste por unidad. La frase anterior tiene trampa, todo diseño se puede afrontar con microcontroladores, pero según qué especificación o escenario, no siempre será la mejor idea usar uno solo, sino varios distribuidos. Habrá aplicaciones para las que no será posible usar un único microcontrolador, pero si varios de ellos, bien por restricciones de funcionamiento o económicas. Un análisis de costes nos dará la respuesta.