Konnekting und Multithreading

[wolfib]

Hallo!

ich bin gerade dabei mein erstes Konnekting Projekt umzusetzen, eine ausgezeichnete Arbeit habt ihr da geleistet!
Bei meinem Projekt geht es um ein RFID Zutrittsystem mit KNX Anbindung. Verwendet wird ein Teensy 3.2 Board (72MHz Cortex M4) und eine MicroBCU. Ich habe mit geringen Anpassungen einen ersten Test zum Laufen gebracht, mit Empfang einer GA kann eine LED ein- und ausgeschaltet werden.
Damit sich das Zutrittsystem und die KNX Anbindung nicht in die Quere kommen habe ich versucht Multithreading zu implementieren, dafür gibt es eine fertige Bibliothek (https://github.com/ftrias/TeensyThreads).

Implementiert habe ich das dann folgendermaßen:

void setup()
{
   ...
   threads.addThread(loop_konnekting);
}

void loop()
{
   //Nothing to do as all handled in seperate Threads
}

void loop_konnekting()
{
   while(1) {
      Knx.task();
      if (Konnekting.isReadyForApplication()) {
         // do device related stuff
      }
   }
}

Grundsätzlich läuft Konnekting auch im Thread aber ca. jedes dritte ankommende Telegramm wird nicht verarbeitet/erkannt. Außerdem zeigt die Debug Ausgabe immer wieder Fehler die ich nicht deuten kann:

Rx: unexpected TPUART_DATA_CONFIRM_FAILED received!

Wie gesagt, die Probleme treten nur auf wenn die task Methode im Thread läuft.
Gibt es Erfahrunge mit Threads? Was könnte die Ursache sein?

Danke, LG Wolfgang

[Albatros62]

Hallo Wolfgang,
ich kenne mich mit Multithreading nicht aus, vermute aber, das der Knx.task nicht oft genug aufgerufen wird. Hier ein Zitat aus dem Wiki:"WARNING: this function shall be called periodically (400us max period)". Ist das gewährleistet?

Gruß
Frank

[SirSydom]

Genau das ist der Knackpunkt. Die Meldungen

Rx: unexpected TPUART_DATA_CONFIRM_FAILED received!

kommen dann, wenn eben nicht schnell genug reagiert wird.

[wolfib]

Ok danke für die Info, ich sehe mir das an.
Warum wurden die zeitkritischen Dinge der Konnekting Bibliothek eigentlich nicht in Interruptroutinen angehandelt? Gibts dafür technische Gründe?

LG Wolfgang

[Eugenius]

Sagen wir mal so, es ist schon per interrupt getrieben, nur nicht perfekt.
UART Buffer wird per interrupt gefüllt.
Seit beta 4b, kann man aus dem buffer mehrere Telegramm auslesen und verarbeiten. Bis beta 4b ging es wirklich nur mit timing und es war nicht toll.

Man könnte noch weiter treiben und komplett auf interrupts umstellen, dann müsste man die Liste komplett umschreiben. Lohnt sich nicht.

Jetzt zu deinem Problem:
Fast alle Multithreading Libs arbeiten mit Interrupts. Aber unser Knx Task kann/mag es nicht. Besonders nicht, wenn sich "multithreading" interrupts und UART interrupts sich gegenseitig in die Quere kommen... ups, aber genau das wolltest du ja vermeiden
Und noch mehr besonders, wenn eine Funktion, die sehr lange dauert, in einem interrupt steckt, der eigentlich ganz kurz sein soll.

Meine Empfehlung: bei den meisten Arduino Sachen, braucht man dieses angebliche multithreading nicht. Bringt nur extra Probleme. Man darf auf keinem Fall delay() nutzen, es geht auch andere Möglichkeiten zu warten

Poste doch dein Sketch bzw. Erkläre wo dein Problem genau ligt, dass du auf Multithreading gehen willst.

[wolfib]

Vielen Dank für die ausführliche Erklärung!
Wie oben geschrieben bin ich dabei ein Zutrittsystem mit KNX Anbindung umzusetzen. Das Zutrittsystem (Basis) beinhaltet RFID Kartenleser mit Userverwaltung und eine Motorschlosssteuerung.
Die Kartenkommunikation ist augrund der Verschlüsselung sehr Ressourcenhungrig. Eine Abfrage des Kartenlesers benötigt ~200ms, und wenn tatsächlich eine Karte gelesen wird dauert eine Abfrage ~1900ms. Wenn gerade eine Karte gelesen wird dann gibt es ein Problem mit der Konnekting Bibliothek, das kommt zwar nicht oft vor aber ist trotzdem unschön.
Ich hatte gehofft das Multithreading eine einfache und schnelle Lösung dafür ist, ist es aber leider nicht.
Eine Möglichkeit wäre die Konnekting Bibliothek umzuschreiben, mal sehen ob ich dafür Zeit und Motivation finde...

LG Wolfgang

[SirSydom]

Eine einfache und schnelle Lösung wäre, für Konnekting einen eigenen µC zu spendieren.
Du gehst ja nicht in Serie wo es auf Stückkosten ankommt. Für 15€ ein ItsyBitsy für Konnekting rein und ein einfaches serielles Protokoll und du musst dir keine Gedanken mehr machen.

Alternativ kannst du natürlich Wochen investieren und die Konnekting-Lib Multithreading-fähig machen

[Albatros62]

Es geht sogar noch günstiger. Ein nackter 328P für unter 2€ würde bei einer I2C-Verbindung reichen. Würde ja nur die Kommunikation erledigen müssen.

[SirSydom]

Es geht sogar noch günstiger. Ein nackter 328P für unter 2€ würde bei einer I2C-Verbindung reichen.

das wird knapp. Die Beta5 Test-Sketches sprengen derzeit schon den 32u4 und den 328p fast (ohne Debug). Auf das Pferd würde ich nicht mehr setzen.
Dann doch eher ein SAMD21 Mini.

[Albatros62]

Ich meine mal gelesen zu haben, dass man die Bibliothek auch so einstellen kann, dass sie nur mit den Minimalfunktionen läuft und solche zusätzlichen Sachen wie Update über den Bus etc. dann deaktiviert sind. Für einen einfachen Konverter benötigt man das ja nicht.

[Eugenius]

Ich meine mal gelesen zu haben, dass man die Bibliothek auch so einstellen kann, dass sie nur mit den Minimalfunktionen läuft und solche zusätzlichen Sachen wie Update über den Bus etc. dann deaktiviert sind. Für einen einfachen Konverter benötigt man das ja nicht.

so war der Plan... wir sind noch an fein justrieren und testen.
Aber ich würde auch in dem Fall auf auf 2x MCUs setzen und mit einander über irgendeinen Protokoll reden.
ein CPU erledigt nur KNX Teil, der andere nur Zutritt.

[Tauri]

Wie klein doch die Welt ist. Ich habe am Wochende auch mit quasi dem gleichen Projekt angefangen und mich gefreut, dass jemand auf der Homepage des "Original" RFID Projektes gepostet hat, dass es auch einen kompakteren Kartenleser gibt, der funktioniert. Danke wolfib! Der sollte dann auch eher in Standardgehäuse von Türsprechanlagen o.ä. passen.

Bisher sind meine Bestellungen noch nicht eingetroffen, aber zur Sicherheit habe ich auch schon mal zwei ItsyBitsy geordert. Leider habe ich bis jetzt keine Erfahrungen mit Arduino im Allgemeinen oder Konnekting gemacht, dafür allerdings in Python und mit Raspberrys und hoffe dies in diesem Kontext anwenden zu können.

Ich bin also sehr gespannt wie es hier weiter geht und versuche gerne mein Wissen und meine Erfahrungen hier einzubringen.

VG Tauri

[wolfib]

Hallo,
danke für den Input, mal sehen wie sich das Projekt entwickelt, derzeit ist noch alles offen.
@Tauri: bitte

Ich hätte noch eine Frage: ich würde gerne ein REG Gerät bauen wie Modularis+. Gibts irgendwo eine Eagle „Vorlage“ für das REG Gehäuse? Würde einiges an Arbeit ersparen.

Vielen Dank, LG

[Tauri]

Nachdem jetzt alle Teile angekommen sind, habe ich heute mal angefangen den ersten ItsyBitsy und das RFID Modul auf einem Breadboard aufzubauen. Nach ein paar wenigen Stunden lief dann auch alles.

Mit den EV2 Karten komme ich auf ungefähr 7 cm Lesedistanz, also etwas weniger als wolfib, aber es könnte durch die Jumperkabel vielleicht Interferenzen geben. Zusätzlichen habe ich noch einen EV2 Schlüsselanhänger und ein EV2 Armband. Diese kommen auf ca. 4,5 cm.

Zwei Sachen über die ich (wahrscheinlich weil Arduinoanfänger und ich die Dokumentationen nur überfolgen habe ) gestolpert bin und vielleicht anderen Anfängern helfen könnte:

1. Der Code verwendet die Funktion "strnicmp" und "stricmp". Manche Boards definieren diese schon selbst, der ItsyBitsy aber nicht. Deswegen gibt es diese Funktion auch schon in "Utils.ccp", müssen aber im Hauptcode darauf angepasst werden.
2. Der ItsyBitsy hat keinen EEPROM aber dafür Flashspeicher. Über die FlashStorage library und die EEPROM Emulation kann man auch den Flashspeicher als Ersatz verwenden. Dazu muss man aber noch "EEPROM.commit()" in die beiden Funktionen einbauen, welche die Userdaten speichern (aufpassen, dass man es nicht in die Schleife setzt, sondern nur am Ende!)
3. Beim Hochladen des Sketches wird der Flashspeicher komplett mit Nullen überschrieben. Also muss man immer erst in der seriellen Konsole "clear" eingeben und dann die Karten neu einlernen.

Das neue Einlernen ist aber eigentlich unnötig, da im Speicher nur die UID der Karte, der Benutzername und eine Flag speichert wird. Zumindest wenn ich es richtig verstanden habe. Also würde es auch reichen, dies nach einem Update in den Flash zu schreiben. Da muss ich mir mal anschauen, wie man was man da machen kann.

Meine bisherigen Überlegungen dazu sind, dass man direkt über das Terminal alle Karten anlernt, die man so brauchen könnte und dann über ein KNX Telegramm "nur" noch anhand des Namens die neu Flag setzt. Damit erkennt der Leser die Karte als autorisiert, aber wenn man die Flag auf Null setzt, öffnet sich keine Tür. Damit könnte man dann über die Visualisierung o.ä. die Karte steuern und würde wahrscheinlich eine Karte nur über die Konsole aus dem Speicher komplett entfernen, wenn sie abhanden gekommen ist.

Einer der nächsten Schritte für mich wäre jetzt den zweiten ItsyBitsy mit an das KNX zu hängen. Dazu erst mal folgende Frage:
Es steht ja überall, dass man den 5WG1117-2AB12 BCU nehmen solle. Jetzt gibt es hier im Forum einmal die MicroBCU von Eugenius und die Micro-BCU (lite) von SirSydom. Welchen sollte man denn nun nehmen, bzw. wo liegen die Vor- oder Nachteile?

VG Tauri

[Albatros62]

Die Siemens-BCU arbeitet mit 5V-Pegeln, die MicroBCU wie auch die Micro-BCU lite arbeiten mit 3,3V und stellen auch eine entsprechende Spannung zur Versorgung der Anwendung zur Verfügung. Hängt also von dem Prozessor ab. Über Pegelwandler funktionieren Alle an Allen.