VBus-Decoder/AVR8-Software

Aus Hobbyelektronik.org
AVR
Typ ATmega32
Takt 12 MHz
Fuses
High 0xCF
Low 0xFF
Engbedded com logo.png Details


Dies ist ein Unterartikel von VBus-Decoder. Auf der Hauptseite gibt es weitere Informationen zum Thema.

Integration

Die Software ist in C geschrieben. Über den Befehl Vbus_ProcessChar() kann ein Zeichen von der seriellen Schnittstelle übergeben werden. Im einfachsten Fall kann die ISR-Routine wie folgt aussehen:

ISR (USART_RXC_vect) {
	Vbus_ProcessChar(UDR);
}

Vorher muss noch der UART initialisiert werden (9600 8N1, sei() nicht vergessen!).

Die empfangenen und dekodierten Daten werden in der Variable vbus_outdata gespeichert. In dieser Variable muss auch angegeben werden, ob ein Paket gelesen werden soll:

vbus_outdata.update = 1;

Ist ein Paket vollständig angekommen, wird die valid-Eigenschaft auf 1 gesetzt. Im Demo-Code wird nach erfolgreichem Empfang das komplette Datenpaket am UART ausgegeben (bitte nicht an den Regler zurückschicken, sondern möglichst an den PC!):

int main() {

  ...

  while(1) {
    if(vbus_outdata.valid == 1) {
      vbus_outdata.valid = 0;
      VBus_Show_Values();
      vbus_outdata.update = 1;
    }
  }
}

Debug-Ausgabe

Anzeige auf dem Display. die ICs unten und rechts gehören nicht zur Schaltung

Der Debug in der Software gibt einige Informationen zur Dekodierung auf einem LC-Display aus.

Dieser Modus kann in der Datei vbus.h Zeile 35 aktiviert werden (standardmäßig deaktiviert).

Über UART würde eine Ausgabe kaum sinn machen, da man durch das langsame Senden den Empfang der Daten verpasst.

Zugegebenermaßen: ich habe einen Exoten mit LC7980-Controller und einer Auflösung von 240x40 Pixel verwendet. Die Routinen lassen sich aber halbwegs einfach auf einen anderen Displaycontroller anpassen. Die Ausgabe auf dem Display sieht wie folgt aus:

Bei jedem Erhalt eines Sync-Wortes wird "Sync" angezeigt.

Wurde der Head empfangen, wird der Displayinhalt gelöscht und folgendes ausgegeben:

D:<Ziel-Adresse> S:<Quell-Adresse> V:<Protokoll-Version> C:<Befehl> F:<Anzahl Frames> X:<Prüfsumme ok|nok>

Danach wird, wenn die Prüfsumme ok ist jedoch das falsche Protokoll angegeben wurde, die Meldung "!V1.0->dropped " ausgegeben. Hat das Paket das "falsche" Adress-Pärchen, wird "Wrong addr->dropped " angezeigt.

Kommen diese beiden Meldungen nicht, werden Informationen über die dekodierten Frames ausgegeben:

 F<Frame-Index><Prüfsumme ok|nok>

Nachdem alle Frames empfangen wurden, wird ein "AFR" (all frames received) ausgegeben

Im Ganzen kann solch eine Ausgabe wie folgt aussehen:

Sync [Display wird geleert]
D:0x0010 S:0x7321 V:1 C:0x0100 F:18 X:ok F0ok F1ok F2ok F3ok F4ok F5ok F6ok F7ok F8ok F9nok F10ok F11ok F12ok F13ok F14nok F15ok F16ok F17ok AFR

Gleiches Beispiel mit meinen Testdaten, nur dass hier (im Gegensatz zu den Daten!!) Frame 9 und 14 ungültig sind.

Zuordnung der Datenfelder

Die Zuordnung der empfangenen Daten kann man relativ einfach zu den entsprechenden Feldern zuordnen.

Im der Datei %ProgramFiles%\RESOL\ServiceCenterFull\eclipse\plugins\de.resol.servicecenter.vbus.<Device>\VBusSpecification<Device>.xml

findet man alle Zuordnungen der Felder. Achtung: es kann Lücken geben - dadurch sind in meinem Code die "unknown"-Felder entstanden.

Alternativ kann man auch die Paketbeschreibung zu Rate ziehen.

Bekannte Fehler/Macken

Daten meiner Auswertung (links) und die des Resol ServiceCenters

Folgendes wurde noch nicht getestet/ist unbekannt:

  • Einstrahlung
  • Werte hinter der Fehler- & Warnungsmaske (muss ich noch in den XML-Dateien nachlesen)
  • Unbekannt-Felder
    • anscheinend immer 0x00
  • Woher kommt der Wochentag bei der Systemzeit

Verbesserungswürdig an der Software:

  • RAM-Belegung
  • Unterstützung der weiteren Protokolle (Parametrisierung - werde ich aber vermutlich nicht in absehbarer Zeit implementieren)
  • Es ist nicht ersichtlich, welche Daten durch Prüfsummenfehler ungültig sind

Downloads