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.
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
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?
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.
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.
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.
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
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.
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.
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...
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.
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.
Hätte noch ein paar SAB82532 herumliegen. Wenn du dir die antun willst, bitteschön. Du würdest zwei sogar geschenkt bekommen!
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.
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.
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.
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?
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?
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?
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 :)
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.
Cypress PSoC5 sollte das können (in gewissen Grenzen sogar beliebige Bitbreiten).
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.
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
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 :)
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.
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.
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
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?
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.
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.
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
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.
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.
Die Takte muessen aber bei 16 Bit Ubertragung fast 2 Mal besser uebereinstimmen.
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.
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.
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.
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.
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… ;-)
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.
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...
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.
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?
Gustl B. schrieb: > Geht es hier überhbaupt um Effizienz? Ja. Beitrag "Re: Mikrocontroller mit 16-Bit-UART"
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.
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?
Gustl B. schrieb: > Man kann auch schnell genug überabtasten. und hat nix gewonnen, wenn 0xffff oder 0x0000 übertragen werden sollen.
Angehängte Dateien:
-
32Bit_Frame.png
8,5 KB -
manual.png
2,9 KB
Infineon XMC sollte Längen 1 bis 63 unterstützen. Auf die Schnelle hab ich 1, 13 und 32 getestet.
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
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...
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?
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.
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.
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.
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.
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.
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.
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
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.
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.
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....
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 :)
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.
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.
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
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
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.
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
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.
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.
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
Rolf schrieb: > Überall gibt es Systeme Von konkreten Beispielen war die Rede. Wohlgemerkt im 7stelligen Bereich.
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
(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.
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…
(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.
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
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.
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.
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.
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.
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?
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.