Umschalt IC für 2 bis 6 TX Pins

[HeXPloreR]

Hallo und vielen Dank für die vielen Antworten.

Also die Baudrate wäre maximal 38400.

Ich würde natürlich dem geringsten Aufbauaufwand vorerst den Vorzug geben.

Es sitzt noch ein weiterer Atmega328 drauf, der sollte aber nur also Haupteinheit das ganze System überwachen.
Vermutlich wird es tatsächlich einfacher sein, was zusätlichen Hardware aufwand betrifft, einen Master zu haben und die anderen (2-6) als Slaves über I²C zu betreiben. Und der Master schickt dann die Daten allein zur SSC.

Der Plan war allerdings die ATmegas einmal kurz über die Haupteinheit zu aktivieren, das Sie das versenden der Daten zur SSC dann ohne Haupteinheit tun.
Der Grund dafür liegt in meiner Berechnung der Inversen Kinematik für meinen Hexapod. Ich wollte dort durch aufteilen der Berechnungen etwas mehr Geschwindigkeit heraus bekommen.

Verliere ich diese Idee damit oder fahre ich mit der Slave Lösung in vielen Fällen immer noch schneller als die Berechnung von einem einizigen 328-20MHz durch führen zu lassen?

Viele Grüße
Jörg

[Mxt]

Ein Master und eine Busverbindung wäre die eine Möglichkeit.

Man könnte das ganze auch dezentral lösen, z.B. mit einer Art "Token Ring": Zuerst sendet der Master dem ersten Slave über ein IO-Bit das Signal (als kurzen Impuls), dass dieser Senden darf. Der Slave sendet etwas (oder hat ggf. nix zu sagen) und gibt danach das Signal an den zweiten Slave weiter. Dieser an den nächsten und zum Schluss der Letzte wieder an den ersten.

Die Kette läuft dann immer reihum, die Slaves senden nur, wenn sie die Signalflanke erhalten. Der Master stuppst das Ganze nur beim Start an.

Man kommt mit wenig Signalen aus, je ein Ein- und Ausgang bei jedem Slave. Natürlich können da Probleme wie in anderen Token-Netzwerken entstehen, wenn z.B. das Signal verloren geht, weil ein Slave vergisst es weiterzugeben. Da wäre eine Master Lösung wie bei SPI ausfallsicherer.

[HeXPloreR]

Ja, genau sowas wollte ich im vorherigen Post beschrieben haben.

Hier mal etwas ausführlicher:
Also die Haupteinheit schaltet die 5V Versorgung der Slaves erst frei wenn die Akkuspannung positiv geprüft wurde.
Die Slaves sind auf Steckplätze gesteckt und messen über einen ADC ihre Steckplatznummer, der über Widerstände eingestellt wird. Erst wenn sich alle eingesteckten µC beim Master per extra IO gemeldet haben, werden Daten zur Berechnung abgeschickt. Diese Daten hatte ich auch über UART geplant. Dadurch wird es möglich das der jeweilige µC im Programmcode verzweigt und nur die Berechnungen durchführt auf dessen Steckplatz er steckt. Und dann eben die zyklische Aktivierung der Sendepins erfolgt.
An dieser Stelle allein macht I²C schon Sinn, denke ich, da mir die aufwändige Verdrahtung von den IO Pins erspart bleibt.
Allein der ADC muss messen können auf welchem Steckplatz der µC steckt und dementsprechend der Code abzweigen. Theoretisch könnten dann auch nur einer gesteckt sein, wenn es im Code abgefangen werden kann und die jeweiligen Berechnungen der anderen Steckplätze dann übernommen werden können.
Wichtig wäre hier jetzt noch zu erwähen das auf allen Slaves der selbe Code laufen wird, und allein durch die ADC-Messung,dann eine Slave-Adresse zugewiesen werden würde. Der Master wäre dann der der auf maximal 6 bekannte Slaves scannt und nachdem alle Slaves identifiziert wären würde ich vermutlich nur noch mit einem General-Call arbeiten damit alle Slaves die selben Daten zur Berechnung erhalten.

Das alles ist noch theoretischer Natur - ich habe momentan nur zwei identische Arduino-ProMini Clone und hatte mich eigentlich in der Planung auf TTL RS232 bisher erfolglos "eingespielt".
Aber ich merke schon I²C hat da einfach Vorteile was auch die Rückmeldungen der Slaves betrifft. Und man ist nicht auf einige IO' sfixiert.

Vielen Dank und Grüße
Jörg

[Mxt]

Hallo,

wenn es die Slaves noch nicht gibt, hast du da mehr Freiheiten. Ich habe am Anfang gedacht, die gäbe es schon. Wenn nämlich mehrere Slave unsynchronisiert senden würden, bleibt wohl nichts anderes übrig, als das ein Master mit vielen UARTs das einsammelt und neu sortiert.

Bei AVR ist I2C dann die naheliegendste Lösung. Bei meinen ARM-Boards würde ich wegen der Performance eher zu SPI tendieren.

Und wenn die Slaves nicht zu viele IOs haben und von der Rechenleistung nur einen 8-Bit Controller auslasten, würde ich sie alle zusammen als Threads auf auf einen großen Controller legen.
http://developer.mbed.org/handbook/RTOS
als Hardware z.B. so was
http://developer.mbed.org/platforms/mbed-LPC1768/
http://developer.mbed.org/platforms/EA-LPC4088/