Forum: Mikrocontroller und Digitale Elektronik Mikrocontroller mit 16-Bit-UART


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Terence S. (takeshi)


Lesenswert?

Kennt jemand einen Mikrocontroller, der ein UART-Modul besitzt, das eine 
längeren Wert als 8 Bit unterstützt? Es gibt ja doch noch einige 
Hersteller, auch weniger verbreitete.

Eine Antwort auf die Frage, falls einer bekannt ist, reicht mir 
eigentlich schon. Aber da sowieso Nachfragen und Belehrungen kommen 
werden, für die Leute gleich der Hintergrund:

Rein technisch spricht nichts dagegen, ein UART-Übertragung mit mehr als 
8 Bit aufzubauen. Die Begrenzung auf 8 Bit stammt noch aus einer Zeit, 
als die Taktquellen nicht so genau waren und daher die Synchronität über 
mehr als 8 Bit nicht gewährleistet werden konnte. Aber die Zeiten haben 
sich geändert und ich bin mir sicher, 16 Bit am Stück wären heute locker 
möglich.

Die Hersteller bauen heute jeden Firlefanz in ihre Mikrocontroller ein, 
aber ein UART-Modul mit mehr als 8 Bit ist mir dabei noch nicht 
untergekommen. Mir ist klar, dass das nicht kompatibel mit dem üblichen 
Standard ist, aber wer klassische Hardware ansprechen will, stellt 
einfach nicht mehr als 8 Bit ein, fertig.

Die Übertragung längerer Wörter hätte Vorteile. Bei einer Aufteilung in 
2x 8 Bit müssen die beiden Bytes maskiert werden, die beiden Bytes 
sicher zu unterscheiden, was bei einem Übertragungsfehler wichtig ist. 
Für 16 Bit wären damit sogar 3 Pakete notwendig. Die Nettodatenrate wäre 
bei gleicher Baud-Rate höher, weil Overhead (wie Start- und Stopp-Bits) 
wegfallen. Also warum das kein mir bekannter Hersteller vorsieht, 
erschließt sich mir nicht.

Für Übertragung von Messwerten zwischen zwei MCUs über UART, die schon 
an die Grenzen der Baud-Rate gehen, wäre das ganz nett.

von Rainer W. (rawi)


Lesenswert?

Terence S. schrieb:
> Für 16 Bit wären damit sogar 3 Pakete notwendig.

Zur Synchronisation bei 16-Bit Daten per 8-Bit Übertragung kann man das 
Parity-Bit benutzen.

: Bearbeitet durch User
von N. M. (mani)


Lesenswert?

9 Bit hab ich schon öfter gesehen. 10 auch schon Mal. Mehr ist mir bis 
jetzt noch nicht untergekommen.

Terence S. schrieb:
> die schon an die Grenzen der Baud-Rate gehen, wäre das ganz nett.

Über wieviel MBit sprechen wir denn?

von Andreas B. (abm)


Lesenswert?

Wer etwas einfaches und kompatibles will, nimmt 8- oder 9-Bit UART, wer 
sich an der geringfügig geringeren Netto-Datenrate stört, nimmt halt die 
synchrone Variante oder SDLC etc. und halst sich damit beträchtliche 
Komplexität auf.

Apropos: Warum gibt's keine M3.7-Schrauben? Weil sich kein Mensch so 
eine Extrawurst antun will.

von Rainer W. (rawi)


Lesenswert?

Andreas B. schrieb:
> Apropos: Warum gibt's keine M3.7-Schrauben? Weil sich kein Mensch so
> eine Extrawurst antun will.

Sonderwünsche lassen sich mit einem FPGA realisieren. Dafür wurden die 
erfunden.

von Max D. (max_d)


Lesenswert?

Der RP2040 (aka pi pico) hat sehr praktische programmierbare io-module. 
ich bin mir sicher damit kannst du deinen uart mit beliebig vielen bits 
basteln.

von Klaus (feelfree)


Lesenswert?

Terence S. schrieb:
> Rein technisch spricht nichts dagegen, ein UART-Übertragung mit mehr als
> 8 Bit aufzubauen.

Es spricht nichts dagegen, aber halt auch nichts dafür. 2x 8N1 sind 20 
bits, 1x 16N1 sind 18. Also 10% Ersparnis, aber zu nix kompatibel und 
schlechtere Übertragungssicherheit.
Und wenn eine ungerade Anzahl Bytes übertragen werden soll, wird's erst 
richtig komisch.

: Bearbeitet durch User
von Tilo R. (joey5337) Benutzerseite


Lesenswert?

Wozu?
In den allermeisten Fällen wird man doch ohnehin irgendein, wenn auch 
einfaches, höheres Protokoll bauen. Und ab da ist die Bedeutung 
High-Byte/Low-Byte durch die Reihenfolge bekannt.

Terence S. schrieb:
> Für Übertragung von Messwerten zwischen zwei MCUs über UART, die schon
> an die Grenzen der Baud-Rate gehen, wäre das ganz nett.
Du hast das Problem schon benannt.

von Gerhard H. (hauptmann)


Lesenswert?

Terence S. schrieb:
> Die Hersteller bauen heute jeden Firlefanz in ihre Mikrocontroller ein,
> aber ein UART-Modul mit mehr als 8 Bit ist mir dabei noch nicht
> untergekommen

Na bloß gut.
Von mir aus sollte im Sinne der Programmier- Vereinfachung in den Modi 
eher abgerüstet werden. 8N1 langt völlig. In gleichem Sinne könnte man 
Empfang/Versand über eingebaute Puffer automatisieren. Das wär mal ein 
brauchbarer Fortschritt.

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> In gleichem Sinne könnte man
> Empfang/Versand über eingebaute Puffer automatisieren. Das wär mal ein
> brauchbarer Fortschritt.

So was wie den 16550 gibt's ja erst seit knapp 40 Jahren...

von Norbert (der_norbert)


Lesenswert?

Terence S. schrieb:
> aber ein UART-Modul mit mehr als 8 Bit ist mir dabei noch nicht
> untergekommen. Mir ist klar, dass das nicht kompatibel mit dem üblichen
> Standard ist

So isses. Also nimmt man anstelle des UART einen USART und kann 
übertragen was man will.

Aber für die vor dir angedeutete triviale Aufgabe nimmt man 
bequemerweise zB. so etwas wie COBS.
Und wenn man nur mal als Beispiel 12bit Werte übertragen will, zwei 
Stück kann man in drei Bytes packen. Dickes Paket schnüren, COBS, weg 
damit. Dann wächst auch noch der mögliche Durchsatz.

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> So was wie den 16550 gibt's ja erst seit knapp 40 Jahren...

Wer redet denn davon?
Ich rede von automatisch arbeitenden Sende/Empfangsautomatiken die nicht 
mehr manuell zu codieren und deren Puffer nicht mehr im Hauptspeicher zu 
verwalten sind. Und das im Controller und nicht irgendwo ausserhalb.

: Bearbeitet durch User
von Helmut -. (dc3yc)


Lesenswert?

Hätte noch ein paar SAB82532 herumliegen. Wenn du dir die antun willst, 
bitteschön. Du würdest zwei sogar geschenkt bekommen!

von Harald K. (kirnbichler)


Lesenswert?

Gerhard H. schrieb:
> In gleichem Sinne könnte man Empfang/Versand über eingebaute
> Puffer automatisieren. Das wär mal ein brauchbarer Fortschritt.

... den es bei UARTs seit über 30 Jahren gibt, wie z.B. dem Klassiker 
16550. Das war eine funktionskompatible Erweiterung der 16450 (die 
letztlich identisch ist zum Urgestein 8250), mit Sende- und 
Empfang-Fifos von je 16 Bytes.

Der ehemalige Hersteller Oxford Semiconductor hatte erweiterte Varianten 
davon im Programm, die größere FIFOs und auch Hardwareunterstützung für 
RS485-Betrieb mit sich brachten. Diese UARTs fang man jahrelang auf 
PC-UART-Karten, z.B. als 16950 mit 265 Byte großen Fifos.
Eine der letzten Inkarnationen davon war die OXPCIe952 
https://www.mouser.com/datasheet/2/38/OXPCIe952_Product_Brief-514786.pdf

Allerdings wurde Oxford Semiconductor irgendwann von PLX geschluckt, und 
danach ging es mit Support und Dokumentation steil bergab. Andererseits 
ist der Bedarf an seriellen Schnittstellen in heutigen PCs auch eher 
überschaubar.


Auf Microcontrollern aber sind derartige UARTs nicht unbedingt 
erforderlich; wenn die mit einem DMA-Controller ausgestattet sind, lässt 
sich das auch in Software nachbilden.

von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Ich rede von automatisch arbeitenden Sende/Empfangsautomatiken die nicht
> mehr manuell zu codieren und deren Puffer nicht mehr im Hauptspeicher zu
> verwalten sind.

Aha, nicht im Hauptspeicher, also irgendwo in einem UART FIFO oder so. 
Also ungefähr so wie beim 16550. Und da müssen sie letztlich auch 
irgendwann raaus, weil irgendwann wird sich deine Applikation dafür 
interessieren. Dann musst Du ja doch wieder "manuell codieren"...

Die Lösung exisitiert dafür auch schon seit mindestens 30 Jahren, und 
nennt sich Hochsprache mit passendem HAL.
Geht natürlich nicht, wenn man über Assembler nie hinausgekommen ist.

von Gerhard H. (hauptmann)


Lesenswert?

Harald K. schrieb:
> mit Sende- und Empfang-Fifos von je 16 Bytes.

Ich rede von Erweiterungen IM Controller. Und da ist es mit lächerlichen 
16 Bytes sicher nicht getan.

> wenn die mit einem DMA-Controller ausgestattet sind, lässt sich das auch
> in Software nachbilden.

Nachbilden lässt sich vieles.
Ich rede hier aber von Vereinfachung.

von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Ich rede hier aber von Vereinfachung.

Wieviel einfacher als

serial.print("Ein paar Bytes zu verschicken ist so einfach!");

hättest Du es denn gerne?

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Geht natürlich nicht, wenn man über Assembler nie hinausgekommen ist.

Helden der Verkomplizierung und eigener Lösungen ist es zu verdanken, 
daß wir heute für ein und dieselbe simple Aufgabe, eine Anzahl Bytes zu 
übertragen, unterschiedlichste Modi im UART Modul und für solche 
Übertragungen haben. Wie überflüssig- nicht wahr, Klaus?

> Wieviel einfacher als
> serial.print("Ein paar Bytes zu verschicken ist so einfach!");
> hättest Du es denn gerne?

Veralbere andere. Wir sind hier auf Hardware-Ebene falls Du das noch 
nicht mitbekommen hast. Warst Du da schon mal?

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Ich rede hier aber von Vereinfachung.

Gerhard H. schrieb:
> Helden der Verkomplizierung

Nun, meine Lösung ist einfach, von welcher Verkomplizierung redest 
Du?
Dass ich die Wahl habe, neben 8 Bits auch nur 7 zu übertragen oder ein 
zusätzliches Parity-Bit, wenn ich glaube es zu benötigen?

Gerhard H. schrieb:
> Wir sind hier auf Hardware-Ebene falls Du das noch
> nicht mitbekommen hast.

Von mir aus. Wie viel einfacher als N Bytes in ein Fifo zu schreiben und 
irgendwann dem Controller zu sagen "ab dafür" hättest Du es gerne?

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Wie viel einfacher als N Bytes in ein Fifo zu schreiben und irgendwann
> dem Controller zu sagen "ab dafür" hättest Du es gerne?

Du scheinst Dein mentales Extern-16550 mit N=16 Gefängnis nicht 
verlassen zu können !? Ist das die Zeit in der Du aufgewachsen bist?

> von welcher Verkomplizierung redest Du?

Das ist Dir vermutlich gar nicht begreiflich zu machen. Scheinst eher 
ein Aktivist technisch umständlicher Lösungen und stolz drauf zu sein. 
So wie in der Haus-Automatisierung :)

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Du scheinst Dein mentales Extern-16550 mit N=16 Gefängnis nicht
> verlassen zu können !?

Nein, ich rede von einem UART IN einem Microcontroller. Nix extern.
Also nochmal:
Ich kenne zwei Möglichkeiten: Entweder ich kopiere da Byte für Byte in 
ein Fifo, und der UART überträgt es. Fertig.
Oder ich sage einer DMA, an Adresse 0x1234 liegen 0x56 bytes, bitte 
schicke mir die über den internen UART raus.

Ich habe in der Tat nicht verstanden, wie Du da was vereinfachen 
möchtest.

von Markus E. (markus_e176)


Lesenswert?

Cypress PSoC5 sollte das können (in gewissen Grenzen sogar beliebige 
Bitbreiten).

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Oder ich sage einer DMA, an Adresse 0x1234 liegen 0x56 bytes, bitte
> schicke mir die über den internen UART raus.

Haben wir überall DMA? Nein.
Selbst mit bleibt das simple Abfragen eines (automatisch eingelesenen) 
Puffers und das automatische Versenden eines Puffers, mit einem einzigen 
auslösenden I/O Flag vielleicht, immer noch einfacher als das alles via 
DMA zu organisieren.

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Haben wir überall DMA? Nein.

Du willst etwas vereinfachen, ohne etwas zu verändern? Also zum Beispiel 
eine DMA zu ergänzen?
Wasch' mich, aber mach mich nicht nass, funktioniert leider nicht.

Dein Getrolle aber sehr gut, ich bin schon wieder darauf reingefallen.

: Bearbeitet durch User
von J. S. (jojos)


Lesenswert?

Die AVR haben kein DMA, also kann es nicht gut sein.

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Dein Getrolle aber sehr gut, ich bin schon wieder darauf reingefallen.

Nö. Eher

> Ich habe in der Tat nicht verstanden, wie Du da was vereinfachen
> möchtest.

Weil Dir auf Hochsprach-Ebene schlicht die Nähe zur Hardware fehlt.

J. S. schrieb:
> Die AVR haben kein DMA, also kann es nicht gut sein.

Täusch Dich da nicht. XMEGA kann mit aufwarten :)

: Bearbeitet durch User
von Terence S. (takeshi)


Lesenswert?

Andreas B. schrieb:
> Apropos: Warum gibt's keine M3.7-Schrauben? Weil sich kein Mensch so
> eine Extrawurst antun will.

Sehr guter Vergleich. Hast du irgendeinen Grund genannt, warum 
M3,7-Schrauben sinnvoll sein könnten? Nein. Habe ich praktikable Gründe 
genannt, warum 16 Bit bei UART sinnvoll sein könnten und die 
Implementierung kein großes Ding? Ja. Nicht alles, was hinkt, ist ein 
Vergleich.
Es ist ja nicht so, als würde heute niemand mit Daten größer als 8 Bit 
hantieren. Oder bin ich da für einige hier zu futuristisch?

Rainer W. schrieb:
> Sonderwünsche lassen sich mit einem FPGA realisieren. Dafür wurden die
> erfunden.

Grundsätzlich ja, nur macht es das Gesamtsystem teuer, die 
Programmierung aufwendiger und alle anderen Module des Mikrocontrollers 
fehlen erst mal.

Max D. schrieb:
> Der RP2040 (aka pi pico) hat sehr praktische programmierbare
> io-module.
> ich bin mir sicher damit kannst du deinen uart mit beliebig vielen bits
> basteln.

Danke, guter Hinweis. Da schaue ich mal.

Klaus schrieb:
> Es spricht nichts dagegen, aber halt auch nichts dafür. 2x 8N1 sind 20
> bits, 1x 16N1 sind 18. Also 10% Ersparnis, aber zu nix kompatibel und
> schlechtere Übertragungssicherheit.

Die Rechnung stimmt halt nicht. Für 16 Bit Daten in einem Paket bräuchte 
ich brutto 18 Bit. Für 16 Bit Daten in zwei Paketen brauche ich, wenn 
ich das Paritätsbit zur Paketunterscheidung nutze, brutto schon 22 Bit. 
Das sind nicht 10% mehr, sondern 22%. Wenn das Paritätsbit nicht zur 
Unterscheidung dient, sind es 3 Pakete. Die könnten um ein Bit gekürzt 
werden, macht dann aber 27 Bit brutto (+50%). In meinem Fall möchte ich 
einen Messwert mit 11 Bit übertragen. Dafür brauche ich aktuell brutto 
18 Bit statt 13 Bit in einem Paket (+38%). Das macht schon was aus.

Und weil die Übertragung über ein Leitung passieren soll (optische 
Übertragung), fallen Schnittstellen wie SPI raus, die das durchaus 
könnten.

von Gerhard H. (hauptmann)


Lesenswert?

Terence S. schrieb:
> Klaus schrieb:
>> Es spricht nichts dagegen, aber halt auch nichts dafür. 2x 8N1 sind 20
>> bits, 1x 16N1 sind 18. Also 10% Ersparnis, aber zu nix kompatibel und
>> schlechtere Übertragungssicherheit.
>
> Die Rechnung stimmt halt nicht.

Beim Klaus stimmen zuviele Rechnungen nicht.

von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> schlicht die Nähe zur Hardware fehlt :)

Nein, weil Dir und deinem Getrolle der Bezug zur Realität fehlt.

Gerhard H. schrieb:
> das automatische Versenden eines Puffers, mit einem einzigen
> auslösenden I/O Flag vielleicht,

Das Prinzip funktioniert und nennt sich DMA.

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?

Terence S. schrieb:
> Es ist ja nicht so, als würde heute niemand mit Daten größer als 8 Bit
> hantieren. Oder bin ich da für einige hier zu futuristisch?

Welches futuristische Vorhaben hast Du denn was noch einen UART-Modus 
mehr rechtfertigen würde?

Klaus schrieb:
> Das Prinzip funktioniert und nennt sich DMA.

Ignorieren hat bei Dir Methode. Nicht wahr, Klaus?

von Klaus (feelfree)


Lesenswert?

Terence S. schrieb:
> In meinem Fall möchte ich
> einen Messwert mit 11 Bit übertragen.

Dann packt man 2 Messwerte in 3 Bytes und alles ist gut.

von J. S. (jojos)


Lesenswert?

DMA hat noch den Vorteil einer geringeren Interruptlast. Mit Multidrop 
und 9 Bit kann man bei den STM32 einen Int auslösen lassen wenn ein 
Paket komplett im Speicher angekommen ist. Das habe ich schon mit 12,5 
MBit/s laufen gehabt, die F7/H7 können das auch mit 25 Mbit/s.
Ist vielleicht auch eine brauchbare Alternative.

von Frank K. (fchk)


Lesenswert?

Terence S. schrieb:

> Die Übertragung längerer Wörter hätte Vorteile. Bei einer Aufteilung in
> 2x 8 Bit müssen die beiden Bytes maskiert werden, die beiden Bytes
> sicher zu unterscheiden, was bei einem Übertragungsfehler wichtig ist.
> Für 16 Bit wären damit sogar 3 Pakete notwendig. Die Nettodatenrate wäre
> bei gleicher Baud-Rate höher, weil Overhead (wie Start- und Stopp-Bits)
> wegfallen. Also warum das kein mir bekannter Hersteller vorsieht,
> erschließt sich mir nicht.
>
> Für Übertragung von Messwerten zwischen zwei MCUs über UART, die schon
> an die Grenzen der Baud-Rate gehen, wäre das ganz nett.

Dafür gibts dann andere Standards und Methoden, die noch effizienter 
sind.
Beispielsweise CAN-FD mit bis zu 8MBit/s in der Datenphase. Da hast Du 
bis zu 64 Datenbytes in einem Paket, mit ID, Prüfsumme und 
Empfangsbestätigung in Hardware und mit differentieller Übertragung.

Das bekommst Du z.B. mit der dsPIC33CK... Serie.

fchk

von Gerhard H. (hauptmann)


Lesenswert?

J. S. schrieb:
> DMA hat noch den Vorteil einer geringeren Interruptlast.

Jetzt stell Dir vor: Mit den von mir vorgeschlagenen Erweiterungen hast 
Du gar keine.

von 900ss (900ss)


Lesenswert?

Max D. schrieb:
> Der RP2040 (aka pi pico) hat sehr praktische programmierbare io-module.
> ich bin mir sicher damit kannst du deinen uart mit beliebig vielen bits
> basteln.

Ja, das kann ich aus eigener Erfahrung sagen. Der UART, den ich 
realisieren musste, hatte 12 Datenbit.
Mit den PIOs geht das sehr gut. Es sind Beispiele vorhanden, die man 
leicht modifizieren kann. Die konnte ich leider nicht nehmen weil noch 
das Start+Stopbit invertiert sein musste. Lies sich aber auch 
realisieren. Mit den PIOs hast du alle Freiheiten. Bis zu 8 Wort tiefe 
FIFOs stehen auch hier Verfügung.

von Uwe B. (Firma: TU Darmstadt) (uwebonnes)


Lesenswert?

Die Takte muessen aber bei 16 Bit Ubertragung fast 2 Mal besser 
uebereinstimmen.

von J. S. (jojos)


Lesenswert?

Gerhard H. schrieb:
> J. S. schrieb:
>> DMA hat noch den Vorteil einer geringeren Interruptlast.
>
> Jetzt stell Dir vor: Mit den von mir vorgeschlagenen Erweiterungen hast
> Du gar keine.

Man muss beim Multidrop den Int nicht aktivieren, wäre aber schön blöd 
die Pakete beim Empfänger heimlich ankommen zu lassen und dann zu 
pollen.
Die ganze Übertragung läuft parallel zur CPU, die kann fröhlich 
weiterrechnen. Nur wenn die richtige Adresse gesendet wurde, wird der 
DMA aktiv. Auch da muss die CPU nichts auswerten.

von Gustl B. (-gb-)


Lesenswert?

Klaus schrieb:
> Terence S. schrieb:
>> In meinem Fall möchte ich
>> einen Messwert mit 11 Bit übertragen.
>
> Dann packt man 2 Messwerte in 3 Bytes und alles ist gut.

Also bei 11 Bits reichen zwei Bytes lockerst. Bei zwei Bytes braucht man 
nur 1 Bit um zu erkennen ob es das MSByte oder LSByte ist. Der Rest der 
Bits - das sind dann 14 - können für Nutzdaten verwendet werden.

0DDDDDDD 1DDDDDDD

In die Ds kannst du die Daten stecken.

von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Mit den von mir vorgeschlagenen Erweiterungen hast
> Du gar keine.

Das wäre blöd, denn nur mit einem I/O-Flag für den Start der Übertragung 
hängt es halt von der aktuellen Sonnenaktivität ab, welche und wieviele 
Bytes übertragen werden.

von Klaus (feelfree)


Lesenswert?

Gustl B. schrieb:
> Also bei 11 Bits reichen zwei Bytes lockerst.

Ja, aber dann üerbträgst Du 20 Brutto-Bits für 11 Datenbits.
Mit meiner Lösung brauchst Du 30 Brutto-Bits für 22 Datenbits.
Darfst selber rechnen, was effizienter ist.

von Norbert (der_norbert)


Lesenswert?

Uwe B. schrieb:
> Die Takte muessen aber bei 16 Bit Ubertragung fast 2 Mal besser
> uebereinstimmen.

Tja, du sagst es. Es gibt einen guten Grund warum die async. Übertragung 
sich nicht auf kilometerlange unsynchronisierte Bitfolgen verlässt.

Aber die Diskussion ist ja kurz nach Eröffnung bereits mehrfach scharf 
abgebogen und kümmert sich nun wie erwartet in einer Art Todesspirale um 
Dinge die niemals nachgefragt wurden.

Luschtig ist's allemal… ;-)

von Gustl B. (-gb-)


Lesenswert?

Klaus schrieb:
> Darfst selber rechnen, was effizienter ist.

Effizienter ist Deine Lösung. Geht es hier überhbaupt um Effizienz? Hat 
der TO irgendwo mal seine Wunschdatenrate genannt? UART kann man sehr 
schnell betreiben wenn man will, da würde ich das mit der Datenpackerei 
eher entspannt sehen.

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Das wäre blöd, denn nur mit einem I/O-Flag für den Start der Übertragung
> hängt es halt von der aktuellen Sonnenaktivität ab, welche und wieviele
> Bytes übertragen werden.

Selbstredend wäre die verwendete Puffergröße in einem I/O Register fix 
eingestellt. Die Größe der Datenpäckchen ist sehr oft konstant.
Schön blöd wessen Fantasie dafür nicht reicht...

: Bearbeitet durch User
von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Selbstredend wäre die verwendete Puffergröße in einem I/O Register fix
> eingestellt.

Stell' dir vor: Dieses I/O-Register findet sich in jeder DMA.

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Stell' dir vor: Dieses I/O-Register findet sich in jeder DMA.

Gerhard H. schrieb:
> Haben wir überall DMA? Nein.
> Selbst mit bleibt das simple Abfragen eines (automatisch eingelesenen)
> Puffers und das automatische Versenden eines Puffers, mit einem einzigen
> auslösenden I/O Flag vielleicht, immer noch einfacher als das alles via
> DMA zu organisieren.

Ob permanente Wiederholung Deine Ignoranzschwelle aufbricht?

von Klaus (feelfree)


Lesenswert?

Gustl B. schrieb:
> Geht es hier überhbaupt um Effizienz?

Ja. Beitrag "Re: Mikrocontroller mit 16-Bit-UART"

von Björn W. (bwieck)


Lesenswert?

Terence S. schrieb:
> Rein technisch spricht nichts dagegen, ein UART-Übertragung mit mehr als
> 8 Bit aufzubauen. Die Begrenzung auf 8 Bit stammt noch aus einer Zeit,
> als die Taktquellen nicht so genau waren und daher die Synchronität über
> mehr als 8 Bit nicht gewährleistet werden konnte. Aber die Zeiten haben
> sich geändert und ich bin mir sicher, 16 Bit am Stück wären heute locker
> möglich.

Früher™ hat man noch Baudratenquarze genommen und den Rest darauf 
abgestimmt. Heute ist es eher Umgekehrt, billige 8,10,16,20MHz Quarze 
benutzen und den Baudratenfehler in Kauf nehmen. So sieht die Realität 
aus.

von Gustl B. (-gb-)


Lesenswert?

Björn W. schrieb:
> und den Baudratenfehler in Kauf nehmen.

Man kann auch schnell genug überabtasten.

Warum eigentlich ein uC wenn man auch für kleines Geld schon einen FPGA 
bekommt?

von Klaus (feelfree)


Lesenswert?

Gustl B. schrieb:
> Man kann auch schnell genug überabtasten.

und hat nix gewonnen, wenn 0xffff oder 0x0000 übertragen werden sollen.

von Martin (martin32)


Angehängte Dateien:

Lesenswert?

Infineon XMC sollte Längen 1 bis 63 unterstützen. Auf die Schnelle hab 
ich 1, 13 und 32 getestet.

von Klaus (feelfree)


Lesenswert?

Gerhard H. schrieb:
> Schön blöd wessen Fantasie dafür nicht reicht...

Ich stelle fest, Du hast etwas "erfunden", das einen Puffer mit fixer 
Quell-Adresse zu einem UART schickt. Die Anzahl der Bytes darf in einem 
konfigurierbarem I/O-Register liegen.
Jetzt brauchst Du nur noch einen Namen für deine Erfindung.

Machen wir einen Wettbewerb daraus? Ich hab noch Chips übrig....

Vorschläge:
TINAD!: This Is Not A DMA!
YADD: Yet Another Dump DMA.
DFD: DMA for Dummies.
HUB2UCM: Highly Unflexible Buffer to UART Copy Machine
GGUH: Gerhard's Genious UART Helper

: Bearbeitet durch User
von Helmut -. (dc3yc)


Lesenswert?

Martin schrieb:
> Infineon XMC sollte Längen 1 bis 63 unterstützen. Auf die Schnelle hab
> ich 1, 13 und 32 getestet.

Die Nachfolger meines vorhin zitierten SAB82532...

von Gerhard H. (hauptmann)


Lesenswert?

Klaus schrieb:
> Ich stelle fest, Du hast etwas "erfunden", das einen Puffer mit fixer
> Quell-Adresse zu einem UART schickt.

Ich stelle einmal mehr fest, daß Dein technisches Verständnis vorn und 
hinten nicht reicht. Halt Dich einfach an Deine Erkenntnis

> Dein Getrolle aber sehr gut, ich bin schon wieder darauf reingefallen.

Martin schrieb:
> Infineon XMC sollte Längen 1 bis 63 unterstützen.

Na endlich.
Ob der TO jetzt mit fliegenden Fahnen mal eben dorthin wechselt?

: Bearbeitet durch User
von Harald K. (kirnbichler)


Lesenswert?

Björn W. schrieb:
> Heute ist es eher Umgekehrt, billige 8,10,16,20MHz Quarze
> benutzen und den Baudratenfehler in Kauf nehmen.

Bessere UARTs (als die in den üblichen AVRs zu findende) haben 
fraktionale Baudratenteiler und können daher auch ohne "Baudratenquarze" 
hinreichend genau arbeiten.

von Gerhard H. (hauptmann)


Lesenswert?

Harald K. schrieb:
> Bessere UARTs (als die in den üblichen AVRs zu findende) haben
> fraktionale Baudratenteiler und können daher auch ohne "Baudratenquarze"
> hinreichend genau arbeiten.

"Zivilisiertere" Baudraten (als hier gefordert?) stemmen aktuelle AVR's 
natürlich längst quarzlos.

von Rainer W. (rawi)


Lesenswert?

Terence S. schrieb:
> In meinem Fall möchte ich einen Messwert mit 11 Bit übertragen.

Und was ist dann dein Problem? Wenn du die in 2 Bytes überträgst, hast 
du 5 Bit frei, von denen du zwei für die Kennzeichnung Low/High Byte 
verwenden kannst, ganz ohne irgendwelche Klimmzüge.

von Michi S. (mista_s)


Lesenswert?

Rainer W. schrieb:
> Terence S. schrieb:
>> In meinem Fall möchte ich einen Messwert mit 11 Bit übertragen.
>
> Und was ist dann dein Problem? Wenn du die in
> 2 Bytes überträgst, hast du 5 Bit frei,
> von denen du zwei für die Kennzeichnung Low/High Byte
> verwenden kannst

Oder Du schickst nur 2 mal 7Bit auf die Reise und hast auf der Leitung 
genauso 18 Bit wie bei einer 16Bit Übertragung.

von Peter D. (peda)


Lesenswert?

Terence S. schrieb:
> Kennt jemand einen Mikrocontroller, der ein UART-Modul besitzt, das eine
> längeren Wert als 8 Bit unterstützt?

Was soll das bringen?
16Bit deckt nur einen seltenen Spezialfall ab, daher lohnt sich diese 
Extrawurst nicht.
In der Regel hat man Multibyte Nachrichten und dafür benutzt man einfach 
ein passendes Protokoll. Zusätzlich kann man solche Nachrichten einfach 
auf Gültigkeit überprüfen (CRC).

Der CAN-Bus kann ja 64Bit und das reicht oft auch nicht aus. Dann werden 
einfach mehrere CAN-Pakete gesendet, z.B. bei einem Firmwarupdate.

von Walter T. (nicolas)


Lesenswert?

Terence S. schrieb:
> Hast du irgendeinen Grund genannt, warum
> M3,7-Schrauben sinnvoll sein könnten?

Naja, wenn M3,5 zu schwach ist und M4 zu groß natürlich.

von 900ss (900ss)


Lesenswert?

Peter D. schrieb:
> Was soll das bringen?
> 16Bit deckt nur einen seltenen Spezialfall ab, daher lohnt sich diese
> Extrawurst nicht.
> In der Regel hat man Multibyte Nachrichten und dafür benutzt man

Manchmal muss man Geräte ersetzen, die ein spezielles Protokoll sprechen 
müssen. In meinem Fall waren das 12 Bit Daten.... dann ist ein seltener 
Spezialfall gegeben. Soll ich jetzt sagen: geht nicht? Oder hat "kann 
ich nicht"?

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?

900ss schrieb:
> spezielles Protokoll sprechen müssen

Müssen tut gar nichts.
Die Entwickler wollten halt dann was Besonderes, Inkompatibles, eben 
einen seltenen Spezialfall. Jeder der hier weiter zuarbeitet unterstützt 
diese Unsitten.

von Harald K. (kirnbichler)


Lesenswert?

900ss schrieb:
> Manchmal muss man Geräte ersetzen, die ein spezielles Protokoll sprechen
> müssen.

Das macht man ständig, aber dafür muss man keine sinnlosen zu nichts in 
der Welt kompatiblen neuen UARTs erfinden, sondern sich ein paar 
Augenblicke lang damit auseinandersetzen, wie man sinnvolle 
Datenübertragungsprotokolle gestaltet. Wenn es soweit geht, daß man 
einzelne Bits einer UART-Übertragung abzählt und zu vermeiden sucht, ist 
man zum Optimieren irgendwo sehr gründlich falsch abgebogen.

von 900ss (900ss)


Lesenswert?

Gerhard H. schrieb:
> Müssen tut gar nichts.

Harald K. schrieb:
> Das macht man ständig, aber dafür muss man keine sinnlosen zu nichts in
> der Welt kompatiblen neuen UARTs erfinden, sondern sich ein paar
> Augenblicke lang damit auseinandersetzen, wie man sinnvolle
> Datenübertragungsprotokolle

Autsch....
Ja, ihr hättet Maschinen, die minimum 7-stellige Summen kosten 
stattdessen ersetzt. Nur weil darin eine Einheit ausgefallen ist, die im 
Original nicht nachgebaut werden kann, weil es Teile nicht mehr gibt. 
Das hättet ihr euren Kunden erzählt. LOL....
So sehen heutige Spezialisten aus. Applaus....

von Gerhard H. (hauptmann)


Lesenswert?

900ss schrieb:
> Ja, ihr hättet Maschinen, die minimum 7-stellige Summen kosten
> stattdessen ersetzt.

Na wenn Du mit diesem Argument kommst erwarte ich jetzt konkrete 
Beispiele!
Und ob sich jemand der solcherlei bezahlen kann mit derlei technischen 
Details abgibt? Applaus für Deine Weitsicht :)

von Le X. (lex_91)


Lesenswert?

Gerhard H. schrieb:
> Helden der Verkomplizierung und eigener Lösungen ist es zu verdanken,
> daß wir heute für ein und dieselbe simple Aufgabe, eine Anzahl Bytes zu
> übertragen, unterschiedlichste Modi im UART Modul und für solche
> Übertragungen haben. Wie überflüssig- nicht wahr, Klaus?

Köstlich.
Wenn ich "eigene Lösungen" denke dann denke ich Hauptmann.

von Gerhard H. (hauptmann)


Lesenswert?

Le X. schrieb:
> Wenn ich "eigene Lösungen" denke

Beschränke die "eigenen Lösungen" mal besser auf dieses Thread-Thema.
Da richten sie in der Tat Unheil an.
Ich bleibe hier nämlich konsequent bei allseits kompatiblem 8N1.

: Bearbeitet durch User
von Fabian H. (fabianh84)


Lesenswert?

Die LIN Module der TI C2000 Reihe können als UART beliebiger Bitlänge 
definiert werden. Könnte sein, dass du mit LIN das bekommst, was du 
suchst!

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1273686/tms320f280025c-using-lin-as-uart-to-serially-transmit-data

von Dergute W. (derguteweka)


Lesenswert?

Moin,

900ss schrieb:
> Ja, ihr hättet Maschinen, die minimum 7-stellige Summen kosten
> stattdessen ersetzt.

Nee, sondern meinen Lieblingscontoller bzw. den, mit dem ich bei den 
restlichen Anforderungen am wenigsten Tralala habe, genommen und ein 
kleines FPGA/CPLD fuer den Wunderfitz-UART. Aber vielleicht passt der 
Lieblingscontroller dann auch noch gleich mit rein...

Gruss
WK

von Peter D. (peda)


Lesenswert?

900ss schrieb:
> Ja, ihr hättet Maschinen, die minimum 7-stellige Summen kosten
> stattdessen ersetzt.

Dann nimmt man eben eine UART im synchronen Modus, da kann man beliebig 
Bytes ohne Start/Stop hintereinander pappen. Noch ein externer Interrupt 
zur Startbiterkennung und fertig.

Ich hab mal ein altes Fremdgerät zu reparieren gehabt, da wurden 3 Byte 
am Stück ohne irgendwelches Protokoll übertragen. Die Geräte mußten 
genau zur gleichen Zeit eingeschaltet werden, damit alles synchron war. 
Irgendeine Störung und die Geräte haben sich nie wieder eingekriegt und 
nur noch Mumpitz übertragen. 24/7 war damit nicht möglich. Man mußte sie 
regelmäßig neu einschalten.
Ist schon kraß, wie früher gepfuscht wurde. Die Leute wußten es eben 
nicht besser, Fehlersicherheit war ein Fremdwort.
Ich hatte schon überlegt, auf beiden Seiten einen ATtiny mit Protokoll 
nachzurüsten.

von Gerhard H. (hauptmann)


Lesenswert?

Peter D. schrieb:
> Ist schon kraß, wie früher gepfuscht wurde.

Nur früher?

von 900ss (900ss)


Lesenswert?

Peter D. schrieb:
> Dann nimmt man eben eine UART im synchronen Modus, da kann man beliebig
> Bytes ohne Start/Stop hintereinander pappen.

Kann der dann auch 12 Datenbit mit jeweils Start/Stopbit? ;)

Edit: je länger ich drüber nachdenken, könnte es doch auch 
funktionieren. Hier wurde eben der RP2040 mit den PIOs genutzt. Ich 
glaube unterm Strich ist es am Ende übersichtlicher damit.

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Harald K. schrieb:

> Bessere UARTs (als die in den üblichen AVRs zu findende) haben
> fraktionale Baudratenteiler und können daher auch ohne "Baudratenquarze"
> hinreichend genau arbeiten.

Die modernen AVR haben auch alle fraktionale Teiler. Und zumindest für 
mich sind das inwischen "die Üblichen".

Viel wichtiger bezüglich UART ist allerdings, dass die auch einen 
RC-Taktgenerator besitzen, der bezüglich der Abhängigkeit von der 
Versorgungsspannung schon von Hause aus hinreichend exakt und stabil 
ist. Zusätzlich besitzen sie fast alle auch einen internen 
Temperatursensor, mit dem man (die nach wie vor recht große) 
Abhängigkeit von der Umgebungstemperatur wegkalibrieren kann.

Erst diese Eigenschaften machen es möglich, auf einen Quarz verzichten 
zu können und trotzdem zuverlässige UART-Kommunikation zu haben.

Der fraktionale Teiler hingegen ist eher dafür nützlich, wenn man 
einerseits einen Quarz mit relativ kleiner "runder" Frequenz benutzen 
möchte oder muss, andererseits aber relativ hohe Standard-Baudraten 
braucht.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Peter D. schrieb:


> Dann nimmt man eben eine UART im synchronen Modus, da kann man beliebig
> Bytes ohne Start/Stop hintereinander pappen.

Ähm, nein. Im synchronen Modus läuft alles ganz genauso wie im 
asnchronen, nur dass zusätzlich der Takt ausgegeben bzw. beim Empfang 
statt eines selbst generierten benutzt wird.

Was du meinst ist: "UART im SPI-Modus". Da fallen dann tatsächlich die 
Start- und Stopbits weg.

von Rolf (rolf22)


Lesenswert?

Gerhard H. schrieb:
>> Ja, ihr hättet Maschinen, die minimum 7-stellige Summen kosten
>> stattdessen ersetzt.
>
> Na wenn Du mit diesem Argument kommst erwarte ich jetzt konkrete
> Beispiele!

Überall gibt es Systeme, die aufwendig am Leben gehalten werden, weil 
niemand da ist, der die uralte Software mit vertretbarem Aufwand 
modernisiert. Der einzige, der das kann, ist vielleicht 80+ und lebt im 
Heim.

https://en.wikipedia.org/wiki/12-bit_computing

von Gerhard H. (hauptmann)


Lesenswert?

Rolf schrieb:
> Überall gibt es Systeme

Von konkreten Beispielen war die Rede.
Wohlgemerkt im 7stelligen Bereich.

von (prx) A. K. (prx)


Lesenswert?

Gerhard H. schrieb:
> "Zivilisiertere" Baudraten (als hier gefordert?) stemmen aktuelle AVR's
> natürlich längst quarzlos.

Async wird beim Startbit für die Dauer des gesamten Frames 
synchronisiert. Je länger der Frame ist, desto höher ist daher der 
Anspruch an die Taktgenauigkeit.

: Bearbeitet durch User
von Gerhard H. (hauptmann)


Lesenswert?

(prx) A. K. schrieb:
> Je länger der Frame ist, desto höher ist daher der Anspruch an die
> Taktgenauigkeit.

Ein Punkt mehr für kompatibles 8N1.

von Norbert (der_norbert)


Lesenswert?

Gerhard H. schrieb:
> (prx) A. K. schrieb:
>> Je länger der Frame ist, desto höher ist daher der Anspruch an die
>> Taktgenauigkeit.
>
> Ein Punkt mehr für kompatibles 8N1.

Ach ich weiß nicht…

Damals, in grauer Vorzeit, haben die Entwickler noch den einen oder 
anderen recht cleveren Trick angewandt.
Bei Datex-P wurde zum Beispiel einige Male ein .<CR> gesendet.
Damit hat sich das Empfängersystem sowohl auf die passende Baudrate, als 
auch auf Parity eingestellt. Und wenn die damals schon so etwas 
schnurbeliges wie fraktionale Teiler zur Verfügung gehabt hätten…

von Mi N. (msx)


Lesenswert?

(prx) A. K. schrieb:
> Async wird beim Startbit für die Dauer des gesamten Frames
> synchronisiert. Je länger der Frame ist, desto höher ist daher der
> Anspruch an die Taktgenauigkeit.

Sobald man ein paar Cent für einen Quarz aufbringen kann, ist das doch 
kein Problem. Im Grunde ist mit dem RP2040 schon ein Controller genannt 
worden, dessen einfaches UART Beispielprogramm für PIO leicht auf 11 Bit 
geändert werden kann.

Nun stellt dieser auch ein 6 Bit UART-Format mit 8 MBaud zur Verfügung, 
was wegen der besseren Startbiterkennung sicherlich stabiler arbeitet. 
FIFO und DMA kommen noch hinzu. Man muß es nur machen.
Zur geforderten Baudrate habe ich vom TO keine Angabe gefunden.

von Joachim B. (jar)


Lesenswert?

Mi N. schrieb:
> Sobald man ein paar Cent für einen Quarz aufbringen kann,

bei sehr verschiedenen footprints kann das schon mal abenteuerlich 
werden, für meinen Arduino mighty mini 1284p war der greifbare SMD Quarz 
foodprint vom Quarz etwas kleiner als der auf der Platine von OSH Park, 
passende Bestellung wäre mit Versendung deutlich teurer als ein paar 
Cent geworden.
https://www.mikrocontroller.net/attachment/preview/240970.jpg

der passte gerade so verlötbar rauf

https://www.mikrocontroller.net/attachment/241335/mighty1_web.jpg

: Bearbeitet durch User
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Joachim B. schrieb:

> für meinen Arduino mighty mini 1284p war der greifbare SMD Quarz
> foodprint vom Quarz etwas kleiner als der auf der Platine von OSH Park,
> passende Bestellung wäre mit Versendung deutlich teurer als ein paar
> Cent geworden.

Das Problem hat man überhaupt nur, wenn man diesen Arduino-Tinnef 
verwendet. Den nimmt man allerhöchstens dann, wenn er vollständig zur 
Anwendung passt.

Und selbst dann eher nur für Entwicklungsversionen der Hardware, damit 
man die Software-Entwicklung schon komplett durchziehen kann, bevor die 
endgültige Hardware fertig ist.

von Joachim B. (jar)


Lesenswert?

Ob S. schrieb:
> Das Problem hat man überhaupt nur, wenn man diesen Arduino-Tinnef
> verwendet.

wie du meinst macht trotzdem Spaß

Ob S. schrieb:
> Und selbst dann eher nur für Entwicklungsversionen der Hardware

ganz genau, ist halt schnell zusammen gebaut und man kann modular 
entwickeln.

Was davon dann in einer Platinenversion landet darfst du den Anderen 
überlassen.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

Joachim B. schrieb:

> ganz genau, ist halt schnell zusammen gebaut und man kann modular
> entwickeln.
>
> Was davon dann in einer Platinenversion landet darfst du den Anderen
> überlassen.

Du musst aber schon zugeben, dass du das Problem mit dem Footprint 
überhaupt nicht hättest, wenn du diesen Arduino-Gammel nicht verwenden 
würdest, oder?

Weil: in der richtigen (=brauch- und zumutbaren) Hardware kann man ja 
den Footprint problemlos auf das günstig lieferbare Teil anpassen.

von Andi Y. (andiy)


Lesenswert?

Terence S. schrieb:
> Kennt jemand einen Mikrocontroller, der ein UART-Modul besitzt, das eine
> längeren Wert als 8 Bit unterstützt? Es gibt ja doch noch einige
> Hersteller, auch weniger verbreitete.

Der Parallax Propeller 2 kann das zum Beispiel. Da kannst du jeden der 
64 Pins als UART RX oder TX konfigurieren. Mit 1 bis 32 Bits pro 
übertragenem Wort, plus Start- und Stoppbit.
Ist halt ein sehr spezieller Mikrokontroller mit vielen Eigenheiten, 
aber auch ganz neuen Möglichkeiten.

von Joachim B. (jar)


Lesenswert?

Ob S. schrieb:
> Du musst aber schon zugeben,

das es kein Arduino Produkt ist und von jemand anderes erstellt wurde 
und einige es gerne nutzen. Was genau verstehst du nicht?

Bitte 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
Noch kein Account? Hier anmelden.