Hi,
was ist, wenn du vor den Daten noch mal einen Datensatz schreibst, der
den CHip auswählt, der es empfangen soll?
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?
-> MEIN PROJEKTBLOG <-
Hi,
was ist, wenn du vor den Daten noch mal einen Datensatz schreibst, der
den CHip auswählt, der es empfangen soll?
Grüße Furtion
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.
-> MEIN PROJEKTBLOG <-
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.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
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...
-> MEIN PROJEKTBLOG <-
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.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
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?
-> MEIN PROJEKTBLOG <-
Lesezeichen