RS-232 als Bus mit dem UART der AVRs

[Paul H. (powl)]

Hi,

ich verwende hier RS-232 als Bus, habe also Sender und Empfänger am UART 
miteinander jeweils verbunden und alle AVR-UARTs untereinander dann mit 
einer Busleitung.

Die Kommunikation erfolgt unter den 3 AVRs ganz einfach. AVR1 sendet ein 
Paket los, das dann von beiden anderen Empfangen wird. Diese werten das 
dann aus. Danach ist AVR2 dran und sendet ein Paket auf den Bus während 
AVR1 und AVR3 zuhören, das gleiche Spiel macht dann AVR3.

Nun habe ich testweise mal nur AVR1 und AVR2 am Bus hängen.
AVR1 sendet nun ein Paket, die Senderoutine sieht folgendermaßen aus:

void uart_send(uint8_t byte)
{
  UCSRB &= ~(1 << RXEN);  // Empfnger ausschalten
  UCSRB |= (1 << TXEN);  // Sender einschalten

  _delay_us(100); // Warten, Bus auf High damit Start-Bit korrekt erkannt wird

  UDR = byte;

  loop_until_bit_is_set(UCSRA, TXC);
  UCSRA |= (1 << TXC);

  UCSRB &= ~(1 << TXEN);  // Sender wieder ausschalten
  UCSRB |= (1 << RXEN);  // Empfnger wieder einschalten
}

Ich denke die ist selbst erklärend. Dadurch, dass der Sender am Ende der 
Routine wieder abgeschaltet wird habe ich am Bus nach dem Stop-Bit auch 
wieder eine fallende Flanke. AVR2, der währenddessen die ganze Zeit am 
Bus lauscht erkennt somit fälschlicherweise zwei eingehende Bytes. Erst 
das echte, tatsächlich gesendete, dessen Empfang man durchs resetten des 
RXC-Flag quittieren muss, und dann noch das fiktive Byte. Kann man den 
Empfang dieses fiktiven Bytes irgendwie verhindern? AVR2 muss nämlich 
warten, ehe er selbst dann ein neues Byte senden kann.

Ebenso verhält sich das, wenn AVR2 dann selbst ein Byte sendet. Der 
Empfänger wird zwar abgeschaltet aber wenn er wieder eingeschaltet wird 
liegt der Bus bereits auf Low-potenzial. Der Empfänger sieht diesen 
Low-Zustand beim Einschalten fälschlicherweise als fallende Flanke an 
und denkt, es würde gerade wieder ein Byte gesendet werden, welches man 
dann am Ende wieder durch resetten des RCX-Flags quittieren muss. Etwas 
nervig. Kann man das irgendwie verhindern?

An jedem Busteilnehmer hängt an der Busleitung noch ein niederomiger 
Pulldown, damit sich beim Senden ständig Stromschleifen ausbilden um die 
Übertragung störsicher zu machen. Eventuell könnte ich das ganze auch 
jeweils gegen VCC schalten?

lg PoWl

[Hc Z. (mizch)]

RS232 ist eine serielle Schnittstelle, aber nicht jede serielle 
Schnittstelle ist RS232.  Deine auch nicht; diese Bezeichnung führt nur 
in die Irre.

Warum machst Du nicht einfach einen Pullup auf den „Bus“?

[MCUA (Gast)]

>RS232 ist eine serielle Schnittstelle
Falsch.
RS232 ist nur eine physikalische U-Pegel-Festlegung.
Das hat nicht das geringste mit parallel/seriell - Protokoll zu tun.

[Gill Bates (Gast)]

> Ich verwende hier RS-232 als Bus

Was blöd ist, denn RS-232 ist nur als Punkt-zu-Punkt spezifiziert, die 
Schnittstellenbausteine sind per se nur dafür gemacht.

Wenn Du Glück hast, hält das, wenn nicht: Pech.

Warum nimmst Du nicht einen richtigen Bus? RS422/485 würden sich 
anbieten - ist durchspezifiziert, es gibt massig Bausteine und mögliche 
Protokolle gibt es auch jede Menge.

[spess53 (Gast)]

Hi

Das so UART so nicht für einen Bus geeignet ist dürfte langsam klar 
sein.

>Kann man den Empfang dieses fiktiven Bytes irgendwie verhindern? AVR2 muss
>nämlich warten, ehe er selbst dann ein neues Byte senden kann.

Den Empfang nicht. Aber bei dem fehlerhaften Byte sollte ein Frame Error 
aufreten. Einfach mal die Fehlerbits in UCSRA abfragen.

MfG Spess

[Hc Z. (mizch)]

MCUA schrieb:
>>RS232 ist eine serielle Schnittstelle
> Falsch.
> RS232 ist nur eine physikalische U-Pegel-Festlegung.
> Das hat nicht das geringste mit parallel/seriell - Protokoll zu tun.

Quatsch.  RS-232 ist ...

TIA/EIA standard for serial transmission between computers and peripheral devices

ein Standard für serielle Datenübertragung.

[Paul H. (powl)]

Na gut.. was solls, lass ichs halt so es funktioniert ja. Beim nächsten 
Projekt nehm ich einfach Pull-Ups oder implementier ein eigenes 
Protokoll in Software.

[MCUA (Gast)]

>>>RS232 ist eine serielle Schnittstelle
>> Falsch.
>> RS232 ist nur eine physikalische U-Pegel-Festlegung.
>> Das hat nicht das geringste mit parallel/seriell - Protokoll zu tun.
> Quatsch.  RS-232 ist ...
> ein Standard für serielle Datenübertragung
Falsch.
Es sind dort NUR physikalische (U,I,R-Werte und SlewRate) definiert.
Mit Bit/Byte/Word/Packet/Sonst-Protokoll hat das NICHTS zu tun.
Ausserdem: Ein MAX232 kann sich für ein Bit/Byte/Word/Packet-Protokoll 
schon PRINZIPIELL nicht interessieren können, da er die 
In-Out-Spannungs-Werte nur physikalisch umsetzt.
Also was bitte soll das mit Bit/Byte/Word/Packet/Sonst-Protokoll zu tun 
haben???

[Hc Z. (mizch)]

Was soll das bitteschön?  Ich habe nie behauptet, dass die seriellen 
Parameter in RS-232 festgelegt sind.  Aber dass es eine serielle 
Schnittstelle sei.

Worauf Du behauptet hast:
> RS232 ist nur eine physikalische U-Pegel-Festlegung.
> Das hat nicht das geringste mit parallel/seriell - Protokoll zu tun.

Was schlicht und einfach Unfug ist.  Weder beschreibt RS-232 bloß die 
„physikalischen U-Pegel“ - es geht weit darüber hinaus und beschreibt 
die einzelnen Signale einer seriellen Schnittstelle - noch hat es „nicht 
das geringste mit parallel/seriell - Protokoll“ zu tun.  Es beschreibt 
sehr wohl ein serielles Schnittstellenprotokoll inklusive der Handshake- 
und sonstigen Signale, nur nicht die Parameterdetails der 
Datenleitungen.

Könntest Du diese kindische Rechthaberei jetzt einfach lassen?  Für mich 
mache ich jedenfalls hier einen Punkt, bevor es lästig wird.

[MCUA (Gast)]

>Was soll das bitteschön?
Na ein Richtigstellung.
>Es beschreibt sehr wohl ein serielles Schnittstellenprotokoll
Nein. Seit wann sind Leitungen ein Protokoll ???
(über die Leitungen können alle möglichen Protokolle laufen)

Ein Auto hat Räder, aber nicht alles was Räder hat ist ein Auto.
Und RS232 ist KEIN "Auto", sondern es sind lediglich die "Räder".
Und wenn jemand Räder benutzt, kann er nicht (wie du) sagen, er benutzt 
Autos.

[Paul H. (powl)]

So. Übrigens, warum sollte sich RS-232 bzw. der UART nicht für einen Bus 
benutzen lassen? Auch wenn das die Spezifikation von RS-232 nicht 
vorsieht. Bei einem Softwaretechnisch realistierem Bus-System macht der 
AVR auch nichts anderes.

Der UART hat sogar einen Multi Processor Communication Mode. Den hatte 
ich zunächst auch verwendet, war aber schlichtweg overkill dafür, dass 
immer die gleichen Datenpakete zu gleichen zeitlichen Abständen hin und 
hergesendet werden.

[Blackbird (Gast)]

V.24 beschreibt das Verhalten der einzelnen Signale der 
RS232-Schnittstelle. RS232 hat mit Protokoll nix zu tun, genauso wie 
RS485 oder RS422 nur die Pegel/Zeiten etc. und nicht die Protokolle 
beschreiben.

@Paul, wie sind den die Sender bei Deinem "Bus" zusammengeschaltet?

Blackbird

[Paul H. (powl)]

Wie gesagt an allen AVRs ist TX und RX verbunden, daneben ein 
niederomiger Pulldown um mit den anderen AVRs Stromschleifen zu bilden. 
Das ganze dann jeweils mit einer gemeinsamen Busleitung verbunden.

Also der Bus funktioniert, jedoch habe ich ständig low auf dem Bus 
liegen wenn grad kein Sender aktiv ist, was direkt beim Abschalten des 
Senders allen Busteilnehmern ein gerade gesendetes Byte vorgaukelt. Das 
wird sich wohl auch nicht verhindern lassen, dazu muss der Bus 
high-aktiv werden, ergo brauche ich Pull-Ups. Das ist nun aber alles 
nicht so schlimm, habe daraus gelernt und es läuft ja.