Frischer Erfahrungsbericht: Um mal eben mit einem nRF24L01+ was
auszuprobieren, etwas auf die Schnelle hingepfuscht. Mit der HAL und
einem STM32F103C8T6 (Blue Pill). Lief natürlich nicht. Zum Schluß nur
noch das STATUS-Register auslesen, mit HAL_SPI_TransmitReceive(). Ergab
nach 8 clocks 0x1C! Also schon Fehler auf unterster SPI-Ebene. Dem
HAL-Gedanken folgend blind weitervertraut und alles mögliche geprüft.
Lief natürlich nicht.
Kurzum: Nach knapp 2 Stunden HAL-gespiele dann Schnauze voll und
systematisch angefangen zu suchen. Irgendwann geschaut, ob die HAL denn
das Peripheral auch selbst enabled, wie man es von Muddi erwartet: Klar;
wird öfters in der Funktion gecheckt (z.B. in Zeile 888):
Dann in wenigen Minuten mit CMSIS die Funktion "ersetzt". Es lief...
Dann in dem HAL-code per CMSIS einfach nur das Peripheral enabled. Es
lief...
Selber schuld.
Unterm Strich betrachtet kommt es mir so vor, als ob man mit Cube HAL
mehr zusätzlichen Aufwand hat, als Nutzen.
So wirklich abstrahiert ist da auch nicht viel, man kann den Controller
trotzdem nicht ohne erhebliche Quelltext-Änderungen wechseln.
Da arbeite ich lieber Copy/Paste Code-Schnipseln, die ich selbst
erstellt oder wenigstens durchprobiert und nachvollzogen habe.
"So wirklich abstrahiert ist da auch nicht viel, man kann den Controller
trotzdem nicht ohne erhebliche Quelltext-Änderungen wechseln."
So bald man soetwas machen kann, wird der Code auch nicht mehr so
Performant sein...
Aber beim Lesen der Doku fällt mir ganz stark auf, dass ich zusätzlich
das Reference Manual, das Datasheet und das Errata lesen muss. Außerdem
muss ich in die Sourcen der HAL schauen, um Dokumentationslücken zu
schließen.
Da kann ich auch gleich ganz auf die HAL verzichten. Mir fällt es ohne
HAL jedenfalls leichter.
Stefanus F. schrieb:> So wirklich abstrahiert ist da auch nicht viel, man kann den Controller> trotzdem nicht ohne erhebliche Quelltext-Änderungen wechseln.
Das ist falsch. Habe persönlich ein umfangreiches Projekt, welches
ursprünglich mit CubeMX für einen STM32F103 erstellt wurde, innerhalb
von einem halben Tag auf einen STM32F302 portiert. Und das hat auch nur
solange gedauert, weil für die USB Schnittstelle grosse Anpassungen
gemacht wurden, damit man ein Kompositgerät mit 3 Endgeräten hat. Das
ist so bei einem Cube HAL Projekt nicht vorgesehen sondern nur ein
Endgerät.
Stefanus F. schrieb:> Da kann ich auch gleich ganz auf die HAL verzichten. Mir fällt es ohne> HAL jedenfalls leichter.
Volle Zustimmung. Gerade bei einem STM32F103 für den es vor der HAL ja
schon die SPL oder so ähnlich gab. Und in 2 Jahren gibt es wieder was
anderes. Dann lieber bei den Registern bleiben, die leben wenigstens so
lange wie der Controller.
Stefanus F. schrieb:> Unterm Strich betrachtet kommt es mir so vor, als ob man mit Cube HAL> mehr zusätzlichen Aufwand hat, als Nutzen.
das sind aber zwei Dinge, die HAL und Cube. Aber der Zauberwürfel kennt
die HAL und weiss was man implementieren muss. Insofern ist es schon
sehr einfach ein kleines Projekt generieren zu lassen und zu schauen was
nötig ist.
temp schrieb:> Dann lieber bei den Registern bleiben, die leben wenigstens so> lange wie der Controller.
gerade die Registerprogrammierung ändert sich von Controller zu
Controller, auch innerhalb einer Familie gibt es mehr oder weniger
moderne. Und da reicht ein nicht gesetztes Bit um zu verzweifeln.
Johannes S. schrieb:> Und da reicht ein nicht gesetztes Bit um zu verzweifeln.
Dieser Satz trifft auf die gesamte Softwareentwicklung zu, egal welchen
Abstraktionslevel man wählt. Bloss wer ist am Ende besser dran, der der
die Register kennt oder der der sie nicht kennt?
Ich habe schon einige male die HAL verwendet, ich muss sagen, da hat ST
im großen und ganzen sehr gute Arbeit geleistet und nimmt einem sehr
viel ab.
Und wenn da mal an der ein oder anderen Stelle ein kleiner Bug drin ist,
dann ist es natürlich hilfreich wenn man das Datasheet kennt.
Copy&Paste habe ich früher auch lieber gemocht, jetzt wo ich je Projekt
den passenden STM32 auswähle nehme ich lieber die HAL & CubeMX.
Johannes S. schrieb:> Lutz schrieb:>> Selber schuld.>> wenn man keine Doku liest.> ======================================================================== ======> ##### How to use this driver #####> ========================================================================
======
> [..]> The SPI HAL driver can be used as follows:>> (#) Declare a SPI_HandleTypeDef handle structure, for example:> SPI_HandleTypeDef hspi;>> (#)Initialize the SPI low level resources by implementing the> HAL_SPI_MspInit() API:> (##) Enable the SPIx interface clock> (##) SPI pins configuration> (+++) Enable the clock for the SPI GPIOs> (+++) Configure these SPI pins as alternate function> push-pull
Natürlich ist es meine Schuld, ohne Zweifel. Und ehrlich gesagt habe ich
auch nur die halbe Wahrheit geschrieben: Ich habe natürlich CubeMX zum
Erstellen genutzt. Und da sind alle von dir zitierten Punkte automatisch
drin! Das Interface wird nur nicht enabled. Ich dachte, daß wird in der
Funktion HAL_Transmit_Receive() gemacht. Wird es irgendwie auch (siehe
Eingangspost), es reicht nur anscheinend nicht. Und: Ich habe recht früh
den LA angeschlossen und das in der Anlage gesehen. Da ging ich
erstmal davon aus, daß das Peripheral auch läuft. Es clockt ja artig
und MOSI stimmt auch immer. Es kommt aber nur beim ersten Byte das
Register STATUS), und zwar inhaltlich fast richtig (STATUS << 1). Und
dann keine Antwort mehr bei den nächsten clocks. Deshalb war ich erstmal
"getäuscht".
Wie gesagt, ist meine Schuld und ich will HAL und CubeMX nicht schlecht
machen. Alleine zum Initialisieren inkl. Takt ist das schon fein. Man
muß das nur noch in ein "normales" Projekt extrahieren/exportieren. Da
suche ich allerdings noch, wie ich das geschmeidig in eclipse mit MCU
plugin importieren kann.
Hm. Ich frage mich, woher denn der Slave weiß, ob der Master richtig
konfiguriert ist. Schließlich wird aus Sicht des slaves sein CSN auf low
gezogen und es kommen 8 clocks (mit richiger CPOL und CPHA). Zumindest
hier müßte er doch dann noch korrekt sein Register STATUS ausgeben.
Um irgendwelche "Rückkopplungen" vom Master auf die MISO-Leitung
auszuschließen, habe ich die gerade mal getrennt und den LA direkt an
MISO des slaves gehängt. Er gibt 0x1C aus! Da komme ich gerade nicht
mit. Hat jemand eine Idee?
