dsPIC33C 8 Bit UART Adress Erkennung

OP #7564499
Lesenswert?

Servus, ich benutze einen dsPIC33CK256MP506. Ich habe früher immer mit 9 Bit RS-485 gearbeitet da hat die Adress Erkennung immer gut funktioniert. Jetzt muss ich das ganze mit 8 Bit realisieren. Laut Datenblatt ist das auch möglich.

Der Vorteil der Adress Erkennung liegt darin das der RX Interrupt nur bei erkannter Adresse aufgerufen wird und nicht bei jedem Byte das auf dem Bus kommt.

Auszug: "In 8-Bit Address Detect mode, the transmitted address IDs are written to Parameter 1. For receivers, the expected address is written to Parameter 2 (UxP2<7:0>) and the mask value to Parameter 3 (UxP3<7:0>). Mask bit values of ‘1’ will include the respective bit position in the compare, whereas a ‘0’ indicates a ‘don’t care’. A mask value of 0x00 will accept all address values, effectively disabling the address detect feature. A mask value of 0xFF will allow only one matching value."

Ich habe die Adresse beim Slave in U2P2 kopiert und 0xFF in U2P3 (da ich UART2 benutze)

Jedoch egal welches Byte ich vom Master aus sende, er ruft mir immer den U2RXInterrupt auf. Hab schon das ERRATA Sheet gewältzt.. nichts.. vlei benutzt jmd von euch diesen oder nen ähnlichen PIC und hat herausgefunden wies geht..

MFG

OP #7564506
Lesenswert?

ja im 9 Bit Modus funktioniert das auch.. jetzt habe ich aber nen Master der nur 8 Bit RS-485 unterstützt. Somit will/muss ich das 8. Bit als Adress Bit benutzen. Ich kann versuchen den Slave im 9 Bit Modus zu betreiben und sehen ob er mit den 8 Bits des Masters zurecht kommt

#7564536
Lesenswert?

Peter D. schrieb:

Bei einer 16550 UART (PC) kann man die Parität entsprechend setzen, d.h. man muß sie vor jedem Byte passend ausrechnen.

Das hat halt den Nachteil, daß man wirklich eine "echte" Hardware-UART dafür braucht, und diese nur im 8250/16450-Modus ohne SendeFIFO betreiben kann. Das wird dann halt recht langsam, bzw. es erzeugt eine hohe Interruptlast. Dazu kommt, daß beim Empfang für statistisch jedes zweite Byte ein Parity-Fehler signalisiert wird, was man entsprechend ignorieren muss.

Mit einem Devicetreiber üblicher Betriebssysteme will man so etwas nicht veranstalten.

Mit USB-UARTs wird das ganze noch unangenehmer, weil die durch das grundlegende USB-Protokoll die effektive Datenrate auf ein paar hundert Byte pro Sekunde reduzieren, denn für jedes zu sendende Byte ist ein separates USB-Kommando zu verwenden (und für das Umschalten der Parity ebenfalls). Und das ist 'ne Geschichte, die man nur mit direkter Ansteuerung der USB-UART überhaupt machen will, nicht aber durch einen Devicetreiber eines Betriebssystems hindurch.

Es gibt aber eine Lösung: Einfach eine /passende/ USB-UART verwenden.

Von MaxLinear (ehemals Exar) gibt es USB-UARTs, die den 9-Bit-Betrieb unterstützen. Die brauchen natürlich ihre eigenen Devicetreiber dafür, aber immerhin:

https://www.maxlinear.com/products/interface/uarts/usb-uarts

#7564684
Lesenswert?

Peter D. schrieb:

Das sollte aber für so einen dicken Boliden keine merkbare Interruptlast darstellen.

Die ist ja nun unabhängig vom Protokoll, ob das Modbus oder was auch immer ist; die Dinger müssen alles, was über den Bus geht, mithören, um herauszufinden, ob sie gemeint sind.

Aber das schaffen auch 8-Bit-Mikrocontroller, sofern man keine allzu bizarren Vorstellungen von der zu verwendenden Baudrate hat.

OP #7565251
Lesenswert?

genau, egal ob Modbus oder nicht das Protokoll spielt für mein Problem keine Rolle. Ist halt Kacke wenn ich den PIC nicht dazu bringe sich nur bei seiner Adresse angesprochen zu fühlen. Es laufen noch einige andere Zeitkritische Sachen im PIC ab.. aber ich meine es wird schon gehen. Finds halt maximal Suboptimal

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren