Forum: Mikrocontroller und Digitale Elektronik STM32L0 LL Library einbinden


von Walt N. (belayason)


Lesenswert?

Hallo,
ich habe mit Hilfe CubeMX einen USART Code für meinen STM32L058 
generieren lassen. Die UART Transmit funktioniert, doch schon bei der 
HAL Interrupt receive Funktion scheitert es die Antwort meiner 
Peripherie zu empfangen. Da die Antwort bei jedem Befehl den ich sende 
unterschiedlich lang ist, habe ich versucht die Antwort im IT Handler 
Byte für Byte in einen Buffer zu speichern. Dabei gehen aber 
informationen verloren.... Ich habe gelesen das die HAL genau für diese 
Funktion ( und allgemein... ) sehr ungünstig und langsam ist. Daher 
wollte ich mich nun in die LL Ebene einarbeiten und dieses UART Projekt 
dafür nutzen. Die LL-Lib habe ich mir auf Github runtergeladen und die 
src & inc Dateien der LL Treiber bei mir im Projekt eingefügt. Ich 
dachte mir ich füge in meiner main.h genau wie für die HAL lib ein 
#include "stm32l0xx_hal.h" hinzu, eben nur für die LL Treiber. Das 
scheint aber nicht der Fall zu sein. Welche Schritte fehlen mir noch die 
LL Treiber zu benutzen? CubeMX hat diese leider nicht automatisch 
hinzugefügt...

von Ben S. (bensch123)


Lesenswert?

Walt N. schrieb:
> Ich habe gelesen das die HAL genau für diese
> Funktion ( und allgemein... ) sehr ungünstig und langsam ist.

Zur LL kann ich nichts sagen, da ich nur ganz tief auf Registerebene mit 
CMSIS arbeite. Aber in deinem Fall würde ich spontan nach dem was ich 
lese DMA vorschlagen und mich gar nicht mit groß mit Interrupts 
auseinandersetzen.

von Stefan F. (Gast)


Lesenswert?

Da haben wir wieder das altbekannte Problem mit USART und HAL - 
sozusagen "der" Klassiker. Da hat schon über 1000 Seiten Dokumentation 
zusätzlich zum Datenblatt und Referenzhandbuch, aber wie man die HAL 
richtig benutzt, steht das letztendlich nicht drin. Ich finde das 
schade.

Der Ansatz mit DMA ist wohl in diesem Fall der beste.

von Johannes S. (Gast)


Lesenswert?

Dafür gibt es zig Beispiele für die verschiedenen Serien, für L0 z.B.
https://github.com/STMicroelectronics/STM32CubeL0
und dann z.B. weiter nach Projects/target/Examples

Walt N. schrieb:
> Ich
> dachte mir ich füge in meiner main.h genau wie für die HAL lib ein
> #include "stm32l0xx_hal.h" hinzu, eben nur für die LL Treiber. Das
> scheint aber nicht der Fall zu sein. Welche Schritte fehlen mir noch die
> LL Treiber zu benutzen?

https://github.com/STMicroelectronics/STM32CubeL0/blob/master/Projects/NUCLEO-L053R8/Templates_LL/Inc/main.h

von Harry L. (mysth)


Angehängte Dateien:

Lesenswert?

So ein Blödsinn!
dafür braucht man kein LL uns schon gar kein DMA!

von Stefan F. (Gast)


Lesenswert?

Harry L. schrieb:
> So ein Blödsinn!

Schönes anschauliches Beispiel, hast du gut gemacht!

von Olaf (Gast)


Lesenswert?

> Der Ansatz mit DMA ist wohl in diesem Fall der beste.

Ach komm, um ein paar Bytes ueber eine serielle Schnittstelle zu 
empfangen?

Das Problem ist doch hier wieder das jemand der keine Ahnung hat glaubt 
weiterhin bloed bleiben zu koennen indem er fertige Libaries nutzt.
Und wenn man das nicht geht dann eine andere Libarie und wenn die nicht 
geht wieder eine andere. Und am Schluss kommt weiterhin nur gequierlte 
Kacke raus weil die neue Libarie mit den fuenf anderen zusammengeklauten 
in dem Projekt nicht zusammenpasst.

Olaf

von Stefan F. (Gast)


Lesenswert?

Olaf schrieb:
> Ach komm, um ein paar Bytes ueber eine serielle Schnittstelle zu
> empfangen?

Bei der HAL schon, sonst hat man zumindest gefühlt einen gewaltigen 
Overhead im Code. Guck dir nur mal Harrys Beispiel an. Ich wüsste jetzt 
nicht, wie man das mit der HAL eleganter lösen könnte. Aber wenn ich die 
Anzahl von Code-Zeilen (insbesondere in den Call-Back Funktionen) zähle, 
fühle ich mich damit nicht wohl.

Ich bin ja eh kein Fan der HAL, aber was die serielle Kommunikation 
angeht, die würde ich wohl meistens anders implementieren.

von Johannes S. (Gast)


Lesenswert?

Stefan ⛄ F. schrieb:
> Aber wenn ich die
> Anzahl von Code-Zeilen (insbesondere in den Call-Back Funktionen) zähle,
> fühle ich mich damit nicht wohl.

Und die Zeilen werden alle durchlaufen? Vielleicht mal mit dem Debugger 
kontrollieren. Da werden nur die möglichen Interruptauslöser abgefragt 
und da gibt es viele. Es gibt viel Code der sowas nicht berücksichtigt. 
Der funktioniert dann nur solange nichts unvorhergesehenes passiert, und 
das ist schlechter Code.

von Thorsten S. (thosch)


Lesenswert?

Genau, der Code von Harry funktioniert bis zum ersten Störimpuls auf der 
Rx-Leitung, der z.B. einen Framing-Error verursacht.

Dann wird nicht der RxCplt Callback aufgerufen, sondern der RxError 
Callback. Da Harry aber nur in ersterem den Empfang wieder 
scharfschaltet, stoppt der Empfang bei jedem Fehler.

von Harry L. (mysth)


Lesenswert?

Thorsten S. schrieb:
> Genau, der Code von Harry funktioniert bis zum ersten Störimpuls auf der
> Rx-Leitung, der z.B. einen Framing-Error verursacht.

Dann zeig mir mal ein proof-of-concept wie du bei asynchroner serieller 
Übertragung mit einem UART einen Framingerror prduzierst.

von Olaf (Gast)


Lesenswert?

> Bei der HAL schon, sonst hat man zumindest gefühlt einen gewaltigen
> Overhead im Code. Guck dir nur mal Harrys Beispiel an.

Das steht vollkommen ausser Frage. Es ist immer besser den ganzen Kram 
nicht zu benutzen gerade und vor allem als Anfaenger der noch was lernen 
will.

Aber trotzdem sollte sowas banales moeglich sein.

Und hier haben wir dann gleich den naechsten Punkt. Wenn etwas nicht 
geht dann sollte man sich ja mal seinen Code anschauen und verstehen 
warum es nicht geht. Und das ist natuerlich mit irgendwelche krassen 
Libaries die fuer drei Dutzend Prozessoren designt sind deutlich 
komplizierter als fuer drei Seiten selbstgeschriebenen Code. .-)

Olaf

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
Noch kein Account? Hier anmelden.