Liebe Leute, ich versuche mich an einer Motorsteuerung, bestehend u.a aus einem avr m328pb und einem SBC, derzeit ein rpi02W. Sie sollen über uart miteinander kommunizieren: Status und Kommandos sind in beide Richtungen austauschen, zudem sollen vom avr debug - Meldungen zum rpi versendet werden. Das ganze muss recht fix passieren, darum habe ich als baudrate > 300000 anvisiert. Der avr sitzt auf einer Platine die auch den SBC huckepack über die 40poligen Pfostenleiste hält. Die Stromversorgung des SBC erfolgt mittels eines 5V - Abwärtsregler. Der avr wird mit den 3V3 des rpi gespeist. Seine Peripherie besteht nur aus zwei Tastern und zwei LED. Das Problem ist nun: Betreibe ich den avr mit dem 14.7456 MHz - Quarz, so ist die höchstmögliche Baudrate für zuverlässige Übertragung 115200. Bei >= 234000 ist die Fehlerrate extrem hoch, es kippt regelmäßig nach ca 12 kB erfolgreicher Übertragung ein bit. Keine Aussetzer gibt es jedoch wenn der avr mit dem internen RC - Oszillator betrieben wird. Mit dem kann ich mit 500000 baud fehlerfrei mehrere Megabytes hin und her schieben. Derzeit habe ich kein Scope zur Hand und ich bin ratlos. Hat jemand so was schon mal gehabt? Schönen Gruß, H.
Harald schrieb: > Der avr wird mit den 3V3 des rpi gespeist. Harald schrieb: > Betreibe ich den avr mit dem 14.7456 MHz - Quarz Datenblatt Auszug: 0 - 20MHz @ 4.5 - 5.5V Harald schrieb: > Bei >= 234000 ist die Fehlerrate extrem hoch http://www.gjlay.de/helferlein/avr-uart-rechner.html Deine Zahlen kurz eingesetzt kommen da teilweise 8% Fehler raus. Harald schrieb: > Keine Aussetzer gibt es jedoch wenn der avr mit dem internen RC - > Oszillator betrieben wird. Mit dem kann ich mit 500000 baud fehlerfrei > mehrere Megabytes hin und her schieben. Vermutlich Glückssache. Verändere Mal die Versorgungsspannung oder Fön in mal auf 60°C.
Angehängte Dateien:
-
Screenshot.png
110 KB
Mit 14,7456MHz und 3,3V betreibst du den AVR schon mal außerhalb der Spezifikationen... Speed Grade: – 0 - 4 MHz @ 1.8 - 5.5V – 0 - 10 MHz @ 2.7 - 5.5V – 0 - 20 MHz @ 4.5 - 5.5V Abgesehen davon hilft ein Blick ins DB Bei einer Baud Rate von 0.5M und 8MHz hast du 0% Fehler Bei einer Baud Rate von 0.5M und 14.7456MHz hast du 7,80% Fehler Also alles ganz normal...
Probiere 921.6K Mit normalem 16mhz Quarz sind 2mb möglich, internem osc 1mb. Rpi geht bis 4mbit.
Peter Z. schrieb: > Bei einer Baud Rate von 0.5M und 8MHz hast du 0% Fehler > Bei einer Baud Rate von 0.5M und 14.7456MHz hast du 7,80% Fehler Genau! Zusätzlich sollte man die Abweichung auf beiden Seiten betrachten. Die nominelle Baudrate ist ziemlich wurst, wichtig ist, dass die tatsächliche Baudrate zwischen beiden Seiten zusammenpasst wenn unterschiedliche Chips mit unterschiedlichen Formeln und Quarzen verwendet werden. Ich hatte das mal hier beschrieben: https://github.com/nospam2000/ch341-baudrate-calculation?tab=readme-ov-file#problem-b-the-calculated-baudrate-is-now-nearer-to-nominal-rate-but-farer-from-the-baud-rate-of-communication-partner Michael
Sorry, ich habe unklar geschrieben. Die Baudratenfehler sind immer 0, da ich mit Quarz 115200, 230400 und auch 921600 probiert habe. Nur mit 115200 klappt's mit Quarz fehlerfrei. Die 500000 funktionieren mit 8 MHz Takt aus dem internen RC - Oszillator. Allerdings: Ein Blick ins richtige Datenblatt zeigt tasächlich dass 3.3V maximal für 13 MHz erlaubt sind... Wie man sich doch täuschen kann. Ich werde auf 11 MHz runtergehen und 460800 baud probieren. Danke für euere Aufmerksamkeit!
Hi >Die 500000 funktionieren mit 8 MHz Takt aus dem internen RC - >Oszillator. Dann ändere mal mit Kältespray/Heißluft die Temperatur des Atmega. MfG Spess
Chris S. schrieb: > Probiere 921.6K > Mit normalem 16mhz Quarz sind 2mb möglich, internem osc 1mb. > Rpi geht bis 4mbit. Millibit wären kein Problem - alles eine Frage der Zeit, Darum geht es hier aber nicht. Quarzfrequenzen liegen eher einen Faktor 10^9 über dem von dir angegebenen Wert. In deinem Beitrag offenbaren sich eklatante Defizite bei dem Umgang mit Maßeinheiten und ihren Vielfachen. https://de.wikipedia.org/wiki/Vors%C3%A4tze_f%C3%BCr_Ma%C3%9Feinheiten
:
Bearbeitet durch User
> Derzeit habe ich kein Scope zur Hand und ich bin ratlos.
Verwende entweder Controller die einen fraktionalen Teiler
haben, oder aber achte darauf Bitclocks zu verwenden die
man aus dem Quarz auch runterteilen kann.
Und ja, es schadet wirklich nichts bei den ersten Bytes
mal ein Oszi zur Hand zu haben. .-)
Was mich aber wundert, wenn man sowas programmiert und sich
die Registerwerte ausrechnet, dann sollte man das eigentlich
merken. Wenn man faul ist und nur anderer Leute Libaries verwendet
dann sollte man Rueckgabewerte abfragen. Wenn eine Libarie solche
grobfalschen Werte setzt ohne einen Fehler zurueckzumelden oder
man zu faul ist sowas in seinem Programm abzufragen dann sollte
man daraus auch etwas lernen...
Vanye
Harald schrieb: > Ich werde auf 11 MHz runtergehen und 460800 baud probieren. Genauer: 11,059200MHz Siehe auch: http://www.hanneslux.de/avr/tipps/baudratenquarz.html
:
Bearbeitet durch Moderator
14.7456 MHz ist ein Quarz für die serielle Schnittstelle mit Vielfachen/Teilern von 115.2kBaud. Wenn Du mehr willst, nimm 115.2kBaud * 2 (230.4), *4 (460.8) oder * 8 (921.6)
Eventuell schwingt der Quarz nicht stabil. Das kann an den angeschlossenen Kondensatoren oder sonstigen Leitungskapazitäten liegen. Kommt auch vor, wenn man den Abblock-Kondensator an der Stromversorgung weg lässt.
Bruno V. schrieb: > Wenn Du mehr willst, nimm 115.2kBaud * 2 (230.4), *4 (460.8) oder * 8 > (921.6) So weit war er doch schon. Du bist nicht der Einzige, der das überlesen hat. Die rein rechnerische Abweichung von der Baudrate durch den Takt-Teiler ist nicht sein Problem. Das muss noch etwas anderes im Argen sein. Ich glaube auch nicht, dass die geringe Versorgungsspannung hier der Knackpunkt ist. Denn genau diese Kombination (3,3 Volt und 14.7456 MHz) habe ich schon öfters bei meinen Basteleien angewendet. Hat bisher noch nie Probleme gemacht.
:
Bearbeitet durch User
Harald schrieb: > Derzeit habe ich kein Scope zur Hand und ich bin ratlos. Aber du kannst ein Foto vom Aufbau machen und uns mitteilen, welchen Quarz und welche Kondensatoren du an der Stelle verwendet hast.
Warum muss man für zwei Taster und zwei LEDs einen Coprozessor mit komplizierter anfälliger Ansteuerung implementieren? Keine weiteren 2 IOs mehr über am RPi?
Monk schrieb: > Die rein rechnerische Abweichung von der Baudrate durch den Takt-Teiler > ist nicht sein Problem. Das muss noch etwas anderes im Argen sein. Wo hat er denn von der Gegenstelle geschrieben? Wenn es mit 500k klappt, dann auch mit 230.4. Es gibt 2 typische Fehlermöglichkeiten: * Die Gegenstelle hat keinen Sio-Quartz * in einer der beiden Seiten hat sich ein off-by one-Fehler eingeschlichen. Ich würde auf off-by one tippen. Teilerregister 16 statt 15.
Upload von Dateien scheint grad nicht zu klappen: An internal Error has occured. If this problem persists, please contact the administrator of this website (webmaster@embdev.net). Ein interner Fehler ist aufgetreten. Falls dieses Problem erneut auftritt, wende dich bitte an den Administrator (webmaster@mikrocontroller.net).
:
Bearbeitet durch User
Jetzt klappt's wieder. Der problemlos funktionierende Vorläufer dieser Schaltung ist übrigens in brutalst möglicher dead bug construction gebaut. Nix mit möglichst kleinen Blockkondensatoren maximal 2.54mm vom UC entfernt und so.
Ich frage nochmal: Welchen Quarz verwendest du? Die genaue Modellnummer bitte.
Verluste an mehreren Stellen. Mein Text zu den pdf ist auch verloren gegangen. Er war in etwa so: Softwareseitig gibt's keinen Grund zum Zweifeln. Avr und rpi sprechen die gleiche Sprache. Die rechnerische Fehlerrate ist immer 0. Die Kommunikation klappt bei niedrigen Baudraten. Über 115200 stottert der avr bei Quarzbetrieb. Der wackelige RC - Takt jedoch schafft 500k ohne Probleme. Ich habe einige Quarze bestellt um zurück in den spezifizierten Bereich zu kommen. Ich glaube auch nicht dass 1.3MHz Übertaktung schlimm sind, aber man weiß ja nie. Beim Lesen des DBs fällt auf dass der 328pb nicht mehr den "full swing oscillator" hat. Es ist nur noch die störanfällige low power - Variante vorhanden. Nun ist der rpi räumlich nicht weit vom avr entfernt. Da er headless betrieben wird ist sein wifi ist immer eingeschaltet und eine potentielle Störquelle(?) Allerdings hört sich der Quarztakt gut an - Frequenzen im Hörbereich sind sauber und konstant. Der RC - Oszillator klingt deutlich schlechter, kraziger, mit gar nicht seidigen Höhen und spürbar unschwarzen Bass!
Monk schrieb: > Ich frage nochmal: Welchen Quarz verwendest du? Die genaue Modellnummer > bitte. Es ist ein IQD LFXTAL012313 von Reichelt. Die Bürdekapazitäten sind 15p.
Harald schrieb: > Es ist ein IQD LFXTAL012313 von Reichelt. Die Bürdekapazitäten sind 15p. Im Shop steht, dass der Quarz 30 pF Lastkapazität braucht. Abzüglich geschätzter 10pF für die Leitungen und den AVR komme ich auf den Bedarf von 2 Kondensatoren mit jeweils 50pF. Deine 15 pF sind davon weit entfernt.
Monk schrieb: > Im Shop steht, dass der Quarz 30 pF nicht so ganz.... Lastkapazität 16 pF steht im Shop die Werte passen also
Angehängte Dateien:
-
2024-09-24_18-54.png
230 KB -
2024-09-24_18-55.png
220 KB -
2024-09-24_18-56.png
240 KB
Monk schrieb: > Im Shop steht, dass der Quarz 30 pF Lastkapazität braucht Ich dachte, ich zeige mal wo ich die 30 pF her habe. Nachtrag: Sorry, ich hatte den Screenshot von RS zu weit beschnitten. Jetzt korrigiert. Thomas Z. schrieb: > Lastkapazität 16 pF steht im Shop Das wäre mir ehrlich gesagt auch lieber gewesen, weil 30 pF ungewöhnlich viel sind. Wo hast du denn die 16 pF gesehen?
:
Bearbeitet durch User
Monk schrieb: > Ich dachte, ich zeige mal wo ich die 30 pF her habe. ich diesen hier: https://www.reichelt.de/standardquarz-grundton-14-7456-mhz-iqd-lfxtal012313-p245415.html?CCOUNTRY=445&LANGUAGE=de
Harald schrieb: > Die Stromversorgung des SBC erfolgt > mittels eines 5V - Abwärtsregler. Der avr wird mit den 3V3 des rpi > gespeist. Seine Peripherie besteht nur aus zwei Tastern und zwei LED. Wenn du sowieso 5V zur Verfügung hast, warum dann den AVR mit 3,3V versorgen? Versorge ihn auch mit 5V und du kannst jeden Quarztakt bis 16/20MHz verwenden. Du kannst alle Baudraten verwenden die vom Quarztakt abgeleitet Ganzzahlig teilbar sind. Bspw. 16MHz Quarz, kannste bspw. 250k oder 500k Baudrate einstellen - 0,0% Abweichung. Auf der Seite vom RPI kann ich nichts dazu sagen, wie fein dieser konfigurierbar ist, er sollte dann auch 0% abweichen. Du suchst also den Größten gemeinsamen Nenner. ;-)
:
Bearbeitet durch User
S. L. schrieb: > Was spricht gegen die 500 kBd mit den internen 8 MHz? Letztendlich nur die Temperaturdrift. Selbst wenn die Langzeitdrift nur +- 1% ist, so könnte unter ungünstigen Umständen (Geschlossenes Gehäuse, Sommersonne etc) der Temperaturgang zum Problem werden. Die Idee war halt, nimm 'nen Quarz und alles wird gut. Spart Frickelei. Der avr hat ja einen Temperatursensor eingebaut, den könnte man zur Kompensation, also zum Nachtrimmen des RC - Oszillators nutzen... Spaßeshalber werde ich mal den Kühlschranktest machen (Kältespray hab ich gerade nicht).
Veit D. schrieb: > Wenn du sowieso 5V zur Verfügung hast, warum dann den AVR mit 3,3V > versorgen? Die gpio des rpi arbeiten mit 3.3V, ohne Pegelwandelung bringt man die beiden nicht zusammen wenn der avr mit 5V läuft.
Monk schrieb: > Harald schrieb: >> Es ist ein IQD LFXTAL012313 von Reichelt. Die Bürdekapazitäten sind 15p. > > Im Shop steht, dass der Quarz 30 pF Lastkapazität braucht. Abzüglich > geschätzter 10pF für die Leitungen und den AVR komme ich auf den Bedarf > von 2 Kondensatoren mit jeweils 50pF. > > Deine 15 pF sind davon weit entfernt. Das ist doch albern. Selbst wenn er ein paar pF neben der optimalem Lastkapazität läge, wäre der Einfluß derselben auf die Schwingfrequenz des Quarzes doch eher marginal. Damit RS-232 wegen Timingproblemen aussteigt, braucht man Abweichungen in der Größenordnung von 10%. Nicht 100ppm. OK, der Quarz könnte mit der falschen Lastkapazität gar nicht anschwingen. Das würde er dann aber sofort merken.
Harald schrieb: > Avr und rpi sprechen > die gleiche Sprache. Die rechnerische Fehlerrate ist immer 0. Kannst Du das mit einem Oszi verifizieren? > Die Kommunikation klappt bei niedrigen Baudraten. Auch wenn es sich komisch anhört: die Baudrate ist fast egal. Da es offensichtlich keine Signal-Probleme gibt (es funktioniert ja mit 500kBaud). Es ist also eher Wahrscheinlich, dass Du einen Fehler bei den Teilern hast. Du kannst die Werte posten oder messen.
Bruno V. schrieb: > Es ist also eher Wahrscheinlich Das ist eher unwahrscheinlich. Ich programmiere den avr in C++. Mittels consteval errechnet der compiler den ubrr (ich schätze das meinst du mit Teiler) und stellt mittels static_assert sicher dass die gewünschte Baudrate zur Taktfrequenz passt. Ist eine Abweichung vorhanden, so scheitert bereits die Kompilierung.
Der 'Teiler' ist ja sehr klein, bei einem Versatz bzw. Fehler von 1
ginge nichts mehr, anstatt
> es kippt regelmäßig nach ca 12 kB erfolgreicher Übertragung ein bit
Axel S. schrieb: > Lastkapazität läge, wäre der Einfluß derselben auf die Schwingfrequenz > des Quarzes doch eher marginal. Kommt drauf an, wieviel neben dem Optimum er liegt. > Damit RS-232 wegen Timingproblemen > aussteigt, braucht man Abweichungen in der Größenordnung von 10%. Nein. Eher 6%. Und das gilt auch nur dann, wenn der Peer auf ein paar ppm die exakte Baudrate hat. Haben beide Teilnehmer Fehler, kann auch schonmal bei drei Prozent Abweichung auf einer Seite der Kuchen gegessen sein. Wenn halt die andere Seite auch 3% hat, nur in die andere Richtung. > OK, der Quarz könnte mit der falschen Lastkapazität gar nicht > anschwingen. Das würde er dann aber sofort merken. Zwischen diesem Fall und dem Fall "läuft mit ein paar ppm Abweichung" existiert aber noch eine gewisse Bandbreite, in der der Quarz quasi "stottert". Das ist der eigentlich gefährliche Bereich, denn hier bemerkt man den Fehler des Taktgebers u.U. eben nur durch solche Effekte wie: UART funktioniert nicht richtig.
Thomas Z. schrieb: >> Ich dachte, ich zeige mal wo ich die 30 pF her habe. > ich diesen hier: > https://www.reichelt.de/standardquarz-grundton-14-7456-mhz-iqd-lfxtal012313-p245415.html?CCOUNTRY=445&LANGUAGE=de Oh, jetzt sehe ich, dass Reichelt mir einen ganz anderen gezeigt hat, obwohl ich die richtige Artikelbezeichnung eingegeben habe. Das habe ich nicht erwartet. Wenn die Lastkapazität 16 pF sein soll, dann komme ich auf 22 pF Kondensatoren. Ich schätze mal, dass in diesem Fall die vorhandenen 15 pF auch noch akzeptabel sind. Axel S. schrieb: > Das ist doch albern. Selbst wenn er ein paar pF neben der optimalem > Lastkapazität läge, wäre der Einfluß derselben auf die Schwingfrequenz > des Quarzes doch eher marginal. Das sehe ich auch so. Allerdings sind 50 pF versus 15 pF mehr als "ein paar pF". Wie dem auch sei, das hat sich ja inzwischen geklärt. Ob S. schrieb: > Zwischen diesem Fall und dem Fall "läuft mit ein paar ppm Abweichung" > existiert aber noch eine gewisse Bandbreite, in der der Quarz quasi > "stottert". Das ist der eigentlich gefährliche Bereich, denn hier > bemerkt man den Fehler des Taktgebers u.U. eben nur durch solche Effekte > wie: UART funktioniert nicht richtig. Deswegen hatte ich die Kondensatoren in Frage gestellt. Harald schrieb: > Allerdings hört sich der Quarztakt gut an - Frequenzen im Hörbereich > sind sauber und konstant Interessante Idee, das so (ohne Oszilloskop) zu verifizieren. 👍
:
Bearbeitet durch User
S. L. schrieb: > Der 'Teiler' ist ja sehr klein Genau. Die uart - Initialierung ist bei 460800 720: 88 e1 ldi r24, 0x18 ; 24 722: 80 93 c1 00 sts 0x00C1, r24 ; 0x8000c1 <__TEXT_REGION_LENGTH__+0x7e00c1> 726: 81 e0 ldi r24, 0x01 ; 1 728: 90 e0 ldi r25, 0x00 ; 0 72a: 90 93 c5 00 sts 0x00C5, r25 ; 0x8000c5 <__TEXT_REGION_LENGTH__+0x7e00c5> 72e: 80 93 c4 00 sts 0x00C4, r24 ; 0x8000c4 <__TEXT_REGION_LENGTH__+0x7e00c4> Für 921600 ist 0xC4 gleich 0. Im code fallen die letzten vier Befehle weg. Gcc ist schlau genug um zu wissen dass die Register nach dem Reset ohnehin 0 sind.
Monk schrieb: > Wenn die Lastkapazität 16 pF sein soll, dann komme ich auf 22 pF > Kondensatoren. Ich schätze mal, dass in diesem Fall die vorhandenen 15 > pF auch noch akzeptabel sind. Die 15pf sind zwar etwas klein. Ich hätte da auch 22pf gewählt aber das passt soweit. Allerdings sagt Digikey für diesen Quarz auch 30pf und die haben dort auch ein einzelnes Datenblatt bereit gestellt. Nicht so ein generisches wie Reichelt
Ob S. schrieb: > Zwischen diesem Fall und dem Fall "läuft mit ein paar ppm Abweichung" > existiert aber noch eine gewisse Bandbreite, in der der Quarz quasi > "stottert" Der Meinung war ich bis gerade eben auch. Jetzt sehe ich das etwas anders. Tatsache ist, am Quarz steht ein stabiler Sinus mit 2V pp an, gemessen mit 1:10 Teiler am Tastkopf. CPU und uart stört das Andocken der Tastkopfspitze am Quarz nicht, sie laufen weiter. Jedoch kommt der uart ins Schleudern wenn ich den Anschluß mit dem Finger berühre. Die CPU läuft jedoch ungestört weiter. Das untermauert OB S.' These des anspruchsvolleren uart, spricht aber auch gegen Oszillations - Probleme. Ich habe eher den rpi im Verdacht: Mit geloopten tx/rx zeigt der rpi bereits ohne involviertern avr seltsames Verhalten. Die bislang nur mit meiner eigenen software festgestellten Übertragungsfehler zeigen sich auch mit anderen Programmen die die serielle Schnittstelle schreiben UND lesen. Ich habe https://github.com/cbrake/linux-serial-test.git probiert. Es schickt einfach Daten an rx, liest von tx und vergleicht sie. Das klappt bis 115200 immer, darüber hinaus treten bei 5% der Versuche Fehler auf.
Ob S. schrieb: > Nein. Eher 6%. Bei 8 Datenbit + Parity, typischer Abtastrate 16-fach, Abtastung bei 7,8 und 9 16tel und perfekter Leitung wird das Stop-Bit nach 10 + 7,8 und 9 /16 Bitdauern abgetastet, wovon 2 "OK" sein müssen. Es bleibt also eine Reserve von 6/16 Bit auf 168/16 bit. Damit sind es 3,6%. Wenn beide falsch laufen, 1,8%. (Ich glaube, es kommt prinzipbedingt noch 1/2 16tel Bit dazu, das wären dann 3,3% bzw. 1,6%) Wohlgemerkt, wenn die physikalischen Signal perfekt sind, 0 Jitter etc. Bei 8-facher Abtastung und check bei 3,4,5 8tel kommt man rechnerisch auf 2/84 also 2,4 bzw. 1.2%. Harald schrieb: > Mittels > consteval errechnet der compiler den ubrr (ich schätze das meinst du mit > Teiler) und stellt mittels static_assert sicher dass die gewünschte > Baudrate zur Taktfrequenz passt. Es geht ja immer um beide Seiten. Für den RPI sind die 961k "krum". Miss einfach per Oszi beide Seiten nach, wenn Du die Möglichkeit hast.
Ob S. schrieb: > Axel S. schrieb: > >> Lastkapazität läge, wäre der Einfluß derselben auf die Schwingfrequenz >> des Quarzes doch eher marginal. > > Kommt drauf an, wieviel neben dem Optimum er liegt. Wenn die Schaltung derart auf Kante genäht ist, daß eine Änderung der Taktfrequenz um ein paar ppm den Unterschied zwischen "funktioniert" und "funktioniert nicht" ausmacht, dann ist sie ohnehin kaputt. >> Damit RS-232 wegen Timingproblemen >> aussteigt, braucht man Abweichungen in der Größenordnung von 10%. > > Nein. Eher 6%. Ja toll. Das ist ja so viel besser! 10% zu 100ppm (und 100ppm sind schon unrealistisch hoch gegriffen) ist Faktor 1000. Und du willst mir jetzt damit kommen, daß es ja nur Faktor 600 ist? Nein. Wenn trotz quarzstabilem Takt der UART spinnt, dann liegt das Problem woanders. Dann stimmt entweder der Realität nicht mit den Annahmen überein (Quarz falsch bedruckt?) oder in der Teilerberechnung stimmt was nicht. Ein beliebter Fehler ist off-by-one, das wurde ja schon gesagt. Auch auf den ersten Blick triviale Probleme, etwa GND Bounce sind möglich.
Bruno V. schrieb: > Für den RPI sind die 961k "krum" Du meinst die 921.6k, die sind gerade für ihn, und er kann sie. Das zeigt * Meine SW. Sie macht im realen Einsatz sehr wenig Gebrauch des uart. Es werden selten Nachrichten ausgetauscht, aber wenn es passiert soll es schnell, sicher und nachvollziehbar vonstatten gehen. Beim Senden stellt der rpi sicher dass das letzte byte der Meldung rausgegangen ist. * Andere Programme, wie das oben verlinkte. Das arbeitet etwas anders, es schreibt und liest 1K - Blöcke und wartet bis die Blöcke komplett über rx reinkommen. Beide Programme zeigen mit steigender Baudrate steigende Fehlerraten. Unterstellen wir mal dass meine hw und sw mangelhaft sind, wir lassen sie außen vor und machen den Idiotentest. Ich nehme also den originalen rpi zero 2W, getrennt vom board, bestromt über USB, setze einen jumper über rx/tx, und sende 5 Sekunden lang mit 921k Daten zu mir selbst. Das klappt /linux-serial-test -f -e -S -p /dev/ttyAMA0 -b 921600 -i5 -o5 Linux serial test app Flush RX buffer. Stopped transmitting. Stopped receiving. Terminating ... /dev/ttyAMA0: count for this session: rx=425994, tx=430115, rx err=0 mehrmals sogar. Doch früher oder später bekomme ich ./linux-serial-test -f -e -S -p /dev/ttyAMA0 -b 921600 -i5 -o5 Linux serial test app Flush RX buffer. Error, count: 12316, expected 1c, got 22 c 8 /dev/ttyAMA0: count for this session: rx=12315, tx=16427, rx err=1 (Etwas zusätzliche CPU - Last erhöht die Chancen) Ich erwarte 1c, bekomme aber 22. Warum?
Harald schrieb: > Ich nehme also den originalen rpi zero 2W, getrennt vom board, bestromt > über USB, setze einen jumper über rx/tx, und sende 5 Sekunden lang mit > 921k Daten zu mir selbst. > > Das klappt Du machst jetzt Witze, oder?
Angehängte Dateien:
Nö. Is wirklich so. Ok, habe vergessen zu erwähnen dass noch eine Kamera angeschlossen ist. Man weiß ja nie...
Harald schrieb: > Doch früher oder später bekomme ich > ./linux-serial-test -f -e -S -p /dev/ttyAMA0 -b 921600 -i5 -o5 [...] > Error, count: 12316, expected 1c, got 22 c 8 > /dev/ttyAMA0: count for this session: rx=12315, tx=16427, rx err=1 > (Etwas zusätzliche CPU - Last erhöht die Chancen) Da fehlt die Zeile mit "overrun = 156". Aus der schließe ich, dass diese Kombination von Hardware, Betriebssystem und Programm schlicht und einfach zu langsam ist.
Harald schrieb: >> Für den RPI sind die 961k "krum" > > Du meinst die 921.6k, die sind gerade für ihn, und er kann sie. Das > zeigt Der Witz war: Harald schrieb: > sende [...] Daten zu mir selbst Für jeden Controller ist jede Baudrate "perfekt", wenn er mit sich selbst spricht. Du hast 3 Probleme: * 961k ist für den RPI krumm * 500k ist für Deinen Quarz krumm * Du verlierst Zeichen beim Empfang. Nichts davon kannst Du im Loop testen, weil A) es lokal keine Baudratenfehler gibt und B) der Sender ggf. langsamer sendet (oder im Gegenteil die TX-Interrupts Rechenleistung klauen) Wenn Du trotzdem im Loop Fehler hast, dann musst Du die vorab beheben. Bei mindestens doppelter Baudrate oder Auslastung! Wenn Du die Baudraten nicht misst (kein Oszi), dann kommen mögliche Konfig-Fehler noch hinzu. Im Übrigen spricht auch nix dagegen, einen glatten Quarz zu nehmen, solange die gewünschten Baudraten mit dem RPI matchen. Mitlesen am PC ist kein Problem: Seriell-USB-Umsetzer können z.B. 1MBaud perfekt. Und wenn sie z.B. 250k nicht können, nimmt man einen zweiten RPI, der auf einer Baudrate horcht und das auf einer geeigneten (höheren) rauspustet.
Bruno V. schrieb: > Für jeden Controller ist jede Baudrate "perfekt", wenn er mit sich > selbst spricht. Das ist schon klar. Ich unterstelle dem rpi einfach mal dass auch 921k rauskommen wenn ich die verlange, ansonsten rechne ich mit einem Fehlercode beim Konfigurieren. Vor allem gehe ich davon aus dass Sende- und Empfangsrate identisch sind (unterschiedliche werden im code auch nicht angefordert). Wie auch immer, ob nun 961k oder 921k6. Rpi und avr haben halten sich daran, siehe Oszillogramme. Ich habe also ein einziges Problem: ich bekomme sporadisch falsche Zeichen zum Lesen. Ich weiß nicht einmal ob sie falsch rausgehen oder beim Lesen kaputt gehen.
Harald schrieb: > Rpi und avr haben halten sich daran, siehe Oszillogramme. Super. Die Werte sind perfekt. > Ich habe also ein einziges Problem: ich > bekomme sporadisch falsche Zeichen zum Lesen. Ich weiß nicht einmal ob > sie falsch rausgehen oder beim Lesen kaputt gehen. "Nicht rausgehen" würde einen SW-Fehler bedeuten, da i.d.R. die Daten einer Nachricht komplett vorliegen und der TX-Fertig-Interrupt solange aktiv bleibt, bis das nächste Zeichen geholt oder errechnet worden ist und ins Sende-Register eingestellt wurde. Typischer Fehler wäre, wenn TX-Interrupt und Main gleichzeitig unveriegelt auf der Nachricht arbeiten. "Nicht empfangen" passiert auch ohne SW-Fehler, einfach weil es an Rechenleistung fehlt (bei 1-Byte Fifo muss der Prozessor dauerhaft in weniger als 10µs reagieren). Allerdings gibt es i.d.R. Flags, die das melden. Framing-Error oder Overrun. Zähle die einfach mal mit.
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.