Also meine Lösung wäre, auf die wrappers total zu verzichten und
"native" in FreeRTOS zu codieren.
Der einzige Vorteil so einer Abstraktion liegt darin, dass Du
plattformübergreifenden Code benutzen kannst, also falls der Code unter
verschiedenen OS laufen können *muss,* kannst Du (in der Theorie...) auf
eine gemeinsame Codebasis zugreifen.
Ansonsten haben slcherlei Abstraktionen nur Nachteile:
1. Du kaufst Dir einen "kleinesten gemeinsamen Nenner," d.h. OS
Funktionen, die der Wrapper nicht kennt, fallen unter den Tisch
2. Erhöhter Footprint
3. Höherer Stackbedarf durch das Traversieren redundanter Aufrufketten
4. Schwerer zu lesender Code (z.B. Kinetis SDK: Da jede Middlerware
ihren eigenen Abstraktionslayer hat, gibt es bei einigen
Codebeispielen bis zu 6 verscheidene Möglichkeiten, einen task zu
erzeugen!)
5. Fehlerpotential in den Implementationen der Wrappers.
6. Kontrollverlust über Speicherlayout (das tut besonders beim Thema
Bootloader weh).
7. Interdependenzen zwischen verschiedenen Versionen der Layers (sh.
Browserversionshölle bei Websites, gleiches in Grün).
Die Abstraktionslayer werden hauptsächlich aus politischen Gründen
gepusht, um entweder vendor lock-in zu erreichen oder (im Fall der
CMSIS) die ARM Plattform insgesamt attraktiver zu machen (was natürlich
den Chipherstellern überhaupt nicht gefällt und in direkter Konkurrenz
mit deren HALs liegt).
Am Beispiel lwip kann man z.B. auch sehr schön sehen, dass
Abstraktionslayer eine potentiell grosse Fehlerquelle sind; es hat z.B.
fast jede Beispielsuite seine eigene Implementation von sys_arch.c (OS
Abstraktion), von der 90% Blindflüge oder Schnellschüsse sind.
In der Praxis ist die Hoffnung, durch die Abstraktionen eine
Middlewarekomponente plug-und-play tauschen zu können, sowieso
unrealistisch, gerade bei Betriebssystemen, wo der Teufel im Detail
liegt (das habe ich mehrfach selber erleben dürfen) und ein
Entwicklunsghaus sich in der Regel auf sehr lange Zeit auf ein RTOS
committed. Die PC Welt ist durch diese Illusion schon vor vielen Jahren
gegangen, als mit Paketen wie XVT versucht wurde, OS-unabhängige UIs zu
erzeugen. Folge: Wartungsprobleme und #ifdef ohne Ende, und da am Schluß
in der Regel nur eine Plattform übriggeblieben ist, war der
Abstraktionslayer nicht nur redundant, sondern aus denselben Gründen wie
oben genannt sogar der nativen Implementation unterlegen.
Dein Fall zeigt eigentlich als case in point, das der Abstraktionslayer
(in diesem Fall CMSIS) statt einer Verbesserung nur Folgeprobleme
bringt. Ich schmeiße in der Regel erstmal Alles überflüssiges Zeug aus
einem Projekt heraus, um mich auf die wahren Herausforderungen
konzentrieren zu können.