Forum: Mikrocontroller und Digitale Elektronik Multiple UART


von Manni (Gast)


Angehängte Dateien:

Lesenswert?

Hat jemand eine Idee, wie die S/W in uC#4 mit ATMegas grundsätzlich 
aufzusetzen ist ?

Soll wie folgt laufen: Jeder uC (#1-3) kann irgendwann was senden. uC#4 
soll alles sammeln und an PC senden, ggf. mit Annotation, von wem was 
gekommen ist. Da die ATmegas i.d.R. nur einen UART haben, muß das Ganze 
natürlich als SUART laufen, z.B. der Code von Peda vom 04.02.2006 22:18 
in der Codesammlung.

Gruß
Manni

von Teplotaxl X. (t3plot4x1)


Lesenswert?

Software uart?

von Andreas K. (a-k)


Lesenswert?

Im ersten Absatz steht die Frage, im zweiten die Lösung. Also wo ist 
noch das Problem?

Übrigens haben diverse AVRs 2 UARTs.

von Marius (Gast)


Lesenswert?

Wenn du einen ATmega2560 nimmst der hat 4 Hardware-UARTS wenn ich 
richtig das Datenblatt gelesen habe. Wie wärs damit statt Software-Uart? 
:)

von Falk B. (falk)


Lesenswert?

@ Manni (Gast)

>natürlich als SUART laufen, z.B. der Code von Peda vom 04.02.2006 22:18
>in der Codesammlung.

4 parallele SoftwareUARTs in einem AVR? Na, das klappt aber nur bei SEHR 
niedrigen Baudraten, so 1200Baud und weniger (Pi mal Daumen).

MFG
Falk

von crazy horse (Gast)


Lesenswert?

mit etwas Protokoll kann du es auch über eine UART abwickeln.
Tx vom Master an alle Rx, Tx 1-3 wired or an Rx Master.

von Manni (Gast)


Lesenswert?

Erst mal vielen Dank für die Hinweise:

@a-k
Das Problem ist, dass man das auf vielfältige Weise erledigen kann. 
Frage ist nur, was zum Ziel führt, ohne eine Doktorarbeit daraus zu 
machen. Wenn ich DIE Lösung zum Ziel hätte, hätt' ich's nicht ins Forum 
gesetzt.

@Marius
Den kenne ich noch nicht. Schaue ihn mir gleich mal an. Würde natürlich 
gerne einen ATmega8/16/32 für alle 4 nehmen, um zu vermeiden, dass ich 
ein neues Layout machen muss.

@falk
Hast du da schon Erfahrungen, wie das gehen könnte ? Im ersten Ansatz 
fällt mir nichts realistisches ein.

@crazy horse
Die Idee klingt genial. Aber kann das wirlich gehen, wenn die 
einkommenden Signale "ge-or-ed" werden? Da kann doch nur Müll im uC#4 
ankommen, oder ?

von Falk B. (falk)


Lesenswert?

@ Manni (Gast)

>Hast du da schon Erfahrungen, wie das gehen könnte ?

Nein, aber die Funktion von Software-UARTs beruht darauf, dass nur der 
Timerinterrupt läuft und der uC schnell darauf reagieren kann. 
Vielleicht KÖNNTE man das umstricken, und die 16 fach Abtastung 
nachbilden, dann wirds deterministischer, aber auch ungleich 
CPU-intensiver.

>Die Idee klingt genial. Aber kann das wirlich gehen, wenn die
>einkommenden Signale "ge-or-ed" werden?

Logisch. Alles Slaves, die nciht antowrten senden immer ein Stop-Bit, 
also '1'.

X or 1 = X.

MFG
Falk

von Hannes L. (hannes)


Lesenswert?

Du musst per Protokoll dafür sorgen, dass Deine Controller (Slaves) nur 
dann reden (senden) wenn sie der Master dazu auffordert.

Es darf also immer nur einer der Slaves senden. Die Senderechte vergibt 
der Master der Reihe nach. Somit weiß jeder Slave, wann er senden darf 
und der Master weiß dann auch wer gerade sendet.

...

von Matthias L. (Gast)


Lesenswert?

@Falk:

>X or 1 = X.

Sicher?

von Manni (Gast)


Lesenswert?

Ahaaaa....also eure Tips gehen dahin, dass alles sehr "kooperative" 
zugeht. D.h. "schön einer nach dem anderen und bloß nicht zusammen 
reden".

Das ist aber nur die theoretische Welt und die habe ich schon realisiert 
mit drei uC via TWI I/F, läuft alles paletti.

Problem ist nur das Austesten der parallel laufenden 3 uC, ob sie nun 
wirklich richtig zusammenspielen. Dazu verwende ich in jedem uC immer 
die "schönen" printf(...) Anweisungen, damit man weiss, ob der erste 
Slave verstanden und auch abgearbeitet hat, was der Master gefordert 
hat.

So...und nun habe ich hier 3 uC auf dem Tisch liegen, die wild und 
munter printf Anweisungen via UART rausspucken. Da ich aber nur ein 
RS232 Interface am PC habe, kann ich immer nur verfolgen, was an EINEM 
uC abläuft.

Deshalb meine Idee, die UART Daten via eines "Sammlers" an den PC zu 
routen, damit ich überhaupt noch den Durchblick behalte, was da in 3 uC 
gleichzeitig abläuft.

Mit diesen Anforderungen erledigt sich also das Konzept einer 
"kooperativen" Vorgehensweise --> Du darfst erst reden, wenn du dazu 
aufgefordert wirst.

Vielleicht habt ihr ja trotzdem noch gute Ideen für mein Problem.

Gruß
Manni

von Andreas K. (a-k)


Lesenswert?

Irgendwie habe ich das komische Gefühl, dass ein USB-Hub mit 3 USB/Ser 
Kabeln dafür die einfachste Lösung ist.

von Manni (Gast)


Lesenswert?

@a-k
Das würde gehen, wenn es ein "Hyperterminal" Programm geben würde, dass 
GLEICHZEITIG 3 COM Schnittstellen scannen und die streams in EINEM Dump 
Fenster darstellen würde.

Kennst du eines ? Jedenfalls mein Docklight Console Programm 
(www.docklight.de) kann immer nur eine Schnittstelle bedienen.

von Andreas K. (a-k)


Lesenswert?

Dein zentraler UART-Konzentrator programmiert sich auch nicht von 
selber. Also such dir aus, ob du solch einen Konzentrator baust und 
programmierst, oder ein passendes PC-Programm.

Ein einfaches Konsolprogramm, das die Daten von N seriellen 
Schittstellen kommentiert auf dem stdout ausgibt, ist jedenfalls recht 
simpel.

von Falk B. (falk)


Lesenswert?

@  Matthias Lipinsky (lippy)

>>X or 1 = X.

>Sicher?

Oder auch nicht ;-)

MFG
Falk

von Manni (Gast)


Lesenswert?

@Andreas Kaiser (a-k)

Tja.. wo er recht hat, hatter recht. Ich hol mir gerade mal eine Münze. 
Ich sag dir dann, was rausgekommen ist :)

von Manni (Gast)


Lesenswert?

@Andreas Kaiser (a-k)
Es kam raus, dass ich ein PC Programm schreiben soll!

Habe aber nur 2 serielle Scnittstellen:
- eine zum dumpen der uC Programme und
- eine zum lesen der printf Anweisungen......

Jetzt muss ich die Münze noch mal werfen :-;

von Andreas K. (a-k)


Lesenswert?

Und kein USB?

Bitte 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
Noch kein Account? Hier anmelden.