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
@ 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
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 ?
@ 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
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.
...
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
@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.
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.
@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 :-;
Multiple_UART.jpg
(20 KB)
