En mi PC este hilo tiene actualmente 28 páginas. es buena técinca de esconder información en un mar de datos. El tema original del hilo tiene su justificación para un electrónico que quiere iniciarse en microcontroladores, escuche y lee de estas 2 familias de controladores y busca información. Ustedes creen que leer al momento 28 páginas y centenares de respuestas en un hilo va ser de ayuda para el lector? Si así lo vreen, adelante!
Pero si Ustedes como yo tienen un tiempo limitado, el título del hilo siuena como que vale hecharle una mirada, to do lo que hacen, al menos eso hago yo, es mirar en la útima y quizá en la primera página del hilo.
Yo creo que es de primordial importancia separar contribuciones al tema original de un hilo de los comentarios.
Habiendo escrito esto y por creer que un novato tiene el derecho de encontrar argumentos para hacer su propia decisión educada por que camino ir, quiero agregar mi dato a este hilo.
Atmel o PIC son equivalentes, decidete por una de las familias de controladores dependiendo de para cual en tu entorno encuentres personas que te asistan durante tu aprendisaje inicial y porterior.
Un controlador de una de las 2 fuentes nombradas aquí es adecuado para milllares de uso y en el internet se encuentran ejemplos para casi todo tipo de usos.
Si la intención es iniciarse de forma seria, quizá con ambiciones para una carrera, es mi opinión, que ambas familias de controladores y las variantes utilizadas son cosa del pasado y no las consideraría adecuadas. Ay, aquí me caen a golpes!
Porque tengo esta opinión? vayamos paso por paso a analizar esto!
Costo y disponibilidad:
Tradicionalemente controladores de uno u otro tipo discutido aquí son de bajo costo y tienen buena disponibilidad.
Herramientas:
Las herramientas son disponibles de forma gratuita y en lengua cristiana, lo que para aquellos no tan familiares con el inglés hace el aprendisaje mas facil.
Las herramientas consisten en tales para la programación y para la busqueda de errores y la verificación del programa que se está desarrollando. Aquí las herramienttas discutidas en el hilo consisten básicamente de 3 tipos:
ASM, o Assembler:
Esta herramienta de programación usa directamente las sentencias del controlador escogido. Buena práctica es escribir "subrutinas" para cosas que siempre se vuelven a necesitar y usar estas en vez de programas a nivel de las sentencias del controlador, muy cercano a lo físico del controlador.
Porque escribo lo de las subrutinas? Pues en cierto sentido esto significa crearse su propia lengua de programación y así ASM se vuelve algo entre lo que usualemente se nombra programación en assembler y el uso de una lengua de programación, que en cierto sentido no es mas que esto, un nivel de abstración entre las sentencias físicas del controlador. Que ventaja tiene esto?
Pues por un lado se vuelve mas sencillo leer un programa escrito en assembler y que usa de forma sistemática subrutinas con nombres que autoexpliquen la función de esta subrutina.
Por otro lado una subrutina que ha demostrado funcionar bien, reduce la probabilidad de errores de programación al usarse estas.
Tercero usando tales subrutinas e ir ampliando la base de subrutinas aumenta la productividad del programador por permitir programar mas rápido y con menos probabilidad de error.
Habiendo escrito esto quizá entendemos que lenguas como "C", Basic u otros no son mas que el resultado de programadores que llevaron la técnica del desaroolo de subrutinas a un nuevo nivel.
Herramientas de programación que no son assembler, se definen por un nombre, sea basic o C como ejemplos, consisten históricamente de 2 tipos:
Lengua de interpretación y lengua de compilación!
Una lengua de programación del tipo interpretador, y Basic era una tal, son escritas con una semántica que fascilita la lectura y el entendimiento, pero que cuando se ejecuta traduce en este momento los elementos de la lengua a un formato que la hardware del controlador entiende, una serie de "0" y "1" en organisaciones de 8, 16, 32 o mas bits por unidad. Para mas facil leer tal código se describen las 16 permutaciones posibles de 4 bits, 4 "0" y "1", también llamado "nibles" con algo que se llama "hex" que consiste de 16 posibles valores de "0" a "9" y de allí "A", "B", "C"" ... hasta "F".
Un compilador hace esta traducción anteriormente a su ejecutación y el proceso se llama compilación y genera un documento que tiene la extensión "*.hex".
Durante mucho tiempo todo programador se reía de la ineficiencia de lenguas interpretadas y juraba que solo una lengua compilada era adecuada. Esto empezó a cambiar cuando lenguas como "Java" aparecieron.
Queda finalmente el proceso de la verificación de un programa escrito y la búsqueda, a veces tediosa, de los errores en ese programa. Aquí la simulación era y es una parte de las herramientas usadas, donde el programa no ejecutado dentro del controlador, sino en el PC usando la herramienta del simulador. la razón para esto es que una software hace la parte de un controlador físico haciendo posible así un sin fín de técnicas de grandísmima ayuda para la programación. Pero quedaba la incertidumbre, que una simulación no es el original y que en el entrono definitivo efectos son posibles que hacen un programa fallas que funcionó perfectamente en el simulador.
Herramientas para reducir o eleiminar esta discrepancia eran carísimas y fuera del alcanze de muchos!
Habiendo presentado las herramientas de forma muy básica y los criterios para un novata de ir por una u otra familia de controladores del tipo Atmel AVR o del tipo PIC, quiero presentar porqué un novato debería ir por otra ruta si tiene mayores ambiciones dentro del entorno económico y de disponibilidad en cosa de sistemas embebidos, lo que creo poder justamente denominar el tipo de sistemas discutidos.
El futuro en sistemas embebidos no es del tipo de controladores discutidos aquí, sino de de aquellos del tipo "ARM Cortex M*". Controladores de este tipo son controladores para sistemas embebidos a diferencia de "procesadores" como los que funcionan en PC como aquellos del tipo 8086 y/o Pentium! En primera aproximación controladores son unidades de procesamiento con el foco en las funciones periféricas incluidas y que no necesariamente requieren de memoria externa y que no usan sistemas operacionales como Linux o Windows, sino que no usan un sistema operacional o algo que se llama RTOS, Real Time Operating System, sistema de operación de tiempo real. Ejemplo en ARM son FreeRTOS. La diferencia básica entre un RTOS y los sistemas operacionales tradicionales es que estos permiten que un sistema reacione en un tiempo predicible.
ARM es una empresa que no produce controladores o procesadores, pero que desarrolla estos y los licencia a empresas que entonces definen sus productos a base de lo aquirido por tal licencia. ARM es increiblemente exitoso y prácticamente to productor de controladores y procesadores tiene en su portfolio productos que usan tal licencia. Se especula que hasta Intel esta metiendose en esto!
El resultado es que todos los proveedores basan sus controladores en la misma licencia y que como consecuencia de esta licencia están obligados a ofrecer de acuerdo a una especificación llamada CMSIS, una biblioteca para cada función periférica que incluye en sus controladores del tipo ARM Cortex M*. Los elementos de tal biblioteca son algo lejanamente similiar a lo que llamé subrutina cuando presenté el tema "Assembler". Lo bueno de CMSIS es que existe en todo controlador ARM Cortex M* y que todas las periferias del mismo tipo son usadas en la programación por el mismo "API", "aplication programing interface" o "interfaz de programación para aplicaciones". El resultado de esto es, que cualquier programa escrito para el controlador ARM Cortex M* de algún proveedor puede ser portado a uno de otro proveedor que tenga el mismo set de funciones periféricas usadas por el programa con un mínimo de esfuerzo!
Esto es de un imenso beneficio para todos, pero en especial también para personas con menos recursos económicos y a mi opinión decide sobre la alternativa de programación entre assembler o una lengua interpretada o compilada, es el programa compilado. Esto no excluye de crear propias sentencias usando assembler para lograr una realización óptima, pero la justificación será válida en menos y menos casos!
Pero también el procso de miniaturisación en la producción de controladores, por la técnica de los semiconductores, influencia de forma decisiva porque no veo un auge en un futuro para controladores de los tipos tradicionales y que impacta el costo por el cual se pueden adquirir estos controladores!
El problema de los proveedores de controladores no es la complejidad y el tamaño del circuito en una componente que da como resultado un controlador, es el tamaño del pedazo de silicio que resulta del número de pines. La miniaturisación ya ha llegado desde algunos años a tal punto que controladores no llenan con sus circuitos el espacio disponible en el chip! El término que describe esto compara una caracterisación de cicuitos integrados:
"Pad Limited" o "Core Limited"
Pad es el nombre imgles del elemento sobre un chip de silicio al cual se solda un cablecito, frecuentemente de oro, para unir un Pin de un empaque al circuito integrado. este tiene cierto tamaño y en la circunferencia del chip solo cabe un número limitado de estos. de allí, si un circuito integrado define su tamaño a razón del número de pads requerido entonces el diseño se llama pad limited.
El interior del pedazito de silicio lo llaman "core". Debido a la miniaturisación los circuitos requieren menos y menos espacio, por lo cual queda espacio sin usar.
Ahora el costo de producción de un circuito integrado en lo que al silicio se refiere es fijo por wafer, así se llama el disco de silicio sobre el cual se producen los circuits a integrar. Cuando mas pequeño un circuito, mas caben en el disco, wafer y mayor es el divisor que reparte el costo en cada componente. El resultado es que los proveedores usan este espacio para meter cosas adicionales.
Pero sigamos mirando la cuestión bajo el aspecto del costo. Una componente moderna como un ARM Cortex M* usa las tecnologías mas avanzadas en su producción, por lo cual el ancho digital de las extructuiras de 32 bit de los ARM Cortex M* a comparación de los 8 o 16 bit de Atmel AVR o PIC no representa una desventaja desde el punto del costo, pero si la posibilidad de beneficiarse de la enorme capacidad de potencia de procesamiento que resulta de los 32 bits a comparación de las estructuras tradicionales. Un ARM Cortex M0 no cuesta mas que un Atmel AVR o un PIC.
Mientras que los Atmel y los PIC tienen una arquitectura tradicional que ha entrado en los años, los ARM Cortex M* se benefician de los últimos avances tecnologicos en materia de diseño de controladores.
Pero tambien en las herramientas y la calidad de las bibliotecas de acuerdo a la especificación CMSIS se beneficia de esta situación. Como los productos ofertados por los proveedores son reemplazables comparativamente facilmente por los clientes debido a CMSIS, los proveedores requieren esfuerzos especiales para manterner sus clientes.
Un argumento es la obligación de ofertar sus productos a precios competitivos en un mercado muy competitivo. De allí el aspecto del costo y la disponibilidad!
Eficiencia y potencia:
Los proveedores no solo ponen todos sus esfuerzos en definir y crear circuitos integrados que justifiquen para un cliente usar sus productos, sino que también tienen un interés vital en que la calidad de las bibliotecas de acuerdo a CMSIS que están obligados a ofrecer debido al contrato de licencia con ARM asegure que las posibilidades del circuito integrado se manifeste en la aplicación manejada por el programa.
No acaba allí! Lo mismo es aplicable al entorno de programación, la tal llamada IDE. Como ejemplo. NXP, antes Philips, ofrecía como IDE y de forma gratuita una ofrecida por "Code Red" y que se basa en un quasi estandard la herramienta "Eclipse". Pues debido a la importancia estrtégica para NXP, NXP adquirió Code Red, doblo el límite del tamaño de código de la versión gratuita de 256 kBytes a 512 kBytes! Quién aquí a escrito código de mas de 512 kBytes? El costo para ampliar a la versión ilimitada es módico.
Pero también el aspecto de la verificación de un programa y de la eliminación de errores y problemas en estos modernos controladores ha dado un salto revolucionario, y esto de forma gratuita o casi gratuita. En vez de tener que utilizar un simulador, es posible descargar y ejecutar el programa en esta fase en el controlador objetivo y en la placa final. La interfaz mágica que permite esto es la interfaz JTAG.
Para ganar los millares de programadores y ingenieros electrónicos que hoy usan componetes como los Atmel o los PIC, pero también para ganar la batalla por los clientes grandes, los proveedores facilitan cosas fantásticas, las placas de evaluación! STMicroelectronics, provedor del los PIC ofrece por precios bajísimos y regala frecuentemente placas como la STM32F0-Discovery. El STM32F0, un ARM Cortex Mo viene en esta placa de solo aproximadamente 95x53mm con un conector USB y un "Embedded ST-LINK/V2". Yo, que fui mas aficionado a los Atmel AVR después de intensos estudios me fui con NXP y sus LPCXpresso. Una de las razones, y confieso mi inabilidad de establecer las herramientas de programación a base de Eclipse por falta de conocimientos, amé que la IDE no solo es autoconfigurada durante la instalación, sino que conoce las placas LPCXpresso, en mi caso la LPCXpresso 1769. por un precio de solo 19,80 Euros por una placa con un super controlador, un LPC1769, un ARM Cortex M3. Un LPC800 solo cuesta 0.968 Euros, el LPC1769 un Cortex M3 en comparación 7,21 Euros.
