mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenübertragung


Autor: Hans im Glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ich bräuchte ein paar Tips bzw Wegweiser um mich dan ein wenig durch die 
Thematik zu lesen.
Im Prinzip möchte ich Daten (0-255) von 3 Sensoren an einem Atmega32 per 
RS232 an den Pc schicken.

Nun wollte ich fragen wie man die Übertragung (Software) am besten 
Aufbaut.
Ich muss ja am Empfänger bzw Pc erkennen welche Daten zu welchen Sensor 
gehören.Das ganze sollte natürlich so schnell wie möglich sein damit die 
Werte möglichst oft refresht bzw geupdatet werden können.

Vieleicht hat ja einer von euch Zeit und Lust mir ein paar Tips,Links 
usw zu posten bin für jede Hilfe dankbar

mfg

Hans

Autor: Huch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Der AD-Wandler kann so und so viele Wandlungen pro Sekunde 
durchführen. Schneller brauchtst Du dann auch nicht zu übertragen.

2. Da alle Werte vorkommen können, empfiehlt es sich die Werte nicht als 
Byte zu übertragen sondern etwa jeweils in zwei ASCII-Hex-Ziffern und 
dazu ein sonst nicht mögliches Byte als Anfangskennzeichen. Evtl. noch 
ein weiteres als Endekennzeichen. Aus der Reihenfolge ergibt sich dann 
auch die Zuordnung des Wertes zum Sensor.

Autor: Ben ___ (burning_silicon)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das zauberwort heißt wohl protokoll...

du kannst ja beispielsweise einen text in der form "1:0000 2:0511 
3:1023" an den PC senden. damit weißt du welcher wert zu welchem sensor 
gehört, hast aber einen ziemlichen overhead an daten.

die einfachste und kürzeste form wären sechs bytes als einen datenblock, 
ggf. ein 7tes byte als prüfsumme. also "00 00 00 ff 01 ff" z.b. nur 
nicht hexadezimal, sondern einfache bytes. wenn dir 8bit auflösung 
reicht (der ADC kann meist 10bit) reichen auch drei bytes für einen 
block "00 7f ff".

wieviele messungen pro sekunde willst du denn anstellen? also wieviele 
brauchst du wirklich, wieviele sind sinnvoll?

Autor: Hans im Glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Vielen Dank für die Antworten !

8Bit reichen für meine Zwecke aus !

Also wenn ich das richtig verstanden habe sende ich die Daten(Messwert) 
dan eine Art Stopmarker dan die Sensor-Nr und dan wieder eine Art 
Stopmaker ?

Daten:Maker:Sensornummer:Maker

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

Bewertung
0 lesenswert
nicht lesenswert
Hans im Glück schrieb:
> Also wenn ich das richtig verstanden habe sende ich die Daten(Messwert)
> dan eine Art Stopmarker dan die Sensor-Nr und dan wieder eine Art
> Stopmaker ?
>
> Daten:Maker:Sensornummer:Maker

Du kannst es machen wie du willst. Du musst nur definieren wie und beide 
Seiten müssen sich dann an das Protokoll halten.
Man könnte zB: auch senden "S1=9b,S2=35,S3=cb,X
Dann hättest Du die Information welcher Sensor welchen Wert hat gleich 
lesbar als Klartext und man kann mit einem einfachen Terminalprogramm 
auf PC Seite prüfen ob es funktioniert. Das X wäre zum Beispiel ein Ende 
Flag. Oder ein "\n" (Zeilenumbruch) als Endezeichen einer Meldung, oder 
auch einfach nix.
Das ist alles Dir überlassen.
der Vorteil von Hexadezimalen Zeichen zur Übertragung ist die 
Lesbarkeit, bei binären Werten wird dann evt. ein nicht sichtbares 
Zeichen oder eins seltsame Steuerinformation für das Terminalprogramm 
daraus.
Wenn Du PC seitig aber ein eigenes Programm nutzt ist das egal, sie 
müssen nur beide die gleiche Sprache sprich Protokoll sprechen.

Autor: Hans im Glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Zitat:
die einfachste und kürzeste form wären sechs bytes als einen datenblock,
ggf. ein 7tes byte als prüfsumme. also "00 00 00 ff 01 ff" z.b. nur
nicht hexadezimal, sondern einfache bytes. wenn dir 8bit auflösung
reicht (der ADC kann meist 10bit) reichen auch drei bytes für einen
block "00 7f ff".
Zitat:

Einfach und kurz hört sich gut an , jetzt muss ich es nurnoch verstehen.

00 00 00 ff 01 ff

00 00 00 = Sensordaten ?

ff = Marker Datenende ?

01 = SensorNummer ?

ff = Marker Sensornummerende ?

Habe ich das soweit richtig verstanden ??




Man könnte zB: auch senden "S1=9b,S2=35,S3=cb,X

Das sieht natürlich sehr einfach aus , ist den die oben genannte Methode 
schneller bzw wo liegen die Vor und Nachteile.
Vielen Dank nochmal das ihr euch die Zeit nehmt mir zu helfen !

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

Bewertung
0 lesenswert
nicht lesenswert
Hans im Glück schrieb:

> Einfach und kurz hört sich gut an , jetzt muss ich es nurnoch verstehen.

Wobei 'einfach' hier relativ ist.
Es ist einfach in der Implementierung. Aber die Probleme, die du dir 
einhandeln kannst, wenn die Programme die Synchronisierung verlieren und 
der Empfänger in

   ... 78 06 45 05 45 93 AF 67 BC 93 F3 ...

nicht mehr weiß, welches Byte jetzt was ist, die sind gewaltig!

> 00 00 00 ff 01 ff
>
> 00 00 00 = Sensordaten ?
>
> ff = Marker Datenende ?
>
> 01 = SensorNummer ?
>
> ff = Marker Sensornummerende ?
>
> Habe ich das soweit richtig verstanden ??

Nein, hast du nicht.
3 Sensoren, jeder Sensor liefert 2 Bytes, macht in Summe 6 Bytes.
Und da in den Daten-Bytes jeder Wert vorkommen kann, gibt es keinen 
Wert, den du als eindeutigen 'Marker' benutzen kannst, an dem der 
Empfänger mit 100% Sicherheit erkennen kann, wann die nächste 
Bytesequenz von vorne anfängt.

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

Bewertung
0 lesenswert
nicht lesenswert
Hans im Glück schrieb:
> as sieht natürlich sehr einfach aus , ist den die oben genannte Methode
> schneller bzw wo liegen die Vor und Nachteile.

Ganz einfach: Die Bytes senden wie sie sind spart auf µC Seite jegliche 
Konvertierungen und Programmieraufwand. Ausserdem je weniger Bytes Du 
überträgst desto mehr Information kannst du bei gegebener 
Übertragungsgeschwindigkeit übertragen. Wenn Du das brauchst!

Nachteile: Zu einfache Protokolle lassen sich evt. nicht mehr ohne 
grundlegende Änderungen erweitern, das 'debuggen' mittels 
Terminalprogramm wird schwierig bis unmöglich und Du brauchst ffg. mehr 
Programmieraufwand am PC für die Auswertung und Anzeige.

Denk halt darüber nach welche Datenmengen du brauchst, ob du das 
Protokoll evt. erweitern willst (evt. auch mit Kommandos vom PC zum µC) 
und ob du beim nächsten Projekt dann ein anderes Protokoll definieren 
musst weil dein einfaches nicht passt und nicht erweiterbar ist.

Das eierlegende Wollmilchsau-Protokoll gibts nicht.

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

Bewertung
0 lesenswert
nicht lesenswert
Ich sach gerne so:
Mit einem guten Protokoll kann man mitten im Betrieb das Kabel abzieht 
und wieder anstecken und alles läuft weiter wie gewohnt.
Eventuell kommt eine Fehlermeldung, dass die Verbindung abgerissen ist. 
Aber dass Messwerte plötzlich den falschen Sensoren zugeordnet werden 
... so etwas darf nicht passieren. Unter keinen Umständen.

Autor: Timo P. (latissimo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Leute, warum so kompliziert? Die daten sollen auf den PC. Was ist üblich 
auf einem PC? CSV-Format!

Dieses kann man dann bequem per Excel öffnen und einfachst einen Graphen 
erstellen!


warum nicht so:

"12;40;100;\n" dann die nächsten Werte:
"13;41;101;\n"
....

Autor: Timo P. (latissimo)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
und, wenn man mit einem Terminalprogramm die Daten entgegennimmt, (der 
Einfachheit halber) Dann kann man direkt in eine Datei schreiben.

unter win per hypertrm
unter lnx per minicom o.ä.

Autor: Timo P. (latissimo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
für die fehlerhaft übertragenen Zeichen: also dazu sage ich nur eins: 
Die Verbindugnsleitung zw. PC und µC so kurz halten, wie möglich. Als 
Takt für den µC einen externen Baudratenquarz nutzen! so entstehen bei 
der Berechnung der Baudrate keine Fehler, es verbleiben nur die 
Fertigungstoleranzen des Bauteils in ppm!

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Timo P. (latissimo)

>für die fehlerhaft übertragenen Zeichen: also dazu sage ich nur eins:
>Die Verbindugnsleitung zw. PC und µC so kurz halten, wie möglich.

Sinnlose Panik. Wenn man nicht gerade einen verrosteten Klingeldraht 
nimmt, ist RS232 da recht genügsam.

> Als Takt für den µC einen externen Baudratenquarz nutzen!

Es gibt sowieso keine internen Baudratenquarze ;-)

Ein paar Daten per RS232 zu übertragen ist ja nun weiß Gott kein Akt. 
Nettes Einsteigerprojekt.

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

Bewertung
0 lesenswert
nicht lesenswert
Timo P. schrieb:
> Leute, warum so kompliziert?

Weil wir 'Hans im Glück' auf mögliche Fallstricke sensibilisieren 
wollen, die bei zu naiver Herangehensweise unweigerlich auf ihn warten.

Das ist so, wie in eine Datendatei am Anfang eine Versionsnummer 
reingehört. Da muss man auch erst 5 mal drauf reinfallen und in 
Schwierigkeiten laufen, ehe man das glaubt.

> Die daten sollen auf den PC. Was ist üblich
> auf einem PC? CSV-Format!

Ja, warum nicht? Ist eine Möglichkeit.
Obwohl heutzutage auf einem PC eher XML 'üblich' ist.
Aber das kann jeder halten wie er will :-)

Autor: Hans im Glück (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Also ich bin für jeden Tip dankbar , selbstverständlich auch jene die 
sich die Fehlerrobstheit des Protokolls beschränken.
Das ganze ist für einen Laien nicht ganz so einfach zu verstehen wie man 
am Anfang vieleicht denkt.

Wenn man schon anfängt sich mit dem Thema Protokoll zu beschäftigen kann 
man es auch gleich richtig machen bzw ein wenig in die Zukunft denken.

Wenn man nun zum Bsp auch Befhele vom PC senden möchte ( könnte ja sein 
das dies einmal von nöten wäre) wie sollte man mit diesem Hintergrund 
das Protokoll aufbauen und warum.

Ich ahbe viel Zeit (Urlaub) und der Weg ist das Ziel also ihr könnt 
alles an Ideen und Vorschlägen posten egal wie abstrakt oder unüblich 
bin für alles dankbar

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

Bewertung
0 lesenswert
nicht lesenswert
Hans im Glück schrieb:

> Das ganze ist für einen Laien nicht ganz so einfach zu verstehen wie man
> am Anfang vieleicht denkt.

Im Grunde ist es eigentlich ziemlich einfach.
Schwierig wird es erst dann, wenn man auch noch schnell sein will. Denn 
das beißt sich oft.

> Wenn man nun zum Bsp auch Befhele vom PC senden möchte ( könnte ja sein
> das dies einmal von nöten wäre) wie sollte man mit diesem Hintergrund
> das Protokoll aufbauen und warum.

Genau das gleiche:
Oberster Grundsatz ist (zumindest bei mir) immer:
Der Empfänger muss eindeutig den Anfang der Übertragung und das Ende der 
Übertragung feststellen können.
Findet er diese Merkmale nicht, dann hat er keinen gültigen Datensatz. 
Findet er diese Merkmale aber, dann:
  Er muss von der Übertragung von jedem Byte sagen können,
  wo es hingehört. Das gibt es jetzt viele Spielarten aber im Grunde
  drehen sich alle darum, dass es eine eindeutige Vorschrift dafür
  gibt. Seien es jetzt Reihenfolgen; seien es Sonderzeichen, die
  einzelne Abschnitte voneinander trennen.
  Spielt alles keine wirkliche Rolle, solange der Hauptzweck erreicht
  werden kann: Der Empfänger kann immer 100% eindeutig feststellen
  was er empfangen hat.
  Die berühmten Pferde aus Blumento, die 'Blumento-Pferde', die in
  Wirklichkeit ein Behälter für Pflanzensubstrat "Blumentopf-Erde"
  sind, die darf es nicht geben.

Autor: Timo P. (latissimo)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:

> Es gibt sowieso keine internen Baudratenquarze ;-)

ganz genau! Intern gibts nur den RC-Oszillator!

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.