Hallo, folgendes Problem: mit meinem ATmega328P empfange ich 10 Byte bei 115200 Baud 8N1 (siehe Bild Blau). Meine Code (Arduino) empfängt die Bytes und sendet sie als Echo wieder zurück. Das was er Empfangen hat wird nocht weiter verarbeitet (CRC Check) Nun habe ich das Problem, dass meine CRC zu 99% fehlschlägt. Der Grund: Es werden zu 99% nicht 10 Byte sondern 8 oder 9 Byte empfangen.(siehe Bild Rot) Nur Byte 0 und Byte 9 enthalten Daten. Alle anderen Bytes sind 0. Byte 0 = temperatur Byte 9 = CRC Wenn ich den Resonator verwende wird das Problem nur noch schlimmer ( teilweise nur 4 von 10 Bytes) Mit dem internen RC Takt gehts am besten. Wo liegt das Problem? Sie Serielle scheint einige Bytes nicht zu empfangen. Alle anderen Timings passen. Der Resonator hat 8 MHz. In Arduino sind 8MHz ausgewählt. Fuses: Low = E2 High = DA Extended = FD
Angehängte Dateien:
-
Serial.png
18 KB
:
Bearbeitet durch User
John P. schrieb: > Wo liegt das Problem? Wenn die Zeitbasis nicht stimmt und Du auch sonst nichts tust um das aufzufangen, ist das eben das Ergebniss. 1% Abweichung oder weniger ist Pflicht, der ATmega328P hat aber +-2%. Wertest Du überhaupt die Uart Fehler aus? Overrun / framing error ?
Im Datenblatt ist eine Tabelle (bei mir Table 20-11), wo Taktraten und der resultierende Baudratenerror aufgelistet sind. Gerade bei 8Mhz und 115200 Baud gibts mit (U2xN = 0) 8,5% Fehler, mit gesetztem U2xN sinds -3,5%, wäre also mal einen Versuch wert. Allerdings ist es schon besser, einen Quarz zu benutzen, bei dem der Fehler 0% ist, z.B. 11,0592MHz oder 14,7456MHz.
Hallo, Tipp schaue doch bitte mal im Datenblatt nach, ob 115200 Baud mit 8MHz überhaupt zusammen passen! Table 20-1. Equations for Calculating Baud Rate Register Setting Entweder wird UBBR = F_CPU/16 /Baudrate -1 oder UBBR = F_CPU /8 /Baudrate -1 gerechnet, je nach Uart Einstellungen. Wenn du das nicht umstellen kannst, da schau mal hier: http://www.gjlay.de/helferlein/avr-uart-rechner.html Speziell der Baudratenfehler sollte klein sein!
Hallo, nimm nicht solche krummen Baudratenwerte. Immer Ganzzahlig teilbare. Zum Bsp. funktionieren 250.000 Baud. Die Kabelverbindung sollte natürlich auch passen und Sender und Empfänger gleich konfiguriert sein.
Michael K. schrieb: > Wertest Du überhaupt die Uart Fehler aus? > Overrun / framing error ? Im Moment noch nicht, werde ich mal nachholen. Matthias S. schrieb: > Gerade bei 8Mhz und 115200 Baud gibts mit (U2xN = 0) 8,5% Fehler, mit > gesetztem U2xN sinds -3,5%, wäre also mal einen Versuch wert. Auch das werde ich mal testen. Aber warum funktioniert es mit dem internen RC besser als mit dem Resonator? Ich dachte es wäre eher anders rum. Und das durch den fehler von 8% ganze Bytes übersprungen werden?
Karl M. schrieb: > Nebenbei ist das eine falsche Aussage. > John P. schrieb: >> Alle anderen Timings passen. Weil?
John P. schrieb: > Aber warum funktioniert es mit dem internen RC besser als mit dem > Resonator? Vermutlich liegt die Frequenz des internen RC-Oszillator näher an der "idealen Frequenz" für die eingestellte UBRR-Werte und Baudrate. Sprich mit dem 8MHz-Resonator oder -Quarz hast du 125000Baud, mit dem RC-Oszillator, der vielleicht mit 7,8MHz läuft, nur 122000Baud, was näher an 115200Baud liegt. John P. schrieb: > Und das durch den fehler von 8% ganze Bytes übersprungen werden? Die werden halt als "falsch" erkannt und daher ignoriert. Mich wundert eher, dass du bei 8% Abweichung überhaupt noch ganze Bytes empfangen kannst... MfG, Arno
John P. schrieb: > Aber warum funktioniert es mit dem internen RC besser Das ist Zufall. Der RC weicht unter den gegebenen Bedingungen von den 8Mhz in die eine oder andere Richtung soweit ab, daß es besser passt als beim genaueren Keramikresonator oder beim Quarz. Mach das Ding mit einem Föhn warm oder sprüh Kältespray drauf, dann sieht das schon ganz anders aus. John P. schrieb: > Und das durch den fehler von 8% ganze Bytes übersprungen werden? Weil das Byte nicht vollständig ist, gibt es einen Frameerror aber kein Receive Ready, was das einzige ist, was du auswertest.
Arno schrieb: > Vermutlich liegt die Frequenz des internen RC-Oszillator näher an der > "idealen Frequenz" für die eingestellte UBRR-Werte und Baudrate. Sprich > mit dem 8MHz-Resonator oder -Quarz hast du 125000Baud, mit dem > RC-Oszillator, der vielleicht mit 7,8MHz läuft, nur 122000Baud, was > näher an 115200Baud liegt. Ok, das verstehe ich. Arno schrieb: > Die werden halt als "falsch" erkannt und daher ignoriert. Mich wundert > eher, dass du bei 8% Abweichung überhaupt noch ganze Bytes empfangen > kannst... Dann war ich wohl mit 8MHz und 115200 Baud etwas optimistisch. Habe ehrlich gesagt vorher nicht den Fehler berechnet. Hatte nur mal testweise einen Arduino Mini Pro verwendet und dort funktionierte es. Aber warscheinlich eher zufällig, weil die Frequenz dort noch besser passte. Werde einen 16MHz Resonator ausprobieren.
John P. schrieb: > Werde einen 16MHz Resonator ausprobieren. Das bringt nichts. Schau Dir doch mal den oben verlinkten Baudraten-Rechner näher an und spiele mit den Werten. Dann siehst Du auch, dass der Fehler für 8MHz und 16MHz derselbe ist. In der Weboberfläche wird der Fehler für viele Quarze ausgegeben. Einfach auf den Button mit der vorgegebenen Frequenz klicken. Nimm einen sog. "Baudratenquarz", z.B. 14,7456 MHz. Damit ist der Fehler dann null. Und Dein AVR rennt dabei auch noch schneller als mit 8MHz.
:
Bearbeitet durch Moderator
John P. schrieb: > Werde einen 16MHz Resonator ausprobieren. Nimm einen 14,7456MHz. Der ist genauso handelsüblich und bringt 0% Abweichung bei 115,2k-Baud.
Hallo, man benötigt keine Baudratenquarze mit ihren krummen Frequenzen. Man nimmt ganzzahlig teilbare Baudratenwerte. Bsp. 125.000, 250.000 oder gar 500.000. Damit ist der systematische Fehler bei 0,0%.
:
Bearbeitet durch User
Veit D. schrieb: > Damit ist der systematische Fehler bei 0,0%. Und was macht die Gegenseite? Wenn das ein PC ist, möchte der gern die üblichen Baudraten haben, weil sein Quarz dafür passend ist.
Veit D. schrieb: > Bsp. 125.000, 250.000 oder gar > 500.000. Das musst du dann aber auch der Gegenstelle beibringen - das geht nicht immer.
Georg G. schrieb: > Veit D. schrieb: >> Damit ist der systematische Fehler bei 0,0%. > > Und was macht die Gegenseite? Wenn das ein PC ist, möchte der gern die > üblichen Baudraten haben, weil sein Quarz dafür passend ist. Ich hatte damit am PC noch keine Probleme. > Das musst du dann aber auch der Gegenstelle beibringen - das geht nicht > immer. Hier müsste der TO einmal sagen was die Gegenstelle und ob die einstellbar ist. Wovon ich erstmal ausgehe. Sonst gibts falsche Vorschläge.
Hallo, >Georg G. schrieb: >> Veit D. schrieb: >>> Damit ist der systematische Fehler bei 0,0%. >> >> Und was macht die Gegenseite? Wenn das ein PC ist, möchte der gern die >> üblichen Baudraten haben, weil sein Quarz dafür passend ist. >Ich hatte damit am PC noch keine Probleme. Ergänzung: Bezog sich auf dem Board verbauten 16MHz Resonator bzw. 8MHz Quarz. Funktionierte bis jetzt jetzt wie gesagt immer. Den internen 8MHz RC eines ATtinys 841 musste ich nachjustieren, weil ich den mit 5V statt mit ab Werk kalibrierten 3,3V betreibe.
Veit D. schrieb: > man benötigt keine Baudratenquarze mit ihren krummen Frequenzen. Man > nimmt ganzzahlig teilbare Baudratenwerte. Bsp. 125.000, 250.000 oder gar > 500.000. Damit ist der systematische Fehler bei 0,0%. Funktioniert nicht. Die Gegenstelle ist ein "Sensor" bei dem ich keine Möglichkeit habe die Baudrate zu ändern. Sonst hätte ich ja schon geringere Baudraten versucht. Die 115200 Baud sind fest. Ebenso die vielen 0 Bytes. Frank M. schrieb: > John P. schrieb: >> Werde einen 16MHz Resonator ausprobieren. > > Das bringt nichts. Schau Dir doch mal den oben verlinkten > Baudraten-Rechner näher an und spiele mit den Werten. Dann siehst Du > auch, dass der Fehler für 8MHz und 16MHz derselbe ist. Naja bei 8MHz sind es -3,5% und bei 16Mhz 2,1% Ist schonmal eine verbesserung. Zugegeben, nicht viel. Und selbst wenn jede dritte CRC Prüfung falsch ist, kann ich damit leben. Außerdem möchte ich kompatibel zu den Mini Pro bleiben (8MHz/16MHz) um die Firmware "extern" entwickeln zu können. Kann sein das es nicht perfekt ist, aber dann kann ich den Resonator immernoch tauschen gegen einen passenden. Der Resonator ist doch in ein paar Minuten getauscht. P.s. Wenn ich z.B. einen 14.7456 MHz Resonator verwende...reicht es bei Arduino die Boards.txt anzupassen? Oder muss die F_CPU noch woanders neu definiert werden?
John P. schrieb: > P.s. Wenn ich z.B. einen 14.7456 MHz Resonator verwende...reicht es bei > Arduino die Boards.txt anzupassen? > Oder muss die F_CPU noch woanders neu definiert werden? du musst den Bootsektor neu kompilieren mit richtiger F_CPU und die Baudrate u.U. anpassen. Programmiert mit dem Atmel Studio 4.18 am ISP Mit Optiboot hast du auch mehr Platz im flash Ich habe das mit dem Optiboot Quellcode gemacht, dann die Boards.txt angepasst
Joachim B. schrieb: > du musst den Bootsektor neu kompilieren mit richtiger F_CPU und die > Baudrate u.U. anpassen. > Programmiert mit dem Atmel Studio 4.18 am ISP > Mit Optiboot hast du auch mehr Platz im flash > Ich habe das mit dem Optiboot Quellcode gemacht, dann die Boards.txt > angepasst Bootloader verwende ich nicht. Ich programmiere nur mit dem USBASP. Daher wäre der Clock nur für die Application entscheidend.
Habe mal testweise den 16MHz Resonator getestet. Keine Veränderung! Weiterhin werden 1-4 0Bytes überlesen. Dann Frage ich mich welcher Quarz sinvoll als ersatz in Frage kommt. Die 14,7456 MHz scheiden wohl eher aus, da der Atmega328P mit 3.3V betrieben wird. Wie siehts aus mit 12MHz? 0,2% Fehler und könnte sogar schon hier rumliegen mit etwas Glück und suchen. Oder 9,216 MHz? Oder 11,0592 MHz?
Nimm einen echten Baudratenquarz, mit dem Du die Baudrate genau triffst. Alles andere ist Scheiße und verursacht nur Probleme, die evtl. erst nach einiger Betriebszeit auftreten. Dann ist das Geheule wieder groß.
John P. schrieb: > Habe mal testweise den 16MHz Resonator getestet. > > Keine Veränderung! Weiterhin werden 1-4 0Bytes überlesen. > > Dann Frage ich mich welcher Quarz sinvoll als ersatz in Frage kommt. > > Die 14,7456 MHz scheiden wohl eher aus, da der Atmega328P mit 3.3V > betrieben wird. Sag mal, liest du überhaupt, was von uns geschrieben wurde? Wenn 14,7456MHz zu viel sind, weshalb versuchst du es dann mit 16MHz? Und den Tipp mit der Baudratenberechnung hast du völlig ignoriert. Jetzt gebe ich dir einen völlig verrückten Tipp: Schau dir mal das Datenblatt des Mega328P an. Da stehen sogar Tabellen drin, mit welchem Quarz bei welcher Baudrate welcher Fehler auftritt. Da mußt du nicht einmal etwas rechnen! Jetzt bin ich gespannt... :-)
Florian S. schrieb: > Sag mal, liest du überhaupt, was von uns geschrieben wurde? > Wenn 14,7456MHz zu viel sind, weshalb versuchst du es dann mit 16MHz? > > Und den Tipp mit der Baudratenberechnung hast du völlig ignoriert. > > Jetzt gebe ich dir einen völlig verrückten Tipp: > Schau dir mal das Datenblatt des Mega328P an. Da stehen sogar Tabellen > drin, mit welchem Quarz bei welcher Baudrate welcher Fehler auftritt. Da > mußt du nicht einmal etwas rechnen! Was ist denn mit dir nicht richtig? Ja ich lese was Ihr schreibt. Ich hab den 16Mhz ausprobiert weil er hier rumliegt. Liest du überhaupt was ich schreibe? Ich möchte kompatibel bleiben zum Pro Mini mit 8MHz bzw 16MHz! Hat nicht geklappt...OK. Datenblatt habe ich selbstverständlich gelesen. Die Tabellen habe ich auch gefunden. Woher sonst sollte ich wohl wissen das ein 12MHz Takt einen fehler von 0,2% bei 115200 Baud hat? Woher sonst sollte ich wissen das 9,216 MHz oder 11,0592 MHz passen würden um 0% fehler zu erreichen? Fang du mal lieber an zu lesen. Oder sag mir wo ich innerhalb von 2Std einen passenden Baudrateresonator im passenden footprint herbekomme. Dann probiere ich den sofort aus. Solange muss ich warten bis Mouser liefert.
:
Bearbeitet durch User
Ben B. schrieb: > Nimm einen echten Baudratenquarz, mit dem Du die Baudrate genau triffst. > Alles andere ist Scheiße und verursacht nur Probleme, die evtl. erst > nach einiger Betriebszeit auftreten. Dann ist das Geheule wieder groß. Tja, wenn ich bei Mouser gucke bleibt aber nur 12MHz übrig. Alles über 12MHz schließe ich mal aus, weil es ja außerhalb der 3,3V Spec ist. 9,216 MHz -> Nicht auf Lager 11,0592 MHz -> Nicht auf Lager 12 MHz -> Verfügbar Außerdem wären 12MHz besser für 100.000 Baud. Aber das ist dann die nächste Baustelle.
John P. schrieb: > 11,0592 MHz -> Nicht auf Lager Ich weiss nicht, wo du bei Mouser schaust, aber vom Hersteller ECS haben die hunderte Quarze mit dieser Frequenz auf Lager. Keramikresonatoren hingegen sind mit dieser Frequenz schon recht ungebräuchlich. https://www.mouser.de/ProductDetail/ECS/ECS-1105-20-4X?qs=sGAEpiMZZMsBj6bBr9Q9aZ%2fM%2fAO6%2f6MxZvAsb7sT4os%3d https://www.mouser.de/ProductDetail/ECS/ECS-1105-20-5PX-TR?qs=sGAEpiMZZMsBj6bBr9Q9aQ6SZfIlWoiSjhF0SGCXOfI%3d https://www.mouser.de/ProductDetail/ECS/ECS-1105-20-18-TR?qs=sGAEpiMZZMsBj6bBr9Q9aQamN4EdKa8pUd89%252bCNM3t0%3d
:
Bearbeitet durch User
Matthias S. schrieb: > Keramikresonatoren > hingegen sind mit dieser Frequenz schon recht ungebräuchlich Ja, und genau da liegt das Problem. Auf der Platine ist ein Resonator und kein Quarz. Die Frage ist auch ob ein 12MHz Resonator mit 0,07% Fehler besser/schlechter ist als ein 14,746 MHz Resonator mit 0,5% fehler (der wäre lieferbar)
:
Bearbeitet durch User
> 9,216 MHz -> Nicht auf Lager > 11,0592 MHz -> Nicht auf Lager > 12 MHz -> Verfügbar Benzin -> nicht auf Lager Diesel -> verfügbar 12V -> kein Akku und kein Netzteil verfügbar 230V -> Steckdose belegt 400V -> Steckdose belegt 660V -> nicht verfügbar 10kV -> Trafostation abgeschlossen 110kV -> Überlandleitung und lange Leiter verfügbar! Na denn mal los! Wenn Du schon so rangehst, wirst Du noch sehr viel Spaß mit der Elektrotechnik haben.
miss die Frequenz aus mit der er wirklich taktet und passe den Teiler entsprechend an
Man das ist doch nicht so schwer. Für 115.2kbaud entweder 11.0592 oder 7.3728 Mhz, damit trifft man die Baudrate ohne Fehler und dann funktioniert der Müll auch.
John P. schrieb: > Auf der Platine ist ein Resonator und kein Quarz. Ist doch wurscht, bau' halt einen Quarz ein.
:
Bearbeitet durch User
John P. schrieb: > Ich möchte kompatibel bleiben zum Pro Mini mit 8MHz > bzw 16MHz! John P. schrieb: > Die 115200 Baud sind fest. John P. schrieb: > Alles über 12MHz schließe ich mal aus, weil es ja außerhalb der 3,3V > Spec ist. man kann sich ja vieles wünschen, aber alle Wünsche werden einem nie erfüllt jedenfalls nicht 115k2 Baud mit 8/16 MHz und 0% Fehler http://www.gjlay.de/helferlein/avr-uart-rechner.html Segor.de 11.0592 MHz http://www.segor.de/#Q=Q11%252C0592MHz-LP&M=1 (Lager im Zulauf) http://www.segor.de/#Q=Q11%252C0592MHz-SMD%252FSM49&M=1 (Lager) 9.216 MHz http://www.segor.de/#Q=Q9%252C216MHz-LP&M=1 (Lager)
:
Bearbeitet durch User
John P. schrieb: > Die Frage ist auch ob ein 12MHz Resonator mit 0,07% Fehler > besser/schlechter ist als ein 14,746 MHz Resonator mit 0,5% fehler (der > wäre lieferbar) Wo hast du die 0,5% Fehler her? Toleranz des Resonators? Klingt viel, schau da mal lieber ins Datenblatt, ob das vielleicht über einen erweiterten Temperaturbereich o.ä. ist. Ansonsten wäre tatsächlich 12MHz mit 0,07% Toleranz und 0,2% nomineller Abweichung, also bis zu 0,27% Gesamtabweichung, meistens besser. Aber auch grenzwertig für eine immer zuverlässig funktionierende serielle Schnittstelle. Du kannst übrigens (unter anderem beim 328P) auch einen höheren Takt verwenden, die CLKDIV8-Fuse setzen (damit der Programmstart zuverlässig funktioniert) und im Programm den Teiler selbst konfigurieren. Also z.B. einen 18,432 MHz-Resonator, dann startet der Controller mit 2,304 MHz und per Software kannst du ihn beim Start auf 9,216 MHz umstellen: http://nongnu.org/avr-libc/user-manual/group__avr__power.html#gae2d32c0c4f18f0019e680354bcc1c3ef MfG, Arno ...der das umgekehrt macht, um Strom zu sparen - die Verfügbarkeit von kleinen SMD-Quarzen mit hohen (Baudraten-)Frequenzen ist besser...
Matthias S. schrieb: > Ist doch wurscht, bau' halt einen Quarz ein. Seit wann haben Quarze (2 oder 4 Pins) das selbe Footprint wie Resonatoren (3 Pins)? Klar kann ich da was ranbasteln, aber das ist doch keine Lösung. Werde mal einen 12MHz und einen 14,746MHz Resonator mit passenden footprint bestellen. Sind ja Cent Artikel.
Arno schrieb: > Du kannst übrigens (unter anderem beim 328P) auch einen höheren Takt > verwenden, die CLKDIV8-Fuse setzen auch bei 3,3V? das kommt mir aber komisch vor, ich kann es mir halt nicht vorstellen, wenn 18,432 MHz ausserhalb der 3,3V Grenze liegt, dann bleibt das doch!
Joachim B. schrieb: > Arno schrieb: >> Du kannst übrigens (unter anderem beim 328P) auch einen höheren Takt >> verwenden, die CLKDIV8-Fuse setzen > > auch bei 3,3V? > das kommt mir aber komisch vor, ich kann es mir halt nicht vorstellen, > wenn 18,432 MHz ausserhalb der 3,3V Grenze liegt, dann bleibt das doch! Ich nehme stark an, dass sich das auf die Frequenz bezieht, mit der der Controller-Kern läuft, nicht auf die Frequenz, die der Oszillator kann. Ganz eindeutig finde ich das im Datenblatt gerade nicht, aber Seite 46 http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf "The Application software must ensure that a sufficient division factor is chosen if the selected clock source has a higher frequency than the maximum frequency of the device at the present operating conditions." deutet für mich darauf hin. MfG, Arno
Arno schrieb: > Du kannst übrigens (unter anderem beim 328P) auch einen höheren Takt > verwenden, die CLKDIV8-Fuse setzen (damit der Programmstart zuverlässig > funktioniert) und im Programm den Teiler selbst konfigurieren. Also z.B. > einen 18,432 MHz-Resonator, dann startet der Controller mit 2,304 MHz > und per Software kannst du ihn beim Start auf 9,216 MHz umstellen: Arno schrieb: > Ich nehme stark an, dass sich das auf die Frequenz bezieht, mit der der > Controller-Kern läuft, nicht auf die Frequenz, die der Oszillator kann. > > Ganz eindeutig finde ich das im Datenblatt gerade nicht, aber Seite 46 > http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf > "The Application software must ensure that a sufficient division factor > is chosen if the selected clock source has a higher frequency than the > maximum frequency of the device at the present operating conditions." > deutet für mich darauf hin. Dann werde ich mal einen 18,432MHz Resonator mitbestellen.
Arno schrieb: > Ich nehme stark an, dass sich das auf die Frequenz bezieht, mit der der > Controller-Kern läuft möglich oder aber der ganze Chip, auch der Oszillator ist ja Teil des Siliziums und da gibt es schon Abhängigkeiten von Spannung und Frequenz > Ganz eindeutig finde ich das im Datenblatt gerade nicht wenn es nicht eindeutig ist dann wissen die es auch nicht haben es nie getestet oder es bleibt beim Einzelchip fraglich. > aber Seite 46 > http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf > "The Application software must ensure that a sufficient division factor > is chosen if the selected clock source has a higher frequency than the > maximum frequency of the device at the present operating conditions." > deutet für mich darauf hin. ja man kann vieles deuten, wir wissen ja das Datenblätter stets fehlerfrei sind :) Und wenns nicht klappt haben wir nur das Datenblatt falsch verstanden :)
:
Bearbeitet durch User
John P. schrieb: > Seit wann haben Quarze (2 oder 4 Pins) das selbe Footprint wie > Resonatoren (3 Pins)? Du lässt den mittleren Pin ungelötet oder verbindest ihn mit dem Quarzgehäuse. Da ist auch nichts 'gebastelt', sondern das ist elektrisch völlig in Ordnung. Selbst ein unkalibrierter Quarzoszillator enthebt dich jedenfalls aller Probleme mit der Genauigkeit der Taktfrequenz. Man nimmt Resonatoren, wenns nicht so auf die genaue Frequenz ankommt und man noch eine Cent sparen möchte. Bei dir kommts aber nun mal auf die genaue Frequenz an - ein Resonator ist also eine schlechte Idee gewesen.
:
Bearbeitet durch User
Hallo, wenn du am Sensor nichts umstellen kannst und kompatibel zu den 8/16MHz Arduinoboards bleiben möchtest, dann würde mir nochwas einfallen. Du nimmst einen 2. µC als UART-USART Übersetzer. Du benötigst einen mit zwei USARTs. ATtiny841 oder 328PB oder ... Den betreibst du mit einen passenden Baudratenquarz für den Sensor. Zwischen dem und deinen großen µC überträgst du syncron. Sensor <> UART 115200 Baud <> µC <> USART xxx Baud <> Arduino Du kannst auch statt USART per I2C oder SPI die Daten auf dem letzten Stück übertragen. Je nach räumlicher Nähe wo welcher µC sitzt. Dann hättest du einen UART<>SPI oder UART<>I2C Übersetzer. Wenn du auf dem Arduino einen "Baudraten-Resonator" nimmst, wie im Thread beschrieben, dann ersparste viel zusätzliche Arbeit. Nach Umbau oder vor Umbau kannst noch in einer Schleife ein 'U' seriell rausschicken und den Takt am Oszi messen. Dann haste etwas zum vergleichen.
:
Bearbeitet durch User
John P. schrieb: > Der Resonator hat 8 MHz. In Arduino sind > 8MHz ausgewählt. Wieso? Hast Du nicht den Quarz (16MHz) aktiviert? John P. schrieb: > Wo liegt das Problem? Bei den 8Mhz? Im Code?
Hallo, er wird einen Arduino Nachbau haben, die gibts auch mit 8MHz für 3,3V Versorgung. Originale Arduinos haben immer einen 16MHz Resonator aufgelötet.
Veit D. schrieb: > er wird einen Arduino Nachbau haben Welchen? Das weisst Du genau so wenig wie ich - falls überhaupt. Warten wir doch auf die genaue Angabe.
John P. schrieb: > Aber warum funktioniert es mit dem internen RC besser als mit dem > Resonator? Weil du Glück hast. Halte mal einen warmen Fön drauf, dann kommt das Pech zurück. Ich habe 115200 Baud vor einigen Monaten auch mal mit 5 Arduino Nanos probiert. Es klappte bei 4 von 5 - also nicht empfehlenswert. 57600 Baud gehen zuverlässig.
Hallo, ich schrieb "Arduino Nachbau". Das kann alles sein. Was aber aus dem Thread hervorgeht ist, dass der µC ATmega328P ist mit 8MHz Resonator der mit 3,3V laufen soll. Der Begriff "Pro Mini" fiel auch schon. Der Arduinokenner weiß damit etwas anzufangen. :-)
Veit D. schrieb: > Originale Arduinos haben immer einen 16MHz Resonator > aufgelötet. Meine beiden (teuren) Original - DueMilanove Arduinos haben keine Resonatoren, sondern 16Mhz Quarze. Das ist allerdings schon ein paar Jahre her.
Hallo, ja die gabs mal original mit Quarz. :-) https://www.arduino.cc/en/Main/Boards Scheinbar den Kosten oder Platz zum Opfer gefallen.
worüber wird hier gerade diskutiert? egal ob 8 oder 16 MHz, egal ob Resonator oder Quarz, alle 4 Möglichkeiten schaffen keine 115k2 mit 0% Fehler, der Rest wenns geht ist Zufall das die Fehlerrate gerade so >0% passt!
Joachim B. schrieb: > worüber wird hier gerade diskutiert? Um es für dich nochmal zusammenzufassen: * TE sagt, das er keinen Resonator für 11,0592 Mhz kaufen kann, weil er nicht lieferbar ist * Empfohlen wird stattdessen ein Quarz (und eben kein Resonator) für 11,0592 Mhz * TE sagt, das er den Quarz nicht verbauen könnte, weil er nur 2 Anschlüsse hat, der Resonator aber 3. * Ich sage, das es möglich ist, den mittleren Pin freizulassen, oder damit den Quarz zu erden. * Kurzer Exkurs, das alte Arduino keine Resonatoren, sondern tatsächlich mit Quarz ausgerüstet waren - vermutlich hat der TE also einen neueren Arduino mit Resonator.
:
Bearbeitet durch User
Hallo, Matthias S. schrieb: > Um es für dich nochmal zusammenzufassen: > ... > vermutlich hat der TE also einen neueren Arduino mit Resonator. Und wo ist jetzt das (scheinbar unlösbare) Problem? rhf
Ich sehe auch kein Problem mehr, er kann nun den Fehler berechnen und sich danach richten. Was er nun mit seiner Hardware macht, ist sein eigenes Problem. [cut]
Matthias S. schrieb: > Um es für dich nochmal zusammenzufassen: du hast ein Leseverständnis wo ist 8MHz und 16MHz geeignet wenn der TO 3,3V mit 115k2 Baud will?
So etwas passiert, wenn man ein (Arduino) Framework verwendet, dass nur die einfache heile Welt beschreibt, jedoch nicht auf die Haken und Ösen hinweist. Die anderen Leute lesen Datenblätter und die Dokumentation der libc, dort steht deutlich drin, welche Einschränkungen zu beachten sind. Meiner Meinung nach beruht die Einfachheit von Arduino hauptsächlich darauf, Teile der IDE, der Doku und der Programmiersprache weg zu lassen. Eine Taktik, die alles schön einfach erscheinen lässt, aber langfristig genau das Gegenteil bewirkt. Vor allem das Weglassen von Doku halte ich für sehr riskant. Das gleiche Spiel kenne ich vielfach aus dem Bereich der Java Enterprise Entwicklung. Berater empfehlen den Managern vermeintlich einfache grafische Anwendungen, mit den die Softwareentwicklung wie durch Magie plötzlich viel einfacher, schneller und billiger werden soll. Im Extremfall braucht die Firma nicht einmal mehr Programmierer, da Geschäftsleute sich jetzt alles einfach zusammen klicken können - so weit die Theorie. Praktisch sind diese Tools sehr oft die Hölle. Man verplempert fast seine ganze Arbeitszeit mit fehlenden Funktionen, nicht dokumentierten Details und mieser Performance. Am Ende bringt diese ganze Vereinfachung nur eins: Abhängigkeit. Arduino ist für einen schnellen Einstieg nett. Aber kurz danach sollte man dringend auf vernünftige Arbeitsmittel umsteigen. Spätestens dann, wenn man auf die ersten Grenzen des Arduino Systems stösst. So, das musste mal raus. Jetzt gehe ich kacken :-)
Beitrag #5738153 wurde von einem Moderator gelöscht.
Ben B. schrieb im Beitrag #5738153: >> Jetzt gehe ich kacken :-) > Mit 8 oder 16 MHz? shit.h geladen? Mit 7,3728 MHz Meiner Meinung nach hätte man die stark seriell orientierten Arduinos von Anfang an mit 7,3728 MHz bestücken sollen, dann gäbe diesen HickHack mit den Baudraten nicht, und auch keine Probleme mit 3,3V bzw. Batteriebetrieb.
Beitrag #5738162 wurde von einem Moderator gelöscht.
Beitrag #5738168 wurde von einem Moderator gelöscht.
Mein Atmega328P ist auf einer eigenen Platine und nicht auf irgendeinem Arduino Board. Bevor ich meine Schaltung fertig gestellt habe, hatte ich viele funktionen vorher mit dem Arduino Mini Pro ausprobiert. So hat auch das Auslesen des Sensors bei 115200 Baud funktioniert. Anscheinend eher zufällig. Zu der Zeit habe ich die BaudRaten/F-CPU Problematik garnicht beachtet. Habe zuvor noch nie mit Atmegas gearbeitet. Bisher waren es immer nur STM32 und NRF52. Ohne Arduino, mit viel lesen im RM. Der Grund warum ich bei diesem Projekt auf Arduino umsteige: Es gibt sehr viel fertige biliotheken die ich einfach Plug&Play nutzen kann. Würde ich auf einen STM32 o.ä. umsteigen müsste ich alles neu coden. Das wollte ich mir damit sparen. Mir ist die Baudraten Problematik bei Atmega jetzt bewusst. Aus euren Aussagen und meinen Test's ist mir auch bewusst das 8MHz/16MHz nicht funktionieren. Daher möchte ich jetzt die nächsten einfachen alternativen testen: 12Mhz (Baud Error 0,2%) 14,746MHz (Baud Error 0,0%) Das lässt sich einfach und Problemlos umbestücken. Muss nur bestellt werden. Wenn das nicht funktioniert. kann man sich weitere Gedanken zu einem Quarz o.ä. machen. Aber auch hier bleibt die Problematik das ich sowohl 115200Baud und 100000 Baud verwenden möchte.
:
Bearbeitet durch User
Auch wenn es wohl einige nicht hören wollen. ich konnte die Baud/Clock Problematik etwas umgehen. (Mouser trifft erst morgen ein mit den neuen resonatoren) Habe wieder auf RC Oscillator umgestellt und die OSCCAL angepasst. Ist nicht schön aber ich kann erstmal weiter programmieren und testen. bei 10% der Daten (je 10 Byte) schlägt der CRC fehl. OSCCAL wurde von 75 auf 76 angepasst.
:
Bearbeitet durch User
John P. schrieb: > Auch wenn es wohl einige nicht hören wollen. > > ich konnte die Baud/Clock Problematik etwas umgehen. (Mouser trifft erst > morgen ein mit den neuen resonatoren) > > Habe wieder auf RC Oscillator umgestellt und die OSCCAL angepasst. Ist > nicht schön aber ich kann erstmal weiter programmieren und testen. > > bei 10% der Daten (je 10 Byte) schlägt der CRC fehl. > OSCCAL wurde von 75 auf 76 angepasst. Dein Problem ist der Abstand zwischen den Bytes. Normalerweise synchronisiert sich der Empfänger immer wieder neu, aber wenn die Bytes zu schnell hintereinander kommen, funktioniert das eben nicht. Wer oder was sendet die Bytes ? Falls du da etwas ändern kannst, probiere es mal mit 2 Stoppbits oder mit größerem Abstand zwischen den Bytes.
Hallo, Marc V. schrieb: > Dein Problem ist der Abstand zwischen den Bytes. Normalerweise > synchronisiert sich der Empfänger immer wieder neu, aber wenn die > Bytes zu schnell hintereinander kommen, funktioniert das eben nicht. das kann ein Problem sein bzw. werden. Man kann etwas entschärfen, wenn man den Sende-UART auf 2 Stopp-Bits setzt. Ansonsten: ich kenne den Nano, den UNO aud auch den Mega328, den schon aus vor-Arduino-Zeiten. Ich kenne das Datenblatt und die Baudratentabellen. Normalerweise nutze ich nur max. 38400 bei 16MHz Takt. Wegen einer Spielerei läuft hier jetzt ein UNO mit 230400Baud. Kritisch ist hier aber offenbar der USRT-seriell-Wandler mit dem Mega16U2. Der verliert wohl Zeichen wenn, wenn er das USB bedient. 50µs Pause zwischen den Bytes haben das Problem gelöst. Es werden Bild-RAW-Daten im Block mit 153600 Byte alle 20s übertragen. Es gibt keine Bit- oder Bytefehler dabei. Ein CH340 (und vermutlich auch ein FTDI) schafft das ohne die zusätlichen 50µs warten. Wenn ich auf 115200 angewiesen wäre, würde ich immer einen Baudratenquarz nehmen. Im Notfall kann man sich auch einen optiboot-loader passend bauen, Source ist ja dabei und die boards.txt anpassen ist auch kein Hexenwerk. Das Problem ist nicht, das "Arduino" drüber steht. Das verbietet nicht automatisch einzugreifen, wo man es für gut befindet. Gruß aus Berlin michael
Marc V. schrieb: > Wer oder was sendet die Bytes ? > Falls du da etwas ändern kannst, probiere es mal mit 2 Stoppbits > oder mit größerem Abstand zwischen den Bytes. Die Daten kommen von einem "Sensor" Da kann ich leider nichts einstellen oder ändern. Michael U. schrieb: > Wenn ich auf 115200 angewiesen wäre, würde ich immer einen > Baudratenquarz nehmen. Der ist gerade auf dem Weg hier her ;)
John P. schrieb: > OSCCAL wurde von 75 auf 76 angepasst. Wie hast Du das ermittelt? OSCCAL ist nichtlinear und macht Sprünge. "The two frequency ranges are overlapping, in other words a setting of OSCCAL=0x7F gives a higher frequency than OSCCAL=0x80." Am besten läßt man das den MC selber ermitteln, indem man auf den ICP1-Pin einen stabilen 1s Takt gibt. Den Wert schreibt man dann in den EEPROM und lädt ihn im Init-Code ins OSCCAL.
Peter D. schrieb: > Wie hast Du das ermittelt? Try&Error ich hatte den default wert ausgelesen -> 75 Damit funktionierte die Serielle ja schonmal fast gut. dann bin ich auf 74, 73, 72 -> und es wurde immer schlimmer dann bin ich auf 76 und bingo. 77 habe ich dann nicht mehr probiert.
Nachtrag: habe jetzt auch endlich mal den 12MHz Resonator ausprobieren können. funktioniert einwandfrei.
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.