Thursday, July 15, 2021

Stdout - Cómo funciona

Usemos el comando ls -l una vez más como ejemplo. Si solo escribe el comando, verá
su resultado en STDOUT. Sin embargo, si escribe ls -l> en algún lugar, le indicará al comando que envíe su salida a otro lugar, en este caso a un archivo que tenga el nombre en algún lugar. Este archivo se creará en el directorio actual si no existe. 

Si ya existe un archivo con este nombre, lo sobrescribirá con este comando. En caso de que desee agregar a un archivo existente en lugar de sobrescribirlo, use ls -l >> en algún lugar. El redirector doble le dice al comando que se agregue al contenido del archivo en lugar de sobrescribirlo. Si el archivo aún no existe, el comando lo creará. Entonces, si desea asegurarse de nunca sobrescribir un archivo existente por accidente al usar la redirección, use >> en todo momento en lugar de >.

Algunos comandos le dan mensajes de error además de la salida. Lo bueno es que también puedes redirigir estos mensajes de error. Para hacer esto, use 2 > en lugar de >. Entonces, si ls -l le da muchos mensajes de error como bueno (lo cual no es muy probable, pero nunca se sabe), puede enviarlos todos al archivo de errores, que se creará en el directorio actual si usa ls -l 2 > errors. E incluso es posible redirigir la salida estándar de un comando en una dirección, mientras se envía la salida de error a otra parte. Por ejemplo, el comando ls -l> salida 2> errores creará dos archivos, el archivo de salida para la salida normal y los errores de archivo para la salida de error. 

En lugar de enviar los resultados de un comando a un archivo, también puede redirigir a algunos de los dispositivos especiales de Linux. Cada pieza de hardware en Linux se puede direccionar mediante un archivo de dispositivo. Por ejemplo, existe el archivo de dispositivo / dev / null, que se puede utilizar como papelera digital. Todo lo que envíe a / dev / null desaparecerá inmediatamente en el aire. Entonces, si simplemente no desea ver ningún mensaje de error, en lugar de guardarlos en algún lugar de su sistema, puede redirigir los mensajes de error al dispositivo / dev / null. El siguiente ejemplo muestra cómo hacerlo:

ls -l 2 > / dev / null 

stdout


Saturday, July 10, 2021

Introducción a CMSIS-RTOS


CMSIS-RTOS es uno de los proyectos dentro del desarrollo del estándar de interfaz de software del microcontrolador Cortex. CMSIS-RTOS es una especificación de API que permite diseñar middleware que funcione con múltiples productos RTOS. El CMSIS-RTOS en sí no es un producto, pero las empresas pueden crear un RTOS que se base en las API de CMSIS-RTOS, o agregar una capa de envoltura sobre sus propias API de SO para hacer las mismas cosas. 

Muchos productos de middleware son bastante complejos; muchos de ellos pueden necesitar utilizar funciones de programación de tareas en el sistema operativo para funcionar. Por ejemplo, una pila de TCP / IP podría ejecutarse como una tarea. 

La necesidad de una capa de emulación de SO para componentes de middleware dentro de un sistema multitarea y es posible que deba generar tareas secundarias adicionales cuando se reciben ciertas solicitudes de servicio. Tradicionalmente, el middleware incluye una capa de emulación de SO que un integrador de software necesita trasladar cuando usa un SO diferente. 

La migración de la capa de emulación del sistema operativo crea trabajo adicional para los desarrolladores de software o, a veces, los proveedores de middleware, y puede aumentar los riesgos del proyecto porque la migración puede no ser sencilla. 

CMSIS-RTOS se creó para resolver este problema. 

Se puede implementar como un conjunto adicional de API o un contenedor para las API de SO existentes. Dado que la API está estandarizada, se puede desarrollar middleware basado en esta API y el producto debería, en teoría, poder funcionar con cualquier sistema operativo integrado que admita CMSIS-RTOS. 

CMSIS-RTOS evita la necesidad de una capa de emulación de SO para cada componente de middleware. 

Los productos RTOS aún pueden tener su propia interfaz API nativa y el código de la aplicación aún puede usarlos directamente para funciones adicionales o para un mayor rendimiento. Esta es una buena noticia para los desarrolladores de aplicaciones porque ahorra mucho tiempo en la migración de middleware y reduce los riesgos del proyecto. También es una buena noticia para los proveedores de middleware porque permite que sus productos funcionen con más sistemas operativos. 

CMSIS-RTOS también beneficia a los proveedores de RTOS: a medida que aumenta la cantidad de middleware que funciona con CMSIS-RTOS, tener compatibilidad con CMSIS-RTOS en un sistema operativo integrado permite que el producto del sistema operativo funcione con más middleware. Además, a medida que aumenta la complejidad del software en los sistemas integrados y el tiempo de comercialización se vuelve más importante, la migración de capas de emulación de SO para middleware ya no es factible para algunos proyectos debido al tiempo adicional necesario y al riesgo asociado del proyecto. CMSIS-RTOS permite que los productos RTOS lleguen a estos mercados, que anteriormente solo podían cubrirse con unas pocas soluciones de plataforma de software.