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
Lt. Datenblatt Mode 4 in UxMODE setzen: "0100 = Asynchronous 9-bit UART with address detect, ninth bit = 1 signals address"
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
Ge E. schrieb: > jetzt habe ich aber nen Master > der nur 8 Bit RS-485 unterstützt. Also doch kein dsPIC33CK256MP506, warum schreibst Du das dann? Du mußt schon den konkreten Typ nennen! Bei einer 16550 UART (PC) kann man die Parität entsprechend setzen, d.h. man muß sie vor jedem Byte passend ausrechnen.
natürlich ist der Slave ein dsPIC33CK256MP506!!! Sonst würde ich es ja kaum scheriben. Der Master eine WAGO von SPS gesteuert kann allerdings nur 8 Bit. Was selten dämlich ist. 485 sollte immer 9 Bit sein
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
der master ist kein PC sondern ne WAGO. Die können alle nur 8 Bit RS-485.. was eben zur Folge hat das bei jedem Byte was beim Slave (dsPIC) rein kommt ein Int aufgerufen wird. Was doof ist..
Ge E. schrieb: > was eben zur Folge hat das bei jedem Byte was beim Slave > (dsPIC) rein kommt ein Int aufgerufen wird. Was doof ist.. Damit wirst Du dann aber leben müssen. Was spricht denn "die Wago" für ein Protokoll? Macht das Ding zufälligerweise Modbus?
Wenn die SPS keine 9Bit-Lib hat, dann gehts eben nicht. Harald K. schrieb: > Macht das Ding zufälligerweise Modbus? Wäre eine Möglichkeit. Das Modbus Protokoll muß natürlich jeder Slave parsen, die nicht adressierten können die Daten verwerfen. Das sollte aber für so einen dicken Boliden keine merkbare Interruptlast darstellen.
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.
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
Ge E. schrieb: > Ist halt Kacke wenn ich den PIC nicht dazu bringe sich nur > bei seiner Adresse angesprochen zu fühlen. Man kann sich auch für 2 Euro einen ATmega328PB oder einen anderen uC mit 2 UARTS leisten, der alle Sendungen mit 8-bit-Protokoll entgegennimmt, mit 9-bit-Protokoll weiterleitet und umgekehrt. Gruß Klaus (der soundsovielte)
Jup das könnte ich machen, habe aber keinen Platz dafür.. Evtl besser einen 33CH mit zwei Cores
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.