ARDUINO am KNX

[tuxedo]

Die Arduino IDE hat einen eingebauten Serialmonitor ... Damit kannst du sehen was der Arduino auf die serielle Schnittstelle schreibt und kannst umgekehrt dem Arduino auch einen String an die Schnittstelle senden.
Setzt allerdings voraus, dass der Arduino entsprechend am Rechner hängt.

Beim Leonardo geht das über die selbe Schnittstelle wie man programmiert. Beim Uno sollte das laut Boardbeschreibung genau so gehen:

• Serial: 0 (RX) and 1 (TX). Used to receive (RX) and transmit (TX) TTL serial data. These pins are connected to the corresponding pins of the ATmega8U2 USB-to-TTL Serial chip.

Communication

The Arduino Uno has a number of facilities for communicating with a computer, another Arduino, or other microcontrollers. TheATmega328 provides UART TTL (5V) serial communication, which is available on digital pins 0 (RX) and 1 (TX). An ATmega16U2 on the board channels this serial communication over USB and appears as a virtual com port to software on the computer. The '16U2 firmware uses the standard USB COM drivers, and no external driver is needed. However, on Windows, a .inf file is required. The Arduino software includes a serial monitor which allows simple textual data to be sent to and from the Arduino board. The RX and TX LEDs on the board will flash when data is being transmitted via the USB-to-serial chip and USB connection to the computer (but not for serial communication on pins 0 and 1).

[division]

Ach so.... ja das klappt... ich kann im Arduino Code ohne Probleme Serial.Println("Hallo") und so weiter benutzen....

Das hat ja aber noch nix mit den PINs des Arduino zu tun um zu gucken ober er an Rx was empfangen kann.

Oder meinstest du was aderes?

EDIT:

Eigentlich beweist das ja schon das Rx und Tx funktionieren.... sonnst für das ja grundsetzlich nicht gehen.
Das geht zwar alles über den USB - Seriel Wandler zum PC aber am ende kommt das an den beiden PINs Rx und Tx vorbei.
Hmmmmmm sehr komisch alles.

Mir gehen da die Ideen aus.

[tuxedo]

Wie wär's mit deinem PC mit dem Arduino IDE Serialmonitor?

[division]

Hmmmm ja sehr komisch alles. Zumal ich ja nich der erste bin der GENAU das so festgestellt hat.

Die Beispiele benötigen doch sicher irgend etwas was per UART was sendet damit man serialEvent() testen kann.

Leider habe ich nicht viel hier dafür... keinen anderen Arduino oder so.

wie könnte ich das den testen?

[tuxedo]

Hmm. Schon seltsam. Kontrolliere sichereitshalber nochmal die Verkabelung bzw. die Pin-Belegung am Siemens BCU.

Hast du mal die Beispielsketches (ohne KNX) probiert?

[division]

Ja... ich hab mir auch mal einen bestellt.... Zwar für 10 Euro... dafür aber mit sofort Versand hier aus Deutschland.....

So ganz schlau bin ich noch nicht hier.

SerialEvent() sollte doch wenigstens ausgerufen verden wenn da an pin was passiert oder?

Erst mal egal was da kommt. Das auswerten macht man ja dann erst.... aber in meinem Code wird das nie aufgerufen....

Komisch.

[tuxedo]

KNX auf der soft-serial würde ich lassen. Wenn dann das debugging auf der soft-serial.

Hast du mal nach einem Code-Beispiel (ohne KNX) gesucht das die serielle Schnittstelle des Uno verwendet? Sofern das nicht sauber funktioniert, brauchst du mit KNX nicht anfangen.

Im übrigen: Einen Arduino Leonardo (groß) oder Micro (passt in eine UP-Dose) bekommst du für ~7EUR ...

[division]

Hallo und vielen Dank für deine Antwort.

Ich habe es mal ganz einfach gemacht.....

void serialEvent() {
 digitalWrite(led, HIGH);
}

Selbst das wird nie mal aufgerufen. Ich komme also garnicht bis dahin, etwas Sinnvolles zu machen.
Weiter vorne auf Seite 29 oder so im Thread hatte ein anderer User hier GENAU das gleiche Problem.
Uno geht nur senden....
Leonardo angesteckt mit gleichem Code...
alles wunderbar.
Also irgendwie hat das schon mit der Seriellen Schnittstelle vom Uno zu tun. Er hat sich damals laut dem Thread hier einfach den Leonardo oder Mega gekauft und fertig. Aber das kann ja nicht die Lösung sein. Kann ich dann die KNX Library auch auf den Software Serial mit den Digitalpins initialisieren? Oder ist die dann nur für debugging?

Viele Grüße Jan

[tuxedo]

Es gibt für Arduino eine SoftSerial Lib. Mit der kannst du zwei Digital-IO Pins zur seriellen Schnittstelle machen. Damit kannst du wieder parallel auf die Console debuggen.

Dein Code ist nicht vollständig was den Empfang einer Gruppenadresse anbelangt. Aktuell nimmst du _jedes_ Telegramm und schaltes in Abhängigkeit vom ersten Datenbyte.

Du musst/solltest auswerten ob es das passende Telegramm ist. Hier mal ein Stückchen Beispielcode, ungetestet und nur schnell zusammenkopiert (weiß ja nicht welche Lib-Version du gerade verwendest):

KnxTelegram* telegram = knx.getReceivedTelegram();

// Check which kind of telegram it is
switch(telegram->getCommand()) {

    // someone is sending data (to us?)
    case KNX_COMMAND_WRITE: 
        byte ga[2];
        telegram->getTarget(ga);
        
        if (ga == _gaSwitch) {
            state = telegram->getBool();
            digitalWrite(led, state);
        }
        break;
        
    default:
        break;
}

[division]

Hallo,

ich versuche mich gerade auch an den ersten Schritten mit einem Arduino. Dank der bemerkenswerten Leistung hier klappt es auch recht einfach auf den Bus zu senden.

Ein Blinklich an der Bürodecke ist kein Problem.

Leider klappt das empfangen und reagieren auf KNX Telegramme überhaupt nicht.

Mein Setup ist der Siemens Busankoppler und ein Arduino Uno R3.
Diese sind wie im ersten Post beschrieben mit einander verbunden.

Ich habe in jedem if des serialEvent() ein digitalWrite(led, HIGH); um zu sehen ob das ganze wenigsten irgendwann mal aufgerufen wird.... Aber es sieht so aus als ob
SerialEvent() niemals durchlaufen wird.

Leider ist man mit dem Uno wegen der einen Seriellen Schnittstelle sehr eingeschränkt was das debuggen angeht.

Jemand eine Idee was ich flasch mache?

Ich versuche das mit diesem Code:

#include <KnxTpUart.h>

KnxTpUart knx(&Serial, "0.0.211");
int led = 13;

void setup() {
    Serial.begin(19200);
    UCSR0C = UCSR0C | B00100000;
    knx.uartReset();
    knx.addListenGroupAddress("0/0/14");

    pinMode(led, OUTPUT);
    digitalWrite(led, LOW);
}


void loop() {
    //knx.groupWriteBool("0/0/14", true);
    //digitalWrite(led, HIGH);   
    //delay(1000);
    //knx.groupWriteBool("0/0/14", false);
    //digitalWrite(led, LOW);    
    //delay(1000);             
}


void serialEvent() {
    KnxTpUartSerialEventType eType = knx.serialEvent();
    if (eType == TPUART_RESET_INDICATION) {
        digitalWrite(led, HIGH);
    }
    
    else if (eType == UNKNOWN) {
        digitalWrite(led, HIGH);
    }
    
    else if (eType == KNX_TELEGRAM) {
        KnxTelegram* telegram = knx.getReceivedTelegram();

        if (telegram->getFirstDataByte() == 0) {
            digitalWrite(led, HIGH);   // turn the LED on (HIGH is the voltage level)
        }
        else {
            digitalWrite(led, LOW);   // turn the LED on (HIGH is the voltage level)
        }
    }

}

Hoffentlich kann mir jemand helfen.....

Viele Grüße

Jan

[tuxedo]

Danke für die aufmunternden Worte. Glücklicherweise habe ich diese Woche Zeit und offenbar auch ausreichend Elan um dran zu bleiben.

Gerade eben wieder ein wunderschönes Beispiel für "Code ohne Debug verhält sich anders als mit Debug" gehabt:

Wenn ich vor dem zurücksenden des MemReadResponse auf Arduino-Seite das telegramm auf der Debug-Console ausgeben lasse, sind auf einmal viele Fehler verschwunden. Und was heisst das? Timing-Problem

Bin glaub nicht sonderlich gut darin das sauber in den Griff zu bekommen. Aktuell behelfe ich mir damit, dass ich vor dem Senden des MemReadResponse einfach 300ms auf Arduino-Seite schlafe (fix 30ms Delay), und auf Calimero-Seite sicherstelle, dass zwischen zwei Telegramm-Sendungen nicht weniger wie 150ms Zeit liegen (ein kalkuliertes Delay).

Aber so richtig toll ist das mit dem Delay ja auch nicht.

Ausgehend von 150ms Delay auf Calimero-Seite:
100x MemWrite mit je 10 byte: Dauert 32sek bei ~18% durchschnittlicher Buslast
---> Läuft mehrfach ohne einen einzigen Fehler. Je niedriger ich das Delay ansetze, desto wahrscheinlicher der Fehlerfall. 150ms scheinen okay zu sein.

Wieder 150ms auf Calimero-Seite, aber 30ms vor der Response-Antwort auf Arduino-Seite:
100x MemRead für je 10 byte: Dauert 65 bis 93sek bei ~20-25% durchschnittlicher Buslast
--> Läuft immer mal wieder ein einen Timeout. Fehlerrate, aber durch Retries noch abgefangen, liegt bei ca. 5-10% (5-10 von 100 MemRead brauchen einen Retry).

In der Praxis wird man auf einen kleinen Arduino wohl eher weniger 1kbyte an Daten Schicken oder von ihm lesen müssen. Von daher sollte das nicht "tragisch" sein. Aber meine Entwickler-Ehre lässt das eigentlich nicht zu. Das muss besser werden.

Ich mache noch ein paar Tests und dann wandert der aktuelle Entwicklungsstand wieder zu Github.

[EPIX]

ich bewundere deine Beharrlichkeit - es klingt spannend...
Besonders beachtlich finde ich wie weit du schon gekommen bist!!

[tuxedo]

Nicht nur Monologe sind was tolles. Nein, auch die Embedded-Entwicklung ist toll... Da kommt's auf 1,7 Millisekunden an. "Hää? Wie, wo, was?"

Ich habe mich gestern noch gewundert, warum die Sache mit dem ACK so durcheinander kommt. Das lag wohl an meinen vielen Debug-Ausgaben auf der seriellen Schnittstelle. Irgendwann hab ich in der TPUart-Doku gelesen:

The U_AckInformation-Service is to indicate if the device is addressed. This service must be send latest 1,7 ms (9600 Baud) after receiving the address type octet of an addressed frame.

Zu deutsch: Wenn der TPUart am dem Arduino ein Telegramm weiterreicht, dann muss der Arduino binnen 1,7ms dem TPUart bescheid sagen ob das Telegramm für ihn relevant ist oder nicht. Und das muss über dieses Acknowledge geschehen.
Wenn man nun zu viel Debug-Informationen ausgibt während man das ankommende Telegramm parst, dann sind da schnell mal 1,7ms vergangen. So zumindest meine Vermutung.

Nun, sämtliche Debug-Ausgaben bis zum Senden des ACk entfernt, und schon sieht die Welt anders aus. Aber funktionieren tut's noch immer nicht. Wenn ich zwischen einem verbindungsabbau und einem verbindungsaufbau (also zwischen 3) und 4)) auf Java-Seite ein kleines Delay einbaue (300ms reichen), dann wird die Sache nochmal besser. Das ACK kommt mit der richtigen Sequenz an, aber Java quittiert den MemRead-Response mit einem N_ACK... Es scheint so, als würde Calimero hier eine falsche Sequenz-Nr. sehen, obwohl der ETS Busmonitor nun alles korrekt dastehen lässt.

Meine Geduld wird wieder einmal auf die Probe gestellt.

Was ich auch nicht verstehe:

Das Delay habe ich zwischen Schritt 3 und 4 eingebaut, wirkt sich aber auf Schritt 6 aus... Ein Delay an anderer Stelle ist nicht relevant.
Und es kommt noch besser: vertausche ich in der Reihenfolge 5 und 6, so klappt alles fehlerfrei?! Dabei sollte es doch egal sein ob ich nun erst schreibe und dann lese oder umgekehrt.

Ich debugge weiter...


[update]

Wenn ich auf PC Seite ruhoger angehen lasse und zwischen jedem Telegramm 300ms Delay einbaue, dann klappt die Sache schon erheblich besser. Ehrlich gesagt stochere ich momentan mal wieder nur im dunkeln. Aber mangels Ideen ist das erstmal besser als nix.
Ich hab nun auch ein Retry eingebaut: Geht ein Lese-versuch seitens Java schief, wird kurz gewartet und einfach nochmal probiert. Das macht Calimero sonst auch so.
Mein Testszenario ist nun etwas anders: ich versuche x-mal nacheinander die gleiche Aktion zu triggern. Bei 300ms Delay zwischen den Aktionen bin ich nun bei mehr oder weniger konstant 10 Erfolgen, gefolgt von einem Fehlversuch angelangt. Und der klappt auch nach 3x probieren nicht. Der Arduino zeigt mir, dass der TPUart das vom Arduino gesendete Antwort-Telegram offenbar nicht annimmt.
Wenn ich jetzt noch wüsste warum?!

[lio123]

"Monologe sind doch was tolles ;-)"

oute mich mal als stiller Mitleser-auch wenn ich nicht alles verstehe, klingt das sehr interessant und es kommt anscheinend etwas ganz Brauchbares dabei raus!

Weiter so - ich melde mich wieder, wenn ich wissen möchte was man damit alles machen könnte


Grüße,
Lio

[tuxedo]

Hab heute weiter am Backend geschraubt: Grund:

read/write mem alleine reicht nicht. Es wäre ja nicht verkehrt zu wissen (und zwar bevor man seinen Arduino mit dem Tool programmiert), ob Hardware/Firmware auch zur Konfiguration passen.
Also bin ich dabei die eine oder andere Property fest (aber einstellbar) einzubauen.

Dabei bin ich - wie sollte es auch ander sein - wieder auf einen hässlichen Bug gestoßen:

Telegramme wie "PropertyvalueRead" die vom PC an den Arduino gehen, müssen mit einem "T_ACK" quittiert werden.
Die Anfrage vom PC enthält eine Sequenz-Nummer. Und die T_ACK Nachricht muss die gleiche inne haben.

Folgendes Testszenario spiele ich gerade durch:

1) Verbinden
2) Eine beliebige Property abfragen
3) Trennen
4) Verbinden
5) Speicher schreiben
6) Speicher lesen
7) Trennen

Probleme macht Punkt 6...

In diesem verbindungsteil sind zwei Aktionen. Und Punkt 6 ist die zweite Aktion. Demnach hat sich hier die Seqzenz-Nr. von 0 auf 1 inkrementiert.
Die T_ACK Nachricht sollte also die SeqNr 1 haben.

Aber im Busmonitor sehe ich das hier:

Bildschirmfoto - 23.06.2015 - 16:23:53.png


Eintrag Nr. 15 zeigt das Problem: Es wird ein T_ACK mit SeqNr 0 gesendet. Und auch nicht nur 1x, sondern 2x, gefolgt von einem eigentlich richtigen T_ACK mit SeqNr. 1 ..

Ich debugge seit Stunden. Immerhin bin ich jetzt auf dem Pfad dass Calimero wohl nicht die Fehlerquelle ist, sondern der Arduino.
Zur Ablenkung zwischendurch hab ich mal ein "besseres" Logo gebastelt:

KARDUINO-Logo.png

Hab mich etwas vom KNX Logo und dem Arduino-Logo bzw. dessen Schriftzug inspirieren lassen. Hoffe das ist "weit genug" von "Verwechslungsgefahr mit KNX und Arduino" entfernt. Sieht ja auch etwas "krakelig" aus. Aber das ist absicht. Ist ja auch ein Bastelprojekt. Gebastelte Schaltung -> Gebasteltes Logo ;-)

Gegenvorschläge?



[update]

Monologe sind doch was tolles ;-)

Gelöst hab ich das Problem noch nicht. Aber ich habe eine der Ursachen gefunden:

Wenn der TPUart dem Arduino ein Telegramm schickt, dann muss der Arduino binnen 1,7 Millisekunden antworten und sagen ob das Telegramm für ihn bestimmt ist oder nicht.

Wenn man vor diesem ACK Debug-Ausgaben etc. hat, dann kostet das u.U. zu viel zeit und das ACK kommt nicht rechtzeitig am TPUart an.
Man man man. Entweder bin ich so "Groß-PC" verwöhnt, oder ich muss jetzt tatsächlich um Millisekunden feilschen.

Bin nun leider an einer Stelle angelangt wo ich ohne Änderung am Code, rein durch mehrfaches ausführen, zu einem unterschiedlichen Ergebnis komme. Das macht die Analyse leider nicht einfach.