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.
Angehängte Dateien:
-
Clipboard01.png
18 KB
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" ....
Angehängte Dateien:
-
Clipboard01.png
18 KB
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.
Falk Brunner schrieb: > Es gibt sowieso keine internen Baudratenquarze ;-) ganz genau! Intern gibts nur den RC-Oszillator!
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.