Terminamos nuestra serie de artículos sobre kernel Bertos, con una comparación razonada de las diversas soluciones que hemos visto.
Ahora es el momento de sacar las conclusiones. Sabiendo los pros y los contras que le permitirán tomar la mejor decisión para sus proyectos.
| N del kernel |
|
|
El primera solución Bertos, utiliza la API, pero no disponen de núcleo específico. Esta arquitectura funciona bien cuando hay pocas cosas que hacer, y deben ser rápidas. Por ejemplo, si durante la carga de ajustes que necesita para comunicarse con una memoria de serie lenta, no es posible comprobar la alarma. En este caso, la CPU está a la espera, de la memoria para responder, sin ninguna posibilidad de utilizar el tiempo para cualquier otra tarea.
| Synctimer |
|
|
El segunda solución utiliza synctimers. La función synctimer_poll () comprueba automáticamente la temperatura, y el voltaje sin ninguna acción del usuario. synctimers Bertos, se puede considerar que todos los efectos, y un planificador sincrónico. Tienen una baja de RAM y ROM, de impacto y no requieren el núcleo. Además, pueden utilizarse también para eventos de un tiro (es decir, no la repetición de episodios), es suficiente para evitar una llamada a synctimer_add () en las devoluciones de llamada asociada.
Esta solución tiene la ventaja de requerir muy poco mantenimiento, y puede manejar con un poquito de decenas, o cientos de memoria de los acontecimientos. Es una buena solución cuando hay muchas cosas que hacer rápido. La ejecución, es siempre sincrónica, por lo que el problema de latencia sigue: cuando el código se está ejecutando, una llamada larga que no es posible ejecutar cualquier otra tarea.
| Cooperativa del núcleo |
|
|
El tercera solución, usos del núcleo Bertos, cooperativa. Esta solución es lo suficiente en tiempo real, y en general lo suficientemente buena para la típica aplicación de incrustado. Si los procesos no utilizan la CPU demasiado, un proceso de alta prioridad, es despertado en decenas / cientos de microsegundos. Tenga en cuenta que en cualquier caso, todos los retrasos debidos a controlador I / O, se quitan porque son codificados para liberar la CPU en los tiempos de espera.
Normalmente, esta es una solución óptima que proporciona un buen rendimiento con la sobrecarga de la memoria, lo suficientemente bajo o sin demasiadas complicaciones. En nuestro caso, la velocidad en que se activa la protección del motor debería ser suficiente.
En resumen, el núcleo Bertos cooperativa, es una buena solución para muchos casos de uso diferentes. Es mucho más rápido y más reactivo que el clásico de soluciones sincrónicas, presentado anteriormente y que permite mantener fácilmente aplicaciones complejas, con muchas interacciones entre los procesos. Es evidente que tales beneficios llegan en el precio de uso de memoria mayor, que en soluciones anteriores.
Lo que el kernel, no puede garantizar la cooperativa, está cumpliendo un proceso de alta prioridad dentro de un plazo fijo. En un núcleo de cooperación, de hecho, cuando un proceso se despertó, no es de ejecución inmediata, sino que debe esperar el actual proceso, para hacer un cambio de contexto. Esto puede ser un problema si algunos procesos utilizan el CPU demasiado, o en el caso de las solicitudes de muy baja latencia.
| kernel preventiva |
|
|
El cuarta solución, es la que utiliza el núcleo de suscripción preferente, que tiene todas las ventajas del kernel de cooperación, con una latencia menor reacción. Por el contrario, la ocupación de memoria, es siempre superior a soluciones más sencillas, y lo más importante, se debe tener cuidado cuando se accede a datos compartidos.
Esto puede parecer una cosa sin importancia, pero pensé dos veces. Por ejemplo, si también nuestra función de protección del motor debe tener acceso a la prm estructura, puede haber habido grandes problemas de latencia. De hecho, debería haber utilizado un semáforo , y el semáforo es utilizado también por los procesos de baja prioridad. Así que un extraño fenómeno llamado inversión de prioridades puede suceder: desde el semáforo está en manos de los procesos de baja prioridad, los procesos de alta prioridad no se puede ejecutar .
En este caso, paradójicamente, el núcleo cooperativa tiene un mejor rendimiento!
Por eso he dicho que el uso de un núcleo preventivo conlleva, una gran responsabilidad: la aplicación debe diseñarse cuidadosamente para evitar tales situaciones. De lo contrario el riesgo es perder todas las ventajas ofrecidas por la prevención.
Dados los riesgos, es necesario determinar si realmente necesita una latencia muy baja. En nuestro caso, probablemente, la latencia no deterministadado por el núcleo de cooperación habría sido suficiente y nos habría ahorrado algunos problemas.
En el caso de los procesos que requieren una latencia muy baja, para mí es siempre importante preguntar: "¿por qué?". Si el trabajo es realmente importante para la seguridad, ¿es una buena idea contar con una aplicación de software? Probablemente una protección basada en hardware que causan menos problemas y sería más rápido.
Por desgracia muchas veces tales decisiones no están bajo nuestro control (tal vez porque las especificaciones no pueden ser modificados o el hardware ya ha sido), pero usted debe conocer las limitaciones de un núcleo de la preventiva.
No hay comentarios:
Publicar un comentario