Hi,
ich stehe aktuell vor einem kleinen Problem. Konkret empfange ich Daten
per Funkmodul auf einer Uart und möchte sie beim empfangen auf einer
anderen Uart über RS485 weiterleiten.
Bei RS485 ist in dem Fall noch zu berücksichtigen, dass halbduplex
übertragen wird und somit noch die Sende/Empfangsrichtung des MAX485
entsprechend beachtet werden muss.
Im Idle Zustand soll der Max485 empfangen und nur für das weiterleiten
der über Funk empfangenen Daten die Richtung wechseln.
Die Übertragung findet sowohl auf der Funk- als auch RS485 Strecke mit
19200 Baudrate statt.
Bisher habe ich folgende Ansätze ausprobiert:
1
ISR(USART1_RX_vect){
2
uint8_tdata;
3
data=UDR1;
4
5
// debug count to check for lost bytes
6
uart_count++;
7
// add data to ringbuffer for later use
8
uart_ringbuff_add(data);
9
10
set_rs485_driver();// set MAX485 to driver mode
11
12
UCSR0A|=(1<<TXC0);// clear USART Transmit Complete Flag
13
while(!(UCSR0A&(1<<UDRE0))){};// wait until buffer is empty
14
UDR0=data;// forward data by RS485
15
while(!(UCSR0A&(1<<TXC0))){};// wait until transmit finished
16
17
reset_rs485_driver();// switch MAX485 back to receiver mode
18
}
Variante 2:
1
ISR(USART1_RX_vect){
2
uint8_tdata;
3
data=UDR1;
4
5
// debug count to check for lost bytes
6
uart_count++;
7
// add data to ringbuffer for later use
8
uart_ringbuff_add(data);
9
10
set_rs485_driver();// set MAX485 to driver mode
11
12
UCSR0A|=(1<<TXC0);// clear USART Transmit Complete Flag
13
while(!(UCSR0A&(1<<UDRE0))){};// wait until buffer is empty
14
UDR0=data;// forward data by RS485
15
}
16
17
ISR(USART1_TX_vect){
18
reset_rs485_driver();// switch MAX485 back to receiver mode
19
}
In beiden Fällen gehen RX Interrupts verloren wenn einige 100 Byte
gesendet werden. Die Variante 1 blockiert in der ISR bis die Daten den
Sendepuffer verlassen haben (blockieren in einer ISR ist sowieso
schlecht). Wenn ich es dem Datenblatt des Atmega1281 richtig entnommen
habe besitzt die USART einen 1-Byte Eingangspuffer. Somit sollte gut
eine Zeichenlänge an Zeit vorhanden sein um den Interrupt abzuarbeiten
und das wird vermutlich zu knapp wenn im Interrupt auf die vollständige
Übertragung von einem Zeichen gewartet wird.
Variante 2 wartet nun allerdings nicht mehr aktiv auf das Ende der
Übertragung sondern nutzt den TX Interrupt um die Richtungsumschaltung
im Max485 zu realisieren.
Allerdings gehen auch hier Zeichen verloren. Hat jemand eine Idee wie
man das möglichst elegant und funktionierend umsetzen kann ?
Dir Richtungsumschaltung bei RS485 muss auf Protokollebene erfolgen.
Alles andere ist Murks. Falls es kein Protokoll gibt setzt man ein
Blockprotokoll drauf.
Zum Problem .. solche Dinge gibt es sowieso nicht :
while(!(UCSR0A & (1<<UDRE0))){}; // wait until buffer is empty
while(!(UCSR0A & (1<<TXC0))){}; // wait until transmit finished
while(!(UCSR0A & (1<<UDRE0))){}; // wait until buffer is empty
Nicht im normalen Code und sowieso nicht in einem Interrupt. Im
Interrupt ist das toedlich. Im obigen code ist nahezu alles ganz falsch.
Nochmals.
Nimm einen Ringpuffer pro Richtung und betreibe beide UARTs vollständig
interruptgetrieben. Die RX-ISRs füllen ihren Puffer, die TX-ISRs
schicken so lange Zeichen auf die Reise, bis ihre Puffer leer sind (und
schalten sich dann ab). Damit hältst du die ISRs kurz.
Kann es sein, dass du nach jedem Zeichen die Richtung wieder
zurückschaltest, und dir vielleicht darum Zeichen verloren gehen? Wenn
du nicht pausenlos überträgst, reicht es vielleicht, wenn du erst bei
leerem Sendepuffer wieder auf Empfang zurückschaltest.
UCSR0A|=(1<<TXC0);// clear USART Transmit Complete Flag
21
set_rs485_driver();// set MAX485 to driver mode
22
UDR0=data;// forward data by RS485
23
}else{
24
UCSR0B&=~(1<<UDRIE0);// no data left disable UDRE interrupt
25
}
26
}
27
28
ISR(USART0_TX_vect){
29
reset_rs485_driver();// switch MAX485 back to receiver mode
30
}
Der weiterzuleitende Datenstrom ist für mich nicht transparent. Die
Richtungsumschaltung auf Protokollbasis ist daher nicht möglich.
Ist der obige Ansatz soweit richtig ? Weiß jemand wie sich der TX
Interrupt in diesem Fall verhält ? Im UDRE Interrupt wird das TXC Flag
zurückgesetzt, die Richtung auf senden umgeschaltet und das Datenbyte in
das Senderegister geschrieben.
Die Frage ist nun was passiert bei einem "kontinuierlichen" Datenstrom
von sagen wir 30Byte. Führt das durch den kleinen internen Buffer der
Uart dazu, dass der TX Interrupt erst nach Übertragung der 30 Byte
ausgelöst wird oder passiert das in obigem Code dann wirklich nach jedem
übertragenen Byte ?
Gruß und Dank :)
>ISR(USART0_TX_vect) {
reset_rs485_driver(); // switch MAX485 back to receiver mode
}
Was soll das ? Der zugehoerende Code ist ja nicht so schwierig, dass man
ihn nicht rein-copy-pasten koennte.
Probier's doch einfach. Ich denk es geht nicht. Der Sender schaltet
einfach um, weiss die andere Seite davon? Woher sollte die andere Seite
davon wissen ?
Ich denke durch reset_rs485_driver(); wird schneller klar wass dort
gemeint ist aber das ist vermutlich Geschmackssache.
Die Richtungsumschaltung im logischen Sinn sollte keine Probleme machen.
Die Kommunikation erfolgt Master / Slave gesteuert.
Ich weiß das über Rs485 nur Daten zu mir gesendet werden, wenn per Funk
vorher ein Datenpaket mit einer Sendeaufforderung geschickt wurde.
Daher wäre der Ablauf immer identisch. Sender sendet über Funk
Datenpaket, ich leite es über RS485 weiter und stelle anschließend
wieder auf empfangen um.
Der Sender würde auch nicht auf die Idee kommen zwei Datenpakete zu
senden ohne vorher die Antwort des 1. Paket empfangen zu haben, oder
durch einen Timeout von einem Fehler auszugehen.
Daher sehe ich in der grundsätzlichen Handshakelogik auch kein größeres
Problem.
Klar ausprobieren werde ich es nachher. Allerdings sind hier ja einige
Profis unterwegs ie gravierende Probleme im Code vermutlich direkt
bemerken. Sonst läuft es nachher bei den Tests gut weil ich zufällig
Glück hatte und irgendwann fängt die große Fehlersuche an.
Es scheint also doch ein Protokoll vorgegeben zu sein. Das erhoeht die
Chancen, dass es laeuft. Jetzt muss nur die Umschaltung noch passend
gemacht werden. Naemlich wenn das Packet fertig ist, und nicht per
Zaehler, oder per Zeit.
Jede Funktion bedeutet ein push/pop, das nicht wirklich noetig ist. Ein
Comment bringt dasselbe Verstaendnis.
set_rs485_driver(); reset_rs485_driver(); sind Makros kein
Funktionsaufruf finde es nur schicker wenn sie wie einer aussehen.
Ich habe den Code gerade mal getestet. Das empfangen und umleiten der
Daten funktioniert jetzt grundsätzlich wie gewünscht.
Das Richtungsumschalten allerdings nocht nicht. Zumindest wird
ISR(USART0_TX_vect) während einer "lückenlosen" Datenübertragung des
Sender mehrfach aufgerufen.
Ja Protokoll gibt es schon aber ich weiß halt nicht wie groß die
einzelnen Pakete konkret sind.
Im Endeffekt liest es sich im Datenblatt aber schon so als wäre der TXC
Interrupt nahezu perfekt. Der Wird aufgerufen wenn ein frame vollständig
gesendet wurde also eigentlich der perfekte Zeitpunkt für den
Richtungswechsel.
Die Frage ist ob es denn überhaupt schadet wenn durch lücken kurzzeitig
wieder auf empfangen und kurz danach wieder auf senden gestellt wird.
Oder nehmen wir den schlimmsten Fall an und es würde vor jedem
gesendeten Byte die Richtung auf senden und im TXC Interrupt wieder auf
empfangen gestellt. Mag nicht schön wirken aber wo liegt dort das
"technische" Problem ?
Hi
>Im Endeffekt liest es sich im Datenblatt aber schon so als wäre der TXC>Interrupt nahezu perfekt. Der Wird aufgerufen wenn ein frame vollständig>gesendet wurde also eigentlich der perfekte Zeitpunkt für den>Richtungswechsel.
Ist es auch. Funktioniert problemlos.
>Das Richtungsumschalten allerdings nocht nicht. Zumindest wird>ISR(USART0_TX_vect) während einer "lückenlosen" Datenübertragung des>Sender mehrfach aufgerufen.
Dann scheint es doch zu 'lücken'.
MfG Spess
Hi,
ich habe jetzt einen ganze Zeit getestet folgendes passiert. (Code wie
im letzten Beispiel, lediglich UCSR0A |= (1<<TXC0); durch UCSR0A =
(1<<TXC0); gemäß Datenblatt durch ersetzt)
Das Zusammenspiel zwischen den Puffern klappt super. Es gehen jetzt
keine Daten mehr verloren. Alles wird empfangen und auch weitergeleitet.
Das Handshake funktioniert allerdings leider nicht. Lasse ich das
Handshake wie im obigen Code, dann gehen Daten auf der Rs485 Strecke
verloren / kommen falsch an. (ISR(USART0_UDRE_vect) wird trotzdem für
jedes Byte korrekt 1x aufgerufen)
Dann habe ich die Richtungsumschaltung auskommentiert und für Testzwecke
fest auf senden gesetzt.
Anschließend funktionierte das weiterleiten ohne Probleme. Das Problem
muss demnach beim Richtungswechsel auftreten.
Dabei habe ich nochmal im Datenblatt nachgelesen und dort steht
explizit:
"The TXCn Flag is useful in half-duplex communication interfaces (like
the RS-485 standard), where a transmitting application must enter
receive mode and free the communication bus immediately after completing
the transmission."
"The TXCn Flag can be used to check that the Transmitter has
completed all transfers, and the RXC Flag can be used to check that
there are no unread data in the receive buffer.
Note that the TXCn Flag must be cleared before each transmission (before
UDRn is written) if it is used for this purpose."
Wodurch entsteht genau das Problem im obigen Code ?
Hallo,
anstatt nach jedem Byte umzuschalten würde ich einen Timer verwenden.
Bei jedem Senden vorher auf Senden schalten und den Timer zurücksetzen.
Nach Ablauf des Timers auf Empfang zurückschalten. Die Zeit die du bist
zum Umschalten auf Empfang lässt hängt natürlich davon ab wie schnelle
die andere Seite am RS485 wieder senden will.
Sascha
Die Timer Idee hatte ich auch schon mittlerweile wird das Problem
allerdings interessanter. Noch immer ist der Code mit dem zuletzt von
mir gezeigten identisch.
Als Testaufbau habe ich an den RS485 BUS einen MAX485 zu FT232 Wandler
angeschlossen um den korekten Datenempfang auszuwerten.
Gesendet wurden zu Testzwecken 10 identische Pakete mit der Bytefolge:
0xFF 0xFF 0x48 0x54 0x98 0x01 0x01 0xC8 0x03 0x92 0x19
Dann habe ich angefangen und mir auf der Senderseite (obiger Code) das
Tx und das driver enable Signal angesehen.
Wie auf Bild 1 zu erkennen ist die DE Leitung anfangs auf empfangen
eingestellt. Mit dem senden der Pakete wird auf senden umgestellt.
Zwischendrin ist der Buffer leergelaufen, daher wurde die DE Leitung auf
Empfangen zurückgesetzt. Nachdem wieder Daten im Puffer waren erfolgte
wieder das umschalten auf Senden und am Ender der Übertragung wieder der
Wechsel auf empfangen.
Die Übertragungspause lässt sich auf Bild 2 recht gut erkennen.
Zeitlich liegt zwischen dem umschalten der DE Leitung bis zum Anfang der
Übertragung des nächsten Byte ca. 1,2µS.
Die gesendeten Bytes sind auf der Senderseite von der Wertigkeit her
korrekt, also keiner falsch gesendeten Bytes auf der Senderseite.
Für mich sieht der Richtungswechsel, als das anfänglich angedachte
Problem, soweit ordentlich funktionierend aus. Die Daten kommen
allerdings im PC Terminal teilweise falsch/fehlerhaft an.
Nachdem auf der Senderseite soweit alles recht gut aussieht habe ich mir
die MAX485 RO Leitung zwischen MAX485 und FT232 angesehen. Dort kommen
die fehlerhaften Bytes bereits an.
Auf Bild 3 müsste auf das Byte 0x92 das Byte 0x19 folgen
übertragen/erkannt wird aber 0x00. Auf Bild 4 lässt sich das Ende der
Datenübertragung sehen. Dort wird hinter dem Byte 0x19 nochmal 0x00
übertragen/erkannt. Die RO Leitung bleibt danach für die restliche Zeit
low ich hatte bisher die Annahme das der Ruhepegel dort high sein
müsste. Irgendwas ist dort komisch.
Ich kann mir da noch nicht wirklich einen Reim drauf machen auf
Senderseite sieht eigentlich doch alles gut aus oder ?
Hat jemand eine Idee was da schieflaufen kann, bzw was ich noch prüfen
könnte ?
Wenn man den TXComplete Interrupt verwendet, sollte man beachten ,dass
dann das letzte Bit des Bytes rausgeschoben ist, das Stoppbit allerdings
noch nicht. Nur falls das dann ein Problem waere.
Und man muss den TxComplete manuell zuruecksetzten mit Schreiben auf
dieses Bit, gemaess Datenblatt
Neue (gebufferte) Daten werden aber per TxEmpty ins UART geladen nicht
per TxComplete..
Bedeutet man verwendet beide, TxEmpty und TxComplete als Interrupt
Naja aber genau das was du beschreibst mache ich doch ?
USART0_UDRE wird in Zusammenarbeit mit USART0_TX verwendet.
Zurückgesetzt wird das TXC Flag wie im Datenblatt beschrieben vor dem
beschreiben von UDR0
1
ISR(USART1_RX_vect){
2
uint8_tdata;
3
data=UDR1;
4
5
uart_ringbuff_add(&tx_buff_uart0,data);
6
// trigger UDRE interrupt to transmit new data
7
UCSR0B|=(1<<UDRIE0);
8
}
9
10
ISR(USART0_UDRE_vect){
11
uint8_tdata;
12
if(uart_ringbuff_remove(&tx_buff_uart0,&data)){
13
if(!(PORTB&(1<<PB7))){
14
PORTB|=(1<<PB7);// set MAX485 to driver mode
15
}
16
UCSR0A=(1<<TXC0);// clear USART Transmit Complete Flag
17
UDR0=data;// forward data by RS485
18
}else{
19
UCSR0B&=~(1<<UDRIE0);// no data left disable UDRE interrupt
20
}
21
}
22
23
ISR(USART0_TX_vect){
24
PORTB&=~(1<<PB7);// switch MAX485 back to receiver mode
Hi
>Wenn man den TXComplete Interrupt verwendet, sollte man beachten ,dass>dann das letzte Bit des Bytes rausgeschoben ist, das Stoppbit allerdings>noch nicht. Nur falls das dann ein Problem waere.
Wie kommst du auf das schmale Brett?
Datenblatt
This flag bit is set when the entire frame in the Transmit Shift
Register has been shifted out and there are no new
data currently present in the transmit buffer (UDRn).
Zu einem vollständigen Frame gehört auch das Stopbit.
>Und man muss den TxComplete manuell zuruecksetzten mit Schreiben auf>dieses Bit, gemaess Datenblatt
Wenn eine Interruptroutine existiert wird das automatisch erledigt.
Datenblatt
The TXCn Flag bit is automatically cleared when a transmit
complete interrupt is executed, or it can be cleared by writing a one to
its bit location.
MfG Spess
Hallo,
hast du den RS485 Bus vorgespannt? Sonst kann es schon mal passieren,
das in dem Moment wo beide Seiten auf Empfang stehen ein undefiniertes
Signal rauskommt. In deinem 3. Bild sieht man ja auch irgend eine
Störung.
Sascha
Vorgespannt ist der Bus aktuell nicht.
Allerdings habe ich jetzt auf Senderseite DE und TX, sowie auf
Empfängerseite RX parallel aufgezeichnet.
Zusätzlich habe ich zwei kleine Delays eingebaut einmal nach den setzen
von DE und vor dem zurücksetzen vonn DE um besser sehen zu können was
passiert.
Das Problem tritt an der Stelle auf bei der gerade keine Zeichen mehr im
Sendepuffer liegen und auf Empfang umgestellt wird. Die Rx Leitung geht
während DE auf empfangen steht auf low. Wenn DE dann wieder auf senden
umgestellt wird geht Rx auf high und die Uart interpretiert das als
falsches Zeichen.
Lässt sich das irgendwie verhindern ?
Oder ist es eventuell genau das von dir beschriebene Verhalten ? Also
das zu dem Zeitpunkt beide Max485 auf Empfang stehen und dadurch jetzt
die Leitungsdifferenz als low angesehen wird und dadurch der high
Ruhepegel auf der RX Leitung nicht mehr zustande kommt ?
Uart schrieb:> Oder ist es eventuell genau das von dir beschriebene Verhalten ? Also> das zu dem Zeitpunkt beide Max485 auf Empfang stehen und dadurch jetzt> die Leitungsdifferenz als low angesehen wird und dadurch der high> Ruhepegel auf der RX Leitung nicht mehr zustande kommt ?
genau, wenn keiner sendet ist der Pegel undefiniert. Sobald am Empfänger
ungewollter Weise die Leitung auf L geht wird das vom Empfänger als
Startbit interpretiert.
Lege mal A mit 1k nach +5V und B mit 1k nach GND.
Sascha
>>Wenn man den TXComplete Interrupt verwendet, sollte man beachten ,dass>>dann das letzte Bit des Bytes rausgeschoben ist, das Stoppbit allerdings>>noch nicht. Nur falls das dann ein Problem waere.>>Wie kommst du auf das schmale Brett?>>Datenblatt>>This flag bit is set when the entire frame in the Transmit Shift>Register has been shifted out and there are no new>data currently present in the transmit buffer (UDRn).>>Zu einem vollständigen Frame gehört auch das Stopbit.
Ich hab's nachgemessen. Bei einem Master-Multislave Bus macht der Slave
den enable des Transceiver weg mit dem TXComplete. Dann fehlt jeweils
das Stopbit. Bei den AVR zumindest. War bisher aber noch nie ein
Problem.
Jetzt Nicht schrieb:> macht der Slave den Enable des Transceiver weg mit dem TXComplete.> Dann fehlt jeweils das Stopbit. Bei den AVR zumindest.
Das Stopbit stellt sicher, dass am Ende des Frames für mindestens eine
Bitzeit der Ruhepegel anliegt und dadurch das Startbit des folgenden
Frames erkannt werden kann.
Wenn die Strecke beim und nach dem Abschalten des Senders weiter den
Ruhepegel führt, ist diese Bedingung ebenfalls erfüllt.
Grüße
Stefan
Hi
>Ich hab's nachgemessen.
Würde mich mal interessieren.
>Bei einem Master-Multislave Bus macht der Slave>den enable des Transceiver weg mit dem TXComplete. Dann fehlt jeweils>das Stopbit.
Das würde unweigerlich zu einem Frame-Error führen. Vorausgesetzt die
USART-Fehler werden überprüft.
MfG Spess
Jetzt Nicht schrieb:> Ich hab's nachgemessen. Bei einem Master-Multislave Bus macht der Slave> den enable des Transceiver weg mit dem TXComplete. Dann fehlt jeweils> das Stopbit. Bei den AVR zumindest. War bisher aber noch nie ein> Problem.
Kann ich beim AVR nicht bestätigen. Gesendet wurde mehrfach 0x00. Das
enable wurde im TXC Interrupt zurückgesetzt.
Die Zeit nach der enable zurückgesetzt wird entspricht recht genau der
Zeit des Stopbit des vorherigen Byte.
Thread beobachten
Seitenaufteilung abschalten