Hallo , kann jemand bitte diese Frage lösen ? Danke
Angehängte Dateien:
Klar, das ist eine recht klare, einfache Fragestelllung. Aber die wirkliche Frage ist nicht, ob hier Jemand diese Frage beantworten kann, sondern warum Du sie nicht beantworten kannst. Zeig doch mal mit einigen Ausführungen, wo Dein Verständnisproblem liegt, was Du schon so an intellektuellem Aufwand getrieben hast, oder auchh nur Deine Erwartungshaltung, warum wir deine Aufgaben lösen sollen.
Anunaya schrieb:> kann jemand bitte diese Frage
lösen ?
Ja. Du! Es sind Deine Hausaufgaben.
Es gibt vielleicht etwas Hilfe, wenn Du erstmal genau schreibst, wie
weit Deine eigenen Überlegungen bisher gingen.
Danke für die Rückmeldung. Ich bin erste mal in diese Forum und ich wusste die Regeln nicht . Also ich denke ich wähle 9600 bit/ s weil für Uart Kommunikation 9600 Bit/s sinnvoll ist und pärität Bit ohne weil ich brauche parität Bit nur Fehler zu überprüfen. Ich glaube 7 Bit/s werde ich wählen weil dazu auch noch statt und stop Bit vorkommen und mit 8 Bit/s wäre die Messwerte Übertragung langsamer. Ist das korrekt?
Anunaya schrieb: > Ist das korrekt? "so schnell wie möglich" ist die einzige Forderung. Ist die mit deiner Lösung erfüllt? Die Aufgabe b) wird dann unerwartet interessant. Da fragt man sich doch glatt: was macht man mit dem nicht verwendeten Bit in jedem 2. Byte?
:
Bearbeitet durch Moderator
Also ich habe geschrieben Was ich könnte , mehr fällt mir gar nicht ein . Bitte kann jemand mir die hinwiese geben wie ich die löse ? Ihr braucht nicht Lösung zu geben aber nur verraten wie ich denken soll ?
Anunaya schrieb: > Also ich denke ich wähle 9600 bit/ s weil für Uart Kommunikation 9600 > Bit/s sinnvoll ist und pärität Bit ohne weil ich brauche parität Bit nur > Fehler zu überprüfen. Ich glaube 7 Bit/s werde ich wählen weil dazu auch > noch statt und stop Bit vorkommen und mit 8 Bit/s wäre die Messwerte > Übertragung langsamer. > Ist das korrekt? Wenn Du für jede Deiner obigen Entscheidungen das exakte Gegenteil nimmst, wird's sinnvoll und richtig. Aber Überlege Dir halt auch, warum. Deine Begründungen der Art "weil für Uart Kommunikation 9600 Bit/s sinnvoll ist", kannst du getrost vergessen, denn wenn es eine solche pauschale Antwort gäbe, dann hätte Dein Lehrer gar nicht erst die Frage nach der Übertragungsrate gestellt.
Anunaya schrieb: > Also ich habe geschrieben Was ich könnte , mehr fällt mir gar > nicht ein > . Bitte kann jemand mir die hinwiese geben wie ich die löse ? Ihr > braucht nicht Lösung zu geben aber nur verraten wie ich denken soll ? Na ja: denke doch mal so: Du hast die Wahl zwischen drei Autos: eines kann 50 Km/h, eines 100, das dritte 200 Km/h fahren. Du wirst gefragt, wit welchem Du am schnellsten eine Last transportieren kannst. Welches Auto wählst Du? Wenn Du diese Nuss geknackt hast, bastelst Du Dir einen ähnlichen Vergleich mit der maximalen Nutzlast eines Autos und der Gesamtlast, die Du transportieren sollst. Was kannst Du mit einer Fahrt transportieren, und wieviel mal musst Du für die Gesamtlast die Strecke fahren) So könnte es was werden mit einer analytischen Denkweise...
:
Bearbeitet durch User
38400,8n1 Macht 9 Bits pro zu übertragendem Byte, 18bits pro Messwert. 2133 Messwerte pro Sekunde. Mit den 1800 hatte ich mich grob ver-überschlagen.
Also ich wähle 200km / h weil das schnellste ist . dann wähle ich 38400 bit/s.
Wf88 schrieb: > 2133 Messwerte pro Sekunde. Mit den 1800 hatte ich mich grob > ver-überschlagen. Immer noch falsch.
Ich glaube, Ihr helft dem TO mehr, wenn Ihr statt fertiger unbegründeter Lösungen den gedanklichen Ansatz aufzeigt. Mit allem gebührenden Respekt und so, sorry, wenn ich Euch auf irgendwelche Zehen getreten habe.
:
Bearbeitet durch User
Wenn du nun 15 Maschinen transportieren muss, nimmst du den LKW der 7 Maschinen transportieren kann oder den der 8 kann? Wie brauchst du am wenigsten LKWs?
Mario M. schrieb: > Wf88 schrieb: >> 2133 Messwerte pro Sekunde. Mit den 1800 hatte ich mich grob >> ver-überschlagen. > > Immer noch falsch. 8 Datenbits + 1 Stopbits pro Byte. 2 Bytes = 18bit. 38400 / 18 = 2133 Was ist daran falsch? (Mann wie ich dieses "falsch . (PUNKT)" hasse, ohne dass da mehr kommen würde von den Oberlehrern....)
8n1 sind aber 10 Bits. Bei 15 Bit pro Meßwert und rein binären Übertragung werden 2 x 10 Bits benötigt. Wenn der Empfänger mal außer Tritt kommt, so interpretiert er den Meßwert falsch, da hilft auch kein 0- oder 1-Bit vorn oder hinten am 15-Bit-Meßwert zur Synchronisation. Den Meßwert als ASCII-kodierten Hexwert übertragen und vorweg noch ein Nicht-ASCCI-Zeichen zur Synchronisation senden sind 5 x 10 Bits. Und die mit 38k übertragen. Blackbird
Ich wähle die 8 transportieren kann . Ich nehme die 2 LKW. Dann ich wähle 8bit.
Wf88 schrieb: > 8 Datenbits + 1 Stopbits pro Byte. > 2 Bytes = 18bit. > > 38400 / 18 = 2133 > > Was ist daran falsch? > > (Mann wie ich dieses "falsch . (PUNKT)" hasse, ohne dass da mehr kommen > würde von den Oberlehrern....) Du hast das Startseite vergessen .. Blackbird
@ Lothar : Ich glaube zur Lösung der Aufgabe gehört nicht noch ein Protokoll zu berücksichtigen.
Martin schrieb: > Startbit ouh, da hab ich das obligatorische Starbit unterschlagen.... Zählt die Ausrede "bei 8n1 wird das ja nicht mit angegeben?" ;)
Beitrag #7306406 wurde vom Autor gelöscht.
Martin schrieb: > @ Lothar : Ich glaube zur Lösung der Aufgabe gehört nicht noch ein > Protokoll zu berücksichtigen. Naja, zu einem Protokoll gehört dann aber auch ein Re-Transmitting des falschen Meßwertes. Dann braucht man noch eine Nummerierung und ein paar Befehle, ... Bei der von mir vorgeschlagenen Methode wird nur ein Meßwert falsch übertragen, ohne jedoch alle folgenden. Blackbird
Lothar J. schrieb: > Bei der von mir vorgeschlagenen Methode wird nur ein Meßwert falsch > übertragen, ohne jedoch alle folgenden. Trotzdem ist es ein einfaches Protokoll. Re-Transmitting usw. ist nicht bei jedem Protokoll notwendig. Zum anderen würde es dann aber auch noch küzer / schneller gehen.
am schnellsten ist 8 bit ohne stop bit und ohne parity Begründung: der zu übertragende Messwert hat 15 Bit, nehme ich 7bit pro Paket muss ich 3 Pakete verwenden. Bei 8 Bit reichen auch 2 Baud 38400 ist klar, schneller gleich besser macht also 2x (startbit Datenpaket) => 18 Bit pro übertragenen Messwert. verstanden? Anselm
Nach alle Hinweise ich habe mich folgende Einstellung überlegt : Baudrate : 38400 Bit/s Parität : ohne Anzahl : 8 Bit 15 Bits d.h 20 bits pro Messwerte . In eine Sekunde : 38400/20 = 1920 1920 messwerte pro Sekunde . Ist das korrekt????
Martin schrieb: > Ich glaube zur Lösung der Aufgabe gehört nicht noch ein Protokoll zu > berücksichtigen. Das sollte man dann aber dazuschreiben... Denn wenn ich schon nicht erkennen muss, welches das High- und welches das Low-Byte ist, dann würde ich in das 16. unbenutze Bit jeweils noch 1 Bit eines zusätzlichen Datenworts "einschleusen" und könnte dann tatsächlich die volle Bandbreite nutzen: 1 Start + 8 Daten + 1 Stop ergibt 10 zu übertragende Bits pro Datenbyte. so könnt eich 3840 Byte/s übertragen. Und in 30 solcherart übertragenen Bytes passen dann 15 + 1 solcher 15-Bit Messwerte. Ergo könnte ich mit meinem Verfahren 3840/30 * 16 = 2048 Messwerte pro Sekunde übertragen (statt nur 1920, wenn ich das 16. Bit unbenutzt lasse).
Anselm schrieb: > am schnellsten ist 8 bit ohne stop bit und ohne parity Gibt's dafür auch Hardware? Ohne Stoppbit funktionieren die UARTs nicht. Blackbird
Nach dem Stoppbit wird nicht gefragt und außerdem ist immer mindestens eins dabei (so weit ich weiß).
Wenn man das Stopbit weglässt, kann man das Startbit auch gleich weglassen...
Lothar M. schrieb: > Martin schrieb: >> Ich glaube zur Lösung der Aufgabe gehört nicht noch ein Protokoll zu >> berücksichtigen. > Das sollte man dann aber dazuschreiben... Ich würde das umdrehen ... Was nicht da steht muss nicht berücksichtigt werden. Was nicht verboten ist, ist erlaubt ;-)
Eins ist klar, der Aufgabensteller hat per se viel Langeweile und will sein WE mit dem Nachdurchdenken der vielen möglichen richtigen Antworten verbringen. Oder es fehlt noch einiges der kompletten Aufgabenstellung.
Einstein schrieb: > Also ich wähle 200km / h weil das schnellste ist . dann wähle ich 38400 > bit/s. Langsam machst du deinem Namen alle Ehre. Respekt. Manche müssen dazu 3,4 oder gar 5 Jahre alt werden um sowas zu lösen.
Einstein schrieb: > Ist das korrekt???? Ja Von dem schnelleren Protokoll aus Beitrag "Re: Uart Kommunikation" will dein Lehrer sehr wahrscheinlich nichts hören. Ich könnte die Idee mit einem Kompressions-Algorithmus noch weiter spinnen, aber auch das wäre hier wohl fehl am Platz.
Lothar M. schrieb: >> Ich glaube zur Lösung der Aufgabe gehört nicht noch ein Protokoll zu >> berücksichtigen. > Das sollte man dann aber dazuschreiben... Hast du vergessen, wie deine Ausbildung war? Selbst in meiner Prüfung liess jede zweite Aufgabe Interpretationsspielraum. Wer im Unterricht aufgepasst hat und die Übungsaufgaben gemacht hat, wusste was von einem erwartet wird.
Einstein schrieb: > Ohne stop Bit ,? Ist auch möglich bei Uart Kommunikation?? Ja zu sagen wäre sicher falsch. In Ausnahmefällen könnte das gehen. z.B. ein Software Uart der die bits einzeln aufgreift ist nach dem achten Datenbit (dem 9. incl Startbit) fertig und kann dann ein weiteres Byte empfangen. Wäre mal interessant zu sehen wie kurz ein Stopbit werden darf bevor der Empfänger kollabiert ;-)
A. H. schrieb: > Wäre mal interessant zu sehen wie kurz ein Stopbit > werden darf bevor der Empfänger kollabiert ;-) Das dürfte unter anderem von der Toleranz der Taktfrequenzen bei Sender und Empfänger abhängen. Außerdem gibt es nicht den Empfänger. Es wird von der Implementierung abhängen. Wenn man am Framing etwas sparen möchte, ist eine asynchrone Übertragung die falsche Wahl.
Klar, das Ergeniss würde dann auch nur für den getesten Empfäger stimmen. Wenns schneller gehen soll nimmt man eine höhere Baudrate das bringt mehr als ein Stopbit einzusparen. Und funktioniert dann auch noch wenn ein Gerät ersetzt wird. In den Einstellmöglichkeiten Oben wird das Stopbit nicht erwähnt (1,1.5,2) daher kann man davon ausgehen das es ein Stopbit ist das nicht wegbleiben kann. Somit hat man die Wahl von 9 (7bit,none) bis 11bit (8bit,parity) Datensatzlänge.
Thilo L. schrieb: > Klar, das ist eine recht klare, einfache Fragestelllung. Ist sie nicht. Würde man für die 15 Datenbits abwechselnd die UART zwischen 7/8Bit umschalten, ist der Empfang von Datenmüll garantiert. Das fällt also flach. Da 15 Bits nicht in einen UART-Frame von 8 Bit passen, ist zwingend ein Protokoll notwendig. Da dieses Protokoll aber nicht genannt wird, ist dessen Overhead unbekannt und somit die Frage nicht beantwortbar. Und neben der Synchronisation des Datenframes ist weiterer Overhead notwendig, um den Haufen von Meßwerten z.B. den jeweiligen Meßpunkten zuordnen zu können. Eine extrem dreckige Möglichkeit wäre, das Paritätsbit zu mißbrauchen, um low- und high-Byte zu unterscheiden.
A. H. schrieb: > Ausnahmefällen könnte das gehen. > z.B. ein Software Uart der die bits einzeln aufgreift ist nach dem > achten Datenbit (dem 9. incl Startbit) fertig und kann dann ein weiteres > Byte empfangen. Nein, es geht nicht. Wenn Du sagst, es geht nur für bestimmte bitmuster, dann ist das albern. Ohne Stopp können 100 Bits in Folge Low sein. Damit brauchst Du Bitstuffing oder ähnliches und hast keinen sinnvollen Nutzen mehr
Wolfgang schrieb: > A. H. schrieb: >> Wäre mal interessant zu sehen wie kurz ein Stopbit >> werden darf bevor der Empfänger kollabiert ;-) > > Das dürfte unter anderem von der Toleranz der Taktfrequenzen bei Sender > und Empfänger abhängen Und von der Abtastung des Empfängers + jitter/Asymmetrie der Flanken. Bei perfekter Baudrate und perfekten Flanken (0ns) muss das stoppbit schon 2 abtasttakte lang sein (bzw. 1, weil man 0,5 Bit Reserve an beiden Seiten hat). Flankenjitter und Asymmetrie gehen direkt ein, baudratendifferenzen in Prozent x Anzahl der Bits (bei 10 Bits und 3% waren das +- 30% einer bitbreite. Kleiner als 1 bitbreite braucht das nicht zu werden, da man dann die Baudrate erhöhen kann. größer als 1,1 macht keinen Sinn, da sonst das vorletzte Bit ebenfalls falsch ist. Warum gibt es dann 1,5 oder 2? Weil damit bei Back to Back Kommunikation der Empfänger eher synchronisiert, falls er aus dem Tritt kommt.
Einstein schrieb: > Nach alle Hinweise ich habe mich folgende Einstellung überlegt : > > Baudrate : 38400 Bit/s > Parität : ohne > Anzahl : 8 Bit > > 15 Bits d.h 20 bits pro Messwerte . > In eine Sekunde : 38400/20 = 1920 > 1920 messwerte pro Sekunde . > Ist das korrekt???? Dafür würde ich die volle Punktzahl geben. Unglücklich ist natürlich, dass das notwendige Start- und Stoppbit in der Fragestellung nicht auftaucht. Aber Du hast es berücksichtig und bist bei 8-Bit Daten auf eine Übertragungslänge von 10-Bit gekommen. Typisch für solche Aufgaben aus dem Studium ist, das die Übertagung in höchster Geschwindigkeit nicht funktioniert. Bei einer pausenlosen Übertragung ist das HSB bzw. LSB nicht zu erkennen. Selbst eine Bit-Synchronisation der UART ist eher zufällig. Es muss immer eine Pause zwischen den Datenpaketen eingelegt werden. Eine Pause von einem Byte (10-Takt-Bits) sorgt für eine zuverlässige Übertragung. Das Start-Bit ist dann jederzeit erkennbar und auch das HSB/LSB ist problemlos zu unterscheiden. In dem Fall wären wir bei 30 Bits pro Übertagung. Damit sind wir bei 1280 Messwerte die zuverlässig pro Sekunde übertragen werden können. Von Tricksereien, die das letzte Bit bei der Übertagung herausholen, ist grundsätzlich abzuraten. KISS - keep it short and simple. Für den Prof. sind es 1920 Messwerte pro Sekunde. Zuverlässig sind es 1280 Messwerte pro Sekunde.
Uwe K. schrieb: > Eine Pause von einem Byte (10-Takt-Bits) sorgt für eine zuverlässige > Übertragung. Das Start-Bit ist dann jederzeit erkennbar Häh? LG, Sebastian
Uwe K. schrieb: > Das Start-Bit > ist dann jederzeit erkennbar und auch das HSB/LSB ist problemlos zu > unterscheiden. In dem Fall wären wir bei 30 Bits pro Übertagung. Damit > sind wir bei 1280 Messwerte die zuverlässig pro Sekunde übertragen > werden können. Das ist das, was schon sehr früh abgefrühstückt wurde: Martin schrieb: > @ Lothar : Ich glaube zur Lösung der Aufgabe gehört nicht noch ein > Protokoll zu berücksichtigen. Und Pausen einlegen wäre eine sehr ineffektive und schwierige Art eines Protokolls (nicht alle Uarts geben dafür die notwendige Info). Für das Uart-Synchronisierungsproblem gehen auch 2 Stoppbits, für das Protokoll reichen z.B. 2 aufeinanderfolge Bytes mit dem höchstwertigen Bit gesetzt. Vielleicht können wir uns einigen, dass die errechnete Geschwindigkeit ein Maximalwert ist, der zwar fast, aber nur im Idealfall ganz erreicht werden kann.
Uwe K. schrieb: > Bei einer pausenlosen > Übertragung ist das HSB bzw. LSB nicht zu erkennen. > Von Tricksereien, die das letzte Bit bei der Übertagung herausholen, ist > grundsätzlich abzuraten. KISS - keep it short and simple. Was wäre so kompliziert daran, drei Zeichen mit 7 Bit zu übertragen. Dann hat man insgesamt 21 Bit zur Verfügung, von den 15 für Nutzdaten verwendet werden (5 Bit pro übertragenem Zeichen) und jeweils zwei Bit für eine Nummerierung zur Verfügung stehen?
Sende alle zwei Sekunden zwei aufeinanderfolgende 0x00 zur Synchronisation und setze ansonsten das nicht benötigte 16. Bit auf 1. Dann sind's immer noch gerundete 1920 Messwerte pro Sekunde.
Uwe K. schrieb: > Unglücklich ist natürlich, dass das notwendige Start- und Stoppbit in > der Fragestellung nicht auftaucht. Indirekt schon, denn da steht "Sie haben eine UART". Da ist definitionsgemäß ein Start- und ein Stopbit enthalten.
Einstein schrieb: > Danke für die Rückmeldung. Ich bin erste mal in diese Forum und ich > wusste die Regeln nicht . Naja, du großer Denker, es sind eigentlich nicht die Regeln des Forums, sondern etwas, das der normale Menschenverstand gebietet. Man soll als Lernender sich selbst um die Lösung der Aufgaben bemühen und nicht danach trachten, selbige von anderen gelöst zu bekommen. Allerdings sehe ich beim Lesen der Aufgabenstellung etwas, das mich ärgert: Da wird von 15 Bit pro Meßwert geschrieben. Sowas legt nahe, daß der Lehrer an eine rein binäre Übertragung gedacht hatte. Ja, das geht, aber bei einer seriellen Übertragung hat man es eigentlich immer mit dem Transportieren von Daten zwischen zwei verschiedenen Geräten zu tun - und die können intern eben mit unterschiedlichen Darstellungen arbeiten. (ja, können aber nicht müssen) Und deshalb ist es sinnvoll, Daten eben NICHT rein binär zu übertragen, sondern als Texte nebst Trennzeichen, aus denen man ersehen kann, wo ein Meßwert endet und wo der nächste beginnt. Das nur zur guten Praxis, es steht nicht explizit in der Aufgabenstellung. W.S.
W.S. schrieb: > aber bei einer seriellen Übertragung hat man es eigentlich immer mit dem > Transportieren von Daten zwischen zwei verschiedenen Geräten zu tun - > und die können intern eben mit unterschiedlichen Darstellungen arbeiten. So what? Heutzutage arbeiten fast alle Protokolle seriell und rein binär codiert. Von SATA über HDMI über USB bis sonstwohin. Das tut der Funktion keinen Abbruch, auch wenn hunderte von verschiedensten Chips beteiligt sind. > Und deshalb ist es sinnvoll, Daten eben > NICHT rein binär zu übertragen, sondern als Texte nebst Trennzeichen Nein, ist es nicht. Und genau deshalb wird es auch fast nirgendwo mehr so gemacht. Alle anderen definieren einfach die Bedeutung jedes einzelnen Bits im Protokoll. Wie die einzelnen Geräte das dann intern behandeln, spielt überhaupt keine Rolle. Es muss halt einfach nur richtig im Sinne der Prokolldefinition gemacht werden. Das ist alles. > Das nur zur guten Praxis Das war gute Praxis, als man die Bytes noch mitlesen konnte. Wenn aber MBit/s oder gar GBit/s über die Strippen gehen sollen, ist es einfach nur noch Unsinn von epischen Ausmaßen. Und die Aufgabenstellung zielte ganz eindeutig auf möglichst hohen Durchsatz.
Angehängte Dateien:
-
UART_xx.jpg
99 KB
c-hater schrieb: >> Und deshalb ist es sinnvoll, Daten eben >> NICHT rein binär zu übertragen, sondern als Texte nebst Trennzeichen > > Nein, ist es nicht. Und genau deshalb wird es auch fast nirgendwo mehr > so gemacht. Da kommen auch Fehler rein, wenn es "jittert". Egal ob ASCII oder rein binär. ciao gustav
c-hater schrieb: > Wenn aber > MBit/s oder gar GBit/s über die Strippen gehen sollen Bei 38,4kBaud denke ich natürlich auch sofort an GBit/s. Text über die UART ist durchaus weit verbreitet und nicht jede Anwendung braucht maximale Geschwindigkeit. Man kann dann die Ausgabe einfach in eine Datei umleiten und lesen.
Peter D. schrieb: > nicht jede Anwendung braucht maximale Geschwindigkeit. Die Aufgabe lautet aber nun mal "so schnell wie möglich". Thema verfehlt, setzen, 6.
Martin schrieb: > Weil dies nicht der Aufgabenstellung entspricht. Worauf beziehst du dich mit diesem weisen Beitrag?
Wolfgang schrieb: > Was wäre so kompliziert daran, drei Zeichen mit 7 Bit zu übertragen. > Dann hat man insgesamt 21 Bit zur Ver Er bezieht sich auf deinen Beitrag zuvor, der eine Lösung vorschlägt, die nicht zum Problem passt.
Klaus schrieb: > Er bezieht sich auf deinen Beitrag zuvor, der eine Lösung vorschlägt, > die nicht zum Problem passt. Heißt du Martin? Aber sei's drum ... Wie stellst du dir denn vor, sicherzustellen, dass die Bits richtig zugeordnet werden? Gegenüber der Lösung mit zwei 8-Bit Zeichen und einer Pause von 10 Bitzeiten spart man mit drei 7-Bit Zeichen immerhin 10% der Übertragungszeit. Stand in der Aufgabe nicht irgendetwas von "so schnell wie möglich"?
Das ist doch eine rein theoretische Aufgabe ohne Realitätsbezug (typisch pädagogisch). Ob es nicht einfach darum, ob jemand die Einheit "bits/s" etc. verstanden hat? Kennt jemand den weiteren Zusammenhang?
Wolfgang schrieb: > Wie stellst du dir denn vor, sicherzustellen, dass die Bits richtig > zugeordnet werden? Das überlege ich mir dann, wenn mir jemand diese Aufgabe stellt und ich sie lösen muss/soll/darf. Konkret würde ich hier in seltenen Abständen (sagen wir mal einmal pro Sekunde) 0xff 0xff übertragen, und das unbenutzte Bit bei Messwerten immer zu 0 setzen. Damit ist eine einfache Synchronisation möglich und fast nix an Bandbreite verschenkt. Wolfgang schrieb: > Stand in der Aufgabe nicht irgendetwas von "so schnell wie möglich"? Genau. Und nix über höherschichtige Protokolle.
c-hater schrieb: > Heutzutage arbeiten fast alle Protokolle seriell und rein binär > codiert. Von SATA über HDMI über USB bis sonstwohin. > ... wird es auch fast nirgendwo mehr so gemacht. Gegenbeispiele: - Kommandos bei Modems und Bluetooth Modulen - GPS Empfänger - Kommunikation zwischen Backend-Systemen (REST, SOAP, JSON, XML) > Das war gute Praxis, als man die Bytes noch mitlesen konnte. Genau dazu ist es immer noch gute Praxis. > Wenn aber MBit/s oder gar GBit/s über die Strippen gehen sollen, ist > es einfach nur noch Unsinn von epischen Ausmaßen. Hier geht es nicht um MBit/s oder gar GBit/s. > Und die Aufgabenstellung zielte ganz eindeutig auf möglichst > hohen Durchsatz. Bei 38400 Baud. Wir sind uns allerdings einig, dass eine Textcodierung der Daten wohl nicht Bestandteil der Aufgabe war. Wenn ich so einen Entwicklungsauftrag bekommen würde, wäre das eine meiner ersten Rückfragen: "Wollen wir die Daten nicht lieber in maschinen- und meschen-lesbarer Form codieren?". Insofern fand ich den Hinweis von W.s. durchaus sinnvoll.
:
Bearbeitet durch User
Steve van de Grens schrieb: >> Das war gute Praxis, als man die Bytes noch mitlesen konnte. > > Genau dazu ist es immer noch gute Praxis. <ironie>Heutzutage, wo Übertragungsrate quasi kostenlos ist spielt Effizienz der Übertragung quasi keine Rolle mehr.</ironie>
Ob ich nun einen Datensatz per jSON oder XML übertrage oder als binäre Struktur - ich finde beides nicht anstößig.
Euro schrieb: > Ob ich nun einen Datensatz per jSON oder XML übertrage oder als binäre > Struktur - ich finde beides nicht anstößig. Wenn 15-Bit möglichst schnell und damit möglichst effizient übertragen werden sollen, sind sowohl jSON als auch XML dafür denkbar ungeeignet, jedenfalls solange die Übertragungsgeschwindigkeit durch die Symbolrate limitiert ist.
Einstein schrieb: > Hallo , kann jemand bitte diese Frage lösen ? > Danke Im Ernst? Dieser Kinderkram war früher 8 Klasse Niveau. Heute sind damit vermutlich die BÄTSCHELORS schwer gefordert.
Zum Stopbit, siehe auch interessanten Thread: Beitrag "Re: UART Startbit/StopBit" Da es ja je nach Empfänger fraglich ist, ob 1. das SB gar nicht ausgewertet wird und der Empfänger sofort wieder bereit ist? 2. Das SB ausgewertet wird aber wann der Empfänger wieder bereit ist? Nach 1/2 SB? Nach dem Letzten Abtasten? Wenn das SB sowieso kürzer sein darf spielt es keine Rolle mehr, wenn der Empfänger sauber in den Stream eingerastet ist. Gruss Chregu
Man könnte auch das Paritätsbit als 9tes Bit missbrauchen, in dem man dynamisch zwischen e un o umschalter. Somit würde man 9 Payload-Bytes in 11 Bytes rein bekommen (außer man will das Stop-Bit auch noch weg lassen) 38400 / 11 * 9 / 15 = 2094 Werte. Und ohne Stop-Bit: 38400 / 10 * 9 / 15 = 2304 Werte. Keiner würde das so machen, aber das wäre "so schnell wie möglich" (ohne Kompression) Gruß Roland
Christian M. schrieb: > Zum Stopbit, siehe auch interessanten Thread: > Beitrag "Re: UART Startbit/StopBit" So sollte es m.E sein (nur beim Sender) ist aber nicht so. Es gibt uC, die dann auch "längere" stoppbits erwarten > Da es ja je nach Empfänger fraglich ist, ob > > das SB gar nicht ausgewertet wird und der Empfänger sofort wieder bereit > ist? > Das SB ausgewertet wird aber wann der Empfänger wieder bereit ist? Nach > 1/2 SB? Nach dem Letzten Abtasten? Es gibt (bei 1 stoppbit) nur eine sinnvolle Art der Auswertung: genau 1 Bitlänge nach dem letzten Bit und auf identische Weise. Meist bei z.b. 3/8, 4/8 und 5/8, best of 3. Und startbereit dann bei 5/8.
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.