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...
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.
Gast
#6448921
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.
Gast
#6448933
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
So ein Blödsinn! dafür braucht man kein LL uns schon gar kein DMA!
Gast
#6448961
Harry L. schrieb: > So ein Blödsinn! Schönes anschauliches Beispiel, hast du gut gemacht!
Gast
#6449502
> 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
Gast
#6449644
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.
Gast
#6449675
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.
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.
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.
Gast
#6449826
> 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