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
Im ersten Absatz steht die Frage, im zweiten die Lösung. Also wo ist noch das Problem? Übrigens haben diverse AVRs 2 UARTs.
Wenn du einen ATmega2560 nimmst der hat 4 Hardware-UARTS wenn ich richtig das Datenblatt gelesen habe. Wie wärs damit statt Software-Uart? :)
@ 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
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.
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
Irgendwie habe ich das komische Gefühl, dass ein USB-Hub mit 3 USB/Ser Kabeln dafür die einfachste Lösung ist.
@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) Tja.. wo er recht hat, hatter recht. Ich hol mir gerade mal eine Münze. Ich sag dir dann, was rausgekommen ist :)
@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 :-;
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.