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