Was ist mit den DeviceSupport/* Ordnern in der CMSIS 2.0.0 passiert? Extreme POLA violation.
Was soll damit sein? Aber die alten Bugs sind immer noch drin. Ich hatte mit dem Autor der V1.20 eine Diskussion dazu, aber die STREX Funktionen sind in 2.0 unverändert Schrott (braucht =&r statt =r sonst gelegentlich Assembler-Fehler). Immerhin sind die Dinger nun inlined, freilich mit "inline" statt "__inline" was je nach Eintellung des Compilers kracht.
Schätze mal, der DeviceSupport ist dort wo er hingehört. Bei den Devices, d.h. den Herstellern und deren Libs.
Ganz so einfach ist es leider nicht. Die Hersteller(*) haben die Mikrocontroller-spezifischen Definitionen in Header-Dateien gesteckt, dafür gesorgt, dass diese in der offiziellen CMSIS landen und sie folglich aus ihren eigenen Bibliotheken entfernt. Nun liefern sie Teile der CMSIS 1.30 mit ihren Bibliotheken aus. Das heisst, man müsste aktuell, wollte man auf dem neusten CMSIS-Stand bleiben, zusätzlich noch Teile der alten CMSIS 1.30 aus den Hersteller-Bibliotheken referenzieren. Dass in der 'change history' der CMSIS dieser Umstand keinerlei Erwähnung findet, ist ärgerlich. Absolut unverständlich ist jedoch, dass nun Anweisungen zur Erstellung eigener DeviceSupport-Ordner existieren. Da konnte sich jemand offenbar nicht entscheiden, ob DeviceSupport in die CMSIS gehört, oder nicht. * Atmel und ST zumindest, bei den anderen habe ich nicht nachgeschaut
RonaldMcDonald schrieb: > Nun liefern sie Teile > der CMSIS 1.30 mit ihren Bibliotheken aus. Eben. Genau so läuft das. ST/TI/NXP/... oder die Hersteller der IDE kombinieren ihren Kram mit der CMSIS-Vorlage von ARM und liefern das als Paket aus. Und irgendwann werden sie die Libs mit 2.0 ausliefern und dann passt es auch. Nur wenn man unbedingt zwei nicht zusammenpassende Libs passend machen will, nämlich die alte Hersteller-Lib und die neue CMSIS, dann gibts Ärger. > Absolut unverständlich ist jedoch, > dass nun Anweisungen zur Erstellung eigener DeviceSupport-Ordner > existieren. Das adressiert den Ersteller der Hersteller-Lib, nicht dich.
Ja, offenbar läuft es so. Entwickler, die das Zusammenspiel von CMSIS und Herstellerbibliotheken als professionell bezeichnen, halten wahrscheinlich auch die STM32 StdPeriph library für platzsparend, effizient und elegant programmiert.
Mein Ding ist die STlib sowieso nicht - ich habe nicht den Eindruck, dass sie Dinge sehr vereinfacht und die Parametrisierung über structs geht mir auf die Nerven. Die einzig gute Lib ist ohnehin die selbst gebaute. ;-) CMSIS ist aber damit nicht identisch und immerhin der Ansatz eines Minimalkonsenses dessen, was die Cortex-basierten Controller vereint. Damit zumindest da nicht jeder eigene Brötchen backt.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.