Hallo zusammen, ich benötige eine UART die bei 115200 Baud extended Frames unterstützt, dabei werden nicht 8-Bit + Parity sonder 9-Bit + Parity übertragen. Das 9. Bit dient zur Unterscheidung zwischen Data oder Command. Die Atmel AVR unterstützen dies noch, ich muss aber einen STM32 benutzen. Eine SW-UART fällt leider raus, da ist der µController fast ausgelastet. Ich habe noch nach UART<->SPI IC geschaut aber nichts gefunden. Vielleicht könnt ihr mir noch mit einer Idee weiterhelfen?
Uwe schrieb: > Ich habe noch nach UART<->SPI IC geschaut aber nichts gefunden. Vorschlag: Nimm einen AVR der genau einen UART <-> SPI IC darstellt. Wäre das vielleicht eine Idee? Bewusst kenne ich leider auch keinen IC, der UART <-> SPI macht aber beim AVR ist das ja nur eine Programmfrage ;)
Externe serielle (I2C/SPI) 9 Datenbits kenne ich auch nicht. Aber man kann ja z.B. einen kleinen AVR benutzen. Da taucht aber wieder das blöde AVR-SPI-slave-Problem auf. I2C?
@Uwe (Gast) >AVR unterstützen dies noch, ich muss aber einen STM32 benutzen. Und der kann das nicht? buuuuhhhh! >Ich habe noch nach UART<->SPI IC geschaut aber nichts gefunden. Was nichts gefunden? Keinen externen UART oder keinen, der 9Bit + Parity kann? Ich hab mal den MAX3100 benutzt, der kann aber auch nur 8+P. https://www.maximintegrated.com/en/products/interface/controllers-expanders/universal-asynchronous-receiver-transmitter-uart.html Hier gibt es aber scheinbar auch keinen 9+P. Ist halt SEHR exotisch.
Hallo, einen zusätzlichen AVR zu verwenden ist wahrscheinlich das einfachste. @Falk ich habe keinen gefunden der 9-Bit + Parity kann.
H.Joachim S. schrieb: > Aber man kann ja z.B. einen kleinen AVR benutzen. Da taucht aber wieder > das blöde AVR-SPI-slave-Problem auf. Wenn ich das richtig lese, hat der ATtiny814 einen SPI-Sendepuffer. D.h. der Slave kann schon das nächste Byte reinschreiben, wärend der Master das vorherige Byte abholt. Ohne Puffer hätte er dazu nur 0,5 Bitzeiten Zeit.
> Aber man kann ja z.B. einen kleinen AVR benutzen. Da taucht aber wieder > das blöde AVR-SPI-slave-Problem auf. So blöde ist das nicht, denn der SPI hat in Empfangsrichtung einen Puffer. Und da es nur um 115kBaud geht, muss das SPI nicht mit 10 MHz ohne Pause laufen. Wenn man weiß was man tut, macht man nach dem CS einfach eine Pause von ein paar us, in welcher der AVR seine Daten ins SPI-Senderegister schreiben kann. Und last but not least kann man einen AVR mit 2 UARTs nehmen, um vom 9+P auf 2x8 Umzusetzen. Oder man nimmt den 2. UART im SPI-Modus, dann hat man Sende- und Empfangspuffer.
Uwe schrieb: > ich muss aber einen STM32 benutzen. Dumm gelaufen. Der ist bei mir mit genau dem Problem des 9. Datenbits aus der Liste der möglichen µCs geflogen. Die 9 Datenbits ohne Parity sehe ich öfters - manchmal auch als MARK/SPACE Parity. Aber mit effektiv 10 Datenbits gibts nur ganz selten einen UART. Dazu kommt dass dann die mögliche Baudratenabweichung deutlich kleiner als normal ausfallen muss - Quarze sind Pflicht. Aber bei 115200 kannste noch den UART in Software bauen - dafür sollte der STM32 schnell genug sein. Hast Du noch ein paar Timer frei...?
Falk B. schrieb: > Wenn man weiß was man tut, macht man nach dem CS > einfach eine Pause von ein paar us, in welcher der AVR seine Daten ins > SPI-Senderegister schreiben kann. Nö, das reicht nicht, die Pause brauchst Du vor jedem Byte. Wie gesagt, einige neuere ATtiny haben ein SPI mit einem Byte Puffer, damit sind 8,5 Bitzeiten Zeit. Die neuen AVR-Datenblätter sind allerdings grauenhaft. Etwas ausführlicher und präziser hätte nicht geschadet.
@Peter Dannegger (peda) >> Wenn man weiß was man tut, macht man nach dem CS >> einfach eine Pause von ein paar us, in welcher der AVR seine Daten ins >> SPI-Senderegister schreiben kann. >Nö, das reicht nicht, die Pause brauchst Du vor jedem Byte. Ok, nicht optimal, geht aber. Der AVR als UART-SPI Converter hat so oder so nix besseres zu tun, als auf des Ende der Übertragung zu warten. Wenn da zwischen den Bytes 1-2us Pause sind, kann man damit leben. Kurze Rechnung. Der AVR kann als Slave max. F_CPU/4 als SPI Takt verarbeiten, macht 4 MHz bei F_CPU = 16 MHz. Die Übertragung von 2 Bytes (9 Daten + Parity) dauert somit 4us + 2x2us Pause, macht 8us / UART-Wort. Das wiederum braucht (9+1+2) * 1/115200 = 104us auf der Leitung. Das SPI ist somit immer noch um Faktor 13 schneller. Sollte reichen. Und 2us Pause zwischen den Bytes sind 32 Takte. Die baucht der AVR nicht zum Nachladen, eher weniger als die Hälfte. Ich sehe gerade, der USART kann nur SPI-Master, nicht Slave. 8-0 Und wenn das alles nicht schön genug ist, nimmt man ein kleines FPGA mit internem Flash und bastelt sich seinen perfekten UART + FIFO + schönes SPI selber.
Uwe schrieb: > Das > 9. Bit dient zur Unterscheidung zwischen Data oder Command Nur senden oder auch Empfangen? Zum Senden braucht man kaum mehr als ein Schieberegister, Empfangen ist viel komplizierter. Für nur Senden ist auch Software zum Rausschieben völlig ausreichend. Georg
Peter D. schrieb: > Die neuen AVR-Datenblätter sind allerdings grauenhaft. Wieso? Die sind doch jetzt schönbunt :-) @Falk: es geht schon irgendwie, insbesonders wenn man Zugriff auf beide Seiten hat. Schön ist das jedenfalls nicht, ein paar meiner grauen Haare gehen auf Kosten der AVR-SPI. Und nach jedem Byte ne Pause einlegen zu müssen, ist nicht unbedingt im Sinne des Erfinders.
> Aber mit effektiv 10 Datenbits gibts nur ganz selten einen UART.
Kuckt ihr Silabs Gecko. Das koennt ihr alles von 4 bis 16Bit einstellen.
Olaf
@H.Joachim Seifert (crazyhorse) >gehen auf Kosten der AVR-SPI. Und nach jedem Byte ne Pause einlegen zu >müssen, ist nicht unbedingt im Sinne des Erfinders. Nein, aber das waren softwarelastige ICs bei SPI sowieso nicht. Zeig mir mal einen uC, der SPI als Slave so schnell und pausenlos wie eine reine Hardwarelösung bedienen kann.
Jim M. schrieb: > Aber mit effektiv 10 Datenbits gibts nur ganz selten einen UART Wenn man Lust zum Experimentieren hat, könnte man für den Empfang ja Folgendes probieren: Empfangen mit 8 Bit + Parity, Parity Error enthält die Information über das 9. Bit, Framing Error enthält die Information über die empfangene Parity. Ohne Garantie, kann auch bei jedem UART verschieden sein. Georg
Hallo zusammen, vielen Dank für die vielen Anregungen. Ich denke ich nehme einen AVR mit zwei UARTS und spendiere noch einen Portpin für Daten/Command auf der ST Seite. Dann muss ich mich nicht mit der SPI rumärgen.
> Nein, aber das waren softwarelastige ICs bei SPI sowieso nicht. Zeig mir > mal einen uC, der SPI als Slave so schnell und pausenlos wie eine reine > Hardwarelösung bedienen kann. 68332 mit TPU. Olaf
Angehängte Dateien:
-
USART1.PNG
37 KB -
USART2.PNG
30 KB
Welcher STM32 ist das? Also der STM32F303 kann 9 Bit UART und ich hab bisher keinen gesehen der es nicht kann.
TriHexagon schrieb: > Welcher STM32 ist das? Also der STM32F303 kann 9 Bit UART und ich hab > bisher keinen gesehen der es nicht kann. 9 Bit + Parity? Das Diagram sagt da was anderes.
@Olaf (Gast) >> Nein, aber das waren softwarelastige ICs bei SPI sowieso nicht. Zeig mir >> mal einen uC, der SPI als Slave so schnell und pausenlos wie eine reine >> Hardwarelösung bedienen kann. >68332 mit TPU. Ja, mit TPU, das ist Beschiss! ;-)
Angehängte Dateien:
-
USART3.PNG
24 KB -
USART4.PNG
54 KB
Mhm du hast recht, allerdings sieht das Diagramm für 8Bit genauso aus. Aber im USART Frame Format Diagramm ist es eindeutig beschrieben. Ok das ist natürlich dämmlich, wollte ST wieder sparen...
Uwe schrieb: > Das > 9. Bit dient zur Unterscheidung zwischen Data oder Command. Aus reiner Neugier, wofür braucht man das denn, welches Gerät verlangt so ein Format?
> Aus reiner Neugier, wofür braucht man das denn, welches Gerät verlangt > so ein Format? Viele. :-) Ich glaube die ersten die damit ankamen waren die MCS51 und da wurde es halt auch genutzt um zwischen Daten und Kommandos zu unterscheiden. Ich denke es wird einige propritaere Industriebusse geben die sowas noch immer verwenden. Und weil Industriekram oftmals 20Jahre und mehr genutzt wird muss man da durch. Bei etwas neuem wuerde man so etwas wohl auch nicht mehr verwenden. Olaf
Olaf schrieb: > Ich glaube die ersten die damit ankamen waren die MCS51 und da wurde es > halt auch genutzt um zwischen Daten und Kommandos zu unterscheiden. Ich > denke es wird einige propritaere Industriebusse geben die sowas noch > immer verwenden. Wenn das im Original ein 8051 war, dann sollte man sich eventuell die EFM8 von Silabs angucken - vielleicht kann man Quelltexte in Teilen übernehmen. Ich kenne den 9-Bit Modus auch - aber ohne weiteres Parity Bit. Fehlererkennung/Korrektur ist auf höherer Protokollebene oft besser angesiedelt.
Olaf schrieb: > Ich glaube die ersten die damit ankamen waren die MCS51 und da wurde es > halt auch genutzt um zwischen Daten und Kommandos zu unterscheiden. Nur ging 9Bit auch nur ohne Parity. Wollte man 8bit + Parity, mußte man das P-Bit nach TB8 kopieren, bzw. bei Empfang P mit RB8 vergleichen.
Wie ich schon gesagt habe die EFM32 von Silabs koennen alles von 4 bis 16Bit. Da gibt es keinen Grund mehr sich mit ollen MCS51 Kamellen abzugeben. Und wo wir schon mal dabei sind, die M16C von Renesas koennen es auch. So selten ist das garnicht. Man muss nur mal ein bisschen ueber den gewohnten Horizont hinausschauen. Allerdings die RX koennen es nicht mehr. olaf
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.