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