Por qué necesitamos uCos

, así que comenzó el camino de uCos. Sin embargo, debido a problemas con la plataforma de hardware, Bi She no usó uCos, sino que usó otro que no era de código abierto. Después de graduarme, trabajé en proyectos que usaban RTX51, uCos y Linux. Cuando estaba trabajando en un proyecto en Linux, estudié el código fuente de Linux por un tiempo y un día, cuando no tenía nada que hacer, fui. Miré el código fuente de uCos y de repente descubrí que en uCos ¡Algunos de los principios son tan clásicos y completos para comprender y construir un sistema operativo! Así que creo que es hora de comprender y aclarar mejor algunos de los principios de uCos. Creo que la primera pregunta a resolver es ¿por qué necesito uCos? Al igual que cuando aprendí programación en C por primera vez, el profesor me dijo que los punteros son muy importantes. En ese momento tenía una gran pregunta: ¿cuáles son los beneficios de los punteros? Todavía estaba murmurando en mi corazón: ¿Cómo puedo escribir el programa de manera diferente sin usar punteros? Ahora piense en el lenguaje C sin punteros, ¡será difícil avanzar! Volviendo al tema, ¿por qué necesitamos uCos? La idea general de programación para dispositivos integrados simples es la siguiente: main{{Procesando transacción 1}; {Procesando transacción 2}; {Procesando transacción 3} .....{Procesando transacción N};}isr_server {{Procesando interrupción}; ;} Esta es la idea más general. Por supuesto, es suficiente para sistemas simples, pero el rendimiento en tiempo real de dicho sistema es muy pobre. Por ejemplo, si la "Transacción 1" es una prueba de entrada del usuario, cuando el usuario Cuando. Al ingresar, si el programa está procesando las transacciones debajo de la transacción 1, entonces la entrada del usuario no será válida esta vez. La experiencia del usuario es "este botón no es sensible, esta máquina es muy lenta", y si ponemos la transacción en la interrupción. para el procesamiento, aunque se mejora el rendimiento en tiempo real, provocará otro problema, que puede provocar una pérdida de interrupción. ¡Esta consecuencia es a veces más grave y mala que "más lenta"! Para otro ejemplo, la transacción 2 es una tarea que solo tarda 1 segundo en procesarse, por lo que obviamente la transacción 2 desperdiciará tiempo de CPU. En este momento, es posible que necesitemos mejorar nuestras ideas de programación. Generalmente, intentaremos utilizar el método de "intervalo de tiempo". En este momento, la programación será de la siguiente manera: main{{Cuando llegue el intervalo de tiempo de la transacción 1, procese la transacción 1} {Cuando llegue el intervalo de tiempo de la transacción 2, procese la transacción 2}; Tiempo de la transacción N Cuando llega el segmento, procesa la transacción N};} time_isr_server{{Juzga si el segmento de tiempo de cada transacción ha llegado y márcalo};} isr_server{{Procesa la interrupción};} Podemos ver que esto mejoró La idea es controlar el tiempo de ejecución de la transacción y la transacción solo se ejecutará después de que llegue su propio intervalo de tiempo. Sin embargo, descubrimos que este método aún no puede resolver completamente el problema del "tiempo real", porque después de un intervalo de tiempo. Cuando llega cierta transacción, no se ejecutará. No se puede ejecutar inmediatamente. Debe esperar hasta que se agote el intervalo de tiempo de la transacción actual y el intervalo de tiempo de la transacción posterior no haya llegado antes de tener la oportunidad de obtener el "tiempo de ejecución". . En este momento, debemos continuar mejorando nuestro pensamiento. Para que una transacción se ejecute inmediatamente después de que llegue su intervalo de tiempo, debemos cambiar la posición de retorno del programa después de juzgar el intervalo de tiempo en la interrupción del reloj, para que el El programa no regresa al punto donde acaba de ser interrumpido y la ejecución comienza desde la última transacción que obtuvo el intervalo de tiempo, resolviendo así por completo el problema de tiempo real de la transacción. Realizamos mejoras basadas en esta idea. Necesitamos guardar el estado actual de la CPU y algunos datos utilizados en la transacción actual antes de ingresar la interrupción del reloj cada vez. Luego ingresamos la interrupción del reloj para el procesamiento del intervalo de tiempo. es nuevo y más urgente Cuando llega el intervalo de tiempo de la transacción, cambiamos la dirección de retorno de la interrupción, restauramos la escena de esta transacción más urgente en la CPU y luego volvemos a la interrupción para comenzar a ejecutar esta transacción más urgente. El párrafo anterior es un poco difícil de leer. De hecho, esto se debe a que es un poco complicado y problemático implementar este proceso. En este momento, necesitamos encontrar un sistema operativo (SO) que nos ayude a hacer estas cosas. puedes hacerlo tú mismo Para implementar este proceso con código, en realidad estás escribiendo el sistema operativo tú mismo. De hecho, también se puede ver desde aquí que los principios del sistema operativo no son tan misteriosos, pero algunos detalles te resultan difíciles. para hacerlo bien.

uCos es uno de esos sistemas operativos que puede ayudarlo a completar estas cosas, ¡y puede hacerlo de manera muy elegante! La utilidad de uCos va mucho más allá de ayudarlo a completar este "procesamiento de intervalos de tiempo de transacción". También puede ayudarlo a manejar varios tiempos de espera, realizar administración de memoria, completar la comunicación entre tareas, etc. Con ella, el nivel del programa también es más claro. dando También es más conveniente agregar funciones al sistema, ¡lo cual se vuelve cada vez más obvio en proyectos a gran escala! Sabemos que uCos puede brindarnos muchas comodidades, ¡así que comencemos a usar uCos!