Mit dem AVR8 bin ich immer gut zurechtgekommen, mit den ARM tue ich mich nach wie vor schwer wegen der umständlichen Parameterbezeichnungen. Schuld daran ist aber wohl eher die Abstraktions als der Controller bzw. seine Register. Die Parameterbezeichnungen sind teils so unfassbar lang manchmal kryptisch, dass es ohne laufend in die Parameteriste, nicht zu benutzen ist als gelegentlicher Bastler. Schlussendlich erscheint es mir erheblich einfacher, wenn ich sowieso ständig die Parameter nachschlagen muss, ins Datenblatt zu schauen und die Register direkt anzusprechen, außer natürlich bei bereits vorhandenen Treibern für z.B. USB oder Displays. Wenn ,an also nicht ständig die Controller tauscht, gibt es einen guten Grund, sich das anzutun?
Max M. schrieb: > wegen der umständlichen Parameterbezeichnungen Da hilft eine gute IDE und abgucken bei den anderen. Die IDE kann dir u.U. schon eine Liste der möglichen Parameter im Pop-Up Fenster vorschlagen, und Initialisierungen kannst dir bei anderen abgucken. Und meistens erarbeitest du dir doch funktionierenden Code, der dann wiederverwendet wird.
Max M. schrieb: > Wenn ,an also nicht ständig die Controller tauscht, gibt es einen guten > Grund, sich das anzutun? Wenn du das ganze privat machst und da keine Vrogaben hast, kannst du das ja genau so machen, wie du willst. Ich persönlich schaue auch lieber ins reference manual und programmiere meine eigenen kleinen Treiberchen. Mit der HAL etc von bspw. ST konnte ich nie viel Anfangen. Die ist teils genau so, oder noch viel mehr komplizierter als die puren Register. Wenn man mal eine Weile programmiert hat auf einer Familie hat man dann sowieso irgendwann seine kleinen Code-Module, die man wieder verwenden kann, solange man nicht den übelsten Spaghetti-Code verbrochen hat. Für mich war der Breaking Point, als ich auf einem STM32F1 kein DMX hinbekommen habe, weil die Interruptroutine von der HAL zu langsam war, obwohl der Controller ein vielfaches schneller ist, als ein AVR, der das auch packt. bare metal ging es dann und war auch deutlich übersichtlicherer Code. Ich programmiere viel auf der STM32F4xx Serie. Wenn man da mal ein bisschen Ahnung hat und die üblichen Fallstricke (Clock vergessen einzuschalten etc...) im Kopf hat, stellt man fest, dass die Peripherie dadrin jetzt auch nicht so kompliziert ist. Und das reference manual ist in den meisten Teilen gut bis sehr gut. Ich habe selbst auch schon USB bare metal auf dem STM gemacht. Das ging auch nach 3 Tagen. Gut... Diese Synopsys USB-Cores, die ST da drin verbaut, sind teilweise schon komisch, aber es geht. SD Karte habe ich auch schon selbst gemacht in Verbindung mit dem "rohen" FatFS, was ja selbst keine Hardwareabhängigkeiten dafür aber sehr klar definierte Schnittstellen zum anderen Schichten hat.
Wilhelm M. schrieb: > Ich finde die HAL total überflüssig. CMSIS wiederum abstrahiert doch einige Nützlichkeiten, und da es direkt von ARM kommt, kann man sich auch drauf verlassen. (OK, Dinge, die zu Compilerfehlern führten, hatten sie auch schon drin.)
Jörg W. schrieb: > Wilhelm M. schrieb: >> Ich finde die HAL total überflüssig. > > CMSIS wiederum abstrahiert doch einige Nützlichkeiten, und da es direkt > von ARM kommt, kann man sich auch drauf verlassen. (OK, Dinge, die zu > Compilerfehlern führten, hatten sie auch schon drin.) CMSIS wird aus den svd Files generiert und die sind auch nicht fehlerfrei.
Hans-Georg L. schrieb: > CMSIS wird aus den svd Files generiert und die sind auch nicht > fehlerfrei. Zumindest ist dann aber ARM in der Pflicht. ;-) Außerdem ist CMSIS natürlich im Wesentlichen nur ein Satz von Makros und damit recht wenig "auftragend". Ich kann mich erinnern, dass HAL (oder auch das Pendant von Atmel/Microchip) da ziemlich weitschweifig ist in dem, was es noch alles auf die Hardwareschicht aufsetzt. Das ist ja nicht bloß unsinniger Overhead, sondern lässt sich auch blöd debuggen.
M. H. schrieb: > Mit der HAL etc von bspw. ST konnte ich nie viel Anfangen. Na ja, das Problem bei den STM ist doch, dass er ständig Initialisierungen braucht, auch mal in völlig abgelegenen Stellen, und wenn man auch nur einen Parameter zu initialisieren vergisst, dann funktioniert es nicht, weil die nicht auf sinnvollen Defaults stehen sondern meist auf abgeschaltet. HAL macht die Funktionsblöcke wenigstens betriebsbereit. Und wenn man dann von einem Modell zum anderen wechselt, überträgt HAL wenigstens die Einstellungen auf die völlig anders verteilten Register. Aber ich finde die Doku von ST unter aller Sau, wenn die wenigstens funktionstuchtige Examples hätten, und halte das fur den Hauptgrund der achleppenden Verbreitung. Selbst Sinotech hat erkannt, wie bedeutend working examples sind für jeden Belang der eingebauten Funktionalität
Beispiele gibt es reichlich in den Cube Versionen der Controllerserien, sowohl als umfassendere Apps als auch Periphiebezogen in kleinen Beispielen. Bis auf Ethernet mit den komplexen H7 funktionieren die auch ganz gut. Für Initialisierung und Teile von Code finde ich HAL auch brauchbar, nur ist die Versionsverwaltung damit ein Graus, besonders mit der CubeIDE. Ständig werden irgendwelche Metafiles verändert, bei Cube Updates kann es Probleme geben, ein zurück ist ein Pokerspiel wenn man nicht git verwendet. SW in Komponenten ist gruselig, das müsste man mit den kaum dokumentierten Templates machen. Es gibt viele OS oder Frameworks mit denen das besser geht.
Jörg W. schrieb: > Hans-Georg L. schrieb: >> CMSIS wird aus den svd Files generiert und die sind auch nicht >> fehlerfrei. > > Zumindest ist dann aber ARM in der Pflicht. ;-) ARM definiert nur das svd Format, der Inhalt kommt von ST ;-) > > Außerdem ist CMSIS natürlich im Wesentlichen nur ein Satz von Makros und > damit recht wenig "auftragend". Die gibt auch noch die LL (low level), da werden im Wesentlichen die Registerzugriffe in inline Funktionen verpackt. Unterstützt aber nicht die sogenannte "Middleware". > Ich kann mich erinnern, dass HAL (oder auch das Pendant von > Atmel/Microchip) da ziemlich weitschweifig ist in > dem, was es noch alles auf die Hardwareschicht aufsetzt. Das ist ja > nicht bloß unsinniger Overhead, sondern lässt sich auch blöd debuggen. Ja das ist ätzend wenn du im Reference Manual liest welche Bits in welchen Register gesetzt sein müssen und erst herausfinden musst welche HAL Funktion das wann macht. Denn oft spielt auch eine Rolle in welcher Reihenfolge die Bits gesetzt werden müssen oder ein Bitfeld kann nicht beschrieben werden wenn ein anderes Bit gesetzt ist usw. Da kann man sich fragen wie sinnvoll ist da eine Abstraktion ...
In der HAL werden Bits schon in der richtigen Reihenfolge gesetzt wenn nötig, mit dem LL Zeug muss man das alles selber nachbauen. LL spart nur etwas Speicher weil es die Init Strukturen nicht gibt.
:
Bearbeitet durch User
Max M. schrieb: > gibt es einen guten Grund, sich das anzutun? Ich kann da voll mit dir mitfühlen. Bisher habe ich die HAL aus den selben Gründen auch gemieden. Wenn man allerdings wechselweise mit unterschiedlichen STM32 Modellen arbeiten muss, dann kann einem die HAL das Leben erheblich vereinfachen, denke ich. Und die ganzen USB Treiber willst du sicher nicht selbst neu schreiben. Praktischerweise baut die HAL auf CMSIS auf, so dass man problemlos HAL Code mit Nicht-HAL Code kombinieren kann.
:
Bearbeitet durch User
Eine HAL zu verwenden ist meiner Erfahrung mit dem ASF nach ein komplexes Interface (Register) durch mindestens genauso komplexe Software zu ersetzen. Dafür habe ich dann die Nachteile: - langsamer - Spezialfälle vereinzelt nicht möglich - teilweise Fehlerbehaftet - schlechter dokumentiert - mehr Speicherverbrauch (gerade bei kleinen Controllern) Das einzige Problem für Einsteiger ist, dass die offiziellen Beispiele damit geschrieben sind. Ich kann nur davon abraten.
Noch viel Ätzender..ich habe hier 5 Bücher zu STM, und eines Setzt auf HAL, das andere auf CMSIS, das andere auf RTOS und CMSIS, das nächsten auf lipopencm3... NARF, und da soll man als Anfänger nicht überfordert sein. Wenn man es in einem Buch nicht versteht, findet man in dem anderen kein passendes Beispiel, weil wieder auf etwas anderes gesetzt wird
J. S. schrieb: > In der HAL werden Bits schon in der richtigen Reihenfolge gesetzt wenn > nötig. Da habe ich andere Erfahrung ... > mit dem LL Zeug muss man das alles selber nachbauen. LL spart nur > etwas Speicher weil es die Init Strukturen nicht gibt. LL Verwendet teilweise auch Init Strukturen.
Max M. schrieb: > und da soll man als Anfänger nicht überfordert sein STM samt zugehörigem Ökosystem haben eben ein gewisses Niveau- gleiches ist vom Anwender gefordert.
Den HAL von STMicro find ich auch sehr bescheiden, da hab ich mir für F1 und F4 recht viel selber nachgebastelt. Das CMSIS ist okay, das verwenden wir ständig. Am meisten geholfen haben aber die Tutorials von Stefan Frings!
Das ist mir bekannt, aber offenbar weiß ich nicht, wie man es richtig
anwendet.
Bei Mikroe z.B. gibt es die Parameter
GPIO_Digital_Output(@GPIOA_BASE, _GPIO_PINMASK_ALL); // Set PORTA as
digital output
GPIO_Alternate_Function_Enable(@_GPIO_MODULE_SPI3_PB345);
GPIO_Alternate_Function_Enable(@_GPIO_MODULE_SWJ_JTAGDISABLE );
Wenn ich JETZT auf @_Gpioxxxx gehe und Steuerung+D Drücke bekomme ich
auch eine super Übersicht
wie ganz unten, nur wie bekomme ich diese Übersicht, wenn ich NICHT
bereits den Parameter habe??
Wenn ich auf GPU_Alternate_Funktion gehe und dort Steuerung+D, kommt
nichts brauchbares
// _GPIO_MODULE_PARTIALREMAP_TIM1 ={(unsigned long)0x00160040},
/*!< TIM1 Partial Alternate Function mapping */
// _GPIO_MODULE_FULLREMAP_TIM1 ={(unsigned long)0x001600C0},
/*!< TIM1 Full Alternate Function mapping */
// _GPIO_MODULE_PARTIALREMAP1_TIM2 ={(unsigned long)0x00180100},
/*!< TIM2 Partial1 Alternate Function mapping */
// _GPIO_MODULE_PARTIALREMAP2_TIM2 ={(unsigned long)0x00180200},
/*!< TIM2 Partial2 Alternate Function mapping */
// _GPIO_MODULE_FULLREMAP_TIM2 ={(unsigned long)0x00180300},
/*!< TIM2 Full Alternate Function mapping */
// _GPIO_MODULE_PARTIALREMAP_TIM3 ={(unsigned long)0x001A0800},
/*!< TIM3 Partial Alternate Function mapping */
// _GPIO_MODULE_FULLREMAP_TIM3 ={(unsigned long)0x001A0C00},
/*!< TIM3 Full Alternate Function mapping */
// _GPIO_MODULE_REMAP_TIM4 ={(unsigned long)0x00001000},
/*!< TIM4 Alternate Function mapping */
// _GPIO_MODULE_REMAP1_CAN1 ={(unsigned long)0x001D4000},
/*!< CAN1 Alternate Function mapping */
// _GPIO_MODULE_REMAP2_CAN1 ={(unsigned long)0x001D6000},
/*!< CAN1 Alternate Function mapping */
// _GPIO_MODULE_REMAP_PD01 ={(unsigned long)0x00008000},
/*!< PD01 Alternate Function mapping */
// _GPIO_MODULE_REMAP_TIM5CH4_LSI ={(unsigned long)0x00200001},
/*!< LSI connected to TIM5 Channel4 input capture for calibration */
// _GPIO_MODULE_REMAP_ADC1_ETRGINJ ={(unsigned long)0x00200002},
/*!< ADC1 External Trigger Injected Conversion remapping */
// _GPIO_MODULE_REMAP_ADC1_ETRGREG ={(unsigned long)0x00200004},
/*!< ADC1 External Trigger Regular Conversion remapping */
// _GPIO_MODULE_REMAP_ADC2_ETRGINJ ={(unsigned long)0x00200008},
/*!< ADC2 External Trigger Injected Conversion remapping */
// _GPIO_MODULE_REMAP_ADC2_ETRGREG ={(unsigned long)0x00200010},
/*!< ADC2 External Trigger Regular Conversion remapping */
// _GPIO_MODULE_REMAP_ETH ={(unsigned long)0x00200020},
/*!< Ethernet remapping (only for Connectivity line devices) */
// _GPIO_MODULE_REMAP_CAN2 ={(unsigned long)0x00200040},
/*!< CAN2 remapping (only for Connectivity line devices) */
// _GPIO_MODULE_REMAP_SWJ_NOJTRST ={(unsigned long)0x00300100},
/*!< Full SWJ Enabled (JTAG-DP + SW-DP) but without JTRST */
_GPIO_MODULE_SWJ_JTAGDISABLE : Module_Struct =(
(0xFFFFFFFF),
(0xFFFFFFFF),
dword(0x00300200) or __ENABLE_REMAP); //*!< JTAG-DP Disabled and SW-DP
Enabled */
_GPIO_MODULE_SWJ_JTAGENABLE : Module_Struct =(
(0xFFFFFFFF),
(0xFFFFFFFF),
Matthias S. schrieb:
> Max M. schrieb:
>> wegen der umständlichen Parameterbezeichnungen
>
> Da hilft eine gute IDE und abgucken bei den anderen. Die IDE kann dir
> u.U. schon eine Liste der möglichen Parameter im Pop-Up Fenster
> vorschlagen, und Initialisierungen kannst dir bei anderen abgucken.
>
> Und meistens erarbeitest du dir doch funktionierenden Code, der dann
> wiederverwendet wird.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.