Hallo Zusammen, Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden, möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale ausserhalb der Toleranz ankommen. Die maximal zulässige Spannung an den Pins ist -0.5 bis 5.5V, somit habe ich zwei Masken auf diese Bereiche gesetzt. Die Signale sind wie folgt einzuhalten: V Input High (min) = 1.9V V Input Low (max) = 0.9V Also habe ich mal ein Sechseck mit den Werten 1.9 und 0.9 für max und min, und die Mitte (1.4) als mittelpunkt. Was mir nun noch fehlt ist die korrekte Berechnung der Zeit. Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca. 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt, bzw auf was ich die Werte setzen soll. Ich suche nach den Zeitwerten für die Punkte 1,2,3,4 (2 und 6 sowie 3 und 5 sind ja gleich). Kann mir jemand weiterhelfen?
Angehängte Dateien:
-
mask_0.png
8,7 KB
schau ins Datenblatt des UART, da sollten die Anforderungen an das Timing drin sein
Johnny S. schrieb: > Die maximal zulässige Spannung an den Pins ist -0.5 bis 5.5V, somit habe > ich zwei Masken auf diese Bereiche gesetzt. Wenn Überschwinger auf der Leitung zu FEHLfunktionen führen, dann ist schon mal was grundsätzlich bedenklich in der Schaltung.
Gesampelt wird in der Mitte des Bits. Die erste Flanke des Startbits startet einen internen Timer mit einer Voreinstellung auf den halben Maximalwert, danach läuft der Timer frei durch bis das Byte inkl. Stopbits durch ist. Danach fängt das Spiel von vorne an. Es gibt halt unterschiedliche UARTs. Beim 8051 wird z.b. dreimal in der Mitte gesampelt und daraus der dominante Level bestimmt.
Johnny S. schrieb: > Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca. > 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt, > bzw auf was ich die Werte setzen soll. Das kommt drauf an, wie der Empfänger das Startbit erkennt und wie er das nachfolgende serielle Signal abtastet.
Johnny S. schrieb: > Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden, > möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask > Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale > ausserhalb der Toleranz ankommen. Wenn die Signale an sich OK sind (Weit genug weg vom Schwellwert, keine Störungen drauf) gibt es 3 häufige Fehler: a) Die erste Flanke ist anders (weil aus der Sättigung) b) Toleranz der Baudrate (letzte Flanke zu früh oder zu spät) c) ungleiche High/Low-Pegel Um diese 3 Fehler per Oszi zu untersuchen, Sende verschiedene Zeichen mit je z.B. 10ms (oder 100) Pause dazwischen. Annahme: Ohne Parity. Startbit =0, Stoppbit=Ruhepegel=#111, Low-Bit first a) 0x55 (#1110101010101 auf der Leitung, triggern auf fallende Flanke) Ausmessen und Vergleichen des ersten und des letzten lows bei Sender und Empfänger b) 0x7e (#111011111101 auf der Leitung, triggern auf steigende Flanke) Ausmessen von Trigger-Flanke zu Stopp-Flanke (genau 7 Takte. Da gleiche Flanke und nicht die Erste, mittelt sich andere Fehler raus) c) 0x40 und 0xbf im Wechsel (#1110000000101 und #1110111111011 auf der Leitung, triggern auf fallende Startflanke) Es entsteht ein Augendiagramm.
Bevor ich mit Daten etwas testen möchte, wäre es doch hilfreich zuerst mal mit einem Augendiagramm zu prüfen ob die Signale an sich überhaupt stimmen. Daher suche ich im ersten Moment für die Daten der Signale an sich, also wie schnell die SIgnalle fallen und steigen müssen etc.
Ja, 9600 Bd hat eine Schrittweite von 104,17 µs. Fang doch einfach mal damit an, dass Anstieg 10 ... 90% und Abfall (Abklingen) 90 ... 10% <= 1/4 davon, also <= 26 µs sein sollten. Wenn dann mit Jitter die "Augenöffnung" (2 - 3 / 6 - 5) mit eindeutigen Logikpegeln noch >= 1/4 der Schrittweite, also 26 µs minimale Breite hat, arbeiten handelsübliche UARTs noch sauber. Wenn die Zeiten passen, ist die UART zu sensibel, wenn nicht, musst du die Ursache des Verschleifens der Pulse suchen...
Kurt schrieb: > Wenn die Zeiten passen, ist die UART zu sensibel, wenn nicht, musst du > die Ursache des Verschleifens der Pulse suchen... Wenn die Signale derart verschleißen ankommen, dass es am UART knapp wird, ist es Zeit für einen vernünftigen Schnittstellentreiber vor dem UART. Eine differentielle Übertragung würde z.B. mit Gleichtaktstörungen wesentlich besser umgehen können.
Johnny S. schrieb: > Der Verbaute MCU ist ein AT89C51 Was für einen Quarz hast Du angeschlossen? Das Signal sieht doch super sauber aus. In der Regel sind UART-Fehler immmer Softwarefehler. Ich hatte mal unerklärliche Fehler mit einem UART-USB Wandler. Mit einer neuen Treiber-DLL waren die weg. Schon seltsam, wie wenig Software getestet wird, ehe man sie verkauft.
Johnny S. schrieb: > Um einen sporadischen Fehler auf einer UART-Schnitstelle zu finden Wie oft kommt der Fehler? Wie stellst du fest, dass ein Fehler aufgetreten ist? Was passiert im Fehlerfall? Wer ist der Sender und warum sollte der solche "unschöne" Effekte wie "kurze Bits" machen können? > möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask > Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale > ausserhalb der Toleranz ankommen. Ich würde da eher im Fehlerfall den entsprechenden Teilnehmer einen Triggerimpuls ausgeben lassen und damit das dausersampelnde Oszilloskop anhalten. > Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca. > 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt, > bzw auf was ich die Werte setzen soll. Die Toleranz ist dort überschritten, wo dein Empfänger nichts mehr mit dem Signal anfangen kann und Fehler produziert. Weil es unterschiedlich robuste Implementationen von Empfängern gibt, sind auch diese Toleranzen unterschiedlich. Johnny S. schrieb: > Bevor ich mit Daten etwas testen möchte Ohne Daten kannst du eh' nichts testen. Und wenn du dann schon Daten erzeugen musst, dann wenigstens solche, die bei der Fehlersuche helfen. > wäre es doch hilfreich zuerst mal mit einem Augendiagramm zu prüfen > ob die Signale an sich überhaupt stimmen. Aus Erfahrung: wenn das Gelbe da oben dein Signal ist, dann hast du andere Probleme, denn dieses Signal sieht gut aus. Nächster Schritt. Oder andersrum: wenn du ein Signal hast, das irgendwie in den schwarzen Bereich deines Augenduiagramms passt, dann kann dein Augendiagramm-Test sagen: "alles gut!", obwohl das Signal im Grunde an sich echt übel aussieht. Denn wenn du ein 5V-UART-signal hast, das normalerweise immer 0V und 5V hat, und dessen H-Pegel wegen einer Buskollision zwischendurch mal auf 2,5V "zusammenbricht", dann wird dein Augendiagramm trotz dieser Kollision keinen Fehler anmeckern, weil ja 2,5V immer noch gut oberhalb von 1,9V sind... Lies und versuche zu verstehen, was A. S. schrieb: > 3 häufige Fehler Denn so werden Fehler auf UART-Schnittstellen gefunden. Johnny S. schrieb: > Der Verbaute MCU ist ein AT89C51 Auf welcher Seite ist der verbaut? Als Sender? Oder als Empfänger?
:
Bearbeitet durch Moderator
Uartfehler sind zum groessten Teil Software Fehler. Falls EMV nicht beachtet wurde allenfalls auch EMV Fehler. Bei einem hinreichend langen Kabel koennte es geschehen, dass die GND Potentiale verschieden sind. Das gibt auch Uebertragungsfehler. Uebertragungsfehler sollten mit einem Protokoll abgefangen werden.
Nochmal zur klarstellung: Es tut mir leid falls es verwirrung gibt zum Screenshot. Der Screenshot zeigt NICHT! das zu analysierende Signal, sondern einfach ein ausgegebenes UART von einem Arduino. Das hatte ich benutzt, um überhaupt einmal die Augenmaske hinzubekommen! Kurt schrieb: > Ja, 9600 Bd hat eine Schrittweite von 104,17 µs. > > Fang doch einfach mal damit an, dass Anstieg 10 ... 90% und Abfall > (Abklingen) 90 ... 10% <= 1/4 davon, also <= 26 µs sein sollten. > > Wenn dann mit Jitter die "Augenöffnung" (2 - 3 / 6 - 5) mit eindeutigen > Logikpegeln noch >= 1/4 der Schrittweite, also 26 µs minimale Breite > hat, arbeiten handelsübliche UARTs noch sauber. > Also wären die Punkte 2 und 3 bei +39us und bei +65us zu setzen? Lothar M. schrieb: > Wie oft kommt der Fehler? Wie stellst du fest, dass ein Fehler > aufgetreten ist? Was passiert im Fehlerfall? Wer ist der Sender und > warum sollte der solche "unschöne" Effekte wie "kurze Bits" machen > können? Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes. Leider ist es dann aber so, das er "ansteht". Ein Reset und so gar Spannungsfrei machen, nützt dann nichts. Deshalb sol das komplette System vermessen werden. >> möchte ich ein Oszilloskop anschliessen mit einem Maskentest (Eye Mask >> Test) um so herauszufinden ob ab und zu unförmige Signale oder Signale >> ausserhalb der Toleranz ankommen. > Ich würde da eher im Fehlerfall den entsprechenden Teilnehmer einen > Triggerimpuls ausgeben lassen und damit das dausersampelnde Oszilloskop > anhalten. > >> Ich habe bereits herausgefunden das ein UART Signal bei 9600baud ca. >> 105uS lang ist, ich frage mich aber aktuell wie denn die Toleranz liegt, >> bzw auf was ich die Werte setzen soll. > Die Toleranz ist dort überschritten, wo dein Empfänger nichts mehr mit > dem Signal anfangen kann und Fehler produziert. Weil es unterschiedlich > robuste Implementationen von Empfängern gibt, sind auch diese Toleranzen > unterschiedlich. > > Ohne Daten kannst du eh' nichts testen. Und wenn du dann schon Daten > erzeugen musst, dann wenigstens solche, die bei der Fehlersuche helfen. Um mit spezifischen Daten zu testen, müsste das komplette System angepasst werden, um Testdaten auszugeben, daher wollte ich vorher prüfen ob die Spannungen überhaupt dauerhaft passen, oder aus irgendeinem Grund nicht den Spezifikationen entsprechen > Johnny S. schrieb: >> Der Verbaute MCU ist ein AT89C51 > Auf welcher Seite ist der verbaut? Als Sender? Oder als Empfänger? Nunja, der MCU ist Quasi der "Master", er Sendet die Initiale Kommunikation, empfängt danach aber natürlich auch Daten.
Johnny S. schrieb: > Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes. Wie oft passiert der Fehler: 1x am Tag oder alle 5 Minuten? Denn beim Dauersenden wäre das etwa jede Minute. Und das ist ziemlich oft. > Leider ist es dann aber so, das er "ansteht". Wie steht "er" an? Woran merkt man diesen "Anstand"? Werden keine Daten mehr übertragen? Warum nicht? > Ein Reset und so gar Spannungsfrei machen, nützt dann nichts. ?? Das ist leider für einen Aussenstehenden nicht nachvollziehbar. > Deshalb sol das komplette System vermessen werden. Dieser logische Spagat ist für mich nicht nachvollziehbar. > Um mit spezifischen Daten zu testen, müsste das komplette System > angepasst werden, um Testdaten auszugeben, Ja, so ist das, wenn man einen solchen Dauerübertragungs-Testmodus nicht von vorn herein vorgesehen und mit eingebaut hat. Das rächt sich... Nach wie vor wäre meine Strategie: wenn da zyklisch Daten übertragen werden und im Fehlerfall der Klimbim stehen bleibt, dann setze ich einen Trigger auf die serielle Übertragung (bzw. auf den Augenblick, wo sie aussetzt und eben nicht mehr zykelt).
Poste echte Scopebilder am Empfänger gemessen.
Johnny S. schrieb: > Der Fehler passiert relativ selten, schätzungsweise 1x pro 50'000 bytes. > Leider ist es dann aber so, das er "ansteht". Ein Reset und so gar > Spannungsfrei machen, nützt dann nichts. Das klingt dann eher nach einem Protokollfehler. Das implementierte Protokoll ist nicht in der Lage, nach einer Störung oder Unterbrechung wieder auf das nächst Paket zu synchronisieren. Das ist aber eigentlich die Mindestanforderung an ein Protokoll.
Johnny S. schrieb: > Daher suche ich im ersten Moment für die Daten der Signale an sich, also > wie schnell die SIgnalle fallen und steigen müssen etc. Revision E des RS232-Standards (aktuell ist mindestens schon F). Transition Region ist der illegale Bereich zwischen -3V und +3V: Certain limitations apply to all interchange signals (data, control, and timing) as follows: * Interchange signals entering transition must proceed to the opposite signal state, and may not reenter the transition region until the next significant change in signal condition. * The direction of voltage must not change while in the transition region. * The time required for a control signal to pass through the transition region must not exceed one millisecond. * The time required for a data or timing signal to pass through the transition region must not exceed one millisecond or 4% of the normal duration of a signal element on that interchange circuit, whichever is the lesser. * The maximum instantaneous rate of voltage must not exceed 30 volts per microsecond
Anne Kragen schrieb: > Transition Region ist der illegale Bereich zwischen -3V und +3V: In der Praxis sind aber RS232-Receiver TTL-compatibel (<=+0.8V, >=+2.4V), z.B. MAX232: "These receivers have a typical threshold of 1.3 V, a typical hysteresis of 0.5V, and can accept ±30-V inputs."
Anne Kragen schrieb: > Revision E des RS232-Standards (aktuell ist mindestens schon F). > Transition Region ist der illegale Bereich zwischen -3V und +3V: Wer sich das Oszibild angesehen hat und es entziffern kann, der erkennt, dass es hier um einen UART mit "TTL"-Pegeln von 5V und 0V geht. Und eben nicht um einen RS232-UART. Insofern sind RS232 Spezifikationen hier nicht so arg hilfreich. Peter D. schrieb: > In der Praxis sind aber RS232-Receiver TTL-compatibel (<=+0.8V, >>=+2.4V), z.B. MAX232: > "These receivers have a typical threshold of 1.3 V, a typical hysteresis > of 0.5V, and can accept ±30-V inputs." In der Praxis hilft das aber nichts, weil die Pegel von '0' und '1' invertiert sind: der Ruhepegel '1' auf der RS232-Seite ist "negative Spannung", der Ruhepegel '1' auf der "TTL" Seite sind positive 5V.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > In der Praxis hilft das aber nichts, weil die Pegel von '0' und '1' > invertiert sind Doch, schon. Einige MCs können IOs umpolen. Oder als SW-UART geht das auch, z.B. in meinem Bootloader.
Peter D. schrieb: > Das klingt dann eher nach einem Protokollfehler. Das implementierte > Protokoll ist nicht in der Lage, nach einer Störung oder Unterbrechung > wieder auf das nächst Paket zu synchronisieren. Das ist aber eigentlich > die Mindestanforderung an ein Protokoll. Das passt aber gar nicht zu: Johnny S. schrieb: > Ein Reset und so gar > Spannungsfrei machen, nützt dann nichts. Wer merkt sich denn dann das Problem? Und wie bekommt er das System dann wieder zum Laufen? Nur eine Seite spannungsfrei machen ist eh Mist, solange die eine Seite noch treiben könnte.
HildeK schrieb: > Johnny S. schrieb: >> Ein Reset und so gar >> Spannungsfrei machen, nützt dann nichts. > > Wer merkt sich denn dann das Problem? Und wie bekommt er das System dann > wieder zum Laufen? > Nur eine Seite spannungsfrei machen ist eh Mist, solange die eine Seite > noch treiben könnte. Ich habe keine eigene Erfahrung mit AT89C51. Kann der aus einem anliegenden High-Pegel an einem Eingang weiter leben? Dann sollte der TO Optokoppler zwischenschalten oder sich was anderes zur Entkopplung ausdenken. Und den Fehler in seiner Software suchen.
Dieter R. schrieb: > Kann der aus einem anliegenden High-Pegel an einem Eingang weiter leben? Fast alle µC können diese Art der parasitären Versorgung. Wenn über den "High-Pegel" am Eingangspin genug Strom kommt. Dieter R. schrieb: > Dann sollte der TO Optokoppler zwischenschalten oder sich was anderes > zur Entkopplung ausdenken. Sowas z.B.
1 | 5V |
2 | o |
3 | | |
4 | 2k2 |
5 | | |
6 | TX ----|<-----o------- RX |
7 | Schottky |
8 | uC1 uC2 |
9 | |
10 | GND ------------------ GND |
Dann wird auch dann nichts parasitär versorgt, wenn TX vom uC1 auf 5V liegt und der uC2 keine Vcc bekommt.
:
Bearbeitet durch Moderator
HildeK schrieb: > Wer merkt sich denn dann das Problem? Die nicht abgeschaltete Seite. Entweder der eine sendet munter weiter, während der andere gerade aus dem Reset kommt. Oder einer sendet wieder, während der andere noch in seiner Empfangsroutine verklemmt ist. Gegen beides hilft ein ordentliches Protokoll. Und ja, ein Timeout ist nie ein ordentliches Protokoll, höchstens nur ein Würgaround.
Break wurde auch schon lange erfunden. Kann auch einen Reset auslösen, wenn man es geschickt anstellt.
Johnny S. (sgt_johnny) schrieb
> Also wären die Punkte 2 und 3 bei +39us und bei +65us zu setzen?
Was zierst du dich nur so mit den µs?
Probier es mit halbwegs plausiblen Daten:
0 - 1/4 - 3/4 - 1 also 0 - 26 - 79 - 104 µs, oder
0 - 1/3 - 2/4 - 1 also 0 µs, 35 µs, 70 µs, 104 µs
Wenn das Bild nichts aussagt, variierst du die Werte. Da kann man sich
doch mit den vorgegebenen Eckwerten rantasten...
Oder...
Du denkst mal darüber nach, wie ein Byte-Fehler die ganze Übertragung,
dauerhaft stören kann. Das ist bestimmt nicht der U(S)ART, auch nicht
das Protokoll, sondern irgendwas nicht zu Ende gedachtes im Programm.
Was rettet denn den Fehler über einen Reset? Wird Müll in's EEPROM
geschrieben, der beim Neustart wiederum Unfug hervorruft?
Kurt schrieb: > Da kann man sich doch mit den vorgegebenen Eckwerten rantasten... Genau das passiert bei der Anleitung, die A. S. schrieb: >>> Es entsteht ein Augendiagramm. Aber ewig nach der allein glückselig machenden Augenspezifikation zu suchen ist eben auch nutzlos. Denn wenn der Sender ein UART-Device hat, das funktioniert, wer soll dann ein Timing verletzen? Und andere Fehler (ESD, Buskollisionen, ...) findet man mit anderen Werkzeugen besser. Ich triggere auf die fallende Flanke und setze die Nachleuchtdauer auf "ewig". Und dann sehe ich mir an, was sich da tut. Danach das selbe mit der steigenden Flanke. Und fertig ist der Test, ob "zu kurze" Bits auf der Leitung unterwegs sind. Gleichzeitig sehe ich, ob da irgendwelche ungültigen und dubiosen Pegel aufgetreten sind. Ein Augendiagramm für diese Aufgabe zu verwenden ist wie ein Gurkenglas mit einem Minibagger aufzuschrauben. Irgendwie wird das schon gehen. Und Hauptsache man kommt an die Gurke. Dass es für diese Aufgabe viel einfachere und bessere Methoden gibt, das sollte man allerdings schon im Hinterkopf haben. Augendiagramme sind gut für Übertragungsfrequenzen, die mindestens 5 Zehnerpotenzen höher liegen. Damit wird auch nicht vorrangig nach einzelnen Bitfehlern gesucht, sondern die Qualität der Übertragungsstrecke vermessen. Abdul K. schrieb: > Break wurde auch schon lange erfunden. > Kann auch einen Reset auslösen, wenn man es geschickt anstellt. Das ist so ein Fall, wo man sich glatt ins Knie schießen kann. Die Behandlung eines Übertragungsfehlers darf nicht automatisch zu einem Reset führen. Ein Reset (z.B. auch per Watchdog) ist kein Fehlerbehandlungsmechanismus. Auch wenn weniger erfahrene Entwickler das meinen. Kurt schrieb: > Du denkst mal darüber nach, wie ein Byte-Fehler die ganze Übertragung, > dauerhaft stören kann. Oder eben irgendein anderer Fehler (Framing, fehlerhafter Start oder umgekipptes Bit nach einem ESD-Spike, ...). Das unterschiedet den schlechten vom mittelmäßigen und guten Programmierer: Der Schlechte geht davon aus, dass die Hardware unfehlbar und absolut störungsfrei ist. Weil es in seiner Welt keine Fehler gibt, macht er keinerlei Fehlerbehandlungsroutinen und wundert sich über sporadische Fehlfunktionen bis zum "Stillstand". Er kommt dann zum Hardwareentwickler und sagt: mach das gut! Der Mittelmäßige schreibt sein Programm so, dass es erkennt, dass da ein Fehler aufgetreten ist, stoppt die Übertragung und zeigt eine Fehlermeldung an. Diese Fehlermeldung bekommt man dann durch Ein- und Ausschalten oder einen anderweitig aufwendigen Resetprozess wieder weg. Der Gute macht die SW so, dass sie erkennt, dass da ein Fehler aufgetreten ist, setzt im Fehlerfall die Übertragung neu auf und zählt einen Fehlerzähler hoch. Bei zu vielen Fehler in zu kurzer Zeit kommt eine Warnung und letztlich eine Fehlermeldung. Während diese Fehlermeldung ansteht, funktioniert die Übertragung aber weiterhin (so gut es geht). Letztlich ist das hier mit deutlich über 99% Wahrscheinlichkeit ein Softwareproblem.
:
Bearbeitet durch Moderator
Es ist sogar andersrum: eine UART-übertragung musst kurze Störungen verkraften (Flanken, high oder low für einige Bitzeiten). Framing/Parity/Overunfehler müssen erkannt werden und mindestens zu einem verlorenen Telegramm führen. Notfalls sequencecounter mit einbauen. Und danach muss es weitergehen. Sonst ist das keine UART-Verbindung sondern synchronraten.
Kennt ich noch die Drucker, die nach einem einzigen fehlerhaften Bit das ganze Magazin mit Hieroglyphen bedrucken? Wenn man diese vor lauter Verzweifelung aus schaltete, musste man den Papierstau heraus pulen und nach dem Wieder-Einschalten ging das Desaster direkt weiter so, mangels Zugriff auf den Printserver/Puffer. Ich bin so froh, dass das vorbei ist.
Stefan ⛄ F. schrieb: > Kennt ich noch die Drucker, die nach einem einzigen fehlerhaften Bit das > ganze Magazin mit Hieroglyphen bedrucken? Die hatten aber Centronics-Schnittstelle. Oder Zentronix?
Dieter R. schrieb: > Die hatten aber Centronics-Schnittstelle Ja, und das meistens mit Netzwerk-Adapter und Print-Server (Puffer) kombiniert.
Wie wäre es, einem weiteren UART anszuschließen und mitzuprotokollieren, was auf der Leitung läuft? Eventuell kann das Protokoll 'von Hand' dekodiert werden und damit eventuelle Protokollfehler gefunden werden.
A. S. schrieb: > Sonst ist das keine UART-Verbindung sondern synchronraten. Das 'A' in UART steht für asynchron ;-)
Ein Hauptgrund für die Entwicklung des CAN-Busses war auch, daß die UART außer der 3-fach Abtastung keinerlei Übertragungssicherung hat. Professionelle UART-Protokollstacks belegen daher gerne mal 100kB an Code, das wird eng auf einem 8051.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.