RS232-Bus

Hallo!
Der Anwendungsfall: Mehrere µCs, auf die ein Datensatz verteilt werden soll. Jeder kriegt 12 Bytes. Bisher passiert das über I2C, allerdings würde ich es gern per RS232/Usart machen. Jeder Controller kriegt dabei einen Chip-Select. Der Datensatz wird 1x über den Bus an alle Slaves gesendet. Per Chip-Select wird ausgewählt, wer gerade lesen soll.
Die Frage: Wie setze ich die Chip-Select-Leitungen am richtigen Zeitpunkt, sodass der Slave keine Daten verpasst und keinen Datenmüll sammelt. Ist das überhaupt möglich? (Datenrate 115200, µc @7,38.. MHz) Kann man sauber in eine laufende Usart-Kommunikation einsteigen?

Hi,

was ist, wenn du vor den Daten noch mal einen Datensatz schreibst, der
den CHip auswählt, der es empfangen soll?

Ich glaube was du meinst ist: Slaveadresse senden, kurz warten, dann die Daten für den Slave senden. also ungefähr so wie I2C. Ich will aber alle 300 Bytes auf einmal senden und jeder Slave sucht sich das raus, was seins ist. Es geht vor allem um die Geschwindigkeit. Wenn das mit den 300 Bytes am Stück nicht funktioniert, kann ich immernoch die 25 Datenpakete einzeln senden und dazwischen die Chip-Select-Leitungen beschalten.

naja dan sende doch die bytes nacheinander...wenn jeder chip weiß an welcher position seine daten stehen....

jeder chip speichert die gesamte folge un sucht sich seinen teil raus

oder chipselect in hardware: vor den rx-pin eine ODER verknüpfung - nur wenn CS am OR-gate low ist kommen die low-impulse überhaupt am rx-pin des uC an ..

edit: kann man auch platzsparend als wired-or mit zwei dioden und einem pull-down widerstand machen

Hw-mässig insteigen kannst du eigentlich nur jeweils im Stopp-Bit.

Ich persönlich würde eher schauen, von jedem Einzelpaket ein Adress-byte einzufügen.
Das wird aber dann immer mehr I2C-mässig.

*räusper*: Was spricht denn gegen die I2C-lösung ? Die ist ja eigentlich genau für sowas gemacht.

Das Ding ist, dass die Daten vom PC kommen. Über USB in einen I2C-Adapter, und dann auf den Bus. Der Adapter selber benutzt für die Übertragung vom Rechner zum Adapter allerdings RS232. Und zwar mit einem ziemlich lahmen ASCII-Protokoll. Wieso soll ich dann nicht gleich die RS232-Fähigkeiten des Adapters benutzen, um die Rohdaten direkt auf die Slaves zu bringen...

dann versuch doch den adapter zu optimieren, RS232 ist nun halt mal KEIN Bus sondern eine serielle datenübertragung, jeedr empfänger bekommt jedes byte und was er damit anstellt muss der empfänger entscheiden, also entweder parallelisierst du die chips und lässt sie entsheiden welches byte sie auswerten sollen oder du optimierst die kommunikation zu deinem adapter.
aber bei der parallelisierung wirst du bestimmt auf granit beissen was die geschwindigkeit angeht. du könntest die rohdaten zum beispiel per burst in den adapter jagen, d.h. das protokoll ändern und alle daten für alle chips auf einmal, der adapter sollte natürlich intelligent genug sein um ihm sowas einzuprogrammieren und das programm übernimmt dann asynchron zum PC die verteilung der daten.

ich habe bei dem obigen einfach mal angenommen das der PC für jeden chip, dem "adapter" sagt, öffne adresse XYZ, sende daten, warte auf antwort, öffne neue adresse ....

vll. hilft es auch wenn du den adapter durch nen USB->RS232 TTL wandler und daran einen atmega8 oder so ersetzt und dann selber ein protokoll machst

EDIT: zumal du mit ein paar dioden usw. auch dem adapter gleich noch ein nettes debug-interface verpassen kannst, so mitanzeige für chipausfall, datenstau, unterforderung :P oder was dir da so einfällt

I see.
Es könnnt nur
jeder Slave beim dem Gesamtpaket mitzählen und seinen Teil rausfischen
Wenn die Übertragung stabil ist und keine Bytes gelegentlich verlorengehen, könnte das schon funzen.

HW: Das Stopp-Bit, ist ja das, was übrigbleibt, wenn grad ein BYte gesendet wurde. d.h. du müßtest:
-->Chip select setzen
--> Bytes für diesen Chip absenden
--> nächster Chip

Also, gewissermassen, das was oben die Slaves mitdenken, müßt nun der Pc oder was dazwischen tun.

Ich dachte an einen Mega8, der den Datenstream analysiert und dann die CS setzt. Der müsste dann natürlich den Steam auf unterster Ebene, sprich Bits analysieren, um die Stoppbits herauszufiltern, oder?

mhhh ein blick auf dein blog verrät mir das du also eine art bildmatrix hast und die schneller machen möchtest ... *grübel* ... also wenn du alle chips parallel anschliesst und einfach die datensätze für jeden chip hintereinander packst und den chips dann überlässt zu entscheiden WELCHES paket für ihn bestimmt ist, wird es so wahrscheinlich am effektivsten sein, aber es kann auch passieren das mal ein oder 2 byte flöten gehen und dann nur salat rauskommt, das ist dann das risiko! aber trotzdem seh ich die optimale lösung darin die daten "komprimiert/optmiert" über RS232 an einen controller chip über einen USB RS232 adapter zu senden der dann aus dem kompakten bilddaten die datensätze macht und dann per i2c sendet ... überlegenswert wäre hier ob du eine echte komprimierung mit ausreichend geschwindigeit erreichen kannst, weil der RS232 ist für bewegte biler doch etwas eng

Sind halt 9000 bytes pro sekunde, bei 30 FPS. Das ist schon machbar. Und ich sehe keinen echten Vorteil in I2C, weil der Bottleneck eh beim RS232 liegt. Auf dem Adapter sitzt überigens schon ein Mega8.

naja wenn du auf absolute zuverlässigkeit pfeifst dann mach das mit dem parallel anschliessen, die bytes werden so oder so von den controllern empfangen(zumindest sollten sie 1 byte kurzzeitig speichern ... ich hab mich mit RS232 noch net auseinandergesetzt :P)

also was spricht dagegen einfach ein bild als frame/bytefolge zu senden und dann jeden controller so einzustellen das er einen bestimmten teil der übertragung nur auswertet der ihm zugeordnet ist ... du könntest praktisch 1 pin benutzen mit nem taster und dann die "kanäle" durchsteppen bis der controller den richtigen frame ausgibt und das dann im EEPROM speichern damit er beim nächsten start nicht neu eingestellt werden muss, sokanst du für alle controller dasselbe progg nehmen

dasselbe programm nehmen ist ja nicht so wichtig. ich werde das mal ohne chip-select testen und schauen, ob jeder controller seine daten selber rausfiltern kann. muss ja eigentlich nur mitzählen. nur ne fehlerkorrektur sollte man auch einbauen, falls mal ein byte verlorengeht. vllt den cs-pin (der nach meinem umbau am wochenende schon existiert) nutzen um allen controllern nach einem frame zu sagen "fangt mit dem zählen bei 0 an, ein neuer frame beginnt." dann hat man vllt mal nen frame mit fehlern, der die nachfolgenden frames aber nicht beeinflusst.

zur not hintendrann nen crc byte berechnen ...die idee mit der signalleitung iss eigentlich auch nciht schlecht, evtl. könntest du ja multiplexen, mit jeder highflanke counten die chips mit, du sendest das datenpaket, alle empfangen es aber nur der angesprochene chip wertet die bytes auch aus, die anderen verwerfen die bytes ... ist das paket empfangen und die prüfsumme in ordnung, sendet der empfänger ein acknowledged signal ... ich merke grad das viele gedanken hier im topic schon in die richtung gegangen sind, aber je mehr ich dein projekt im detail kennenlern umso klarer wirds das direktes ansprechen besser sit aber eben unzuverlässiger ^^

eigentlich hast du recht, wenn du jedem chip per leitung sagst empfange oder empfange nichts wäre es wohl besser aber vom timing her würde ich mir keine gedanken machen, wenn du erst im register den einen pin auf low ziehst, dann den nächsten auf high, und dann erst mit der übertragung beginnst sollte es sich am empfänger schon auswerten lassen wer was empfängt

Zitat:

---

Zitat von Ceos

wenn du erst im register den einen pin auf low ziehst, dann den nächsten auf high, und dann erst mit der übertragung beginnst sollte es sich am empfänger schon auswerten lassen wer was empfängt

---

Ich versteh nicht so ganz, was du meinst. Ich dachte eher (wenn ich tatsächlich CS benutze) die Leitung so lange high zu halten, wie der Slave empfangen soll. Also quasi Uart enable. Wenn der Pin nicht high ist, hört der Slave gar nicht mit.

naja das "nicht mithören" ist etwas problematisch, es könnte passieren das noch ein byte im eingangspuffer liegt und dann murks rauskommt, alle sollten schon bewusst die bytes empfangen aber eben alle nur empfangen und nicht auswerten, es sein denn die leitung ist high ... obs nun mit flanke(multiplex modus mit einer leitung) oder pegel(1 leitung je empfänger) läuft bleibt dir überlassen .. du kannst ja auch echte mux/demux nehmen und die selectleitung anpulsen die dann den pin für jeden chip einzeln hochziehen und wieder runterziehen aber das wäre schon fast wieder overkill ^^

Und wenn du die daten wie ein schieberegister reinschiebst?

ceos: ich hatte schon geplant, nen schieberegister zu nehmen, um nachher alle CS-Leitungen getrennt per pegel anzusprechen.

thehawk: ?