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?
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.
@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
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! ;-)
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
