|
Anzeige
|
stm32f411 USART2 will nicht wie er soll
Es sollen immer sieben Zeichen gesendet werden. Das erste Byte wird per isr angesprungen und richtig in den buffer geschrieben. Danach wird die isr nicht mehr ausgeführt. Im Debugger - langsam - funktioniert es alle 7 bytes durch (natürlich nicht mit einer Sendefolge). Was mache ich falsch?
Gast
#7789661
Warum schaltest du innerhalb der ISR den Receiver aus und wieder ein? Du hast zu viel Arbeit in die ISR gepackt. So verpasst du während der Ausgabe due nächsten Bytes. Die ISR sollte die empfangenen Daten nur in den Puffer schreiben. Deren Verarbeitung gehört außerhalb von ISR in die main loop.
Beitrag "Re: STM32F4xx UART-State während des Empfangs zurücksetzen"
Wenn das 7.byte empfangen ist ist das Empfangen beendet und die isr wird nicht mehr gebraucht. Zwecks Fehlersuche habe ich da die tft-Ausgabe eingebaut. fliegt wieder raus wenn das ganze funktionieren sollte. In meiner ISR sind 4 Takte - das ist sehr viel kürzer als das hal-Gedöns. Der code scheint prinzipiell auch zu funktionieren. Wenn ich mit dem avr sende, werden Zeichen - zum Teil richtig - angezeigt. Vielleicht ist das Ganze nur ein Timing-Problem. Kann mir jemand verraten, wo man bei Cube die Usart-Baudrate einstellt? Habe das im ioc nicht gefunden. Hal generiert
kann es ja irgendwie nicht sein?
So versteckt ist die Einstellung jetzt auch nicht....
Angehängte Dateien:
Doch, so geht das. Schau dir meinen Code mal an! Der funktioniert bei mir in vielen Projekten sehr zuverlässig:
Wenn du zweimal hintereinander USART2 initialisierst, solltest du dazwischen ein De_Init auslösen. Aber generell reicht tatsächlich ein einmaliges Init mit den richtigen Settings. Lass die ISR nur ein Flag setzen und steuere das LCD aus dem Hauptprogramm.
Ist beim U(S)ART mit HAL tatsächlich nicht erforderlich. Ein "beherztes Init" reicht in diesem Fall aus. Allerdings sollte das die Ausnahme sein. Im Normalfall stellt man die Parameter einmal im CubeMX ein, und kümmert sich nicht weiter darum. Die Geschwindigkeit oder das Frame-Format im laufenden Betrieb zu wechseln, dürfte ein eher exotisches Scenario sein...ist aber auch kein Hexenwerk.
trotzdem danke
danke - mach ich morgen 2 x 0xff vom PC gesendet. Das Osci erkennt 0x1f. Zeit zwischen Zwei steigenden Flanken 1,14ms. Müsste sein 1sec/9600/(1+8+1)=1,0416ms. Ich werde jetzt mal versuchen, die Zeit zwischen zwei Interrupts des stm zu messen. ist
für Abholen des Bytes und Rücksetzen auf Lesezustand ausreichend und richtig?
Angehängte Dateien:
Gast
#7789909
Du resettest den Receiver nach jedem einzelnen Byte während er das nächste Byte empfängt. Du verpasst bzw. verwirfst also jedes zweite Byte. Was du vermutlich machen wolltest: Erst NACH dem Empfang des siebten Bytes den Receiver disablen, dann dir 7 Bytes verarbeiten/anzeigen, und DANACH den Receiver wieder enablen.
Ist das so? RXNE wir ausgelöst zum Zeitpunkt "Anfang bis Mitte Stoppbit". Es ist dann zumindest Zeit bis zum nächsten Startbit. Ich habe leider vergeblich versucht herauszufinden, welche Register-Bits in den HAL-UART-Routinen gesetzt und geschrieben werden. Allein das Lesen von USART2->DR führt jedenfalls nicht dazu, dass DR für das Lesen des nächsten Bytes freigegeben wird.
Gast
#7790047
Ich habe auf die Schnelle keine Info gefunden, wie schnell der Receiver nach dem enablen empfangsbereit wird. Vielleicht dauert das länger, als bis zum Beginn des nächsten Start-Bit. Kannst du das Timing deines Test-Senders ändern, um dieses Deal zu erforschen?
Beim F1, F3 und L0 ist das aber ganz sicher so. Und im Referenzhandbuch vom F4 steht: "In single buffer mode, clearing the RXNE bit is performed by a software read to the USART_DR register. " Deine Versuche, HAL und direkte Registerzugriffe zu mischen ist einfach eine ganz schlechte Idee (so lange man nicht wirklich versteht, was man tut), und zudem vollkommen unnötig! RTFM ! https://oku.ozturkibrahim.com/docs_stm32f4/UM1725_User_manual_rev6.pdf
Gast
#7790065
Der HAL Code ist wirklich scheer zu durchschauen, vor allem für Anfänger. Ich denke, das ist ST durchaus bewusst. Für die F0 und L0 Modelle stellt die Firma immer noch reichlich Code-Beispiele mit direkten Register-Zugriffen bereit. Ich denke, diese Serien eignen sich besser, um sich mit STM32 vertraut zu machen.
Eigentlich alles. In der ISR schreibt man die Bytes nur in einen Puffer und mehr nicht. Das aber auch erst, wenn das Statusregister den Empfang anzeigt. Diese Abfrage fehlt.
Im 'Normalfall' braucht man CubeMX dafür garnicht ;-)
Gast
#7790076
Spätestens wenn der federführende Student wo anders einen besseren Job gefunden hat kommt das nächste inkompatible Framework. Mein Bauch sagt mir, dass es bald wieder so weit sein wird.
Sorry - wenn im Statusregister der Empfang angezeigt wird wird der Interrupt ausgelöst. Was soll ich da in der zugehörigen isr noch abfragen ob der Empfang erfolgt ist? In der ISR schreibt man die Bytes nur in einen Puffer und mehr nicht. Das macht ja wohl rx_buff[rx_buff_ct++]=USART2->DR; nur dann hört es mit dem Empfangen auf. Das Problem wurde hier Beitrag "Re: STM32F4xx UART-State während des Empfangs zurücksetzen" diskutiert und mit USART2->CR1 &= ~USART_CR1_RE; USART2->CR1 |= USART_CR1_RE;// gelöst. Mehr hab ich bei den ersten bytes nicht drin und kürzer ist kaum denkbar. Vergleich das mal mit den Hal-Usart-Abfragen. Es hat ja auch ein paar mal funktioniert. Das Problem ist m.E. das Timing des Senders. Das haut die STM-Fehlerabfragen zu und dann geht rx halt nicht mehr.
Ich versuche, das ohne Hal registernah zu programmieren. Dafür müsste ich nur wissen, wie man den Empfang nach auslesen von DR wieder freigibt.
Das Löschen des RXNE funktioniert auch - nur das DR-Register wird nicht geleert oder freigegeben.
Gast
#7790207
ja
OK, verstanden. Hast du inzwischen meinen Korrekturvorschlag ausprobiert?
Nein, da ging es um ein ganz anderes Problem. Dort sollte der Mikrocontroller nach einem einem Framing Fehler "den nächsten Low-Pegel wieder als Startbit (und nicht als x-tes Datenbit) erkennen". Bei dir geht es nicht um Framing Fehler, und vermutlich um ein engeres Timing.
Sorry, du hast noch sehr wenig Ahnung .... Wenn ein Interrupt ausgelöst wird ist das ein Signal dass sich etwas im Status verändert hat, und das ist nun mal nicht nur das Received-Bit welches sich ändern kann. Sorgfältigerweise muss man noch abfragen ob das richtige Bit gesetzt ist (hier RXNE) sonst greift man evtl. ins Leere.
Käse! Sobald du das RX Register gelesen hast ist es automatisch frei für den nächsten Empfang.
Brauchst du nicht, wie gerade vorher beschrieben.
Nein! Das Problem ist dass du viel zu viel Zeit in der ISR verschwendest. Es ist nicht egal wo man ein und dieselbe Aufgabe erledigt. Schaue dir um Gottes Willen endlich ein vernünftiges Beispiel an und lerne daraus, oder "Copiere und Paste" Teile daraus bevor du spekulierst (nicht verstehst) was mit den Registern passiert.
.... ist durchaus empfehlenswert! Eine Tücke ist das es beim Cortex-M mehrere Busse gibt und die Devices asynchron laufen, das ist nicht so einfach wie bei AVR.
Nur darum muß man sich hier garnicht kümmern, außer die passende Bustaktfrequenz für die Baudrateneinstellung zu verwenden.
Gut, dann hänge ich mal etwas an, was bei mir auf einem F407 läuft und USART3 verwendet. Das kann man ja auf USART2 ändern. Die Sende- und Empfangspuffer kann man jederzeit löschen. 'HAL'frei und vegan! ;-)
Danke, das war es wohl:
statt
läuft es mit
Gast
#7790539
Das glaube ich dir, aber welchen Sinn macht es, innerhalb der ISR diesen einen Interrupt zu deaktivieren und wieder aktivieren? Bei mir sehen die ISR ganz schlicht so aus:
Weitere Registerzugriffe finden dort nicht statt. Das vollständige Beispiel ist auf: http://stefanfrings.de/stm32/stm32f1.html#usart
bis
USART_CR1_RXNEIE ist vielleicht der Holzhammer - aber zumindest bei 9600 Baud wirkt er perfekt. Kürzer geht es nicht. Was spricht also gegen den Holzhammer?
Gast
#7790565
Ich weiß 100% sicher, dass man auf L0, F1 und F3 nichts extra freigeben muss. Wenn das beim F4 entgegen seinem Referenzhandbuch plötzlich anders ist, fresse ich einen Besen. Im Errata steht auch nichts dazu. Der Professor Laurent Latorre sieht das sieht vielen Jahren genau so: 2.2 Basic USART RX interrupt handler
Beim F411 muss auch nichts „freigegeben werden” – für einfache (Test)Zwecke reicht es aus, es so mit einer Zeile zu machen wie Du es vorhin geschrieben hast. Das Lesen des Datenregisters löscht das RXNE-Flag. Wenn man es besser machen will, dann sollte man die drei Haupt-Error-Flags (ORE, NF/NE und FE) überprüfen. Die Sequenz, diese zu löschen, ist etwas anders, aber auch nicht schwer: Statusregister lesen, danach Datenregister lesen und fertig – ist alles im Reference Manual beschrieben. Was hier mit dem F411 gemacht wird, gleicht einer Comedy.
Angehängte Dateien:
.... Troll-Comedy par Excellence. Hingeworfene, zusammenhang-lose Code-Fragmente und Unbelehrbarkeit, Beratungsresistenz (Hinweise werden gnadenlos ignoriert) zeigen wo es lang geht. Das TO- Verhalten kann eigentlich nur durch Dummheit und/oder Wahrnehmungs- störungen entschuldigt werden. Übrigens, wer zusätzlich den Sende-Interrupt aktiviert oder ihn abfragt, obwohl dieser deaktiviert ist, ist selber schuld und hat meistens seine Hausaufgaben nicht gemacht – diesen Interrupt braucht man normalerweise nicht, denn was man zu welchem Zeitpunkt sendet, weiß man ja in der Regel selbst – der Zeitpunkt des Empfangs ist dagegen unbekannt und muss daher per Interrupt abgefangen werden – das ist ja auch der Witz an der Geschichte. Durch den aktivierten Sendeinterrupt verschenkt man ferner auch unnötig Rechenzeit der CPU, denn die Interruptroutine wird bei jedem Senden (Überschreiben der Sendedaten in das Output-Schieberegister) immer sinnlos in voller Montur angesprungen – mit Prolog und Epilog – obwohl nichts angekommen ist. Vollführt man dann auch noch nur eine einzige Fließkommaberechnung in derselben, so werden auch diese Spezial-Register von der CPU real auf dem Stack gerettet und das dauert dann gleich 2-3x so lange als der übliche Prolog und Epilog. Ist nur der Interrupt für den Empfang aktiviert, muss man auch nicht immer stupide abfragen, was nun passiert ist, denn das ist dann völlig klar – im Empfangsbuffer ist etwas angekommen. Ob es verwertbar ist oder nicht, kann man dann anhand der Error-Flags entscheiden – das hat aber erstmal mit dem ersten Sachverhalt nichts zu tun, sondern ist nur eine zusätzliche Luxusaufgabe. Wer wirklich den Sendeinterrupt braucht und ihn deswegen explizit einschaltet, der wird in der Regel auch wissen, wie das mit dem Lesen und Löschen der Flags und dem Empfang von Daten vonstattengeht und dass man das vorab auch abzufragen braucht. Es gibt noch den TC-Interrupt – hier gilt eigentlich das gleiche – was nicht nötig ist, wird auch nicht aktiviert und braucht deswegen in der Interruptroutine auch nicht abgefragt zu werden. Ferner gibt es bei den STM32 noch gebündelte Interrupts – hier muss man dann ggfs. vorher die Instanz, von der der Interrupt kommt, abfragen. HAL, LL und selbstgeschriebene Registerzugriffe miteinander zu verbinden, ist eigentlich gar nicht so schwer – jedes Kind kann das, welches z.B. mit 6 Jahren angefangen hat, seine – ihm vom Schicksal vorher bestimmte – Geige zu spielen. Wer aber sehr fleißig mit dem Studieren der Datenblätter ist, schafft es auch mühelos im Laufe der Jahre trotz seines Alters. Aufholen wird er das Kind aber vermutlich nicht.
Dummheit muss man nicht entschuldigen. Es gibt halt nicht nur kluge sondern auch dumme Menschen. Ich muss al dummer Mensch Probleme bewältigen, die kluge Menschen vielleicht gar nicht erst haben.
if ((USART2->ISR & USART_ISR_RXNE) == USART_ISR_RXNE) { // RXNE flags automatically clears when reading RDR. // Store incoming byte console_rx_byte = USART2->RDR; console_rx_irq = 1; } Ist ein interessanter Ansatz: During an USART reception, data shifts in least significant bit first through the RX pin. In this mode, the USART_DR register consists of a buffer (RDR) between the internal bus and the received shift register. Der Professor greift statt des DR das RDR-Register ab. Das soll funktionieren? Muss man erst mal drauf kommen. Ich werde das ausprobieren. Es gibt hier verschiedene stm-Uart-threads wo zunächst was nicht ging - was eigentlich hätte gehen müssen - und dann auf einmal doch ging: STM-Mysterium.
Gast
#7790679
Wenn man ungepuffert sendet: ja Das ist aber eher Anfänger-Niveau. Selbst Arduino ist darüber hinweg.
Gast
#7790682
Weil das ein Beispiel für den STM32F072 ist, der hat kein DR Register (stattdessen RDR und TDR).
Die meisten AVRs haben für RX und TX getrennte Interruptvektoren und genau darum geht es – also am besten nochmal darüber nachsinnen. Besser noch – immer vor dem Schreiben diese Aufgabe sorgfältig mehrmals tätigen.
Gast
#7790701
Na und? Erstens diskutieren wir hier nicht über AVR, und zweitens hast du unabhängig davon geschrieben:
ausprobiert:
liest immer das erste Byte - und dann ist Schluss. Mag bei einem F0 funktionieren - bei meinem F4 nicht.
Was soll das? Einfach irgendwas hingerotzt ohne Zusammenhänge zu zeigen. Entweder bist du ein hartnäckiger Troll oder du musst noch sehr viel (vieeeeel) lernen. Fang am besten mal hier an (falls du kein Troll sein willst: Netiquette Besonders Punkt drei gilt es stark zu beherzigen. Aber eigentlich bist du zu lange hier angemeldet (mehr als 13 Jahre) um das nicht zu wissen. Also doch eher Troll(iges) Verhalten ..... Folgender auf ein Minimum reduzierter Code funktioniert mit einem STM32F411RET6 ohne Probleme:
Ich kann vom PC aus über ein Terminal sowohl einzelne Zeichen als auch lange Textpassagen versenden – alles kommt ordnungsgemäß zum Terminal zurück und es blockiert sich nichts, ich kann anschließend immer wieder erneut etwas schicken und bekomme es ordnungsgemäß zurück. Die Interruptroutine wird auch nicht fehlerhaft mehrfach ausgeführt, da das besagte RXNE-Flag durch das Lesen des Datenregisters gelöscht wird, so wie es im Datenblatt steht. Die USART-Verbindung läuft über ST-LINK-2V1 und dann über USB-Kabel zum PC – das Terminalprogramm ist HTerm, würde aber auch mit anderen, vergleichbaren Programmen funktionieren. Genommen wurde meine Standardbaudrate 115200, das F411-Board selbst stammt aus meinen Entwürfen, die ich offiziell verkaufe, mit einem F411RE-Nucleo wird es aber genauso funktionieren. Aktiviert ist in so einem Fall natürlich nur der Empfangsinterrupt.
daran hab ich keine Zweifel. Das ist so und das bleibt so.
Unsinn. STM32CubeMX ist mittlerweile ein ziemliches leistungsfähiger Konfigurator für so ziemlich alles geworden und wird immer weiter ausgebaut. Neue Features sind zwar anfangs manchmal etwas fehlerhaft (wie bei fast jeder Software), aber ein, zwei Versionen später recht brauchbar. Da es das Programm schon seit deutlich über zehn Jahre gibt, dürfte "der federführende Student" entweder schon längst bei ST fest angestellt sein, oder es steckt wohl mittlerweile längst ein ganzes Team dahinter.
Gast
#7791066
Sage das keinem Bauch :-) Spaß beiseite: Ich würde mich natürlich freuen, wenn das noch lange weiter gepflegt wird.
Das glaube ich dir. Ich habe nur einen STM32F411CEU6 - mit dem funktioniert das fortlaufende Lesen nur mittels Auslesen von USART2->DR; nicht. Das habe ich jetzt genügend getestet. Ich verstehe den hier teilweise auftretenden Unmut, weil es wohl eigentlich funktionieren müsste. Das hilft mir mit meinem speziellen CEU6 nicht weiter. Ihr erklärt mir, wie es normalerweise laufen müsste. Ich probiere es aus und es geht nicht und frage nach wie es funktionieren soll weil die Erklärungen zum normalen Verlauf nicht zum erwarteten Ergebnis führen. Wir reden aneinander vorbei. Liegt vielleicht an dem speziellen chip. Kommt bei stm wohl schon mal vor.
Gast
#7791103
Da im Errata nichts dazu steht, würde ich dazu mal ein minimales Testprogramm erstellen und ST zur Analyse schicken. Vielleicht wird dann das Errata aktualisiert.
Es ist sehr unwahrscheinlich, dass es am Chip liegt, den Fehler solltest Du in erster Linie bei Dir selbst suchen, das ist zu 99% immer so – Code, Aufbau, Design, Testmethode etc. So speziell ist der CEU6 außerdem auch wieder nicht wie man von außen denken könnte – hier ist das Siliziumplättchen vermutlich einfach nur in einem anderen Gehäuse mit weniger Bonding eingekapselt, aber wenn Du Zweifel daran hast, kannst Du Dich mit diesem Anliegen direkt an STM wenden. Viel wichtiger ist außerdem die Revisionsnummer des Chips, aber als ich meine Boards entwickelt habe, habe ich damals nichts Besorgniserregendes zu den F411 und F446 in den Erratas gefunden – die üblichen Fehler halt, die sich in den Kernen von Familie zu Familie wiederholen. Beim STM32F303CCT6 war das z.B. anders – hier ist es wichtig, die richtige Revision beim Kauf erwischt zu haben. Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
