A menudo no se requiere un sistema operativo, incluso si está utilizando una pila de “middleware” como TCP / IP, USB o un sistema de archivos.
A veces, los chips son demasiado pequeños, por ejemplo, nunca podrá instalar un sistema operativo en el PIC10F200, con solo 256 palabras flash de 12 bits y 16 bytes de RAM.
Cuando se piensa en sistemas operativos para micros, Linux viene a la mente, pero no es realmente adecuado para la mayoría de los sistemas integrados porque Linux estándar no es en tiempo real, y requiere un procesador rápido de 32 bits con una unidad de administración de memoria (MMU) y muchos MB de memoria.
- ¿Cuál es el mejor libro para incrustar?
- ¿Cuáles son algunos de los buenos institutos de capacitación de sistemas integrados en Kanpur?
- ¿Por qué se usa la programación en C en sistemas embebidos?
- ¿Cuál es la diferencia entre sistema embebido y robots?
- ¿Qué es la conexión y las diferencias entre el diseño VLSI y los sistemas integrados?
La mayoría de los sistemas operativos en tiempo real para dispositivos integrados no son un sistema operativo completo en el sentido de que Linux lo es; pueden proporcionar solo programación de tareas, comunicación entre procesos (IPC), sincronización de sincronización y servicios de interrupción, esencialmente solo el núcleo. No incluyen todas las utilidades y programas de usuario porque están diseñados para ser utilizados por una aplicación dedicada, en lugar de los usuarios que han iniciado sesión.
Uno de los sistemas operativos en tiempo real (RTOS) más conocidos es FreeRTOS, que ha sido portado a más de 100 microcontroladores. Es uno de los pocos que se ha portado a microcontroladores de 8 bits, a saber, el 8051. Hay docenas de RTOS de código abierto disponibles, principalmente para chips de 32 bits (especialmente ARM), aunque algunos de 16 bits también están representados como las TI MSP430 y PIC24 y dsPIC de Microchip.
Además de la programación de tareas y los otros elementos mencionados anteriormente, una de las cosas que puede proporcionar un RTOS es una capa de abstracción de hardware (HAL) que aísla los detalles del hardware del programador de la aplicación, lo que facilita la escritura de código portátil.
Si uno no está usando un sistema operativo, se dice que el firmware incorporado está “ejecutándose en el metal desnudo”. A menudo, el código toma la forma de un ” super loop “, que llama a múltiples máquinas de estado de nivel inferior. Cada máquina de estado está a cargo de un dispositivo o tarea en particular, como el mantenimiento de un códec o la verificación de pulsaciones de botones, etc.
Por lo tanto, el código podría verse así, para un simple generador de tonos de audio con una interfaz de usuario. Primero main() llama a una rutina para inicializar el sistema (como configurar puertos, etc.), y luego implementa el súper loop, llamando a cada una de las máquinas de tareas de nivel inferior una y otra vez:
int main (nulo)
{
// Inicializa todos los módulos, incluida la aplicación
SYS_Initialize ();
mientras (cierto)
{
// actualizar el controlador de códec
DRV_CODEC_Tasks (sysObj.drvCodec0);
// actualizar gráficos
GFX_Update ();
// mantener la máquina de estado de la aplicación
APP_Tasks ();
}
// La ejecución no debe venir aquí durante la operación normal
volver (EXIT_FAILURE);
}
La máquina de estado de la aplicación APP_Tasks podría parecerse al siguiente código. Primero llama a una máquina de estado de nivel aún más bajo para procesar las pulsaciones de los botones, y luego pasa por los distintos estados para inicializar la aplicación. Después de eso, procesará los botones presionados según sea necesario.
La nota en los botones no necesariamente se sondearía en la máquina de estado, sino que se reconocería antes en una rutina de servicio de interrupción (ISR) desencadenada por un evento de notificación de cambio de puerto y luego se colocaría en una cola para que la máquina de estado la procese más tarde.
Los detalles de la inicialización del códec en sí mismo, que podría tomar varios pasos por su cuenta, se dejan a la máquina de estado del códec llamada en el super loop. Dado que esto tiene lugar de forma asincrónica con respecto a la máquina de estado de la aplicación, cuando finaliza, devuelve un estado de SYS_STATUS_READY.
nulo APP_Tasks (nulo)
{
// verifica si hay cambios en el botón (SW1 … SW5)
button_state = APP_ButtonTask ();
conmutador (appData.state)
{
caso APP_STATE_CODEC_OPEN: // estado inicial
{
si (SYS_STATUS_READY ==
DRV_CODEC_Status (sysObj.drvCodec0))
{
codecData.handle = DRV_CODEC_Open (
sysObj.drvCodec0, DRV_IO_INTENT_WRITE);
if (codecData.handle! = DRV_HANDLE_INVALID)
{
appData.state = APP_STATE_SET_BUFFER_HANDLER;
}
}
}
rotura;
caso APP_STATE_SET_BUFFER_HANDLER:
{
// etcétera etcétera.
}
rotura;
// muchos más estados
}
}
Si está ejecutando en metal desnudo, y no está utilizando un sistema operativo, aún puede obtener los beneficios de usar controladores de dispositivos utilizando un marco como MPLAB Harmony de Microchip, que está disponible para sus dispositivos PIC32. Incluye pilas de USB, Bluetooth y TCP / IP (sin la necesidad de un RTOS) junto con una extensa biblioteca de gráficos. Los ejemplos anteriores se resumen de ese marco. Si lo desea, Harmony también se puede usar con varios RTOS, incluido FreeRTOS.
