LAN-Anbindung für BSB-Bus (Brötje, Elco Thision etc.)

[freetz]

...da waren wir wohl gleichzeitig am Werk, ich hab's jetzt glaube ich auch hinbekommen, zumindest läuft es jetzt ...
Das mit den doppelten Variablen ist nicht schön gelöst, aber kann ich denn auf public Klassenvariablen einfach so zugreifen, als wären sie globale Variablen? Ich dachte, das ginge nicht und habe deshalb extra Funktionen wie getBusType eingeführt, um an den Inhalt der bus_type Variable zu kommen. Wenn es da andere Möglichkeiten gibt, wäre das natürlich überflüssig...

[loetmeister]

Hi,

ja, auf public Variablen kannst du über das objekt zugreifen (lesen/setzen). Schöner (besser?) ist es aber sie als private zu definieren und nur die Zugriffe (also z.B. nur lesen) als Funktion zur Verfügung zu stellen... so wie es du es gemacht hast (z.b. uint8_t getBusType(); )
Oder die Funktion die auf die private Variable zugreift ist teil der Klasse. (wie z.b. printTelegram oder LogTelegram ??) - bin noch etwas verloren im Code... 

Was mich etwas gewundert hatte, sind diese, für mich etwas doppel wirkende Passagen..

Code Auswählen Erweitern

uint8_t BSB::setBusType(uint8_t bus_type_val, uint16_t addr, uint16_t d_addr) {
  bus_type = bus_type_val;
  switch (bus_type) {
    case 0: len_idx = 3; break;
    case 1: len_idx = 1; break;
    case 2: len_idx = 8; break;
    default: len_idx = 3; break;

Code Auswählen Erweitern

void setup() {
... 
  switch (bus_type) {
    case 0:
      len_idx = 3;
      pl_start = 9;
      break;
    case 1:
      len_idx = 1;
      pl_start = 13;
      break;
    case 2:
      len_idx = 9;
      pl_start = 6;
      break;
  }

Gruß,
Thomas

[freetz]

Danke, das mit dem direkten Zugriff auf Klassenvariablen kannte ich noch nicht, daher hatte ich das immer mit den dafür geschriebenen kleinen Funktionen gemacht.

Das mit len_idx ist leider etwas unschön umgesetzt, da ich urspünglich davon ausgegangen bin, dass diese Werte gleich bleiben. Tun sie aber (zumindest bei PPS) nicht, aber dafür dann andere Variablenbezeichnugen einzuführen, war mir dann zu umständlich. Ich muss mir aber mal ernsthaft überlegen, ob ich bei einer Migration auf eine andere Plattform vielleicht doch einen kompletten Rewrite-from-Scratch mache, anstatt den Code 1:1 zu portieren. Als ich BSB-LAN vor drei Jahren übernommen habe, war das meine erste Begegnung mit C(++), und an einigen Stellen merkt man das eben noch ...

[stan23]

EDIT: die BSB::Monitor() Funktion wartet schon in der ursprünglichen (SoftwareSerial-basierten) Variante drei ms auf ein weiteres Zeichen, und betrachtet das Telegramm dann als beendet an, wenn innerhalb dieses Zeitraums keine Daten mehr folgen. Seltsamerweise wird diese Zeitspanne aber in 15 µs Schritten abgewartet, in denen nach einem solchen Schritt keine weitere Überprüfung o.ä. stattfindet. Der Sinn dahinter erschließt sich mir leider ebenfalls nicht...

Das kann keinen tieferen Sinn haben.
Wahrscheinlich war mal geplant in der Schleife nach jedem 15 us-Schritt zu prüfen ob was empfangen wurde, und dann das while() abzubrechen.

[freetz]

Ah, danke! Haben denn die 15 Microsekunden einen tieferen Sinn?

[stan23]

Den Sinn von 15 us kann ich auch nicht erkennen.
Ich würde gleich so lange warten wie ein Bit dauert, also die ~200 us.

Andererseits ist es egal wie man die Zeit verbrennt, in 15 us Häppchen oder 200 us Häppchen: Interrupts kommen in jedem Fall durch.

[freetz]

Stimmt, danke!

[loetmeister]

Hi freetz,

meine C++ Kenntnisse sind auch nicht so doll... hatte mich in der Vergangenheit auf C beschränkt und Microchip PIC programmiert. Mit Arduino/Atmel kam dann C++

Falls es ohne Probleme möglich ist zu "mergen", hier mein diff, damit das Serielle interface für die Ausgabe am PC initialisiert wird, bevor Daten an das Interface geschickt werden:
https://github.com/fredlcore/bsb_lan/compare/master...loetmeister:master#diff-1118998d47d0c636c492e49a080339afR6681
Lohnt da ein Pull Request zu stellen? 

Gruß,
Thomas

[freetz]

Danke, aber was genau ist das Ziel dieser Änderungen? Ich freue mich immer über Verbesserungen, aber da ich wie gesagt schon ursprünglich auf einer Code-Basis aufbauen musste, die nicht meine war und die ich erst Schritt für Schritt verstehen musste, bin ich immer etwas zurückhaltend, Pull Requests direkt zu übernehmen.
Du ziehst die Init-Ausgabe in setup() höher und erzeugst mit BUS_TYPE eine neue Variable, deren Sinn ich nicht verstehe (bessere Lesbarkeit)? Ich weiß auch, dass die Notation x = y ? a : b kürzer ist, als meine if-then-else Blöcke, aber ich finde letztere einfacher zu lesen, und m.W. ist der Speicherverbrauch identisch.

Dass das mit dem De-/Reaktivieren der Interrupts in bsb.cpp überflüssig ist, war mir noch nicht klar. Gibt es denn einen anderen Grund, warum Gero(?) das eingebaut haben könnte? Denn Du hast natürlich Recht, in der (BSB)SoftwareSerial::write() Funktion werden die Interrupts vor dem Schreiben deaktiviert. Allerdings werden sie quasi nach dem Senden eines jeden einzelnen Bytes wieder aktiviert, so dass zwischen dem Senden von zwei Bytes ein Interrupt ausgelöst werden könnte. Soll das damit vielleicht verhindert werden?

Auf jeden Fall Danke und VG, F.

[loetmeister]

Hi,

neben den Kommentaren, war die Änderung das Serielle Interface erst richtig zu starten um die Ausgabe unten zu vermeiden. Welche ensteht wenn uint8_t bus_type = bus.setBusType(0); von BSB_lan_config.h ausgeführt wird (was ja mit dem #include sehr früh passiert - noch bevor die Baudrate von Serial #0 eingestellt ist.
Statt static const uint8_t BUS_TYPE = 0; könnte man auch #define BUS_TYPE 0 schreiben. static const uint8_t passte hier aber besser
EDIT: BUS_TYPE da ich bus_type = bus.setBusType(BUS_TYPE); aus der Header Datei BSB_lan_config.h in setup() verschoben hatte..

Code Auswählen Erweitern

21:09:41.131 -> 昆⸮ address: 66
21:09:41.131 -> Destination address: 0
21:09:41.131 -> READY

(BSB)SoftwareSerial::write() Funktion werden die Interrupts vor dem Schreiben deaktiviert. Allerdings werden sie quasi nach dem Senden eines jeden einzelnen Bytes wieder aktiviert, so dass zwischen dem Senden von zwei Bytes ein Interrupt ausgelöst werden könnte. Soll das damit vielleicht verhindert werden?

Vermutlich hast du recht, es ist sicherer wären dem send loop keine Interrupts zuzulassen... wobei eigentlich nur zu große Interrupt Funktionen ein Problem sein könnten. 4800 Baud ist recht langsam... da könnte der Prozessor noch andere dinge tun.
Ich werde eh USART nutzen, da ist es nicht relevant. 

Gruß,
Thomas

[freetz]

Ah, prima, danke, dass da vorher schon über setBusType eine Ausgabe kommt, hatte ich gar nicht auf dem Schirm ...
Mit BUS_TYPE ist es natürlich schöner, aber es würde auch bedeuten, dass bei allen Leuten, die sich ein Update ziehen, das Kompilieren erst mal fehlschlägt, wenn in der _config.h (die ja nicht überschrieben wird) nicht die BUS_TYPE Variable bzw. das Definement gesetzt werden. Von daher lasse ich das wohl erst mal so, bis die nächste zwingende Änderung in der _config.h fällig ist, aber dann übernehme ich das gerne.
Mit dem Entfernen von cli() und sei() werde ich das mal eine Zeit lang testen. Wenn man das rausnehmen könnte, würde es den Code schon noch etwas besser lesbar machen...

[loetmeister]

Hallo Schotty,

konnte nun endlich den Adapter testen und /Q laufen lassen.
Brötje BGB EVO 20 i

Code Auswählen Erweitern

Scanne nach Geräten...
Geräteadresse gefunden: 0
Geräteadresse gefunden: 10

Teste Geräteadresse 0:
Gerätefamilie: 163
Gerätevariante: 5
Geräte-Identifikation: LMS15.003A100
Software-Version: 4.6
Entwicklungs-Index: decoding error
Objektverzeichnis-Version: 1.8
Bootloader-Version:
EEPROM-Version: ---
Konfiguration - Info 2 OEM: 0
Zugangscode Inbetriebnahme?: 0
Zugangscode Fachmannebene ?: 0
Zugangscode OEM?: 0
Zugangscode OEM2?: 0
Bisher unbekannte Geräteabfrage: 20
Hersteller-ID (letzten vier Bytes): 191290114
Bisher unbekannte Geräteabfrage: 04010F00C8 - unknown type
Außentemperatur (10003): 4.5 °C
Außentemperatur (10004): 4.5 °C

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
163;5;LMS15.003A100;4.6;decoding error;1.8;---;0;0;0;0;0;20;191290114;04010F00C8 - unknown type;


Starte Test...
Test beendet.

Teste Geräteadresse 10:
Gerätefamilie: 92
Gerätevariante: 100
Geräte-Identifikation: AVS37.294/100
Software-Version: 7.6
Entwicklungs-Index:
Objektverzeichnis-Version: 102.0
Bootloader-Version:
EEPROM-Version:
Konfiguration - Info 2 OEM:
Zugangscode Inbetriebnahme?:
Zugangscode Fachmannebene ?:
Zugangscode OEM?:
Zugangscode OEM2?:
Bisher unbekannte Geräteabfrage: ---
Hersteller-ID (letzten vier Bytes): 1830956
Bisher unbekannte Geräteabfrage:
Außentemperatur (10003):
Außentemperatur (10004):

6225;6226;6224;6220;6221;6227;6229;6231;6232;6233;6234;6235;6223;6236;6237;
92;100;AVS37.294/100;7.6;;102.0;;;;;;;---;1830956;;


Starte Test...
Test beendet.

Fertig.

Gruß,
Thomas

[Schotty]

Danke Thomas.
Sag mal, hast du zufällig 'freie Sicht' auf den LMS15-Regler? Also recht freie Draufsicht samt Stecker etc.?

[loetmeister]

Hi,

Ja, hab freie Sicht drauf... Anschlussplan ist in der Vorwand.
Soll ich Fotos machen? 

Edit: Montageanleitung und detaillierte Dokumentation ist aber auch online verfügbar...

Gruß,
Thomas

[Schotty]

Hi Thomas,
oh jaa bitte, Fotos wären klasse, ich bräuchte noch welche fürs Handbuch. Da möchte ich lieber keine aus anderen Quellen verwenden..
Schick sie mir dann gern per Email. Danke!