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