Hallo, ich bin momentan dabei das GLM Netzwerk, ein Management Bus von Genelec zur Steuerung von aktiv Boxen, zu analysieren. Die Grundlagen des Protokolls hab ich soweit verstanden. Wenn da jemand Interesse dran hat kann ich die Erkenntnisse gerne teilen. Eigentlich wollte ich einen ESP32 verwenden um mich in den Bus einklinken zu können, nur der kann kein 9N3, ein doch sehr ungewöhnliches Format. Nun, der von Genelec verwendete STM32F407VG kann es auch nicht. Also wie machen die das? Welche Option habe ich übersehen? Die Daten: 288 kBaud 9 Datenbits, keine Parity, 3 Stopbits MSB (Bit 9) ist der Address indentifier, also nur high wenn die Datenbits eine Adresse sind. Terminator ist 0x7F (DEL) Hardware Ebene: RS-485 half-duplex, keine hardware flow control. Man könnte mit Pulsen auf den CTS Pin eine Art drittes Stopbit erzwingen, das wäre allerdings sehr durch die Brust ins Auge. Danke Johannes
9 Bits gehen aber grundsätzlich? Die Stopbits sind ja nie ein Problem. Du musst ja nur das Senden des nächsten Bytes passend verzögern, dann hast 3 Stopbits. Für den Empfänger ist das nicht unterscheidbar.
9 Bits gehen, zumindest wenn man Hardwarenah programmiert und nicht die Arduino Umgebung nutzt. Das Timing in Software zu erledigen würde auch gehen, aber warum sollten die das bei einem µC mit FIFO, DMA und allen anderen Helferlein tun? Es gibt viele Wege die Stopbits zu verlängern, nur warum? Deswegen vermute ich noch, das ich etwas übersehen habe.
Mit 9N1 kann der F407 das sehr effizient, mit HW Adressdekodierung und DMA gibts nur einen Interrupt beim Empfang eines Pakets mit bekannter Länge. Wie man da drei Stoppbits reintrickst habe ich aber auch noch nicht gesehen, soll das störsicherer werden oder langsamer HW eine Chance geben? Der F407 schafft da sogar 10,5 MBit/s, die F7 nochmal das doppelte.
RS-485 Halb-Duplex braucht ja ein Driver Enable und das darf erst nach dem Ende des letzten Stopbits abgeschaltet werden. Der 407 kann das wohl nicht per Hardware, also muss die Software nach dem letzten Byte noch auf Transmit Complete warten. Normal benutzt man aber den TXE Interrupt. Vielleicht war es einfacher, immer ein Bit länger zu warten. Wenn man einen Timer- statt dem UART-Interrupt benutzt, könnte das ein paar Befehle sparen. Und dann gibt es nach jedem Byte eine Driver-Disable-Angst-Pause... Ein gutes UART (nicht die STM32) kann 9N3 indem man 9S2 einstellt, also 9 Daten, Space-Parity und 2 Stopp.
Ich sollte mir wohl doch mal den Driver enable und ein paar weitere Signale im original Interface angucken. Evtl wird es dann logisch. Andererseits habe ich schon genug verstanden um die Dinge, wie Lautstärke etc die mich interessieren ändern zu können, nur dann mit einem 9N3 mit Software timing. Die Ursache für das 9N3 und die Adress vergabe auch noch verstanden zu haben wäre ein schönes Sahnehäubchen der Dokumentation willen.
Man kann die Übertragung der einzelnen Bytes per Timer "anstossen". Dann geht auch 9N4,7 ;-)
Wenn Du nur schreiben willst, dann kannst Du Dir den Datenstrom als 9N3 im Speicher bitweise zusammenbauen und das ganze über SPI raushauen. Dem Empfänger ist ja egal, ob die Daten von einem UART kommen oder nicht.
Olaf schrieb: > Klingt nach einer Anwendung fuer den Propeller. :-D Klar, weil Du einen Aspekt Deines Bausteins noch nicht verstanden hast greifst Du zu einem komplett neuen Baustein. <Stirnrunzeln/>
Uwe Bonnes schrieb: > STM32 kann auch CTS/RTS durch Hardware bedienen/beobachten. Kann man RTS als Driver Enable missbrauchen? Ich glaube nicht. Die neueren STM32 können statt RTS auch DE erzeugen, dann geht das. Weiß man denn überhaupt, ob 9N3 zum Protokoll gehört? Vielleicht macht nur dieses eine Gerät eine kleine Pause und 9N1 würde auch funktionieren?
Argh, die F4 Serie hat noch die alte U(S)ART IP. Ab F3 gibt es auch DE.
Die 288 kBaud können bei geringem MCU Takt und IRQ statt DMA getrieben schonmal aussehen wie 9N3. Der IRQ braucht ja etwas bis er behandelt wird und dann muss ja noch ein Byte aus einer FIFO gepopelt werden. Kommt das mit den 9N3 durch Beobachtung am Oszi oder steht das irgendwo niedergeschrieben? Daher einfach mal probieren ob der Empfänger (also die Box) auch bei 9N1 deine Befehle erkennt.
Welcher Prozessor steckt denn in der originalen Hardware und mit welchem Takt wird er betrieben? Wenn dort immer der Transmission-complete-IRQ benutzt wird, kann das schon wie 9N3 aussehen. Thomas
> Welcher Prozessor steckt denn in der originalen Hardware und mit welchem > Takt wird er betrieben? DAs hab ich mich auch schon gefragt. 9N3 ist ja dasselbe wie 9N1 bloss mit etwas Zeit zwischen den Bytes. Es kann also sein das ein Empfaenger sowas vorschreibt weil er zu langsam ist. Man kann es ja mal mit 9N2 probieren und wenn das nicht geht dann noch etwas warten. Bei 115k2 wohl okay, bei 300B eher nicht. :) Olaf
Die 9N3 sind eine Beobachtung mit dem Oszi. Der STM32F407 kann 168 MHz. Der UART läuft mit 8 oder 12 MHz, bzw bis zu 16 fachem Oversampling, müsste ich ausprobieren zu welchem Zeitpunkt ein neues Startbit möglich ist. Vom Raster das der UART kann, könnte das Zufall sein, das es wie 3 Stopbit aussieht es aber nur die Verzögerung durch eine IRQ Ablaufsteuerung ist. Nur bei 168 MHz zu 288 kBaud sind das schon eine Menge Befehle die für eine solche Verzögerung nötig wären. Ich denke die Boxen werden auch 9N1 und 9N2 verstehen. Hätte ja sein können das ich Option xyz übersehen habe, die als Nebeneffekt 3 Stopbit hat, die mir dann wiederum andere Eigenarten des Protokolls verrät. Wie gesagt, auch 9N3 bekommt man irgendwie hin, nur hat Genelec das extra so gemacht und wenn warum, bzw wodurch kommt das zu stande? Vielen Dank für die Ideen und Anregungen.
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.