Habe gesehen das es hier viele helle Köpfe hat :-) Daher einige Kontrollfragen zum Thema UART. Angenommen ich habe 75 ATMEGA128P. Der Erste ist via UART mit dem Zweiten verbunden, diese über die 2te UART mit dem Dritten, usw... Wenn ich die UART nun auf 115kBaut einstelle (damit ich diese von einem PC ansteuern kann) wie lange dauert es bis ein Byte beim 75igsten ATMEGA128P agekommen ist. (Es geht mir nicht darum dies genau zu wissen, sondern um eine grobe Abschätzung, da ich noch nie was mit einem AVR oder UART gemacht habe) meine handgelenk mal Phi Rechnung: Übertragungszeit von einem ATMEGA zum nächsten: 0.11ms Verarbeitsungszeit Eingang UART1 - Ausgang UART2 bei 20MIPS: 50 Zeilen Assambler = 3us --> Somit wäre das Byte etwa nach 10ms beim 75igsten ATMEGA. Stimmt meine Grobabschätzung halbwegs?
>...da ich noch nie was mit einem AVR oder UART gemacht habe)
Sehr merkwürdig diese Frage!
Nur zur Orientierung: Gammler aber Assembler, Maut aber Baud.
David wrote: > Habe gesehen das es hier viele helle Köpfe hat :-) Danke für den Honig, falls das welcher war. Wobei mich das Grinsen da am Ende irgendwie grübeln lässt... > Stimmt meine Grobabschätzung halbwegs? Die 'hellen Köpfe' würden meistens gerne genauer wissen wofür so Gedankenspiele gut sein sollen, bevor sie ihren Senf dazu abgeben.
Hallo, ein PC kann diverse Baudraten, nicht nur 115200. Zum weiterreichen reichen 2 Befehle: in temp,UDR0 out UDR1,temp Dazu kommt die Zeit, den Receive-IRQ aufzurufen und wieder zu beenden, sind ca. 12 Zyklen. Deine Schätzung hat also noch etwas Reserve. Gruß aus Berlin Michael
>>@Joan P. Sarksmus liegt mir zwar im Blut, aber in diesem Punkt ausnahmsweise nicht... >>@Michael U. 12 Zykeln + 2 Befehle werden wohl 14 Zyklen sein, tönt soweit gut... ein PC kann diverse Baudraten, nicht nur 115200. Äh habe einfach einmal Hyper Terminal aufgemacht und dort nachgeschaut was ich für Bautraten einstellen kann, 115200 ist dabei, wiso geht diese nicht? Welche dann die in der nähe liegen? Stimmt meine Schätzung für die übertragungszeit inetwa?
Versuch macht klug. :- )))
Man könnte ja auch einfach sagen, dass David's Überlegungen völlig richtig sind. Aber des Entwicklers Lieblingsbeschäftigung ist die Spitzfindigkeit. Insofern würde ich gerne wissen, wo die 0.11ms herkommen. Ich hätte jetzt einfach mal 10 Bit pro Byte (8N1) angenommen und damit komme ich auf 87us pro Byte.
Die UART-Geschwindigkeit kannst Du noch bedeutend höher schrauben als 115200. Für PCs gibt es z.B. USB-Serial-Adapter, die 8*115200=921600 können. Du kannst auch noch die anderen Schnittstellen nutzen (z.B. SPI im MHz-Bereich) und das Netzwerk stärker vermaschen, d.h. ein Empfänger sendet die Info an mehrere Empfänger. Da erinnere ich mich an die Transputer (T800-Serie, waren die nicht von Inmos?): um einen Cluster aufbauen zu können, hatte jeder einzelne Prozessor 4 high-Speed-Schnittstellen. Erzähl uns doch bitte mal, was Du damit vor hast.
Also Freunde 1. Fehlt der Prozessortakt. 2. Der Atmega 128 besitzt 2 USART welche unabhängig voneinander also zeitgleich empfangen und senden können. Somit bleiben als Latenz die Zahl der Prozessortakte welche nötig sind das Signal von der einen USART in die Andere zu portieren. Das erste Byte erreicht den letzten Prozessor also nach 75*(Latenz + Übertragungsdauer für ein Byte entsprechend der Baudrate) Wenn man es optimal angeht wartete der Prozessor auf das eingehende Byte um es gleich durch die andere Tür wieder rauszuschieben. Dann braucht es nicht mal die Zeit um nen IRQ auszuführen.
habe jetzt zwar nicht die lust zu rechen, aber wenn bytes mit 8bit, 1stop bit und noch die parität übertragen werden dann dann muss der Atmel erst alle bits sammeln und kann dann erst die daten weiterleiten, also wird die meiste zeit mit dem sammeln und wieder rauschicken der bits vergehen. Mann kann ja schlecht die bits weiterreichen.
@ Peter Klar das geht auch nur den permanent einen eingang auf einen Ausgang kopieren. aber das wahr hier wohl nicht gefragt? Aber wie schon gesagt Die beiden HW-USART könne parallel arbeiten, während die erste sammelt spuckt die zweite aus. Der µC_Kern braucht nur das Bytereciveflag auswerten und wenn etwas da ist das Byte aus dem Reciveregister holen und ins Transmitregister legen. Da beide Schnitstellen syncron getaktet werden ist das letze Byte raus wenn das nächste eintrifft. Mit Fifo schaffts der PC genauso schnell.
Hallo, hatte soweit alles schon so gegen 17.00 geschrieben. ;) Zusätzlich: eigentlich reicht auch ein UART, der kann durchaus parallel senden und empfamgen. Gruß aus Berlin Michael
@Winfried J. Du redest viel, sagst aber nichts. Zumindest nichts neues. Egal wie Du es drehst: Als Latenz bleibt immer die Übertragungsdauer für ein Byte. Insofern stimmt das, was David sagt, weiterhin.
Die Antworten gefallen mir, tönt soweit positiv. (Aufgrund der grossen Anzahl von Antworten verzichte ich jetzt darauf auf jede einzeln einzugehen) Noch 2 kurze fragen: 1) Osszillator Ich habe im Datenblatt keine angaben zur genauigkeit des kalibrierten RC Osszillators gefunden. Wie hoch sind bei diesem die Tolleranzen, Temperaturstabilität, etc? Respektive wo finde ich diese Daten? Ist es überhaupt möglich/Sinnvoll den ATMEGA via RC-Osszilator zu betreiben, wenn man punkto Fehlertolleranz auf der Sicheren Seite stehen möchte? 2) Leitungslänge Zwischen den Leiterplatten wo der ATMEGA aktiv ist, liegt die länge bei rund 20cm (auf der Leiterplatte selbst + 3cm Flachbandkabel). Vom PC auf den ersten ATMEGA kämme ich auf eine Länge von etwa 8 Meter. Wird dies Problemlos funktionieren? Muss ich spezielles beachten?
Wnn du USART benutzen willst, fängst du dir mit jedem int. Taktgeber nur Probleme ein. Einen Quarz pro AVR muss schon sein.
Hallo, 8m bei 115kBaud könnten an die Grenze gehen, gutes Kabel benutzen, ausprobieren oder mit der Rate runtergehen wenn möglich. Mit 38400 habe ich zwischen 2 Rechnern schon stabil 35m gehabt, bei 57600 gab es dann gehäuft Übertragungsfehler. Zum internen Oszillator wurde schon alles gesagt. Quarze ran, Baudratenquarz, z.B. 14,7456MHz. Gruß aus Berlin Michael
@technikadonis hab ich eben auch befürchtet... trotzdem würden mich die toleranzdaten des internen RC-osszillators interessieren, wo finde ich diese? @Michael Auch das habe ich befürchtet :-) Gibts es da eine Formel, Faustregel oder was ähnliches damit ich handgelenk mal phi bestimmen kann was eigentlich dringlegen müsste (natürlich bei geschirmtem twisted-pair kabel). Für meine Anwendung ist mir eine zuverlässige kommunikation wichtig...
Hallo, im Datenblatt des Mega128 ist dazu ein Diagramm, in meinem auf Seite 352. Schon der Gedanke, für 75 Mega128 jeweils das Calibrierungsbyte zu bestimmen und dann den Fehler zu suchern, welcher in der Kette gerade die Lust verloren hat....... Meine Faustregel zur Länge: Ring Kabel und 2 PCs oder PC + AVR Probieren... Letzlich kommen Sachen wie Störungen durch die Umgebung usw. zum Tragen, die man vorher nicht unbedingt einschätzen kann. Alternativ eben zwischen PC und 1. AVR statt RS232 z.B. RS485 nehmen. Gruß aus Berlin Michael
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.