Datenpakete mit ATmega88 verarbeiten

[Patrick R. (pat711)]

Guten Tag zusammen,

ich bin derzeit damit beschäftigt Datenpakete eines externen Geräts an 
meinem ATmega88 auszulesen.
Diese Datenpakete haben keine einheitliche Länge, Da die Daten 
unterschiedlich lang sind. Daher befinden sich in diesem Datenpaket zwei 
Bytes die die Länge der Daten angeben.
Nun wollte ich fragen ob es irgendwelche Tricks oder so gibt um die 
Pakete möglichst einfach zu bearbeiten und temporär in Variablen zu 
speichern. Eine Möglichkeit wäre nun bis zu den beiden Bytes in ein 
neues Array auszulesen und abzuspeichern. Nach empfangen dieser beiden 
Byte die Länge des Paketes bestimmen und einen Endwert festzulegen. Bei 
erreichen des Endwertes dann in das Nächste Array (beispielsweise eines 
Mehrdimensionalen Arrays wechseln) und in diesem wieder von vorne zu 
beginnen.
Die Datenpakete werden am USART empfangen.

Aufbau der Datenpakete:
Start Delimiter 1 Byte | Packet Type identification 1 Byte | Op code 1 
Byte | Data length 2 Byte | Checksum 1 Byte | Packet Data X Byte | End 
delimiter 1Byte

Beispiel:

Array[0][0] Zeichen vom USART einlesen und speichern
Array[0][1] Zeichen vom USART einlesen und speichern
...
Array[0][5] Zeichen vom USART einlesen und speichern
            Endwert festlegen aus Byte 4 und 5
...
Array[0][Endwert] Zeichen vom USART einlesen und speichern
                  zum nächsten Array wechseln

Array[1][0] Zeichen vom USART einlesen und speichern
Array[1][1] Zeichen vom USART einlesen und speichern
...
Array[1][5] Zeichen vom USART einlesen und speichern
            Endwert festlegen aus Byte 4 und 5
...
Array[1][Endwert] Zeichen vom USART einlesen und speichern
                  zum nächsten Array wechseln

...


MfG Pat711

[Antwort (Gast)]

Am einfachsten wird es sein die Daten beim Empfang in einen Ringpuffer 
zu speichern. Dabei kümmerst du dich nicht darum was du da eigentlich 
empfangen hast, sondern schreibst es stumpf in den Ringpuffer rein.
Das schreiben in den Ringpuffer läuft im Empfangsinterrupt der UART 
Schnittstele (Interrupt wenn ein Byte empfangen wurde).

Den Ringbuffer machst du dann bsw. 256Byte lang (oder eben so lang das 
du zumindest mal 4-5 deiner Packete abspeichern kanst). So brauchst du 
den Bytepointer einfach nur immer zu inkrementieren und fängst durch den 
überlauf wieder bei 0 an.

Nun hast du das Datenpacket im Ringpuffer stehen (oder auch schon 
mehrere) und über eine extra Funktion suchst du nun von deiner letzten 
Lese-position (zu Beginn wird das 0 sein) den ersten auftauchenden 
"Start Delimiter". Nun schreibst du jedes fogende Byte in einen 
zwischenpuffer bis du zum "End delimiter" gelangst (dabei kontinuierlich 
prüfen ob der Lese pointer nicht über den Schreibe-pointer hinausläuft).

Nun hast du in deinem Zwischenpuffer das Packet ohne Start/End delimiter 
stehen. Du kannst nun je nach Packet identification und Op-code ein 
struct erzeugen in dem du dann die Daten aus dem Zwischenpuffer 
abspeicherst. (neu erzeugen der Checksum und vergleich mit der alten 
natürlich nicht vergessen).

Um das ganze etwas leichter erweiterbar zu machen arbeite ich dabei 
gerne mit Unions. Dazu definiere ich mir für jedes mögliche ankommende 
datenpacket ein eigenes struct. All diese Structs fasse ich in einem 
Union zusammen (bei definition der structs muss ggf. #pragma pack(1) 
verwendet werden). Das erste byte in jedem struct enthält dabei einen 
identificationscode um festzustellen was da eigentlich drinnen steht. 
Bei dir wäre das dann wohl "Packet type identification" oder "Op Code". 
Nun übergibst du an jede Funktion nur noch Pointer auf die Unions, liest 
das erste Byte zur Identifikation aus und kannst anhand dessen 
feststellen was zu amchen ist. So lässt sich der Code sehr leicht für 
weitere mögliche Datenpackete erweitern.

[Patrick R. (pat711)]

Danke, deine Antwort ist schonmal sehr hilfreich ich werde mir nun mal 
was du mit den union's und struct's meinst, welche mir unbekannt sind 
;-). (wohl ne Art Maske, schätz ich mal)

Aber das mit dem Ringpuffer ist eine tolle Idee ^^ allerdings könnte ich 
dann Probleme mit meinem Speicher bekommen. Vielleicht muss ich dann den 
EEPROM zu hilfe nehmen.

MfG Pat711

[Sascha W. (sascha_w)]

Patrick R. schrieb:
> Aber das mit dem Ringpuffer ist eine tolle Idee ^^ allerdings könnte ich
> dann Probleme mit meinem Speicher bekommen.
weil? nicht genug Platz?

> Vielleicht muss ich dann den
> EEPROM zu hilfe nehmen.
keine gute Idee, der lässt sich für den Anwendungsfall nicht oft genug 
überschreiben

mal noch was zur Kärung:
* wie groß können die Packete maximal sein
* wie groß ist die minnimale Pause zwischen zwei Packeten
* ist der 'End delimiter' einmalig, oder kann der Wert dieses Bytes auch 
im Rest des Packets enthalten sein

Sascha

[Antwort (Gast)]

Das mit structs und unions ist wie folgt gemeint:

//Opcode Typedefs
#define DEFINE_DATA_1   0
#define DEFINE_DATA_2   1

//Auf ARM 7 macht er aus uint8_t sonst uint16_t weil er da besser/schneller zugreifen kann. Kostet aber mehr Platz. Daher das pragma welches dies verhindert

#pragma pack(1) 
typedef struct{
uint8_t u8OpCode; //enthält Zahl zur Identifikation des structs
uint8_t u8MyData1;
uint8_t u8MyData2;
} tdsMY_DATA_1;

#pragma pack(1)
typedef struct{
uint8_t u8OpCode; //enthält Zahl zur Identifikation des structs
uint16_t u16MyData1;
char[5] cMyWord;
} tdsMY_DATA_2

typedef union{
tdsMY_DATA_1 tdsMyData1;
tdsMY_DATA_2 tdsMyData2;
} tduMY_RECEIVE_DATA;

Nach füllen des Zwischenspeichers könnte man nun wie folgt vorgehen:

tduMY_RECEIVE_DATA gtduGetReceiveData(){
uint8_t u8Buffer[20];
tduMY_RECEIVE_DATA tduReceivedData;

...    //erstmal zwischenspeicher füllen. Alles ausser delimiter enthalten

switch(u8Buffer[1]){ //Identification anhand OpCode

case DEFINE_DATA_1:
     //union befüllen
     (tdsMY_DATA_1)tduReceivedData.u8OpCode = DEFINE_DATA_1;
     (tdsMY_DATA_1)tduReceivedData.u8MyData1 = u8Buffer[2];
     (tdsMY_DATA_1)tduReceivedData.u8OMyData2 = u8Buffer[3];
     break;

case DEFINE_DATA_2:
     //befüllen
     break;
}

return tduReceiveData;
}

In einer anderen Funktion könnte die Auswertung wie folgt aussehen:

void gvMyFunction(tduMY_RECEIVE_DATA* ptduMyReceiveData){

//OpCode auslesen
switch(*ptduMyReceiveData){

case DEFINE_DATA_1:
     //tue etwas
     break;

case DEFINE_DATA_2:
     //tue etwas
     break;
}
}

Wichtig ist das die Zahl zur Identifikation des structs immer an erster 
stelle steht.

[Patrick R. (pat711)]

@Sascha:
Das mit dem Platz sollte schon irgendwie zu machen sein der ATmega88 hat 
ja immerhin 1kByte Speicher.

Und noch zu deinen Fragen:
* Die Größe der Pakete ist im Datenblatt mit einem Maximum der 
Datenlänge von 333 Byte also 7Byte + 333Datenbyte.
Dies ist allerdings nur voll ausgenutzt wenn der Controller Daten an den 
Chip sendet. Im umgekehrten Fall habe ich bisher Pakete mit einer 
maximalen Länge von 16 Byte empfangen. Viel längere werden nicht 
gesendet werden.


* Diese Pause beträgt laut Logicanalyser 0,1sec also 100ms da der 
Datenfluss sich aber mit RTS und CTS anhalten lassen sollte, sollte dies 
kein Problem darstellen.

* Im Datenteil des Paketes kann der End delimiter auch vorkommen

MfG Pat711

[Sascha W. (sascha_w)]

Patrick R. schrieb:
> @Sascha:
> Das mit dem Platz sollte schon irgendwie zu machen sein der ATmega88 hat
> ja immerhin 1kByte Speicher.
soviel ist das nicht

> Und noch zu deinen Fragen:
> * Die Größe der Pakete ist im Datenblatt mit einem Maximum der
> Datenlänge von 333 Byte also 7Byte + 333Datenbyte.
dann könnte man mit der Variante von 'Antwort' höchstens 1 Paket puffern

> Dies ist allerdings nur voll ausgenutzt wenn der Controller Daten an den
> Chip sendet. Im umgekehrten Fall habe ich bisher Pakete mit einer
> maximalen Länge von 16 Byte empfangen. Viel längere werden nicht
> gesendet werden.
du empfängst also blos?

>
> * Diese Pause beträgt laut Logicanalyser 0,1sec also 100ms da der
> Datenfluss sich aber mit RTS und CTS anhalten lassen sollte, sollte dies
> kein Problem darstellen.
liest du nur mit?

die 100ms sollten locker ausreichen um das empfange Paket noch im 
Empfangspuffer zu verarbeiten.
mein Vorschlag:
*eingehende Daten Byteweise in einen Puffer ablegen (Array), dabei 
Anzahl der Bytes mitzählen und Obergrenze überwachen (Obergrenze wird 
erst mal auf die Größe des Arrays festgelegt)
*nach Empfang von Byte 5 (2.Byte der Länge) Paketlänge berechnen und 
Obergrenze neu festlegen
*bei Erreichen von Obergrenze Flag setzten, das von Main aus das Paket 
verarbeitet werden kann, wenn dabei Obergrenze=Arraygröße dann ist ein 
Fehler aufgetreten (Daten haben nicht in das Array gepasst)

Sascha

[Patrick R. (pat711)]

Tag zusammen,

klar so viel ist 1kB nun auch wieder nicht aber es sollte reichen.

Und es wird außerdem auch gesendet, aber das ist ja wieder ein anderer 
Part.
Und das mit den 100ms ist eben nicht so sicher, da der Controller 
nebenher auch noch messwerte aufnehmen muss.

Die Vorgehensweise die du mir da beschreibst ist ja praktisch die aus 
meinem ersten Post ein wenig erweitert, oder?
`
MfG Pat711

[Sascha W. (sascha_w)]

Patrick R. schrieb:
> Die Vorgehensweise die du mir da beschreibst ist ja praktisch die aus
> meinem ersten Post ein wenig erweitert, oder?
nicht ganz, in deiner Variante sieht es je eher so aus als ob du in dem 
mehrdimensionalen Array alle Datenpakete speichern willst.
Nach meinem Vorschlag wird im Array immer nur ein Paket gespeichert, 
und nach dessen vollständigem Empfang werden nur die Werte die du 
brauchst in separaten Variablen abgelegt.

Sascha

[Patrick R. (pat711)]

#include <avr/io.h>
#include <arf32.h>
#include <lcd-routines.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include <util/delay.h> 

#define PAKET   25    // Maximale Paketlänge festlegen
#define CTS    PD7    // CTS - Pin des BT - Moduls (in)
#define RTS    PD6    // RTS - Pin des BT - Moduls (out)

uint8_t buffer = 0;    // Puffervariable in der das empfangene Zeichen abgelegt wird
uint8_t daten[PAKET];  // Variable, in der die Empfangenen Pakete abgelegt werden
uint8_t count0 = 0;    // Zähler zur erstellung der Pakete
uint8_t count1 = 0;
uint8_t zeile = 1;    // zum festlegend der LCD - Zeile
uint8_t paket_ende = 0; // Paketende - Flag um zu signalisieren, dass das Paket vollständig empfangen wurde
uint8_t paket_laenge = PAKET;
uint8_t lcd_zeichen = 0;
uint8_t kont = 0;

ISR (USART_RX_vect)
{
  buffer = UDR0;        // Empfangenes Zeichen in Puffer einlesen
  daten[count0] = buffer;    // Empfangenes Zeichen dem Paket hinzufügen
  count0 ++;
  if (count0 == (paket_laenge + 1))
  {
    paket_ende = 1;      // Paket wurde emfangen
    paket_laenge = PAKET;
    count0 = 0;
  }
  if (count0 == 5)        // Wenn beide Datenlänge Bits empfangen wurden
  {
    paket_laenge = (daten[4] * 256) + daten[3] + 7;
    lcd_zeichen = paket_laenge;
    
    lcd_clear();
    char Puffer[20]; // in diesem {} lokal
    itoa(daten[paket_laenge], Puffer, 10); 
    set_cursor(0,1);
    lcd_string(Puffer);
    
    itoa(daten[3], Puffer, 10); 
    set_cursor(5,1);
    lcd_string(Puffer);
    
    itoa(daten[4], Puffer, 10); 
    set_cursor(10,1);
    lcd_string(Puffer);  
  }
}

int main(void)
{
  _delay_ms(100);
  DDRD |= (1<<CTS);  // Pin an CTS-Eingangs des BT-Moduls als Ausgang derfinieren
  PORTD |= (1<<RTS);  // Pull-Up Widerstand am Eingang des Pins am RTS-AUsgang des BT-Moduls
  PORTD &= ~(1<<CTS); // Mittels CTS empfangsbereitschaft signalisieren
  lcd_init();
  uart_init();
  lcd_clear();
  set_cursor(0,1);
  lcd_string("Suche BT-Geraete");
  while(PIND & (1<<RTS))  // Warten, bis BT - Modul bereit zum Empfangen ist
  {}
  PORTD |= (1<<CTS);     // Nicht empfangsbereit
  BT_environment_inquiry();  // Umgebung nach BT - Geräten absuchen
  PORTD &= ~(1<<CTS);      // Empfangsbereit
  sei();
  lcd_clear();
  while (1)
  {
    if (paket_ende == 1)
    {
      count1 = 1;
      while (count1 > (lcd_zeichen - 1))
      {
        lcd_clear();
        char Puffer[20]; // in diesem {} lokal
        itoa(daten[count1], Puffer, 10); 
        set_cursor(0,zeile);
        lcd_string(Puffer);
        count1 ++;
        if (count1 == 15)
        {
          zeile = 2;
        }
      }
    }
    if(paket_laenge > PAKET)    // Falls Paketgröße die größe der Paketvariable übersteigt
    {
      set_cursor(0,2);
      lcd_string("Err0:Paketlaenge");
      while(1);
    }
    else if(paket_laenge < 7)    // Fehler beim berechnen der Paketgröße
    {
      set_cursor(0,2);
      lcd_string("Err1:Paketlaenge");
      while(1);
    }
    if ((daten[0] != 0x02) && (count0 > 1))  // Paketanfang ist nicht Start Delimiter!
    {
      lcd_clear();
      set_cursor(0,2);
      lcd_string("Err2:Paketanfang");
      
      char Puffer[20]; // in diesem {} lokal
      itoa(daten[0], Puffer, 10); 
      set_cursor(14,1);
      lcd_string(Puffer);
      
      while(1);
    }
  }  
}

Ich habe nun mal versucht das ganze umzusetzen allerdings stimmt 
irgendwas bei der Reihenfolge wie die Byte gespeichert werden nicht. Der 
Start Delimiter fehlt des öfteren ( = 0).
Vielleicht sollte ich es doch mal mit dem Rinpuffer versuchen.

Die ANfrage an das Modul (BT_environmen_inqury) wird korrekt gesendet. 
Die Antworten kommen aus am UART -Eingang an. (Logic Analyser)

MfG Pat711

[Sascha W. (sascha_w)]

schmeiß mal die ganzen LCD Ausgaben aus der ISR raus, das dauert dort 
viel zu lange! Wenn du die Daten unbedingt ausgeben willst, dann setze 
noch ein FLAG und mach die Ausgabe in Main.
UND definiere alle Variablen die in Main und der ISR verändert werden 
als volatile!

Sascha

[Patrick R. (pat711)]

Guten Tag zusammen,

die LCD ausgaben habe ich erst nachträgich eingefügt, um den Fehler zu 
finden. Nun habe ich sie wieder herausgenommen, aber es funktioniert 
auch so nicht.
Es wird auf dem LCD immer Err2:Paketanfang angezeigt, was bedeutet, dass 
mein Startdelimiter fehlerhaft ist. Die Variable data[0], welche neben 
dem Fehler angezeigt wird hat immer einen der folgenden Werte: 14, 23, 
105 oder 114.
Diese Werte kommen in der Antwort des Moduls gar nicht vor. Diese 
Antwrot sieht folgendermasen aus:
0x02 Start Delimiter
0x69 Packet Type identification
0x01 Op Code
0x09 Data length
0x00 Data length
0x73 Checksum
0x72 Packet Data
0x15 Packet Data
0x07 Packet Data
0x0E Packet Data
0x19 Packet Data
0x00 Packet Data
0x04 Packet Data
0x01 Packet Data
0x3E Packet Data
0x03 End Delimiter

#include <avr/io.h>
#include <arf32.h>
#include <lcd-routines.h>
#include <stdlib.h>
#include <avr/interrupt.h>
#include <util/delay.h> 

#define PAKET   25    // Maximale Paketlänge festlegen
#define CTS    PD7    // CTS - Pin des BT - Moduls (in)
#define RTS    PD6    // RTS - Pin des BT - Moduls (out)

uint8_t buffer = 0;    // Puffervariable in der das empfangene Zeichen abgelegt wird
uint8_t daten[PAKET];  // Variable, in der die Empfangenen Pakete abgelegt werden
uint8_t count0 = 0;    // Zähler zur erstellung der Pakete
uint8_t count1 = 0;
uint8_t zeile = 1;    // zum festlegend der LCD - Zeile
uint8_t paket_ende = 0; // Paketende - Flag um zu signalisieren, dass das Paket vollständig empfangen wurde
uint8_t paket_laenge = PAKET;
uint8_t lcd_zeichen = 0;
uint8_t kont = 0;
uint8_t lcd_flag = 0;

ISR (USART_RX_vect)
{
  buffer = UDR0;        // Empfangenes Zeichen in Puffer einlesen
  daten[count0] = buffer;    // Empfangenes Zeichen dem Paket hinzufügen
  count0 ++;
  if (count0 == (paket_laenge + 1))
  {
    paket_ende = 1;      // Paket wurde emfangen
    paket_laenge = PAKET;
    count0 = 0;
  }
  if (count0 == 5)        // Wenn beide Datenlänge Bits empfangen wurden
  {
    paket_laenge = (daten[4] * 256) + daten[3] + 7;
    lcd_zeichen = paket_laenge;
    
    lcd_flag = 1;  
  }
}

int main(void)
{
  _delay_ms(100);
  DDRD |= (1<<CTS);  // Pin an CTS-Eingangs des BT-Moduls als Ausgang derfinieren
  PORTD |= (1<<RTS);  // Pull-Up Widerstand am Eingang des Pins am RTS-AUsgang des BT-Moduls
  PORTD &= ~(1<<CTS); // Mittels CTS empfangsbereitschaft signalisieren
  lcd_init();
  uart_init();
  lcd_clear();
  set_cursor(0,1);
  lcd_string("Suche BT-Geraete");
  while(PIND & (1<<RTS))  // Warten, bis BT - Modul bereit zum Empfangen ist
  {}
  PORTD |= (1<<CTS);     // Nicht empfangsbereit
  BT_environment_inquiry();  // Umgebung nach BT - Geräten absuchen
  PORTD &= ~(1<<CTS);    // Empfangsbereit
  sei();
  lcd_clear();
  while (1)
  {
    if (paket_ende == 1)
    {
      count1 = 1;
      while (count1 > (lcd_zeichen - 1))
      {
        lcd_clear();
        char Puffer[20]; // in diesem {} lokal
        itoa(daten[count1], Puffer, 10); 
        set_cursor(0,zeile);
        lcd_string(Puffer);
        count1 ++;
        if (count1 == 15)
        {
          zeile = 2;
        }
      }
    }
    if(paket_laenge > PAKET)    // Falls Paketgröße die größe der Paketvariable übersteigt
    {
      set_cursor(0,2);
      lcd_string("Err0:Paketlaenge");
      while(1);
    }
    else if(paket_laenge < 7)    // Fehler beim berechnen der Paketgröße
    {
      set_cursor(0,2);
      lcd_string("Err1:Paketlaenge");
      while(1);
    }
    if ((daten[0] != 0x02) && (count0 > 1))  // Paketanfang ist nicht Start Delimiter!
    {
      lcd_clear();
      set_cursor(0,2);
      lcd_string("Err2:Paketanfang");
      
      char Puffer[20]; // in diesem {} lokal
      itoa(daten[0], Puffer, 10); 
      set_cursor(13,1);
      lcd_string(Puffer);
      
      while(1);
    }
    if (lcd_flag == 1)
    {
      lcd_clear();
      char Puffer[20]; // in diesem {} lokal
      itoa(daten[paket_laenge], Puffer, 10); 
      set_cursor(0,1);
      lcd_string(Puffer);
      
      itoa(daten[3], Puffer, 10); 
      set_cursor(5,1);
      lcd_string(Puffer);
      
      itoa(daten[4], Puffer, 10); 
      set_cursor(10,1);
      lcd_string(Puffer);  
    }
  }  
}

[Patrick R. (pat711)]

Im letzten Thread hatte ich einen kleinen Fehler, und zwar kommen die 
Werte doch auch alle bis auf einen in der Antwort vor.
114 -> 0x72 Packet Data 1.Stelle
105 -> 0x69 Packet Type identification
23  -> 0x17 kommt nicht vor ???
14  -> 0x0E Packet Data 4.Stelle

heißt wohl dass mein Programm zu lansam arbeitet, oder?

und das mit den volatile habe ich auch noch vergessen die werde ich nun 
verändern.
Edit: Macht keinen Unterschied

MfG Pat711

[Sascha W. (sascha_w)]

Patrick R. schrieb:
> heißt wohl dass mein Programm zu lansam arbeitet, oder?
das würde erst mal heißen das das 1.Byte verschluckt wird, was schon 
dadurch passieren kann wenn die Schnittstelle erst nach dem Einschalten 
verbunden wird und dadurch eine Flanke am Eingang auftritt.
Das Problem was ich momentan noch sehe ist die fehlende Syncronisation 
am Anfang. Wenn irgendwas aus dem Tritt kommt wird count0 ja erst wieder 
auf null gesetzt wenn der Puffer voll ist, und auch dann werden 
anschließend die Daten wieder falsch eingelesen. Wenn das Startbyte auch 
innerhalb der Daten vorkommt bleibt zur Syncronisation nur ein Timeout, 
also ein Reset des count0 wenn für z.B. 100ms keine Daten kommen, oder 
wenn die Daten nur auf Anforderung gesendet werden dann am besten vor 
dem senden den count0=0 setzen.

Sascha

[Patrick R. (pat711)]

Das mit dem Timer ist eine gute Idee. Aber ich vermute, dass ich mit 
einem Ringpuffer besser arbeiten kann. Ich werde dies jetzt einmal 
ausprobieren da ich vermite, dabei mehr chancen zu haben keine Bytes zu 
verlieren.
Der Ringpuffer muss ja auch nicht 256 Byte lang sein.

MfG Pat711