Stefanus F. schrieb:
> Dennoch heißt es hier immer wieder, man solle Anfängern nicht die AVR µC
> empfehlen, weil bei STM32 ja alles einfacher und besser sei. Wo ist die
> Logik darin?
die STM32 sind nicht unbedingt einfacher, das behaupte ich schon nicht
mehr. Aber sie (und andere Cortex-M natürlich auch) haben deutlich
komplexere und leistungsfähigere Peripherie. Einige Probleme scheinen
daher zu kommen das da verschiedene Clockdomains zusammenarbeiten und
die Synchronisation zickig ist. Das sowas schon bei 'simplen' Sachen wie
SPI zuschlägt macht es für Anfänger nicht einfach. Daher empfehle ich
gerne die LPC von NXP (bin nicht mit denen verwandt oder verschwägert)
weil die Peripherie viel mehr 32 Bit breite nutzt und irgendwie
intuitiver zu programmieren ist.
Die STM32 haben für mich die Nase in Sachen Grafik vorne und das
STM32F407VE Board bekommt man für ca. 10€ und für noch einen 10er gibts
ein TFT dazu das man nur aufstecken braucht. Ansteuerung per FSMC
sauschnell. Da gibt es zur Zeit nichts vergleichbares.
In mbed wird für STM die HAL verwendet und deshalb habe ich das jetzt
auch genutzt. Da diese SW auch von ST kommt sehe ich das als Referenz
und Erratas sollten darin auch berücksichtigt sein. Ob das immer so ist
weiss ich allerdings nicht. Und bei diesem letzten Fehler war das
Problem der sonst saubere Aufbau mit mehreren Schichten, nur im Debug
build zu langsam.
Ich weiss das über HAL viel gemeckert wird, wenn ich da so blödsinnige
Abfragen sehen verstehe ich auch warum, aber so ein SDC interface würde
ich nicht in 3 Tagen aus Datenblättern zusammenschreiben.
1 | if((Timeout == 0U)||((HAL_GetTick()-tickstart) >= Timeout))
|
Also wenn die Funktion ein Timeout 0 übergeben bekommt wird immer ein
Fehler gemeldet, auch wenn es kein Timeout gab.
Die Jungs von stm32duino haben im libmaple core das ohne HAL
hinbekommen, aber da haben die sicher ein paar Stunden an der
Implementierung gesessen.
