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
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.
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?
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
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.
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 !
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.
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.
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.
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"
....
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.ä.
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!
@ 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.
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 :-)
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
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.
