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?
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.
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.
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.
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.
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...
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.
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.
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?
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.
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!
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.
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.
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. ;-)
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).
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.
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.
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.
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.
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.
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.
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.
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
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.
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%.
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.
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.
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
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.
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.
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.
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.
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.
Das ist überhaupt die Idee! Ich schließe ein SW - Problem, versursacht durch den Schreib / Lesewechsel am RPI nicht aus. Mit dem parallel geschalteten uart am PC habe ich eine neutrale Instanz die nur liest.
Der avr benutzt nur den Leseinterrupt. Ausgehende Nachrichten werden aus der main geschrieben. Die eingehenden werden vom Interrupt in eine queue transferiert, die wiederum von der main abgearbeitet wird. Das sollte so passen.
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.
Das "Stottern" kannst du mit einem Oszi überhaupt nicht sehen. Jedenfalls nicht, wenn du am Quarz selber misst.
Wenn du einen µC hast, bei dem man den erzeugten Takt auch wieder ausleiten kann, dann wird das schon eher was, wenn du halt an diesem Ausgang misst. Ist mit einem einfachen Oszi aber auch hier nicht ganz einfach zu erkennen.
Der muß mindestens eine integrierte Frequenzmessung bieten, dann sieht man das an diesem Messwert.
Auf dem grafischen Rechteck auf dem Display ist das allenfalls nur an einem "unnormalen" Jitter der Flanken zu bemerken, selbst wenn der Frequenzmesswert schon einen recht erheblichen Anteil "ausgefallener" Takte signalisiert. Man muss schon einige Erfahrung haben, um diesen Jitter zu sehen und korrekt einzuschätzen.
da ist doch was Wahres dran. Der rpi kann die 921k6 schon, aber diese rate scheint nicht seine bevorzugte zu sein. Wenn ich's recht verstehe (https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf) kann er gar nicht beliebige Takte erzeugen, sondern teilt auch nur einen Basistakt herunter.
Der ist halt hoch genug (48MHz?) um bei niedrigen Raten kleinste Abweichungen zu erreichen. Bei > 115200 wird's dann zunehmend wackeliger.
Ausgenommen die 500000, wie bestätigt durch den RC - getakteten avr. 750000 gehen auch. Darum habe ich den avr jetzt mit 12.0 MHz Quarz laufen, dann kriegt er diese Rate auch glatt hin. Zudem ist er innerhalb der spezifizierten Frequenz für 3V3.
Allerdings sind die 750000 nicht in der üblichen Baudrate - Liste vorhanden. Für das OS sind sie dann krumm. Zum Glück kann man jedoch (in Grenzen) über einen Umweg dann doch beliebige Raten setzen.
Dein Oszi-Mitschnitt zeigt, dass alles OK ist. Von daher alles gut.
Am Ende braucht ein Uart für den Empfang einen Takt von 16xBaudrate, also z.B. 16MHz bei 1MBaud. (Für das Senden würde ein 1MHz-Takt völlig ausreichen)
Das "Zählen" der Takte erfolgt ab dem Takt, der die Startflanke erkannt hat, ich nenne den mal Takt 0 (T0). Das Startbit geht dann bis T15. Alle weiteren Bits werden dann in der Mitte abgetastet, meist 3 Mal, um "glitche" auszufiltern. Bit n wird also bei T(n * 16 + 6), T(n * 16 + 7) und T(n * 16 + 8) abgetastet (Mehrheit gewinnt).
tl;dr;: Für nMBaud brauchst Du einen Takt T von 16*n Herz. Dieser Takt T muss aus einem internen Takt erzeugt werden, meist aus dem Quarz (bzw. dessen Vervielfachern). Mit 48MHz-Clock kannst Du 1MBaud (16MHz-Takt) durch zählen bis 3 erzeugen (Baudraten-Register-Wert = 2). Bei 921KBaud (14.745MHz) bräuchtest Du "Fraktionale Teiler". D.H., manche Takte sind 3 Clockzyklen, manche 4. Das bietet nicht jeder µC.
Dein RPI sollte aber 1 GHz Clock haben, so dass sich 14.x MHz genügend genau "zählen" lassen.
Den kann man wohl konfigurieren. Ich habe ihn mal auf
init_uart_clock=12000000
gesetzt, das wäre perfekt für die 750000. Ich kann aber keinen Unterschied zum default feststellen.
Nebenbei habe ich noch einen banana pi zero 2W mit einem Arduino verdrahtet, prinzipiell genauso wie die rpi / avr - Kombination. Der Arduino läuft also mit 16MHz bei 3V3. Weit außerhalb der specs, aber ohne Ausfälle.
Und das scannen des Starts erfolgt für jedes eingehende
Paket, oder nur periodisch / pro "session" burst etc?
Ich kenne die Raspberry Pi Modelle nicht im Detail, aber normalerweise wird das Startbit für jedes Byte erneut gesucht. Deswegen hilft bei gestörten Leitungen die Einstellung "2 Stop-Bits senden" oft, auch wenn der Empfänger nur eins benötigt.
OK, verstehe. Und das scannen des Starts erfolgt für jedes eingehende
Paket, oder nur periodisch / pro "session" burst etc?
Jedes Byte ist für sich abgeschlossen. Sonst wären 3% Baudratentoleranz nicht zu erreichen. Wenn Du es Dir aufzeichnest oder durchdenkst: Ab der Mitte des Stop-Bits muss der Empfänger wieder bereit sein, das nächste Startbit zu erkennen. Sonst dürfte der Sender nicht "back to back" senden.
zu 2 Stoppbits:
Die Einstellung von 2 Stopp-Bits hilft bei der Synchronisation, vor allem wenn der Empfänger "mitten im Datenstrom" eingeschaltet wird. Der Empfänger kann beliebige 1-0-Flanken nicht vom Startbit unterscheiden. Durch 2 aufeinanderfolgende 1-Bits am Ende (2 Stopp-Bits) ist der Empfänger spätestens nach ein paar Bytes synchronisiert.
10011001100
Ein positiver Effekt bei Baudraten-Abweichung ist nur dann gegeben, wenn die Uart-Einstellung 2 (oder 1.5) Stoppbits nur auf TX, nicht auf RX wirkt (was bei manchen der Fall ist).
Ein positiver Effekt bei Baudraten-Abweichung ist nur dann gegeben, wenn
die Uart-Einstellung 2 (oder 1.5) Stoppbits nur auf TX, nicht auf RX
wirkt (was bei manchen der Fall ist).
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.
Hallo,
ich melde mich nochmal deswegen. Man benötigt dafür nicht unbedingt eine separate Pegelwandlung. 3,3V vom RPI sind für den AVR sicheres High Signal. Die 5V vom AVR bringt man über einen Spannungsteiler an den RPI. Für USART ist das ausreichend, weil man 2 getrennte Leitungen für TX und RX hat.
Übrigens, wenn man "dauerhaft" ein 'U' sendet, erhält man auf der USART Leitung ein Taktsignal. Vielleicht hilft das bei der Fehlersuche.
Du kannst zum Test mit deiner Baudrate deutlich runtergehen, ob sich dann immer noch Zeichen verschlucken. Und lasse dir einmal auf beiden Controllern den Wert des eingestellten Baudratenregisters ausgeben und rechne das nach.
Hab ich auch immer gedacht. Leider hatten wir mindestens einen anderen. Muss ich morgen raussuchen.
Im Datenblatt ist es oft schwer zu finden, weil es nicht um die Auswertung geht, sondern um den Zeitpunkt, an dem der Receiver für ein neues Startbit bereit ist (in der Mitte des ersten Stoppbits).
Du kannst zum Test mit deiner Baudrate deutlich runtergehen, ob sich
dann immer noch Zeichen verschlucken
Jetzt läuft der avr ja mit 12 MHz. Das reicht dicke für meine Zwecke, somit reichen die 3V3. Den Spannungsteiler kann ich nicht ohne weiteres probieren, weil tx und rx direkt verbunden sind um die Flanken sauber zu halten.
Ich glaube mittlerweile eher dass der rpi die Schwachstelle ist weil:
* Die Fehlerrate mit steigender baudrate ansteigt
* Die Fehlerrate mit steigender CPU - Last ansteigt
* Ein OS im Betrieb ist, das kann nicht hexen
* Die fifos der SBC auch nur 24 (rpi) bzw 64 (bpi) bytes gross sind
Auf dem rpi bin ich mit 350000 baud auf der sicheren Seite. Auch mit voll ausgelasteter CPU (vier Endlosschleifen per bash im Hintergrund) läuft das stundenlang fehlerfrei. Die vom OS gemeldeten "overrun" sind 0. Verdoppele ich auf 750000, so bewirkt zusätzliche CPU - Last oft overruns und potentielle Übertragungsfehler.
Mit dem banana pi sieht es ähnlich aus, der ist bei 500000 stabil, kann aber gar keine 1000000.
"Fehler" heißt hier also Versagen im Stresstest, der bezüglich Nachrichten - Anzahl und - Frequenz weitab praktischer Anforderungen ist. In Sachen CPU - Auslastung ist er u. U. gar nicht so extrem, für den Fall das der SBC auch als git - server etc. missbraucht wird.
das bedeutet, wenn das Raspi OS bremst, das nur die Datenrichtung vom AVR zum Raspi Probleme bereitet. Vom Raspi zum AVR sollte mit jeder Baudrate funktionieren, nehme ich an.
Verwendest du die Desktop Version vom Raspi OS oder die ohne Desktop? Wenn mit Desktop, könntest du nochmal die Light ohne Desktop ausprobieren.
Vom Raspi zum AVR sollte mit jeder
Baudrate funktionieren, nehme ich an
Hmm, das habe ich noch gar nicht bedacht. Guter Hinweis.
Auf dem rpi läuft nicht Raspi OS, sondern arch linux ("alarm"). Das sollte aber keinen Unterschied machen.
das bedeutet, wenn das Raspi OS bremst, das nur die Datenrichtung vom
AVR zum Raspi Probleme bereitet. Vom Raspi zum AVR sollte mit jeder
Baudrate funktionieren, nehme ich an.
Ja, soweit ich sagen kann ist der rpi das Nadelöhr.
Und immer für Überraschung gut: Das bisherige Exemplar habe ich durch Unachtsamkeit geschrottet. Ein neues allerdings bestand mit gleichem Setup nicht einmal den CPU - Stresstest, ab einer gewissen Temperatur aufwärts brach das wifi zusammen.
Ursache ist wohl eine zu niedrige interne Versorgungsspannung. Mit dem Eintrag over_voltage=2 in der /boot/config.txt klappts dann wieder...
In Sachen uart sieht es jetzt so aus: Der avr läuft quarzbetrieben mit 12 MHz@3V3. Das Quarzgehäuse habe ich auf Masse gelegt. Tatsächlich ist der uart leicht mit Taktstörungen aus dem Tritt zu bringen. Berühren des Quarzes ist vielleicht nur eine Möglichkeit davon und immerhin ist das wifi des rpi nicht so weit entfernt.
Die Baudrate ist 750000 und somit eher unüblich. Nicht alle Terminal - Programme können sie. Die SW am rpi nutzt libc/termios2 um sie einzustellen. Siehe
https://github.com/npat-efault/picocom.git
Der eigentliche Trick ist, dem rpi nicht zu viel zuzumuten. Bei höheren Baudraten kommt der einfach nicht mehr nach, wenn er bei starker CPU - Last gleichzeitig Senden und Empfangen soll. Falls nötig muss der avr also eine kleine Pause nach dem Senden eines Paketes machen.
