QP | ||
---|---|---|
Parte de framework | ||
Información general | ||
Tipo de programa | aplicación informática | |
Licencia | GNU General Public License | |
Información técnica | ||
Programado en | C++ | |
Enlaces | ||
QP ("Quantum Platform") es una familia de marcos de software de código abierto ligeros para crear aplicaciones integradas en tiempo real modulares y receptivas como sistemas de objetos activos (actores) cooperantes y controlados por eventos .
Visión general
La familia QP consta de marcos QP / C, QP / C ++ y QP-nano, todos con control de calidad, documentado[1] y con licencia comercial .
Todos los marcos de QP pueden ejecutarse en microcontroladores de un solo chip "bare-metal", reemplazando por completo un sistema operativo en tiempo real tradicional (RTOS).[2] Se proporcionan puertos y ejemplos listos para usar para todas las principales familias de CPU . QP / C y QP / C ++ también pueden funcionar con un sistema operativo / RTOS tradicional, como: POSIX ( Linux, QNX ), Windows, VxWorks, ThreadX, MicroC / OS, FreeRTOS, etc.[3]
El comportamiento de los objetos activos (actores) se especifica en QP mediante máquinas de estado jerárquicas (gráficos de estado UML). Los frameworks admiten la codificación manual de máquinas de estado UML en C o C ++, así como la generación de código totalmente automática mediante la herramienta de modelado gráfico QM gratuito.[4]
Los marcos QP y la herramienta de modelado QM se utilizan en dispositivos médicos, defensa y aeroespacial, robótica, electrónica de consumo, telecomunicaciones inalámbricas y alámbricas, automatización industrial, transporte y muchos más.
Antecedentes
Los objetos activos admiten de forma inherente y hacen cumplir automáticamente las siguientes mejores prácticas de programación concurrente:[5]
- Mantenga todos los datos de la tarea locales, vinculados a la tarea en sí y ocultos del resto del sistema.
- Comunicarse entre tareas de forma asincrónica a través de objetos de eventos intermedios. El uso de la publicación de eventos asincrónica mantiene las tareas ejecutándose de manera verdaderamente independiente sin bloquearse entre sí.
- Las tareas deben pasar toda su vida respondiendo a eventos entrantes, por lo que su línea principal debe consistir en un ciclo de eventos .
- Las tareas deben procesar los eventos de uno en uno (hasta su finalización), evitando así cualquier peligro de concurrencia dentro de una tarea en sí.
Los objetos activos mejoran drásticamente su capacidad de razonar sobre el software concurrente. Por el contrario, el uso directo de tareas RTOS sin procesar es un problema por varias razones, particularmente porque las tareas sin procesar le permiten hacer cualquier cosa y no le ofrecen ayuda o automatización para las mejores prácticas.[6] Al igual que con todos los buenos patrones, los objetos activos elevan el nivel de abstracción por encima de los hilos desnudos y le permiten expresar su intención de manera más directa, mejorando así su productividad.
Los objetos activos no pueden operar en el vacío y requieren una infraestructura de software (framework) que proporcione, como mínimo: un hilo de ejecución para cada objeto activo, cola de eventos y servicios de temporización basados en eventos. En los sistemas embebidos con recursos limitados, la mayor preocupación siempre ha sido la escalabilidad y la eficiencia de dichos marcos, especialmente que los marcos que acompañan a varias herramientas de modelado se han construido tradicionalmente sobre un RTOS convencional, lo que agrega espacio de memoria y sobrecarga de CPU a la solución final.
Los marcos de QP se han diseñado para ofrecer eficiencia y una huella mínima desde cero y no necesitan un RTOS en la configuración independiente. De hecho, en comparación con los RTOS convencionales, los marcos QP proporcionan una huella más pequeña, especialmente en RAM (espacio de datos), pero también en ROM (espacio de código). Esto es posible, porque los objetos activos no necesitan bloquearse, por lo que la mayoría de los mecanismos de bloqueo (por ejemplo, semáforos ) de un RTOS convencional no son necesarios.
Todas estas características hacen que los objetos activos controlados por eventos se adapten perfectamente a los microcontroladores de un solo chip (MCU). No solo obtiene el aumento de productividad al trabajar a un nivel más alto de abstracción que las tareas RTOS sin procesar, sino que además lo obtiene con una menor utilización de recursos y una mejor eficiencia energética, porque los sistemas controlados por eventos usan la CPU solo cuando procesan eventos y pueden Ponga el chip en modo de suspensión de bajo consumo.
Arquitectura y componentes de QP
QP consta de un procesador de eventos universal compatible con UML (QEP), un marco de trabajo en tiempo real (QF) portátil, controlado por eventos, un pequeño kernel de ejecución hasta su finalización (QK) y un sistema de seguimiento de software (QS).
QEP (Quantum Event Processor / Procesador de eventos cuánticos) es un procesador de eventos universal compatible con UML que permite la codificación directa de máquinas de estado UML ( diagramas de estado UML) en C o C ++ de fácil mantenimiento, en el que cada elemento de la máquina de estado se asigna al código de forma precisa, inequívoca y exacta una vez. ( trazabilidad ). QEP es totalmente compatible con el anidamiento jerárquico de estados, lo que permite reutilizar el comportamiento en muchos estados en lugar de repetir las mismas acciones y transiciones una y otra vez.
QF (Quantum Framework / Marco cuántico) es un marco de aplicación en tiempo real, controlado por eventos y altamente portátil para la ejecución concurrente de máquinas de estado diseñado específicamente para sistemas embebidos en tiempo real .
QK ( Quantum Kernel / Kernel cuántico) es un pequeño kernel preventivo de ejecución hasta finalización sin bloqueo diseñado específicamente para ejecutar máquinas de estado en una forma de ejecución hasta finalización (RTC).
QS (Quantum Spy / Espía cuántico) es un sistema de rastreo de software que permite el monitoreo en vivo de aplicaciones QP basadas en eventos con recursos mínimos del sistema de destino y sin detener o ralentizar significativamente el código.
Procesadores compatibles
Todos los tipos de marcos de QP (QP / C, QP / C ++ y QP-nano) se pueden adaptar fácilmente a varias arquitecturas de microprocesadores y compiladores. La adaptación del software QP se denomina portabilidad y todos los marcos de QP se han diseñado desde cero para facilitar esta portabilidad.
Actualmente, existen puertos Quantum Platform completos para las siguientes arquitecturas de procesador:
- BRAZO Cortex-M4F (TI Stellaris)
- BRAZO Cortex-M3 (TI Stellaris, ST STM32, NXP LPC)
- BRAZO Cortex-M0 (NXP LPC1114)
- BRAZO7/9 (Atmel EN91R4x, EN91SAM7, NXP LPC, ST STR912)
- Atmel AVR Mega
- Atmel AVR32 UC3-Un3
- TI MSP430
- TI TMS320C28x
- TI TMS320C55x
- Renesas Rx600
- Renesas R8C
- Renesas H8
- Freescale Coldfire
- Freescale 68HC08
- Altera Nios II
- 8051 (Laboratorios de Silicio)
- 80251 (Atmel)
- Microchip PIC24/dsPIC
- Ciprés PSoC1
- 80x86 modo real
Sistemas operativos compatibles
Los marcos QP / C y QP / C ++ también pueden funcionar con los sistemas operativos tradicionales y RTOS.
Actualmente, existen puertos QP para los siguientes sistemas operativos / RTOS:
- Linux (POSIX)
- Gana32 (todo desktop Ventanas y WindowsCE)
- VxWorks
- ThreadX
- FreeRTOS
- MicroC/OS-II
- QNX (POSIX)
- Integridad (POSIX)
Licencia
Todos los tipos de marcos de QP tienen licencia doble bajo la GPLv2 de código abierto y una licencia tradicional de código cerrado. Los usuarios que deseen distribuir QP (por ejemplo, integrados en dispositivos actualizables por el usuario) pueden conservar el estado de propiedad de su código por una tarifa. Se encuentran disponibles varios tipos de licencias comerciales, libres de regalías y de código cerrado.
Véase también
Referencias
- ↑ Samek, Miro (2008). Practical UML Statecharts in C/C++, Second Edition: Event-Driven Programming for Embedded Systems. Newnes. p. 728. ISBN 978-0-7506-8706-5.
- ↑ Ejemplo de uso de QP en repositorio en GitHup
- ↑ Soporte de RTOS y SO
- ↑ «free graphical QM modeling tool».
- ↑ Herb Sutter (16 de marzo de 2009). «Use Threads Correctly = Isolation + Asynchronous Messages».
- ↑ Herb Sutter (14 de junio de 2010). «Prefer Using Active Objects Instead of Naked Threads».
Enlaces externos
- state-machine.com
- QP Proyecto en Sourceforge.net
- qf4red: Marco Cuántico para .Neto
- qfj: Marco cuántico para Java en Sourceforge.net
- Miros: Un módulo de máquina estatal jerárquico en Pitón
- Miros: Un módulo de máquina estatal jerárquico en Lua
- Estatal-Programación Orientada (Groovy)
- ACCU Sobrecarga Revista #64 "Aún así Otra Máquina Estatal Jerárquica"
- #C/#C++ Usuarios Revista "Quién Movió Mi Estado?"
- #C/#C++ Usuarios Revista "Deja Vu"
- Búsqueda en Abierto CNC el sistema Basado en Marco Cuántico
- Objetos activos por Schmidt