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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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 :)
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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?
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.
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
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.
Bessere UARTs (als die in den üblichen AVRs zu findende) haben
fraktionale Baudratenteiler und können daher auch ohne "Baudratenquarze"
hinreichend genau arbeiten.
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.
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.
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.
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"?
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.
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.
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....
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 :)
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.
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.
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...
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.
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.
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.
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.
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.
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.
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…
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.
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
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.
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.
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.
