Hallo! Der Titel klingt vermutlich spannender als es eigentlich ist ;-) Ich habe zwei µCs die über USART Kommunizieren. Der eine sendet, der andere empfängt und stellt die Bytes auf einem Display dar. Gesendet wird: 0 1 2 3 4 5 127 128 255 (zyklisch, im Sekundentakt). Empfangen wird: 0 2 12 14 16 18 0 254 254 Ich sehe zwar, dass da ein Muster hinter steckt, aber ich komm nicht drauf was da genau los ist... kann vielleicht jemand den Zusammenhang zwischen gesendeten und empfangenen Bytes erkennen? Daraus könne ich dann rückschließen, wo der Fehler im Code steckt... Danke! :-)
Den USART Code anhängen wäre klüger. Benutzt du den synchronen oder asynchronen Modus? Glaskugel kaputt.
Jens schrieb: > Ich sehe zwar, dass da ein Muster hinter steckt, aber ich komm nicht > drauf was da genau los ist... kann vielleicht jemand den Zusammenhang > zwischen gesendeten und empfangenen Bytes erkennen? Ein Muster, das bei auch nur grössenordnungsmässig passender Baudrate aus gesendetem 127 den empfangenen Wert 0 macht, das möchte ich mal sehen. S01234567E S=Startbit, E=Stopbit 0 => 100000000011 127 => 101111111011 bei 127 ist maximal eine Bitposition auf 0, bei 0 sind es gleich 9. Ansonsten wäre es sinnvoll, die empfangenen Werte den gesendeten direkt gegenüber zu stellen, falls 0/127 nicht zusammen gehören.
Apropos Info: Die verwendete Hardware darzustellen wäre auch nicht falsch. Also alles zwischen UART-Pin raus und UART-Pin rein.
OK, also ein paar Details :-) Ich benutze einen STM32103 und einen ATMEGA8 als µCs. Beide laufen im asynchronen Modus. (Die gesendeten und empfangenen Werte habe ich schon direkt gegenübergestellt, da ich die auch alle einzeln ausprobiert habe).
Bischen genauer geht's nicht? TTL? ECL? RS232? RS485? 2500m Kabel?
Ähhh, sorry, ich kann dir nicht mehr folgen :-( Ich bin noch ziemlich neu in dem ganzen Thema... Das Kabel ist ca. 20cm lang, was die anderen Sachen bedeuten weiß ich nicht mal...
Jens schrieb: > Das Kabel ist ca. 20cm lang, was die anderen Sachen bedeuten weiß ich > nicht mal... Das ist doch schonmal was, du weisst also, was ein Kabel ist. ;-) Ich habe aber doch die Hoffnung, dass du nicht einfach einen STM32 und einen AVR Beine nach oben auf den Tisch gelegt und per Lötkolben verbunden hast. Sondern irgendwas anderes gemacht hast. Wahscheinlich auch keinen der beiden Controller direkt als Chip eingelötet hast. Als wär's wohl an der Zeit, etwas mehr über das zu verraten, was da vor die auf dem Tisch liegt. Welche Karten/Module, welche Stecker davon du verbunden hast usw. Das müsste sich doch machen lassen, oder?
Jens schrieb: > Daraus könne ich dann rückschließen, wo der Fehler im Code steckt... Poste doch einfach mal den Code, evtl. findet sich ja so viel schneller der Fehler ;)
:-D OK, das geht. Linke Seite: STM32 Primer von Raisonance (im Prinzip ein Gameboy für Bastler) ;-) Da habe ich an GND und UART2 Rx und Tx ein 3-Adriges Kabel drangelötet. Als Software benutze ich Stück Code von stm32circle.com, welches laut Forumsangaben funktionieren soll (über USART2 empfangen, Bytes auf Display schreiben). Rechte Seite: Eine AVR-Minimalschaltung: ATMEGA8, mit dem 3-Adrigen Kabel von der linken Seite verbunden (GND, RX, TX). Als Software auch hier Code aus dem Internet (Initialisiert den UART, sendet dann fröhlich Bytes). Beide laufen auf 3,3V Versorgungsspannung. Beobachtetes Verhalten: Ich sende im Abstand von einer Sekunde abwechselnd eine 0 und eine 1 vom AVR aus. Der STM empfängt (und zeigt auf dem Display) 0 und 2 (wie zu erwarten im Abstand von einer Sekunde). Beim senden von anderen Werten kommen auch komische Dinge an (siehe erstes Posting). Hilft das weiter?
für den Anfang ok, wäre trotzdem nett wenn du als anhang den code senden könntest.
Jens schrieb: > Eine AVR-Minimalschaltung: ATMEGA8, mit dem 3-Adrigen Kabel von der > linken Seite verbunden (GND, RX, TX). Als Software auch hier Code aus > dem Internet (Initialisiert den UART, sendet dann fröhlich Bytes). Quarz? Baudrate?
Jens schrieb: > Ich sehe zwar, dass da ein Muster hinter steckt, ... Hmmm, das sehe ich eigentlich nicht ;-).
USART ist wie folgt konfiguriert: 1 Parität, kein Stoppbit und 9600 Baudrate Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert, beim STM32 weiß ich's ehrlich gesagt nicht (72 Mhz?). Das Muster sehe ich da: 2 -> 12 3 -> 14 4 -> 16 5 -> 18 Oder bilde ich mir das ein? ^;-) Den Code werde ich heut Abend mal zurechtstutzen und dann hier reinstellen. Danke für eure Hilfe :-)
> Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert
Vielleicht(tm) liegt der einfach weit genug daneben. Häng doch testweise
mal einen Quarz aus der Grabbelkiste dran.
Jens schrieb: > Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert Nunja, das könnte schon das Problem sein. Von der Genaugikeit her ist der nicht soos gut wie ein externes Quarz und daher auch eher suboptimal für eine UART-Verbindung. Jens schrieb: > 1 Parität, kein Stoppbit und 9600 Baudrate Und die Einstellungen haben ganz sicher BEIDE Controller?
Jens schrieb: > Gesendet wird: > > 0 = 0000 0000 (1) > 1 = 0000 0001 (2) > 2 = 0000 0010 (3) > 3 = 0000 0011 (4) > 4 = 0000 0100 (5) > 5 = 0000 0101 (6) > 127 = 0111 1111 (7) > 128 = 1000 0000 (8) > 255 = 1111 1111 (9) > > (zyklisch, im Sekundentakt). > Empfangen wird: > > 0 = 0000 0000 (1) > 2 = 0000 0010 (2) > 12 = 0000 1100 (3) > 14 = 0000 1110 (4) > 16 = 0001 0000 (5) > 18 = 0001 0010 (6) > 0 = 0000 0000 (7) > 254 = 1111 1110 (8) > 254 = 1111 1110 (9) Ich hab mal den Kram binär dargestellt und durchnummeriert. Bei (1) bis (4) sowie bei (6) und (9) sieht es immer so aus, dass die Taktraten voneinander abweichen. Folge davon ist, dass einzelne Bits verschoben erscheinen bzw. mehrere Bits an falscher stelle erkannt werden oder eben ein bit als zwei eingelesen wird. mfg mf
Jens schrieb: > Das Muster sehe ich da: > 2 -> 12 > 3 -> 14 > 4 -> 16 > 5 -> 18 > Oder bilde ich mir das ein? ^;-) Nana, das ist noch kein "Nash"- Syndrom ;-). Jedoch sollte ein Signal einem Muster folgen, bevor jenes als solches erkannt wird. Und das ist hier (bis auf die Daten von dir gerade) nicht der Fall. > ... Bits an falscher stelle erkannt werden oder eben ein bit als zwei ... Das "ODER" ist das Problem einer konkreten Aussage ;-). Ich denke auch, Du hast ein SYNC Problem. Iteriere mal die Baudraten durch und schau, ob das "Muster" wieder auftaucht.
Oliver Punk schrieb: > Ich denke auch, Du hast ein SYNC Problem. Iteriere mal die Baudraten > durch und schau, ob das "Muster" wieder auftaucht. Oben schreibt er, dass jede Sekunde ein Byte gesendet wird. Das schliesst ein Sync-Problem aus. Und das Paar 127/0 schliess auch ein Baudratenproblem aus, denn um aus 127 ein 0 zu machen muss der Empfänger die 9fache Baudrate haben (denkbar bei Mega8 mit 1MHz bei gedachten 8MHz) - was bei anderen Werten zu mehreren empfangenen Bytes würde. Da wird also weder links noch rechts ein Schuh draus. Vorausgesetzt er hat nicht die Hälfte weggelassen um uns nicht zu verwirren ;-).
Jens schrieb: > Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert Welchen internen Quarz? Der hat keinen internen Quarz sondern einen RC-Oszillator. (Komisch, das sich nach Jahren immer noch das Gerücht hält, die AVRs hätten interne Quarze). Der RC-Oszillator ist dafür bekannt deutliche Abweichungen von der Sollfrequenz zu haben. Nimm wirklich einen Quarz. Dann haut's hin.
Grrrr schrieb: > Jens schrieb: >> Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert > > Welchen internen Quarz? Der hat keinen internen Quarz sondern einen > RC-Oszillator. (Komisch, das sich nach Jahren immer noch das Gerücht > hält, die AVRs hätten interne Quarze). Ruhig Blut! Also ich lese da was von einem 8MHz Oszi(llator). Gruß, Magnetus
Grrrr schrieb: >> Der ATMEGA8 hat den internen 8Mhz Oszi aktiviert > > Welchen internen Quarz? Super Beispiel für selektive Wahrnehmung.
>> ... Bits an falscher stelle erkannt werden oder eben ein bit als zwei ... >Das "ODER" ist das Problem einer konkreten Aussage ;-). ich sehe wir verstehen uns :D mfg mf
Hier schon mal der Code vom STM32 (Empfänger):
1 | USART_InitTypeDef USART_InitStructure; |
2 | USART_ClockInitTypeDef USART_ClockInitStructure; |
3 | /* USART configuration ------------------------------------------------------*/
|
4 | |
5 | USART_InitStructure.USART_BaudRate = 9600; |
6 | USART_InitStructure.USART_WordLength = USART_WordLength_8b; |
7 | USART_InitStructure.USART_StopBits = USART_StopBits_1; |
8 | USART_InitStructure.USART_Parity = USART_Parity_No ; |
9 | USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; |
10 | USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; |
11 | USART_Init(USART2, &USART_InitStructure); |
12 | |
13 | |
14 | /* Configure USART2 */
|
15 | USART_Init(USART2, &USART_InitStructure); |
16 | |
17 | /* Enable USART2 Receive and Transmit interrupts */
|
18 | USART_ITConfig(USART2, USART_IT_RXNE, ENABLE); |
19 | USART_ITConfig(USART2, USART_IT_TXE, ENABLE); |
20 | |
21 | /* Enable the USART2 */
|
22 | USART_Cmd(USART2, ENABLE); |
Julian W. schrieb: > Jens schrieb: >> 1 Parität, kein Stoppbit und 9600 Baudrate > > Und die Einstellungen haben ganz sicher BEIDE Controller? "Kein Stoppbit" gibt's nicht ! Eins, anderthalb oder zwei geht. "1 Parität" ist garkeine Aussage. Welche Parität wäre da interessanter. Interne Quarze haben im wesentlichen nur RTC-ICs. "8MHz Oscillator" gibt keinen Hinweis darauf wie der Takt erzeugt wird, kann RC, ring-osc oder sonstwas sein, bei intern jedoch eher nicht mit Quarz ! Nur mit einem Quarzoscillator, ersatzweise einem Resonator, sind ausreichende Genauigkeiten für eine serielle Übertragung möglich. Aussagen wie " beim STM32 weiß ich's ehrlich gesagt nicht (72 Mhz?)." beängstigen mich. Hier ist offensichtlich bereits bei der Takterzeugung und Baudratengenerierung ein Verständnisproblem. Dieses gilt es zu lösen. Dann können wir uns mal die Hardware anschauen. Also bitte, zum wiederholten Male, Kode und Schaltplan, bitte. Bitte !
Ja entschuldige, das ist ein Dreher. Ich meinte 1 Stoppbit, KEIN Paritätsbit. Wegen der Genauigkeit: dann würden aber doch immer andere Dinge ankommen, oder? Die übertragenen Daten sind aber immer zuverlässig gleich... Wegen dem STM32: Da gehe ich einfach mal davon aus, dass das so funktioniert wie's verkauft wird. Ist ja alles schon vorkonfiguriert und scheint auch bei anderen Leuten zu klappen (Der Primer 2 ist ja quasi komplett vorkonfiguriert). Den COde des AVR werde ich morgen nachreichen, meine Freundin wird langsam sauer (ganzen Sonntag vor der Kiste verbracht) ;-) Gruß, Jens
Jens schrieb: > ankommen, oder? Die übertragenen Daten sind aber immer zuverlässig > gleich... Der interne Oszillator hat halt zuverlässig 7,9 MHz statt 8 MHz. http://www.mikrocontroller.net/articles/AVR-Tutorial:_UART Wichtiger Hinweis 2 :-)
Kann es sein, dass bei den empfangenen Bytes das zweit- und das drittletzte vertauscht sind? Wenn die richtige Reihenfolge so ist 0 2 12 14 16 18 254 0 254 dann wäre ein Baudratenfehler tatsächlich ein Erklärung. Und zwar ist die Baudrate des Empfängers um den Faktor 1,5 bis 1,625 höher als die des Senders. Dieser große Unterschied lässt sich nicht alleine mit den Toleranzen des RC-Oszillators des ATmega8 erklären, da ist irgendwo noch ein Denkfehler. Zuerst solltest du dir im Klaren sein, mit welcher Taktfrequenz die beiden Controller tatsächlich laufen. Dann musst du wissen, auf welche Taktfrequenz die Software der beiden Controller konfiguriert ist. Bspw. kann dieser Aufruf
1 | USART_Init(USART2, &USART_InitStructure); |
die Baudrate nur dann richtig setzen, wenn die aufgerufene Funktion weiß, wie schnell der STM32 läuft. Geht sie von falschen Annahmen aus, kann die Baudrate nicht stimmen. Beim ATmega8 verhält es sich ähnlich. Falls du ein Oszi hast, kannst du die tatsächliche Baudrate der beiden Controller auch messen.
@Jens Da hatten sich unsere Posts überschnitten. Ach und Du benutzt Primer2. Da gab's schon haufenweise Problem mit der Baudrate. http://www.stm32circle.com/forum/viewtopic.php?id=962 Ich hab' nicht den ganzen Thread gelesen, aber im Prinzip geht es um die Einstellung der Systemtaktrate, die von Quarz und PLL abhängig ist. Da scheinen einige Libs nicht ganz sauber zusammenzuspielen.
Ich weiss noch was schrieb: > Da gab's schon haufenweise Problem mit der Baudrate. > http://www.stm32circle.com/forum/viewtopic.php?id=962 Da steht geschrieben: "My baudrate is 1.5 times faster as it should be." Das deckt sich ja genau mit dem in meinem letzten Beitrag ermittelten Faktor von 1,5 bis 1,625. Also lohnt es sich wohl, den zitierten Thread zu Ende zu lesen. Ich selbst hab's nicht getan, aber der Threadstarter scheint am Schluss glücklich gewesen zu sein :)
PS: Wegen oben dem Thema "Muster": Ja da ist eins Zitat: > 2 -> 12 +10 > 3 -> 14 +11 > 4 -> 16 +12 > 5 -> 18 +13 Hat vielleicht nichts damit zu tun, wollte es nur erwähnen.
uart mit internem rc geht ja wohl gar nicht... quraz ran problem gelöst...
Thread beobachten
Seitenaufteilung abschaltenBitte 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.