-         

Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 10 von 19

Thema: RS232-Bus

  1. #1
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253

    RS232-Bus

    Anzeige

    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?

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    13.05.2005
    Alter
    26
    Beiträge
    601
    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

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253
    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.

  4. #4
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.09.2006
    Alter
    28
    Beiträge
    841
    Blog-Einträge
    1
    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

  5. #5
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    04.11.2007
    Beiträge
    100
    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

  6. #6
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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.

  7. #7
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253
    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...

  8. #8
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    11.12.2007
    Ort
    weit weg von nahe Bonn
    Alter
    33
    Beiträge
    2.383
    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

  9. #9
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.836
    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.

  10. #10
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    09.05.2004
    Ort
    Bielefeld / Paderborn
    Beiträge
    1.253
    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?

Seite 1 von 2 12 LetzteLetzte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •