Je tiens à écrire un module qui nécessite des API de RTOS, telles que Mbox et la création de tâches API!
J'essaie d'avoir un code structuré et de faire cela, je regarde certaines bibliothèques comme "lwip". Dans "lwip", il y a un fichier nommé SYS-Arch.c, qui, à ma connaissance, est une couche d'abstraction aux API de RTOS! Mais dans mon port, il comprenait cmsis_os.h et utilisé ces API. Pourquoi ont-ils fait cela au lieu d'utiliser cmsis_os directement?
Dois-je avoir une nouvelle couche d'exploitation pour avoir un code portable ou cmsis_os suffit?
3 Réponses :
Cette réponse est très opinée basée.
Dans mon expérience, il est toujours judicieux d'utiliser la fonction / définir autour de vos accès au système d'exploitation. Si vous utilisez cmsis_os ou votre propre couche ne fait pas une grande différence à côté de vous avez plus de travail si vous utilisez votre propre portage et des tests particulièrement lourds avec plus d'un système d'exploitation.
Le CMSIS_OS vous lie aux systèmes Cortex-M, mais comme ils implémentent ce que vous implémenteriez dans votre couche également et de manière assez habituelle, il est assez simple de porter de CMSIS_OS à votre propre couche plus tard. Ce n'est pas si simple si vous utilisez des appels directs vers un système d'exploitation spécifique dans votre code directement, mais il est également possible si vous ne comptez que sur des fonctionnalités standard (jetez un coup d'œil sur cmsis_os quelles sont les caractéristiques courantes des RTO sont) et n'utilisez pas spécial Caractéristiques de votre système d'exploitation.
LwIP est bien structuré de sorte que votre API RTOS prend en charge ses exigences sémantiques, tout ce que vous avez à faire est d'adapter SYS_ARCH.c à votre API OS et vous avez terminé. En faisant SYS_ARCH.C à l'aide de l'abstraction CMSIS_OS API, cela signifierait que vous pouvez utiliser n'importe quel système d'exploitation compatible CMSIS OS API sans changer ce port de SYS_ARCH.c. C'est une couche supplémentaire d'indirecte que vous seul pouvez décider si cela en vaut la peine ou non. Si vous ne prévoyez pas d'utiliser différents RTOS en dessous, il n'y a aucune raison de ne pas avoir de SYS_ARCH.C spécifique à un seul RTO.
Quoi qu'il en soit, les exigences Lwip RTOS sont assez modestes. À peu près une douzaine de fonctions, mais n'implique vraiment que la boîte aux lettres et les sémaphores avec certaines caractéristiques.
Pourquoi ont-ils fait cela au lieu d'utiliser cmsis_os directement?
Parce que:
L'idée est de résumer l'API de tout rtos. Si votre cible n'a pas utilisé CMSIS RTOS, vous devez écrire une couche de portage dans tout cas.
L'API de CMSIS RTOS est un bras Cortex-M spécifique et LwIP n'est pas.
Dois-je avoir une nouvelle couche d'exploitation pour avoir un code portable ou cmsis_os suffit?
CMSIS n'est suffisant que si vous ne cible jamais un bras cortex-m, et il existe une couche CMSIS pour tout RTO que vous pourriez être tenu d'utiliser. CMSIS est une abstraction de portabilité, mais pas peut-être une abstraction de convivialité. Vous pouvez choisir de mettre en œuvre une abstraction plus simple de votre propre CMSI pouvant également être porté à d'autres cibles.