www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Datenblöcke + Fehlererkennung


Autor: Karl Meinert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tag,
ich beschäftige mich seit kurzer zeit mit µC und bin im Moment an ein
Problem gestossen, wo ich mir nicht mehr weiter Helfen kann ohne
weiteres. Und zwar habe ich irgendwann mal vor ein System zu erschaffen
das Daten drathlos von µC(1) zum µC(2) sendet.
Im Moment mache ich das alles theoretisch deshalb noch kein bestimmter
µC usw.
Zum Problem:
Der µC(1) bekommt 2 - 6 Analoge Werte (16 bitwort), habe schon
allgemein gelesen wie man die Daten verwaltet bzw. mit den benötigten
Registern bearbeitet. Jetzt weiss ich erstens nicht, bis wieviel Daten
man in solchen Registern verwalten bzw. speichern kann (pro kanal).
Zweitens möchte ich diese Daten in einem geeigneten gewählten Block
bzw. Blockgrösse zusammenfassen, damit ich ein CRC Check über diesen
Datenblock machen kann und dann diesen an µC(2) senden und auf
Richtigkeit überprüfen.
Habe schon über CRC gelesen, kann mir das aber nicht so recht
vorstellen wie ich das mit [1.] Datenblock hinbekomme dann [2.] den CRC
Check mache (meine Vorstellung dazu ist ein festen Generatorpolynom zu
nehmen der dem Sender und Empfänger bekannt ist). Wie das Code
technisch aussieht weiss ich auch noch nicht.
Das mit den Datenblöcken??? müsste die Daten von den unterschiedlichen
Kanälen zusammen Packen, aber ich darf die Daten nicht vertauschen usw.
, wie gehe ich da vor???
Falls mir jemand weiter Helfen kann bzw. Tips geben könnte, bitte ich
darum.

Denke ich habe die Probleme erkannt, nur bin ich jetzt überfordert um
es zu lösen, Literatur gibt es viel aber nicht spezifisch zu meinem
Problem, oder?
Vielleicht ist das jetzt zuviel des guten aufeinmal, man kann auch
püapü weiter Helfen.

Karl Meinert

Autor: Karl Meinert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
Hat keiner einen Tip, wennigstens das mit den Datenblöcken?

mfg
Karl

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sind etwas sehr viele sehr unterschiedliche Fragen, die insgesamt den
Eindruck erwecken "habe alles gelesen, nichts verstanden und einen
riesen Katalog von Fragen von denen ich nicht mal weiss was ich
eigentlich fragen soll". Klar, so ist das öfter. Schreckt aber ab.

Drösel das ganze doch erst mal in Teilgebiete auf und schmeiss nicht
alle auf einmal hier rein. Sonst wird jeder gleich von der Aussicht
erschlagen, die nächsten Wochen mit diesem Thema befasst zu sein und
duckt sich weg.

Und was CRCs angeht: Es gibt reichlich Beispiele dafür im Internet, und
alles was man am Anfang braucht ist ein PC oder Mac und ein C Compiler.
In den Fall vielleicht auch zwei. Und dann mal ein bischen
ausprobieren.

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Karl,

wie soll ich es sagen oder dir zu nahe zu treten? Deine 'Braindump'
liest sich ein wenig konfus.

>Der µC(1) bekommt 2 - 6 Analoge Werte (16 bitwort)
>Das mit den Datenblöcken??? müsste die Daten von den
>unterschiedlichen Kanälen zusammen Packen, aber ich darf die Daten
>nicht vertauschen usw., wie gehe ich da vor???

Unterschiedliche Kanäle? was für unterschiedliche Kanäle?
Beschreib uns doch bitte erst einmal genau, was µC(1) genau machen
soll.

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Karl Meinert
Na ja, deine Fragen sind ja im Grunde schon ziemlich gut sortiert, da
sind ja auch schon fast die Antworten mit drin...

a)
Das mit den Datenblöcken??? müsste die Daten von den unterschiedlichen
Kanälen zusammen Packen, aber ich darf die Daten nicht vertauschen usw.
, wie gehe ich da vor???

Du definierst dir ein eigenes Paket-Protokoll. Beispiel:

Steuerbefehl-Tabelle:
01: Anfrage zur Übermittlung eines kompletten Datenpaketes
02: Datenpaket-übermittlung von UC1 nach UC2, initiiert von UC1
03: irgendwas sonstiges sinnvolles

genereller Paketaufbau:
Steuerbefehl 1 byte   ;selbst definierte Tabelle
Paketlänge   2 byte   ;damit max. 2^16 bytes pro Paket übermittelbar
paketspezifisches  nn bytes
Prüfsumme   2 bytes

--
und für z.B. Steuerbefehl 02 wäre dann der paketspezifische Inhalt z.B.


Kanal_Nr    1 byte
Datenwert    2 byte

beliebig oft



z.B. würde dann ein Sitzungsablauf so aussehen:

UC2 schickt UC1 folgende Sequenz:

01 00 4711     (01=schicke mir Datenpaket, 00=keine weitere Info im
Block, 4711=Prüfsumme)

und UC2 antwortet:
02 09   01 1234    02 3456    05 678A   0815
(hier ist ein Datenpaket mit 9 bytes Nutzinhalt. Prüfsumme ist 0815)

etc.


für das Generatorpolynom: schau mal z.B. unter beliebiger Unix-Kiste
unter dem Befehl "man cksum", das Generatorpolynom ist da detailliert
beschrieben und allgemeingültig

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, ich hab grad noch mal drüber gelesen, und folgenden Fehler
festgestellt:

In meiner Beschreibung habe ich angegeben: Paketlämnge (2 bytes). Im
angeführten Beispiel-Mitschnitt ist aber nur 1 byte verwendet worden.
Ich denke du bekomst den Spagat hin, da passend zu machen (man kann
leider einmal eingestellte Beiträge hier im Board nicht editieren)

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um da mal die Sache etwas weiter zu spinnen:

Du kannst dir jetzt überlegen, was sinnvoller oder aufwendiger ist:
Werden "in einem Rutsch" imemr alle 6 Analogwerte übermittelt (auch
wenn diese sich nicht geändert haben), dann wäre das DAtenpaket imemr
ziemlich einfach zu bauen:

01 4711
02 4567
03 0000
04 FFFF
05 2323
06 AFFE

Da braucht auch kein komplexes Protokoll geschrieben zu werden, dann
könnte z.B. UC1 jede Minute oder so einfach von sich aus losquaken und
alle 6 Werte übermitteln. Wenn die prüfsumme nicht stimmt, dann nimmt
halt UC2 das Zeugs nicht an und wartet eine Minute auf das nächste
Paket.

Wenn du allerdings ein Protokoll implementierst wie zuvor skizziert
dann könntest du möglicherweise mehr Daten häufiger übermitteln etc.

Wenn du mehrere UC1 hast, dann könnte jeder einzelne noch seine eigene
UC-Kennung mitliefern etc. ISt also beliebig ausbaubar bzw.
einschränkbar.

Autor: Karl Meinert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
@Martin S.
Danke, genau das meinte ich.
Und natürlich sind wieder andere fragen entstanden bzw. auch
Verständnis fragen.

a)
Also, ich würde es gerne so machen, das man immer alle analogen werte
(Kanäle) schickt und die möglichkeit zum wiederholten senden besteht,
falls was daneben geht.
Also, bräuchte ich eine Steuerbefehl Tabelle, wie bei Dir und benutze
sie dann so:

und UC1 antwortet:
02 09   01 1234    02 3456    05 678A   0815
(hier ist ein Datenpaket mit 9 bytes Nutzinhalt. Prüfsumme ist 0815)

Verstehe den Code nicht ganz, 02 09 ist klar. 01 1234 schicke ..??...
02 3456 ein Datenpacket mit 3456 byte. 05 678A ???. 0815 Prüfsumme???

Hier müsste ich dan quasi, so wie ober vorgehen und zwar z.B.
02 18 ...................  0815
18 Nutzbyte = 6 * Kanal_info (je 1 byte) + 6 * Kanal_wert (je 2 byte)
weiss zwar noch nicht wie ich die einzelnen Register ansprechen könnte
und mir meine 2 byte da raus saugen soll (vielleicht so wie du oben,
was ich nicht ganz verstanden habe??)

b.)
Von einer Steuerbefehl Tabelle habe ich noch nichts gelesen, kann mir
nur vorstellen, dass da Befehle stehen die ich nutzen kann wie z.B.
deine Tabelle. Ist die Tabelle schon vor definiert oder definert man
selbst? wenn selbst , dann wie?

c.)
was bedeutet:
01 4711
02 4567
03 0000
04 FFFF
05 2323
06 AFFE
???????


mfg
Karl

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rückwärts:

c) die "kleinste" Geschichte die du nutzen kannst ist: Sende in
Festem Abstand alle (6) Werte aller Fühler vom MC1 zu MC2. Initiiert
wird das ganze einfahc nur durch eine Zeitsteuerung von MC1, ohne
irgendwelches umfangreiches hin-und-her. du hast 6 Meßwerte die zu
übertragen sind, und die sind jeweils 2 bytes groß. Zur Sicherheit
überträgst du noch z.B. eine 2-byte Prüfsumme hintendran. Insgesamt
also werden da jede Minute 6*2 + 2 bytes = 14 bytes übertragen. Die
Position und Bedeutung der einzelnen Bytes ist ja dem Sender und dem
Empfänger bekannt, nämlich:

byte 1+2 = Meßwert vom Fühler 01
byte 3+4 = ...
..
byte 11+12 = Fühler 6
byte 13+14 = Prüfsumme

Die prüfsumme wird quer über den datenteil von byte 1-byte 12 gezogen.

MC2 empfängt also jede Minute 14 byte, sortiert dei geeignet ein, udn
wenn de Prüfsumme nicht passt wartet er halt 1 Minute

das was ich da aufgezeichnet und du unter C) hinterfragt hattest war
der (angenommene) Wert vom Fühler 01 .. 06


b) Wenn du es "ganz groß" haben willst, dannn muß da "mehr"
Kommunikation sein. Im besten Falle Fordert MC2 vom MC1 bestimmte Daten
an, d.h. die beiden quasseln in irgendeiner erweiterten Form
miteinander.

Dazu gibt es keine (mir bekannten) Definitionen, also definier dir
einfach selbst ein "Quasselprotokoll" und "Quasselbefehle".

----

Ich weiß nicht was du mit einzelnen Registern meinst. Das ganze ist
natürlich Prozessor-abhängig, aber ich könnte mir z.B. folgendes
Szenario vorstellen:

a) du hast einen (1) A/D Wandler an/im Prozesor, udn kannst über einen
analogen, softwaretechnisch anzusteuernden Umschalter  zwischen 6
verschiednenen Signalquellen umschalten.

Ab jetzt hängt es ein bischen davon ab wie schnell sich deine Meßwerte
ändern und wie häufig du übertragen möchtest. Nehmen wir mal an, daß
sich deine Meßwerte nicht allzu häufig ändern, und du nur 1 * jde
Minute denAnalogwert abfragen magst.

Du führts nun folgendes aus:

für alle Messstellen von 1..6
  schalte um auf Meßstelle x
  hole den analogen Wert von Meßstelle x ab
  speicher den Meßwert an Speicherstelle x (oder in Register x)

wenn alle 6 Meßwerte abgefragt sind
  generiere eine Prüfsumme über die Meßwerte
  Versene die 14 bytes in geeeigneter Form.


Wenns komplizierter werden soll, dan kanst du natürlich auch häufiger
de Analogwerte abholen, die arithmetisch mitteln udn den somit
gemittelten Wert übertragen.



a) ist somit auch erklärbar bzw. du wirst sehen, daß deine Gedanken
diesbezüglich komplett verkehrt waren



Du siehst, die Spanne der Funktionen kann von "ganz einfach" bis
"ziemlich komplex" reichen. Wer dir erst mal bewußt (oder verrate es
uns) welceh Werte du zu übertragen gedenkst, udn wie schnell die sich
wandeln etc.

Autor: Karl Meinert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Danke für die herforagende Erklärung.

Also, ich möchte an einem Projekt mitmachen, bin aber noch nicht ganz
in der Materie, wie man sieht, deshalb versuche ich mich so schnell wie
möglich zu informieren um abzuwägen ob das Sinn macht, komme nähmlich
nicht aus dieser Richtung aber finde es sehr interessant.

Beim Projekt sollen zunächt erstmal Temperatursensoren ausgelesen
werden. Da würde man mit einer geringen Abtastrate noch auskommen aber
es sollen noch 2 Wegsensoren ausgelesen werden, deren abtastfrequenz
bei ca. 16 - 32 kHz liegt.
Wie kann man das realisieren? genauso wie oben?
Kann mir das im Moment garnicht vorstellen, da in ein Register 1 low
und high byte passen, aber ich werde quasi überschwemmt mit Werten,
gibt es dazu auch was passendes, leichtverständliches damit man die
Werte Verwalten kann? wo , wie, wohin ?

mfg
Karl Meinert

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na du hast doch geschrieben daß du Daten (wegen mir drahtlos) von MC1
nach MC2 transportieren möchtest. Das heißt für mich erst mal:

MC1 sammelt Daten auf und bereitet diese zum Transport vor
MC1 transportiert dann die Daten regelmäßig, unregelmäßig, freiwillig,
auf Anforderung oder wie auch imemr zu MC2

MC2 nimmt deise Daten und macht damit schöne Dinge, z.B.
- Abspeichern in irgendein Speichermedium
- Darstellen auf irgendeinem Display
- sonstewas anderes

Somit ist doch die Aufgabe vom MC1 relativ "gering" und
überschaubar.

Dein Einwand mit der Überschwemmung von Werten ist nicht unberechtigt.
Es kommt halt drauf an welche Werte du zur weiteren Nutzung (am MC2)
benötigst, bzw. wei weit die verdichtet werden können / dürfen.


kleiner Exkurs:
Ich habe mal mit jemanden gesprochen, der sich mit der
Verkehrsmengen-Messung auf den Autobahnen auskennt (wenns dich
interessiert: www.ddg.de). Da hängen an jeder Brücke so komische Fässer
und messen "irgendwas". Und genau das ist es: Die messen jedes
vorbeizischende Auto bezüglich Geschwindigkeit und die Automengen etc.
Allerdings ist es dem zentralen Staurechner ziemlich schnurz, ob die
nun das Auto, welches am 02.04.2005 15:55:03 an Erfassungspunkt 1397
vorbei kam 97 oder 99 km/h schnell war. Das wäre mörderisch viel Info,
die dem Leitrechner gar nicht interessiert. Er müßte ja dann noch aus
der Menge an Info "irgendwie" ermitteln, daß sich da ein Stau
zusammen braut.

"Mit passender Software" (in der jede Menge mathematischer Grips
steckt) kann man jedoch die Informations-Flut direkt in den
Erfassungsstationen gewaltig reduzieren. Nicht im Sinne von
Mega-Komprimierung, sondern in Sinne von intelligenten Algorithmen,
welche nur die Infos übermitteln, welche relevant sind.

/ ende Exkurs


Dein Projekt scheint mir aber weniger kompliziert zu sein, da reichen
möglicherweise schon einfachere Ansätze der Art:

Ermittle von deinen 6 Meßfühlern jeweils alle 6 Sekunden die Werte, und
bilde den Mittelwert pro Fühler. Übermittle dann den Mittelwert jede
Minute [somit bekommt man etwas verlässlichere Waret, als wenn man nur
"zufälligerweise" einen astronomisch abweichenden Wert hat, und sein
gesamten Meßvorgang damit scheinbar unsinnige Werte liefert.

Autor: Karl Meinert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
genau das was du beschrieben hast habe ich vor.

Bei den Wegsensoren werde ich wohl öffter abtasten müssen, d.h. ich
müsste ausrechnen wieviel maximal mein System an Abtastrate und somit
Datenmenge Verkraften würde.

Zunächst aber noch eine frage zu deinem Posting, wie würde ich den
Mittelwert z.B. von den 6 sekunden ermitteln, ich weiss wohl wie man
ein Mittelwert bildet aber ich glaube ich habe da ein MC Verständigungs
Problem. Wenn ich soviele Werte bekomme muss ich sie doch irgendwo
speichern damit ich einen Mittelwert bilden kann, da in einem Register
1 Byte passen werden die Werte doch irgendwie und irgendwo abgelegt
werden müssen. Wie kann ich mir das vorstellen bzw. lösen???

Nehmen wir doch das Beispiel 1 Wegsensor, der mit einer abtastfrequenz
von 32 kHz arbeitet, d.h. 32 000 * 2 Byte (16 Bitwert)= 64 kByte pro
Sekunde an Werten, ist das realistisch?
Was schaffen gute Systeme ca.? ich weiss es überhaupt nicht stelle mir
aber 64 kByte viel vor, oder?

mfg
Karl Meinert

Autor: Martin S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich weiß nicht was du immer mit deinen Registern hast.... Ein Computer
(egal ob "großer" Pentium oer was weiß ich oder Microcontroller)
basieren alle auf einer ähnlichen Struktur: Sie haben eine gewisse
(kleine) Anzahl an Registern, welche für kurzfristige Operationen
genutzt werden, darüber hinaus aber auch Zugriff auf nur-lesbaren oder
les-und beschreibbaren Speicher. Ob der Speicher nun "im Chip selbst"
drin ist oder extern als Komponente mit drangelötet wird ist für die
globale Betrachtung unerheblich.


Zu deiner Frage:
Du liest die Werte einfach ein, und lagerst sie in einer zu definierten
Speicheradresse ab, z.B:

Fühler_1: (analoges gilt auch für die anderen Fühler)

Ennahme: Ein bereits vorher eingelesener Wert von Fühler_1 steht an
Speicheradresse 0100+0101 (2 bytes)

Eine einfach Möglichkeit zur Mittlung des nächsten Wertes wäre:

lese den neuen Wert des AD/Wandler Fühler_1 ein in Register xy_1
halbiere den Wert (das geht bei binärzahlen sehr einfach)
lade den "alten" Wert in ein Register xy_2, halbere ihn auch
addiere den Inhalt von Register xy_1 zu den Wert von Register xy_2
speichere den Wert von Register xy_2 wieder an die Speicheradresse
0100+0101 zurück

das fasst du in einer Schleife, welche alle 6 Werte abfragt, etc...



Dein Abtastwert scheint mir nicht sehr schlimm zu sein. gängige
Mikrocontroller laufen mit Taktraten von 1 Mhz bis 30 MHz, und
benötigen (je nach Architektur) 1-5 Takte Pro Befehl. (Zur Info: Dein
Prozessor am PC läuft intern an bestimmten Stellen mit 3000 MHz, also
etwas schneller g)

Dann rechne dir hal anhand eines real exisiterenden Prozessors und
eines real existierenden Assembler-Programms (für deine
Aufgabenstellung reicht auch eine Hochsprache wie C oder Basic) wieviel
Operationen du welcher Art machen kannst.

Autor: Marcel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
64 kByte/s:
Ist das die Abtastrate des Sensors oder die Übertragungs-rate, die du
erreichen willst?
Abtastrate und Übertragungsrate haben nichts mit einander zu tun. Wenn
ein Sensor alle 1ns einen neuen Wert abtastet und du aber nur alle par
secunden den wert brauchst/holst macht das auch nichts.

Dann etwas zum Protokoll: (1 Byte befehl) + (1 byte länge d. daten) +
(2 byte prüfsumme).
1 byte für die länge müsste reichen

befehle sender:
00  sende analog Daten
01  sende weg-sensor 1
02  sende weg-sensor 2
...

evtl. noch zus.
55  AcK (alles ok)
AA  NAK (fehler aufgetreten)
FF  STALL (kann nicht mehr...)

befehle emfpänger (antworten):
00  analogdaten folgen
01  wegsensor 1 daten folgen
02  wegsensor 2 daten folgen
...

evtl. noch zus.
55  AcK (alles ok)
AA  NAK (fehler aufgetreten)
FF  STALL (kann nicht mehr...)

Bei 00 feuert uC1 alle 6 analog Daten, egal ob die sich geändert haben
oder nicht. Oder der uC1 sendet alle Messdaten direkt hintereinander
(analog + Wege) dann brauchst du die Befehle 01 und 02 nicht.

uC2:
00 00 xxxx
^  ^  ^
|  |  |
|  |  prüfsumme (oder crc)
|  kein payload (zus. daten)
sende analog daten

uC1:
00 0C 0101 0202 0303 0404 0505 0606 xxxx
^  ^  ^                             ^
|  |  |                             |
|  |  |                             prüfsumme oder crc
|  |  die daten der sensoren
|  6 sensor daten a 2 byte
analog daten folgen

wenn die anzahl immer fest ist, dann kannst du auch die länge der daten
weg lassen.

Wenn uC1 aber immer broadcasten soll, was er gerade hat, dann kannst du
auf die sende-befehle ganz verzichten und nur STALL benutzen (wenn der
puffer voll ist). SO dass uC1 eine (kurze) zeit aufhört daten zu
senden.

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.