embedded - sistemas - software embebido
Lenguajes alternativos para la programación embebida. (18)
Estoy buscando lenguajes de programación alternativos (desde ensamblador, C, C ++ y básico) hasta programación integrada (microcontrolador).
¿Es posible, por ejemplo, programar microcontroladores en C # o Java? Tal vez Ruby o Python?
Si es posible, publique las herramientas de desarrollo y el hardware utilizado.
Creo que hay (al menos) dos respuestas a esta pregunta. Primero, quiero enfatizar que si está programando cerca del hardware y con un recurso limitado, encontrará que C o C ++ son las herramientas que mejor se adaptan a usted. Los lenguajes de alto nivel no facilitan la manipulación a nivel de bits, etc., pero estas cosas se hacen fácilmente en C. Parte de la solución es descubrir qué herramienta es la mejor para el trabajo y para cosas de bajo nivel Python O Ruby no es lo que quieres.
Por otro lado, si lo que desea hacer es simplemente escribir una aplicación que se ejecute en un microcontrolador, entonces puede tener varias opciones dependiendo del objetivo en el que esté trabajando. Muchas de las llamadas plataformas integradas son mucho más potentes que las estaciones de trabajo de pocos años de antigüedad y, por lo tanto, ejecutan Linux en stock, lo que le brinda una gran cantidad de opciones de idioma.
Desde un kickstarter, Micro Python está ahora disponible y diseñado para dispositivos integrados http://micropython.org/ https://mail.python.org/pipermail/python-list/2014-June/672994.html
"Admite la sintaxis de Python 3 casi completa, incluido el rendimiento (compila el 99,99% de la biblioteca estándar de Python 3)".
FORTH tiene sus virtudes en máquinas pequeñas, pero hay una pequeña curva de aprendizaje.
FORTH tiene muchos lados, cualquiera o todos los cuales se pueden usar para el desarrollo integrado.
Parte de la lucha con FORTH es lidiar con la dicotomía que está presente.
Por un lado, los pequeños y crudos FORTHs de antaño, los viejos intérpretes de subprocesos FigForth Z-80, tienen un nivel MUY bajo en términos del entorno que le brindan a usted, el desarrollador. Ciertamente son más altos que el ensamblaje, pero, posiblemente, (en algún caso) que C.
Por ejemplo, fuera de la caja, FORTH (estas FORTH pequeñas y antiguas en las que muchas personas piensan con CPU pequeñas) no le permite asignar memoria dinámica, o hacer aritmética de punteros (fácil). Ni siquiera tiene "estructuras" como concepto de lenguaje. Básicamente puedes jugar con las compensaciones a través de constantes. Inicialmente, ni siquiera podías hacer recursión. Podría decirse que su mayor limitación es que no tiene tipos de datos reales. No está escrito en absoluto, es todos los números que pueden o no pueden ser punteros a la memoria que pueden o no ser datos o caracteres o lo que sea.
Por supuesto, al mismo tiempo, puede obtener el sistema completo, con un ensamblador y editor, etc., todo dentro de 8K de RAM.
Entonces, de esa manera, es, sí, un nivel más alto que el ensamblaje, pero más bajo que C.
Pero (y es un gran But) ...
Si bien puede comenzar en un nivel bajo, usted, como programador, puede elevarlo a cualquier nivel de abstracción con el que esté contento; puede llevarlo lo más lejos posible.
¿Quieres estructuras? ¿Quieres un montón de malloc de? ¿Quieres un sistema de objetos? Esos están todos disponibles para la construcción sobre la base.
¿Desea soporte de primera clase, a nivel de idioma, para su pequeño sistema de registro basado en ISAM? Fácil.
Considera Common Lisp. Dos de sus características más poderosas son Macros y el Reader, que le dan la oportunidad de convertir texto arbitrario en código que luego se compila.
FORTH tiene la misma capacidad, solo que va incluso más lejos. En los FORTH más antiguos, incluso tiene acceso al compilador, no solo a la entrada del compilador. Los intérpretes con hilos son bastante sencillos y fáciles de modificar. Usted tiene tal acceso "en bruto" a la imagen de memoria que puede, literalmente, hacer lo que quiera, todo desde el propio sistema FORTH.
Así es como FORTHs puede "portarse" a otras arquitecturas fácilmente, cómo pueden optimizar estructuras de datos específicas. Muchos FORTH más viejos son intérpretes con hilos, pero no hay razón para que lo sean. Puede compilar FORTH en código de máquina puro (es decir, sin intérprete) si lo desea.
Por supuesto, en los "microcontroladores" modernos, es probable que simplemente pueda trasladar todo el entorno de desarrollo al dispositivo. Nunca vuelva a copiar una imagen sobre el cable (hasta que la respalde, por supuesto).
Todo esto requiere trabajo, por supuesto. Tal vez demasiado trabajo, eso depende del diseñador / codificador para decidir. Es un conjunto de herramientas primitivo que se puede usar para hacer cosas muy poderosas.
Hace unos meses, se inició el proyecto RubimC : compilador de Ruby y framefork para microcontroladores con poca memoria. La versión actual está funcionando, pero no se da cuenta de todas las características de Ruby.
Hay varios dispositivos físicamente pequeños que ejecutan una versión más o menos completa de Linux. Puede programarlos en prácticamente cualquier lenguaje de programación que se ejecute en Linux, es decir, prácticamente en cualquier lenguaje de programación conocido por la humanidad.
Para microcontroladores con pequeñas cantidades de RAM, demasiado pequeños para ejecutar Linux, vea : "¿Cuáles son los lenguajes interactivos disponibles que se ejecutan en una pequeña memoria?" .
He usado intérpretes de pcode personalizados en máquinas más pequeñas para ahorrar espacio de código.
La mayoría de los sistemas integrados tienen una parte que puede ser de alto rendimiento y muchas cosas que se ejecutan rara vez o para las que el rendimiento no importa.
He implementado una serie de aplicaciones en las que las cosas rápidas del núcleo duro se escribieron en el ensamblador (porque eso es todo lo que podía obtener como herramienta de desarrollo), y luego codifiqué un intérprete de pcode para mi propio conjunto de instrucciones privadas, típicamente con orientación de apilado.
Casi todo lo que necesita para comenzar son los códigos de operación para el operando PUSH / POP (de 8 o 16 bytes), ADD / SUB / MUL / DIV, CMP, IF / GOTO, y call, y estos se codifican fácilmente incluso en conjuntos de instrucciones feas . Después de eso, intenta escribir subrutinas usando CALL, y solo agrega códigos de operación para hacer las cosas que el pcode no puede hacer (dispositivo de E / S), o que requieren una evaluación más rápida.
La codificación en dicho intérprete de pcode es bastante fácil incluso con un ensamblador; simplemente escribe las directivas "BYTE" de ensamblador intercaladas con las directivas "WORD" según lo que quiera el código de operación.
Esta respuesta es esencialmente la variación del hombre pobre de la respuesta de FORTH que di anteriormente.
Para PIC''s hay JAL , viene con algunas bibliotecas agradables.
Para Python solía haber un proyecto interesante: Python profundamente incrustado , pero creo que ha estado muerto desde hace algún tiempo.
Primero, asm y C son las elecciones primarias, y por una buena razón. Comienza allí y construye una base sobre la que puedas apoyarte.
Notamos que el wikireader, es cuarto impulsado o al menos tiene algunos componentes. Un idioma que nunca he aprendido pero que algún día podría.
La placa TINI de Dallas Semiconductor (dallas semi ha sido asimilada por Maxim) fue diseñada para ser una placa JAVA incorporada. Como resultado, tuvieron que poner toneladas de memoria RAM y destellar en relación con un microcontrolador / placa normal. Creo que esas tablas todavía están por ahí.
En el momento en que salió el TINI, el argumento era que Java podría estar incrustado. Tal vez pueda. Tengo entendido que Python es similar a Java en el sentido de que se interpreta o compila a un código de byte o código de máquina común. En el caso de JAVA, el jvm es el emulador de ese lenguaje de máquina común para un objetivo específico. Si ese es el caso de python, en teoría python puede estar tan incrustado como java. Me dicen que adelante está basado en la pila o que es lo que es java, por lo que también implica que adelante puede funcionar incrustado como java. Siempre y cuando tengas suficiente ram para la pila y suficiente espacio de programa y ancho de banda para el vm / emulador. Y ahí radica el problema. Y ahí radica el problema. ram y rom son caros, el precio dominante y los consumidores de potencia de la parte. ¿Quién quiere pagar $ 10 por algo para que pueda usar Java cuando pueden obtener más de una parte de $ 1 usando C / asm? Al menos eso es lo que el mercado te va a decir.
Por otro lado, existe la idea de que Linux se puede incrustar y la gente lo está utilizando de esa manera. Eso significa mega o gigabytes, donde los kilobytes habrían hecho el trabajo más rápido, mejor y más confiablemente (aunque posiblemente a un costo de desarrollo inicial más alto). Así que algunas de las nuevas ARM y mips incorporadas tendrán los recursos que está buscando.
Tengo entendido que gcc y quizás eventualmente, si no es así, llvm puede tener java y otras interfaces (ada por ejemplo, tal vez pascal). lo que significa que puede escribir en java, por ejemplo, pero compilarlo en código de máquina para el procesador de destino y no el código de byte java genérico o como se llame. Esa sería su situación ideal para pasar del lenguaje de scripty a instrucciones de máquina reales (suponiendo que continúe buscando algo que no sea C / asm).
Respuesta corta: ¿Posible? Si posiblemente. El TINI de Dallas es o fue un ejemplo específico utilizando java. Mire también al wikireader, usando lo que parece ser el siguiente.
Puede escribir código en C# bajo .NET . Debe utilizar .NET Micro Framework . Pero prefiero el lenguaje C para estas cosas como cosas. Escribo en C en el procesador ARM7Cortex-M3 con Keil Framework y este es un buen funcionamiento, este marco es compatible con muchas interfaces de programación y procesadores.
Nota: Micro Framework NO es un sistema operativo en tiempo real (por Matthew Whited de los comentarios)
Puede probar python-on-a-chip , compatible con plataformas mbed o STM32, y también portátil a otras plataformas.
Como la mayoría de las cosas en el mundo integrado, sus opciones dependen de sus restricciones. ¿Te has comprometido con una plataforma? ¿Cuánto espacio de código / RAM tiene disponible? ¿Puede su chip soportar un sistema operativo?
Puedes echarle un vistazo al muy potente AvrCo Multitasking Pascal para AVR. Puedes probarlo en http://www.e-lab.de . La versión MEGA8 / 88 es gratuita. Hay toneladas de controladores y simuladores con el depurador JTAG y agradables visualizaciones en vivo o simuladas de todos los dispositivos estándar (LCD, 7SEG, 14SEG, LEDDOT, TECLADO, RC5, SERVO, PASADOR ...).
Si cuenta JavaCard como un microcontrolador, entonces puede programarlo en Java.
Si está programando microcontroladores, casi siempre querrá C o Embedded C ++, todo lo demás es demasiado valioso para el chip flash. Esos son los únicos dos idiomas que recomendaría, si no estás ensamblando cosas a mano (y realmente, ¿quién hace eso en estos días?)
Utilizo Embedded C ++ como todos los demás, en Arduino, por ejemplo, también uso C en su mayor parte en una placa ARM que utilizo.
Solía programar Zilog Z180 en FORTH. ¡No me gustaría volver a hacerlo!
C # se puede usar en .NET Micro , pero necesitará un procesador de 32 bits con al menos 256 Kb de RAM, y no es bueno para aplicaciones en tiempo real. Sin embargo, es de alta productividad para la aplicación correcta, y es posible emplear codificadores sin una amplia experiencia integrada, si esto es escaso y la experiencia en C # no lo es.
Java es factible, especialmente en una parte con ejecución de código de bytes de hardware como la unidad Jazelle en algunos dispositivos ARM9 y ARM de gama superior. Sin embargo, todavía necesita un puerto JVM, y eso puede ser costoso. Por lo general, se usa como parte de un puerto Linux incorporado, por lo que también tiene toda esa sobrecarga, por lo que probablemente tenga más recursos que .NET Micro.
Intel solía producir un lenguaje muy simple llamado PL/M (lenguaje de programación para microcomputadoras) para varios procesadores Intel desde el 4004 hasta el 803286, pero ya no está disponible ni es compatible, y no tiene beneficios sobre C.
Ada se usa ampliamente, especialmente en aplicaciones militares, de aviación y críticas para la seguridad.
Pascal incrustado está disponible para algunos objetivos.
Puede usar NI LabView como un generador de código para sistemas embebidos. De hecho, eso es en lo que se basa Lego Mindstorms. Sin embargo, la versión industrial es algo más sofisticada y completa que la versión de juguete. Del mismo modo, puede generar código incrustado utilizando MATLAB y SimuLink. Estos no son necesariamente los más eficientes, pero más como el procesamiento preciso de señales de control del motor, SimuLink puede ser altamente productivo.
También está Lua. Ver eLua .
FORTH ha sido popular en sistemas embebidos durante mucho tiempo. No tengo experiencia específica con él, pero está muy bien diseñado para proporcionar mucha funcionalidad en una pequeña cantidad de espacio, incluso en microcontroladores difíciles, utilizando métodos de interpretación de código de subprocesos. Incluso es bastante rápido para lo que equivale a un intérprete. Es fácil obtener entornos de desarrollo para FORTH, y es bastante fácil trasladarlo a nuevos sistemas.
La gente lo ama o lo odia, porque insiste en que codifiques en una notación de pulido inverso (básicamente es una máquina de pila con una gran pila de operadores predefinidos).
Este hilo SO parece relevante: https://.com/questions/122292/forth-love-if-honk-then