www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Das A und O des UART- Puffers


Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin!

Ein Atmega8535 soll zwischen mehreren RS232- Signalquellen umschalten. 
Gelöst mittels HC151, klappt ganz herrlich.

Aber angenommen:
die Umschaltung auf eine neue Quelle erfolgt gerade inmitten eines 
gesendeten Bytes. Der Puffer empfängt also das Ende eines Bytes, hält es 
für den Anfang dessen, und beendet es mit dem Anfang des nächsten 
kommenden Bytes.
Da kann ja nur Kacke bei rauskommem.

Ist die Sorge berechtigt oder wie lässt sich das soft-/hardwaremäßig 
ausschließen?

Mange Tak- Stephan

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Wer bedient den Umschalter? Der ATMega oder....

MfG Spess

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nix oder, das macht der Atmega.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Ist die Sorge berechtigt oder wie lässt sich das soft-/hardwaremäßig
> ausschließen?
Das kann nicht nur passieren.
Nach dem Gesetz von Murphy muss und wird passieren...

Du wirst also deine SW so anpassen müssen, dass sie damit klarkommt. 
Insbesondere ist ein einzelnes Byte nur ein Bruchstück der Wahrheit. 
Denn i.A. wird ja eine ganze Zeichenkette über die RS232 gesendet, wo 
jedes Byte seine eigene Bedeutung hat...

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Der Puffer empfängt also das Ende eines Bytes, hält es
> für den Anfang dessen, und beendet es mit dem Anfang des nächsten
> kommenden Bytes.

Es gibt ne Erfindung die nennt sich Start Bit!

Daher gibt das kein Müll, nur das eine Byte ist kaputt...

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lmiller und Docean sind sich uneins..

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was macht die UART mit kaputten Bytes? Wegschmeissen?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Lmiller und Docean sind sich uneins..
Wir sind ja auch zwei... ;-)
Aber ich habe recht...

>>> Aber angenommen: die Umschaltung auf eine neue Quelle erfolgt
>>> gerade inmitten eines gesendeten Bytes.
>> Es gibt ne Erfindung die nennt sich Start Bit!
>> Daher gibt das kein Müll, nur das eine Byte ist kaputt...
Nehmen wir mal das:
A=Startbit
D=Datenbits
E=Stopbit
X=Umschaltzeitpunkt
           AD       E
TX1    1111011110000111111111111  -- sendet 0xf0
                AD       E
TX2    1111111110111100001111111  -- sendet 0xf0
               X
RX     1111011110111100001111111  -- empfängt 0xf7 und 0x1f
            11110111  00011111    --> zwei Bytes korrekt empfangen,
                                      aber Daten korrupt

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Was macht die UART mit kaputten Bytes? Wegschmeissen?

Das musst du organisieren.

Wie wäre es, einfach die Fehlerbits der UART auszuwerten?

MfG Spess

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Entsteht denn bei dem von Lothar sehr schön dargestellten Fall (mein 
Worst-case) ein Fehlerbit? Und was ist ein Fehlerbit? So etwas wie eine 
checksumme?

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du musst halt die Umschaltung in der Software sperren wenn du gerade was 
sendest. Und diese Erst nach dem Senden freigeben.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar Miller: genau!

@Stephan R.: Wirst du entweder die Quellen synchronisieren müssen oder 
mit einer Prüfsumme (CRC) die Möglichkeit der Fehlererkennung seitens 
des Empfängers einführen müssen.

Einfach drauflos ballern iss nix.

Gruß
ich

Autor: Sven H. (dsb_sven)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es denn die Handshake Leitungen zu verwenden? Im ersten Post 
wird ja eine hardwareseitige Lösung nicht ausgeschlossen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Entsteht denn bei dem von Lothar sehr schön dargestellten Fall (mein
> Worst-case) ein Fehlerbit?
Nein. Passt alles für 8N1...
> Und was ist ein Fehlerbit?
Der naheliegendste Fehler ist ein Framing Error, dass eigentlich ein 
Stopbit erwartet, aber eine 0 erkannt wurde.
> So etwas wie eine checksumme?
Nein. Diese Fehler greifen nur auf der Bitebene des Protokolls. 
Prüfsummen beziehen sich auf mehrere Bits.

Und mein Beispiel bezieht sich zudem auch "nur" darauf, dass beide 
Sender bitsynchron sind. In der Realität sind sie das kaum bis niemals, 
und deshalb wird es einige urige Fehlerbilder geben...

Insbesondere, wenn beide Sender Bytes ohne Pause hintereinander senden 
kannst du durchaus auch viele falsche Bytes korrekt empfangen...

Autor: Fabian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst Du nicht, wenn Du zwischen zwei Streams hin und herschaltest, 
über "0" schalten?! Also erst die Leitung trennen "kurz" warten und dann 
auf die andere aufschalten?!

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Handshake wird leider nix, da sie Signalquellen keins anbieten.
Synchronisieren wird auch schwierig, da die Geräte vällig autonom sind 
(LWL- Interface und GPS- Empfänger).
Ich habe also keine Wahl als mitten in den Datenstrom reinzuspringen.

Framing-Error hört sich für mich am geeignetsten an.

Einziges Risiko wäre doch, dass, bis das erste falsche Stop- Bit 
auftaucht (was statistisch nicht allzu lang dauern dürfte), nur Mist 
ankommt, was denn weggeschmissen wird. (Oder?)

Wie lautet denn die Abfrage nach der Correctness des Bits? Und was tut 
die UART von haus aus, wenn dieser Error auftritt?

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde, falls es deine Anwendung erlaubt, das serielle Eingangssignal 
in ein Schieberegister mit seriellem Ein- und Ausgang jagen. Am 
parallelen Ausgang siehst du ob sich gerade irgendwas an der Übertragung 
tut. Diese Ausgänge kannst du "verodern". Wenn auch nur ein Bit gesetzt 
ist dann ist was in der "Pipe".
Das erfordert natürlich, dass über die Länge von min. einem Byte keine 
Daten gesendet werden um die Pause erkennen zu können.
Das Schieberegister muss dann mit der Baudrate getaktet werden. Den Takt 
könnte der Controller erzeugen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Insbesondere, wenn beide Sender Bytes ohne Pause hintereinander senden
>> kannst du durchaus auch viele falsche Bytes korrekt empfangen...
So etwa:
           AD       E
TX1    1111011110000111111111111  -- sendet 0xf0
                AD       E
TX2    111111111011110000101111000010111100001111111  -- sendet 0xf0
               X
RX     111101111011110000101111000010111100001111111  -- empfängt 0xf7 0x17, 0x17 und 0x1f
            11110111  00010111  00010111  00011111    --> vier Bytes korrekt empfangen, aber Daten korrupt

> Kannst Du nicht, wenn Du zwischen zwei Streams hin und herschaltest,
> über "0" schalten?!
Richtig wäre: über '1' umzuschalten, das ist der inaktive RS232-Pegel.
Das hilft aber auch nicht weiter:
           AD       E
TX1    1111011110000111111111111  -- sendet 0xf0
                AD       E
TX2    111111111011110000101111000010111100001111111  -- sendet 0xf0
               XXXX  <-- Umschalten
RX     111101111111110000101111000010111100001111111  -- empfängt 0x17, 0x17 und 0x1f
                      00010111  00010111  00011111    --> drei Bytes korrekt empfangen, aber Daten korrupt

Jede andere Kombination ist problemlos vorstellbar...

Autor: ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
noch einfacher: Benutze einen Controller mit mehreren UARTS. Der xmega 
bietet bis zu 8 USARTs

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider schon 50m Fädeldraht verfädelt, zu spät für Controllerwechsel. 
Und für ein Schieberegister ist auch ken Platz mehr.. Ich möchte mich 
auf die Stoppbitverarbeitung konzentrieren.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Leider schon 50m Fädeldraht verfädelt, zu spät für Controllerwechsel.
> Und für ein Schieberegister ist auch ken Platz mehr.. Ich möchte mich
> auf die Stoppbitverarbeitung konzentrieren.

Auf Bitebene ist das Alles ohne Synchronisierung nix. Schau dir Lothar's 
Beispiele an, da hilft dir auch ein Stopbit nichts, wenn die Zahl der 
Bits stimmt und der Empfänger vom Umschalten nichts mitbekommt.

Ein Stopbit ist eben ein Stopbit und dient nicht der Fehlererkennung, 
die du hier dringend brauchst.

Führe wenigstens CRC ein, damit der Empfänger falsche Pakete verwerfen 
kann.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Insbesondere, wenn beide Sender Bytes ohne Pause hintereinander senden
> kannst du durchaus auch viele falsche Bytes korrekt empfangen...

Stimmt!

Laß mal den MC irgendwelchen Text ununterbrochen senden.
Und danach starte auf dem PC ein Terminal und schließe ihn an.
20 Zeilen nur Mist sind durchaus möglich, ehe der Text lesbar wird.

Mit 2 Stopbits entschärft sich das leicht (nur 3 Zeilen Mist).

Du brauchst also unbedingt eine Synchronisation.
Z.B. der Sender macht vor einem neuen Paket ne Pause von mindestens 10 
Bitzeiten.
Oder ein Byte mit nur einer Startflanke (0x00, 0x80, 0xC0, ... 0xFF).


Peter

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Synchronisation schön und gut..
Liesse sich denn seitens des Empfangspuffers synchronisieren? Soll 
heissen: falls die ankommenden Zeichen nicht aus 0-9 oder A-Z bestehen, 
"was" machen.
Nur was? Schieboperation im Puffer? Gibts das?

Die einherströmende Datenflut (NMEA) kann ich echt schlecht 
beeinflussen!

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Die einherströmende Datenflut (NMEA) kann ich echt schlecht
> beeinflussen!

Kann man den Geräten denn nicht sagen wann sie anfangen sollen zu 
senden. Was sind das für Teile, die einfach ununterbrochen senden? Das 
macht doch keinen Sinn.
Und wenn sie ununterbrochen senden, dann müssen Sie ein Protokoll 
besitzen, mit dem Du den Anfang eines logisch zusammengehörigen 
Datenpakets erkennen und auch prüfen kannst.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> falls die ankommenden Zeichen nicht aus 0-9 oder A-Z bestehen,
Dann liesse sich langfristig was machen.

> Nur was? Schieboperation im Puffer? Gibts das?
Du kannst auf jeden Fall gleich mal alles wegwerfen, was nicht aus 
diesen Zeichen besteht. Dann auf eine Pause im Datenstrom hoffen, und 
wenn irgendwann keine Framing-Fehler mehr kommen und du nur noch 
"sinnvolle" Zeichen empfängst, hast du es geschafft, dich wieder 
aufzusynchronisieren. Bis dahin hilft nur hoffen... :-/

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Die einherströmende Datenflut (NMEA) kann ich echt schlecht
> beeinflussen!

Sicher, daß da keine Pausen zwischen den Paketen sind?

Ohne Pausen kann der Empfänger nicht 100%-ig synchronisieren, basta.

Man kann im RX-Interrupt nen Zeitstempel nehmen, ob nach dem Umschalten 
bzw. zum vorherigen RX mindestens 20 Bitzeiten vergangen sind. Und erst 
dann nimmt man das Paket entgegen.


Peter

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> Was sind das für Teile, die einfach ununterbrochen senden? Das
> macht doch keinen Sinn.

Eben z.B GPS-Empfänger, die die Frames z.B. im NMEA-Format im 1 
Sekundentakt
senden.
Klar macht das Sinn.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn sie im 1 Sekundentakt senden, senden sie eben nicht ununterbrochen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> Eben z.B GPS-Empfänger, die die Frames z.B. im NMEA-Format im 1
> Sekundentakt
> senden.

Und die Frames sind dann auch wirklich 1s lang?
Wenn sie kürzer sind, hast Du doch ne Pause und alles ist in Butter.


Peter

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe gerade mal gegoogelt NMEA ist doch ein standardisiertes 
Datenformat, Zwischen 2 NMEA Sätzen ist bestimmt eine Pause die dafür 
sorgt daß der UART bei Bitweiser Misssynchronisation einen Fehler wirft 
und vorher anfangen zu lesen hat eh keinen Wert.
Ab dann liest Du den kompletten NMEA Datensatz ein, der hat sogar einen 
(optionalen) CRC, den Du auswerten solltest falls vorhanden. Danach 
schaltest Du auf den 2. Kanal und synchronisierst analog je nach 
darüberliegendem Protokoll auf diese Daten.
Byte oder gar Bitweises Denken ist hier vollkommen unnötig.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@U.R. Schmitt:
nen Standard-GPS- Empfänger.

Werde mich mal in der Spec umsehen, obs nicht doch einen Befehl gibt, 
die Aktualiesierungrate zu vergrößern. Irgendwas hab ich da mal 
gelesen..

Bleibt offen: was tut der Atmega -werkseingestellt- mit Framingerrors? 
Wird ein Flag gesetzt und das Byte dennoch ausgegeben oder wird es 
gleich verworfen?

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Wenn sie im 1 Sekundentakt senden, senden sie eben nicht ununterbrochen.

War klar, dass die Antwort kommen musste. Fast richtig, ist nur Mist, 
wenn du 8 Quellen hast, die nicht gegenseitig aufeinander warten und 
synchron laufen, oder?

Wenn z.B. zwei GPS-Sender als Quellen dienen, der erste bei 0s anfängt, 
der zweite bei 0,2s, dann sendet jeder für sich noch immer im 
Sekundentakt, das Delta zwischen beiden ist aber 0,2s. Schaltet der 
Multiplexer z.B zum Zeitpunkt 0,8s, dann erwischt er den zweiten Sender 
und der sendet noch 0,4s seinen Krempel. Damit wäre Lothar's Fall wieder 
gültig, nämlich eine Überlagerung von Bits, die im ungünstigsten Fall 
eben ein korrektes Byte bauen.

Bei 8 Sendern oder Geräten, mit oder ohne Takt, wird's dann noch 
kritischer. Irgendwie ist das alles keine saubere Lösung, wenn der 
Multiplexer nicht auf die Quellen synchronisiert wird.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> (NMEA)
Dann ist es quasi schon simpel.
Schade, dass diese Information erst nach 2 Stunden kommt... :-/

>> und der sendet noch 0,4s seinen Krempel.
Macht doch nichts....
Eine Sekunde später hast du wieder ein gültiges Datenpaket.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:

> Irgendwie ist das alles keine saubere Lösung,

Das sowieso.
Da ist jemand zu blauäugig an die Sache herangegangen.
Die sauberste Lösung wäre, ein IC mit mehreren USART in die Schaltung 
mit aufzunehmen. Alles andere ist Murks. AUch wenn einem NMEA hier unter 
die Arme greift:
  Es gibt (normalerweise) eine physische Pause zwischen den Sätzen
  Wir wissen, dass jeder Satz mit $ anfängt

Aber ohne dass einem zwischendurch ein paar Datensätze verloren gehen, 
wirds nicht gehen.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
>>> und der sendet noch 0,4s seinen Krempel.
> Macht doch nichts....
> Eine Sekunde später hast du wieder ein gültiges Datenpaket.

Stimmt, wenn es sich ausschliesslich um periodisch gesendete Datenpakete 
handelt.

Aber was ist, wenn auf einem Kanal der GPS arbeitet, auf einem anderen 
irgendeine nicht-zyklische Information gesendet wird, die zudem nicht 
verloren gehen darf?

Vielleicht habe ich es in meiner Abwesenheit der Mittagspause überlesen, 
ansonsten wäre es gut zu wissen, was auf den anderen Kanälen gesendet 
wird (periodisch oder nicht, wichtige, z.B. sicherheitsrelevante Daten 
oder nicht).

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Alles andere ist Murks.

Das sehe ich auch so. Ohne das verachtend zu meinen, ich würde so etwas 
nicht wie oben genannt implementieren.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> War klar, dass die Antwort kommen musste. Fast richtig, ist nur Mist,
> wenn du 8 Quellen hast, die nicht gegenseitig aufeinander warten und
> synchron laufen, oder?

Das ist egal.
Du schaltest einfach um und prüfst auf die Pause. Dadurch ist das 
folgende Paket gültig.
Dann schaltest Du wieder um, ...


Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:

> Vielleicht habe ich es in meiner Abwesenheit der Mittagspause überlesen,
> ansonsten wäre es gut zu wissen, was auf den anderen Kanälen gesendet
> wird (periodisch oder nicht, wichtige, z.B. sicherheitsrelevante Daten
> oder nicht).

Sicher bin ich mir natürlich nicht, aber das hier
Beitrag "Re: Das A und O des UART- Puffers"
würde für mich den Schluss zu lassen, dass wir es mit 8 GPS Empfängern 
zu tun haben. Was auch immer es für einen Sinn haben soll, 8 GPS 
Empfänger in einer Schaltung zu haben.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> Aber was ist, wenn auf einem Kanal der GPS arbeitet, auf einem anderen
> irgendeine nicht-zyklische Information gesendet wird, die zudem nicht
> verloren gehen darf?

Dann gehört derjenige, der sowas verzapft, geteert und gefedert.

Wenn ein Paket nicht verloren gehen darf, dann muß ich das irgendwie 
absichern.
Z.B. dadurch, daß dieses Paket quittiert werden muß, sonst wird es nach 
einer Pause nochmal gesendet.


Peter

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nene, es ist ein GPS Empfänger mit NMEA Ausgang und ein LWL- Interface, 
wo zwar wichtige aber dafür sich ständig wiederholende Daten reinkommen.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Was auch immer es für einen Sinn haben soll, 8 GPS
> Empfänger in einer Schaltung zu haben.
Könnte es sein, dass dann die statistische Abweichung quadratisch 
kleiner wird? Nur so eine Idee, immerhin macht Elektor auch einen Stall 
voll OPs auf eine Platine um das Rauschen zu reduzieren... ;-)

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Das ist egal.
> Du schaltest einfach um und prüfst auf die Pause. Dadurch ist das
> folgende Paket gültig.
> Dann schaltest Du wieder um, ...

Wenn du davon ausgehst, dass es sich um Quellen handelt, deren 
Informationen periodisch gesendet werden, gebe ich dir recht.

Aber was ist, wenn z.B. eine Quelle eine Bytefolge asynchron sendet und 
mit dem Senden beginnt, während der Multiplexer noch eine andere Quelle 
aufgeschaltet hat, bevor er auf die erstgenannte schaltet? Dann ist 
dieses Datenpaket auf jeden Fall beschädigt. Und wenn es sich z.B. nicht 
um GPS-Pakete handelt, sondern z.B. um irgendeinen anderen Wert, der 
alle 2 Minuten mal gesendet wird, dann erfolgt bis dahin kein Update, 
das ist unabhängig vom zyklisch sendenden GPS oder sonstwas.

Kommt eben auf den Fall an. Bei ausschliesslich GPS-Daten hast du recht.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Nene, es ist ein GPS Empfänger mit NMEA Ausgang und ein LWL- Interface,
> wo zwar wichtige aber dafür sich ständig wiederholende Daten reinkommen.

Damit wäre Peter's Ansatz möglich. Solche Infos wären von Anfang an 
wichtig gewesen, Hellsehen ist noch buggy.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> Bei ausschliesslich GPS-Daten hast du recht.

Korrektur: "Bei GPS oder anderen zyklischen Daten..." müsste es heissen, 
sorry.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Wenn ein Paket nicht verloren gehen darf, dann muß ich das irgendwie
> absichern.
> Z.B. dadurch, daß dieses Paket quittiert werden muß, sonst wird es nach
> einer Pause nochmal gesendet.

Eben, meine obige Aussagen. Ist nur die Frage, ob Stephan das auch 
weiss.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> Aber was ist, wenn z.B. eine Quelle eine Bytefolge asynchron sendet und
> mit dem Senden beginnt, während der Multiplexer noch eine andere Quelle
> aufgeschaltet hat, bevor er auf die erstgenannte schaltet? Dann ist
> dieses Datenpaket auf jeden Fall beschädigt. ...

Hallo,

so kompliziert muss man garnicht argumentieren, bei 1 UART und 8 Quellen 
sind verlorene Pakete von vornherein unvermeidlich. Schliesslich kann 
von gleichzeitig ankommenden Datensätzen nur einer empfangen werden. Bei 
GPS ist das egal, dürfen dagegen aus einem Stream keine Daten 
verlorengehen ist das Konzept unbrauchbar.

Gruss Reinhard

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> bei 1 UART und 8 Quellen
> sind verlorene Pakete von vornherein unvermeidlich.

In Stephan's Fall richtig.

Allgemein nicht. Könnte man die Quellen senderseitig zentral aktivieren, 
den Multiplexer der jeweils aktiven Quelle zuteilen und per Software der 
Quelle erlauben, erst dann zu senden, wenn sie aktiviert wurde, geht da 
gar nichts verloren, so lange die Daten nicht autonom von der Quelle wie 
dem GPS-Empfänger im Sekundentakt gesendet werden.

Schon zig mal gemacht. Klappt prima und ist unkompliziert.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> und per Software der
> Quelle erlauben, erst dann zu senden, wenn sie aktiviert wurde
Das ist klar, denn dann ist die Übertragung ja sogar auf Protokollebene 
garantiert synchron.
Nur: so schön geordnet ist die Lage von Stephan leider nicht...

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
O wie wahr...

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar Miller schrieb:
> Nur: so schön geordnet ist die Lage von Stephan leider nicht...

Schon klar.

Aber ich habe mich bezogen auf die Aussage:

>so kompliziert muss man garnicht argumentieren, bei 1 UART und 8 Quellen
>sind verlorene Pakete von vornherein unvermeidlich.

Kann man pauschal eben nicht sagen.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> O wie wahr...

Aus wie vielen Bytes bestehen die Daten über das LWL-Interface? Gibt es 
einen Header, meinetwegen ein Startbyte, der den Frameanfang 
kennzeichnet?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gun B. schrieb:
> Stephan R. schrieb:
>> O wie wahr...
>
> Aus wie vielen Bytes bestehen die Daten über das LWL-Interface? Gibt es
> einen Header, meinetwegen ein Startbyte, der den Frameanfang
> kennzeichnet?

Das Problem ist immer dasselbe.
Steigt man asynchron in eine UART Übertragung ein, so kann man sich erst 
einmal auf gar nichts verlassen. Jedes Byte das empfangen wurde, kann 
fehlerhaft sein. Noch nicht mal auf den von der Hardware gemeldeten 
Framing-Error kann man sich verlassen. D.h. man kann sich schon auf ihn 
verlassen nur auf die Umkehrung nicht. Das Ausbleiben eines Framing 
Errors bedeutet nicht, dass man jetzt sauber in den Datenstrom 
eingeklinkt ist.
Das kann genausogut Zufall sein, dass gerade die richtigen Bits 
übertragen werden, damit kein Framing Error entsteht.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DAS kann ich mir zum Glück noch aussuchen. (Ursprung: eigenes Programm 
aufm Laptop)

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stephan:

Jetzt noch mal genau die Frage, die ich oben irgendwie nicht beantwortet 
sehe: Ist der schaltende Controller auch der Empfänger ODER kann er 
zumindest auf seiner RxD mithören?

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der umschaltende Controller ist auch der Empfänger der Daten.

Autor: g. b. (gunb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stephan R. schrieb:
> Der umschaltende Controller ist auch der Empfänger der Daten.

Also,

du kennst:

- den Header des GPS-Frames aus der NMEA
- der Frame endet mit <CR> <LF>
- du kennst den Sekundentakt des Moduls
- die Länge des GPS-Frames aus dem NMEA-Protokoll
- die Baudrate des Moduls
- damit kennst du auch die Zeitdauer des Frames

eine Menge bekannter Daten also

du schreibst:

- das du das Datenformat auf dem LWL-Interface selbst bestimmen kannst
- dann gibst du dem Frame mindestens einen Header, am besten auch eine 
Endsequenz
- du kennst die Baudrate, damit die maximale Zeitdauer eines Frames
- du kannst auch hier vielleicht eine Pause zwischen den Frames 
einfügen?!

auch eine Menge bekannter Größen also.


Eine Lösung wäre:

- Du startest mit dem GPS-Modul und wartest auf die nächste Pause.
- Dann auf den Beginn des Frames und schreibst ihn bis zum <CR> <LF> 
weg.
- Dann schaltest du auf das LWL-Intf. um.

Du landest nun mit aller Wahrscheinlichkeit irgendwo in einem bereits 
begonnenen Frame. Macht nix.

- Bei Implementation mit Pause wartest du auf diese, bevor du mitloggst.
- Mit Beginn des ersten Bytes nach der Pause schreibst du bis zum Ende 
des Frames mit.
- Ende: entweder durch Endsequenz oder durch Anzahl der Bytes erkennen, 
wenn konstant, oder Pause.

- Implementation ohne Pause setzt Header/Endsequenz voraus, auf den/die 
du synchronisieren musst.

Dann wieder umschalten auf GPS-Modul, Pause abwarten und Folgebytes 
wegschreiben. Könntest auch auf den GPS-Header synchonisieren, musst 
dann aber die ASCIIs analysieren.

So, in diesem Fall würden sich deine Schaltzeiten nach den Frames 
richten, d.h., nach den erkannten Headern und der Länge der Frames.

Sollte die Vorgabe aber eine periodische Umschaltung mit gleichen Zeiten 
von Kanal zu Kanal sein, dann richtet sich die Framelänge eben nach dem 
längeren Frame der beiden Quellen + Pause. Glaube, ist klar, was ich 
meine.

Könntest auch die doppelte Framelänge z.B. beim LWL-Interf. einlesen und 
außerhalb der Interruptroutine die Auswertung machen, in dem du nach dem 
Header/Trailer suchst und die entsprechende Anzahl Bytes auswertest.

Wie auch immer, aber mit den Infos sollte es einfach sein. Anfangs 
entstand der Eindruck eines Multiplexers mit mehr Einschränkungen.

Autor: Stephan R. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, ich verstehe.
So viele Päus-chen sind zwar nicht schön aber wat mut dat mut.
Werds morgen -wenn ich wieder einen laufenden ISP-Programmer hab- mal 
testen.

Vielen Dank für die rege Beteiligung!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.