Hi, weiß jmd von euch ob ein 72MHz Prozessor ST schnell genug ist um DMX Daten von USB auf 5x UARTS zu senden bzw. zu empfangen? Hab nämlich gerade die Rückinfo bekommen von Enttec das mit den FTDIs das Receiven von DMX nicht möglich ist :-(... Jetzt suche ich dringend nach einer Alternative für 4x DMX Ein/Ausgänge. Gruß Bernd
Bernd schrieb: > Hab nämlich gerade die Rückinfo bekommen von Enttec das mit den FTDIs > das Receiven von DMX nicht möglich ist :-(... Naja, die wollen halt, daß Du ihr Zeugs kaufst. Ein kurzer Blick auf die FTDI-Seite: mit 4 UARTs ist der FT4232H wohl Dein Chip. USB: bis 480MBit UART: bis 12MBaud Also über läppische 4 * 250kBaud lacht der nur. Peter
Peter Dannegger schrieb: > Ein kurzer Blick auf die FTDI-Seite: mit 4 UARTs ist der FT4232H wohl > Dein Chip. Das ist völlig richtig von dir erkannt, nur leider schaffe ich es nicht den DMX-Break mit diesem FT4232H IC zu erkennen.
hier noch der thread in dem ich auch einen Code gepostet habe, mit dem es meiner Meinung funktionieren sollte: aber leider bekomme ich die CE_BREAK Notification viel öfters geliefert als der Break im DMX Signal wirklich ankommmt. Beitrag "FTDI: DMX Rx Break detection"
Bernd schrieb: > Das ist völlig richtig von dir erkannt, nur leider schaffe ich es nicht > den DMX-Break mit diesem FT4232H IC zu erkennen. Ich hätte vermutet, daß die UARTs als standard 16550-UART emuliert werden. Und dann ist Bit 4 im Line Status Register das Break-Indikator Bit. Der Windows Treiber sollte ja ne Funktion zum Status lesen bereitstellen. Peter
das Problem ist dass diese Break zwar erkannt wird (mit FT_W32_WaitCommEvent()), aber wenn ich im Anschluss daran die Daten auslese (mit FT_W32_ReadFile()), das DMX-Startbyte sonst wo liegt im Buffer, aber nicht an erster Stelle.
hier hab ich grad mal was interessantes gefunden über diese FTDI Devices, was genau mein Problem wiederspiegelt:
1 | USB-Serial converters are generally a very bad solution - at least with the devices available today. They are known for their very bad design and drivers. No USB-Serial converter today has an 11-bit receiver FIFO, which is necessary to maintain the synchronization between bytes and flags, and the automatic flow control may be so limited that it is useless in practice. Especially, we will warn against the big majority of USB-serial converters, which use chips from Future Technology Devices International Ltd. (FTDI) like the FT232(x) series: |
http://max-i.org/testprogram.htm Vielleicht hat schon mal jmd diesbezüglich Probleme gehabt: Gruß Bernd
"USB-Serial converters are generally a very bad solution - at least with the devices available today. They are known for their very bad design and drivers. No USB-Serial converter today has an 11-bit receiver FIFO, which is necessary to maintain the synchronization between bytes and flags, and the automatic flow control may be so limited that it is useless in practice. Especially, we will warn against the big majority of USB-serial converters, which use chips from Future Technology Devices International Ltd. (FTDI) like the FT232(x) series:" Hier nochmal der Text
Bernd schrieb: > weiß jmd von euch ob ein 72MHz Prozessor ST schnell genug ist um DMX > Daten von USB auf 5x UARTS zu senden bzw. zu empfangen? Mal zurück zu deiner Ursprungsfrage: Ja, schnell genug sind die allemal, insbesondere wenn du sinnvoll die DMA-Kanäle nutzt.
Vor vielen Jahren mal habe ich einen USB Datenspion entwickelt, der exakt die ankommenden V24-Daten beider Datenrichtungen incl Flags aufzeichnet. Es waren schlussendlich 2 Bytes je Kanal. - Datenbyte - Statusbyte incl Richtungs-Bits Das geht nur mit einer extra Hardware. Ein STM32 reicht für diese Aufgabe aus. Er kann 12MBaud Full Speed USB, das sollte reichen. Allerdings muss man mehrere USB Endpoints benutzen, am besten einen je UART-Kanal. Man muss sich bewust sein, dass der PC (Host)den USB Triggert aber der STM32 den Datenbuffer freigeben muss. Der PC Triggert die USB Kommunikation alle 1ms, dabei kann ein Datenframe sowie das "double Buffered" Frame übertragen werden. Um USB zu Proggen ist etwas Hintergrundinfo schon nett zu wissen, steht in der Doku der USB Organisation. Damit kann man den Code effizienter gestalten, ansonsten hat man tatsächlich Probleme die Daten rüber zu schaufeln. (Dieses Problem haben alle Prozessoren)
Christoph Budelmann schrieb: > Mal zurück zu deiner Ursprungsfrage: Ja, schnell genug sind die allemal, > insbesondere wenn du sinnvoll die DMA-Kanäle nutzt. Hast du diese Prozessoren schon mal eingesetzt??? Ich möchte ungern nocheinmal so einen Bug haben, der dann dazu führt wieder auf eine andere Schiene umsteigen zu müssen... Gerade was USB, UART, Timer, DMA und Interrupts angeht. Ich weiß ja nicht wie genau und ausführlich diese Errata-Sheets immer sind
Bernd schrieb: > Hast du diese Prozessoren schon mal eingesetzt??? Ich möchte ungern > nocheinmal so einen Bug haben, der dann dazu führt wieder auf eine > andere Schiene umsteigen zu müssen... Ja, wir setzen die recht häufig ein. USB, UART, CAN, DMA, fast alles über Interrupts, funktioniert sehr gut. > Gerade was USB, UART, Timer, DMA und Interrupts angeht. Ich weiß ja > nicht wie genau und ausführlich diese Errata-Sheets immer sind Bei den 103ern hatten wir keinerlei Probleme, auch die Errata halten sich in Grenzen. Schwierig war der Einstieg mit den 105ern (2x CAN und USB gleichzeitig), da diese einen Bug im Bootloader hatten und der für uns wichtig war. ST hat das leider erst recht spät in das Errata Sheet aufgenommen, was uns einiges an Zeit gekostet hat. Das Problem tritt aber bei neuen Prozessoren immer mal auf, die 103er sind inzwischen aber schon recht etabliert.
Bernd schrieb: > Hast du diese Prozessoren schon mal eingesetzt??? Ich möchte ungern > nocheinmal so einen Bug haben, der dann dazu führt wieder auf eine > andere Schiene umsteigen zu müssen... Ich bin mit dem STM32 so sehr zufrieden, dass ich keinen anderen mehr nehmen möchte. Ich habe USB, UART, CAN und sonst alle anderen Module bereits genutzt. Siehe auch Artikel STM32 Da stehen viele wertvolle Tipps drin.
noch eine kleine zusätzliche Frage zu dem SMT32F103xV Prozessor: unterstützt dieser auch JTAG Chaining? Anhand welchen Merkmalen lässt sich das aus einem Datenblatt herausfinden?
Angehängte Dateien:
-
Bild1.png
29 KB
Der Segger J-Link kann das. Anbei ein Auszug aus deren Doku. Ich selbst habe das nie probiert. Einfach mal bei Segger anrufen ob das auch mit dem STM32 geht. Wenn Platzprobleme herrschen, dann empfehle ich diese JTAG Steckerbelegung: http://www.mikrocontroller.net/articles/JTAG#Der_10-polige_JTAG_Stecker_von_mmvisual
zum Programmieren verwende ich das Ulink2, welches das JTAG Chaining auf jeden Fall unterstützt. Aber der Prozessor muss es soweit ich weiß auch unterstützen. Bzw. nicht jeder Prozessor unterstützt JTAG Chaining. Aber wie gesagt, das ist jetzt auch komplett Neuland für mich. Bis jetzt hatte ich immer den notwendigen Platz für die JTAG Buchse. Gruß Bernd
Oder Du nimmst SWD (Single Wire Debug) dann reichen 5 Drähte. Mit SWD und meinem JLink hatte ich schon Probleme, liegt wohl daran, dass mein JLink nicht das aktuellste Modell ist. Ansonsten mal beim Ulink2 Hersteller nachfragen, der kann sicher Auskunft geben.
Markus Müller schrieb: > Ansonsten mal beim Ulink2 Hersteller nachfragen, der kann sicher > Auskunft geben aber der IC selbst unterstützt das JTAG Chaining?
Markus Müller schrieb: > Man muss sich bewust sein, dass der PC (Host)den USB Triggert aber der > STM32 den Datenbuffer freigeben muss. Der PC Triggert die USB > Kommunikation alle 1ms, dabei kann ein Datenframe sowie das "double > Buffered" Frame übertragen werden. Ich denke dass ein größeres Zeitintervall von ca. 16ms effizienter sein wird. Da ich ja die Daten per Bulktransfer übertragen werde und gleich ein komplettes DMX-Datenpaket (513 Bytes). Die Information, wann ein Break im DMX Signal aufgetreten ist, muss ich in diesem Fall nicht mitübertragen (USB), sondern nur die reinen Daten, so dass immer das Startbyte dem ersten Wert im Bytebuffer entspricht.
Wegen > aber der IC selbst unterstützt das JTAG Chaining? Frage doch im STM32 Forum, dort antworten direkt auch die Experten von ST. (In der Doku habe ich auf der schnelle nichts gefunden, deren Antwort würde mich auch interessieren.) 16ms ist kein Problem. Die CPU wird dann einfach nach 16ms das Paket für den Versand freigeben, der PC holt es dann ab, spätestens nach 1ms, wenn die nächste Anfrage läuft. In der Zwischenzeit kann ein zweiter 512 Byte Buffer beschrieben werden (oder man speichert die Daten im RAM).
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.