Hallo zusammen,
Ich habe mich mal damit beschäftigt einen Tastsensor zu entwickeln. Da das TAS-UP1-Touch-BE Projekt von IngDom schon relativ lange kein Update mehr gesehen hat muss/darf ich hier wohl neu anfangen
Die Hardware für das Projekt habe ich soweit schon mal grundlegend entworfen:
Der Touch Controller soll ein CAP1188 von Microchip werden. Es werden 4 Touch Flächen (zwei Wippen oder 4 Taster). Wenn die Hardware mitspielt soll es auch eine Näherungsdetektion geben.
Der CAP1188 hat IO-Ausgänge welche nach Parametrierung des Sensors bei Touch Detektion ein 3.3V Signal ausgeben. Er ist damit eher ein analoges Frontend das zwischen den Touch-Elektroden und dem RP2040 sitzt. Für den RP2040 sieht das im laufenden Betrieb aus wie normale Taster-Buttons
LED's werden über WS2811 angesteuert. (Die WS2811 im vergleich zu den WS2812B haben den Vorteil, dass LED's nicht integriert sind. Das erlaubt die WS2811 im Prinzip als programmierbare Stromsenken zu benutzen. Das nutze ich um die angeschlossenen LED's dunkler zu fahren, da sonst bei dwenig helligkeit die Farbauflösung massiv abnimmt -> Stichwort Nachtlicht.
Die ganze Hardware ist wie beim TAS-UP1-Touch-BE auf zwei PCB's aufgeteilt. Ein PCB macht nur den Touch-Part, das Zweite übernimmt die Kommunikation mit dem KNX-Bus und die Spannungsversorgung. Die Pinbelegung habe ich mir von hier https://github.com/OpenKNX/OpenKNX/w...S-UP1-Touch-BE genommen, da sich da ja IngDom anscheinend schon mal Gedanken gemacht hat.
Eine Herausforderung beim Kapazitiven messen ist in diesem Anwendungsfall, dass man das schwarze KNX-GND Kabel nicht als GND verwenden kann.
Dieser KNX-GND ist nämlich Verdrosselt und stört damit das kapazitive Sensing. Bei Buskommunikation ändert KNX-GND über die Zeit sein Potential Ich werde hierzu die Gelb/Weiße unverdrosselte Klemme verwenden müssen, da hier über den weißen Draht ein stabiler(er) GND bereitgestellt wird. Die KNX-Kommunikation muss dann optisch entkoppelt sein. Sollte auch die Gelb/Weiße klemme nicht stabil genug sein kann es eventuell sogar nötig sein eine PE-Verbindung herzustellen (aber das hoffe ich definitiv nicht)
Ich habe mich hierzu schon einige Stunden in die Software eingewühlt, musste allerdings feststellen, dass ich ohne Hilfe wohl nicht weiter komme...
Folgenden "Schlachtplan" habe ich mir für die Software ausgedacht:
Schritt 1:
- Die Firmware für den SEN-UP1-8xTH drauf flashen.
- Vor jeglicher KNX-Setup (in der Setup()-routine im main.c-file) Routine den CAP1188 per I2C parametrieren, danach den KNX-Stack und alles was kommt "einfach machen lassen"
- Die Ansteuerung der einzelnen WS2811 LED's in der main.c --> loop() nach openknx.loop() laufen lassen. Kann sein, dass es funktioniert, kann auch nicht funktionieren.
- Die Firmware muss dann über die ETS natürlich auf die Hardware parametriert werden.
Schritt 2:
- den CAP1188 als neuen Sensor in das OFM-THPSensorModule einbinden. Edit: Nope, ein egenes Lokales Hardware modul basteln
Hier kommt dann auch schon das erste große Hindernis, da ich hier die XML-Dateien für den KNX-Producer ändern muss. Und ich aus dem ganzen XML-Kram einfach nicht schlau werde.
- den neuen CAP1188 dann als nicht parametrierbaren Sensor an die fest verdahteten I2C Leitungen einprogrammieren, sowie die 4 (bzw. 5 mit Näherungsdetektion) Taster auf "ist fest an diesem pin" verdrahten
Schritt 3:
- die WS2811 (Softwaretechnisch werden die genauso angesteuert wie die gängigen WS2812B) irgendwie als Modul einbinden, wobei ich noch keine Ahnung habe wie hier das beste vorgehen ist.
Schritt 4:
- Alles über die ETS Parametrierbar machen, also Farbein der LED's, Helligkeiten, eventuell so Sachen wie Sampling-Time oder Sensitivity des CAP1188 parametrierbar machen. Dafür muss ich noch mehr Hardware-Versuche machen um herauszufinden welche Stellschrauben der CAP1188 braucht um in der Praxis zuverlässig zu funktionieren
Anregungen/Stolpersteine zu den Schritten welche ihr sofort seht?
Anregungen wie man die Umsetzung der einzelnen Schritte angehen würde?
Ein paar weitere Fragen:
Durch welche Doku sollte ich mich noch durchwühlen? Ich habe mir schon das GitHub Wiki zu Gemüte geführt, habe mich schon mit jemanden der noch mehr von C/C++ versteht durch den Code gegraben.
Welche Toolchain nehmt ihr her für die Änderung der XML-Dateien? Wird das wirklich per Hand editiert? Der OpenKNXproducer ist ja auch "nur" ein Hilfstool welches die XML's checkt und in eine knxprod umwandelt. (Soweit ich das richtig verstanden habe😅)
Was macht die knxprod.h? Ich verstehe, dass hier die Information liegen muss, welche parameter welche "id" haben, aber wie wird im programmcode drauf zugegriffen? Die defines die ich hier finde, findet man die in den XML-Dateien wieder? Kann ich die defines einfach im programmcode verwenden und die Software im Hintergrund kümmert sich automatisch um das laden und speichern in den flash? Wenn ich einen parameter aus diesem .h File in den XML's suche, dann finde ich diesen Bezeichner nirgends.
Also generell bin ich noch etwas aufgeschmissen wie der Code die Identifier mit der knxprod "verknüpft"
Was ist eine BAU/Bus Access Unit und was sind die unterschiedlichen Ausführungen dahinter (zum Beispiel "Bau07B0")? Muss ich mir dazu überhaupt Gedanken machen?
Ein kleines bisschen Erklärung zu mir noch:
Ich bin hauptsächlich Hardwareentwickler für alles was irgendwie Analog- und Digitalhardware ist. Mit C/C++ kenne ich mich eigentlich ganz gut aus, allerdings bin ich hier definitiv kein Profi der im "täglichen Gebrauch" programmiert.
Aufgrund von, sagen wir mal "übermäßigen Enthusiasmus", ist mir in der Arbeit das Aufbauen und Betreuen der kompletten KNX-Haussteuerung zugefallen (~350 KNX Geräte mit allem was ein moderner Neubau halt so hat)
Dieses Taster-Projekt ist allerdings ein rein privates Projekt für meine Haussteuerung zuhause.
Anbei noch Bilder von meinem Hardware Konzept (noch nicht fertig)
image.pngimage.png
Das schematic vom Touch-Board hänge ich ebenfalls mal an, am Interface-Board mit dem RP2040 arbeite ich grade noch.
So, viel geschrieben ich bin generell immer noch viel verwirrt. Mal sehen was bei rum kommt
Danke schon mal.
- cad435
Ich habe mich mal damit beschäftigt einen Tastsensor zu entwickeln. Da das TAS-UP1-Touch-BE Projekt von IngDom schon relativ lange kein Update mehr gesehen hat muss/darf ich hier wohl neu anfangen
Die Hardware für das Projekt habe ich soweit schon mal grundlegend entworfen:
Der Touch Controller soll ein CAP1188 von Microchip werden. Es werden 4 Touch Flächen (zwei Wippen oder 4 Taster). Wenn die Hardware mitspielt soll es auch eine Näherungsdetektion geben.
Der CAP1188 hat IO-Ausgänge welche nach Parametrierung des Sensors bei Touch Detektion ein 3.3V Signal ausgeben. Er ist damit eher ein analoges Frontend das zwischen den Touch-Elektroden und dem RP2040 sitzt. Für den RP2040 sieht das im laufenden Betrieb aus wie normale Taster-Buttons
LED's werden über WS2811 angesteuert. (Die WS2811 im vergleich zu den WS2812B haben den Vorteil, dass LED's nicht integriert sind. Das erlaubt die WS2811 im Prinzip als programmierbare Stromsenken zu benutzen. Das nutze ich um die angeschlossenen LED's dunkler zu fahren, da sonst bei dwenig helligkeit die Farbauflösung massiv abnimmt -> Stichwort Nachtlicht.
Die ganze Hardware ist wie beim TAS-UP1-Touch-BE auf zwei PCB's aufgeteilt. Ein PCB macht nur den Touch-Part, das Zweite übernimmt die Kommunikation mit dem KNX-Bus und die Spannungsversorgung. Die Pinbelegung habe ich mir von hier https://github.com/OpenKNX/OpenKNX/w...S-UP1-Touch-BE genommen, da sich da ja IngDom anscheinend schon mal Gedanken gemacht hat.
Eine Herausforderung beim Kapazitiven messen ist in diesem Anwendungsfall, dass man das schwarze KNX-GND Kabel nicht als GND verwenden kann.
Dieser KNX-GND ist nämlich Verdrosselt und stört damit das kapazitive Sensing. Bei Buskommunikation ändert KNX-GND über die Zeit sein Potential Ich werde hierzu die Gelb/Weiße unverdrosselte Klemme verwenden müssen, da hier über den weißen Draht ein stabiler(er) GND bereitgestellt wird. Die KNX-Kommunikation muss dann optisch entkoppelt sein. Sollte auch die Gelb/Weiße klemme nicht stabil genug sein kann es eventuell sogar nötig sein eine PE-Verbindung herzustellen (aber das hoffe ich definitiv nicht)
Ich habe mich hierzu schon einige Stunden in die Software eingewühlt, musste allerdings feststellen, dass ich ohne Hilfe wohl nicht weiter komme...
Folgenden "Schlachtplan" habe ich mir für die Software ausgedacht:
Schritt 1:
- Die Firmware für den SEN-UP1-8xTH drauf flashen.
- Vor jeglicher KNX-Setup (in der Setup()-routine im main.c-file) Routine den CAP1188 per I2C parametrieren, danach den KNX-Stack und alles was kommt "einfach machen lassen"
- Die Ansteuerung der einzelnen WS2811 LED's in der main.c --> loop() nach openknx.loop() laufen lassen. Kann sein, dass es funktioniert, kann auch nicht funktionieren.
- Die Firmware muss dann über die ETS natürlich auf die Hardware parametriert werden.
Schritt 2:
- den CAP1188 als neuen Sensor in das OFM-THPSensorModule einbinden. Edit: Nope, ein egenes Lokales Hardware modul basteln
Hier kommt dann auch schon das erste große Hindernis, da ich hier die XML-Dateien für den KNX-Producer ändern muss. Und ich aus dem ganzen XML-Kram einfach nicht schlau werde.
- den neuen CAP1188 dann als nicht parametrierbaren Sensor an die fest verdahteten I2C Leitungen einprogrammieren, sowie die 4 (bzw. 5 mit Näherungsdetektion) Taster auf "ist fest an diesem pin" verdrahten
Schritt 3:
- die WS2811 (Softwaretechnisch werden die genauso angesteuert wie die gängigen WS2812B) irgendwie als Modul einbinden, wobei ich noch keine Ahnung habe wie hier das beste vorgehen ist.
Schritt 4:
- Alles über die ETS Parametrierbar machen, also Farbein der LED's, Helligkeiten, eventuell so Sachen wie Sampling-Time oder Sensitivity des CAP1188 parametrierbar machen. Dafür muss ich noch mehr Hardware-Versuche machen um herauszufinden welche Stellschrauben der CAP1188 braucht um in der Praxis zuverlässig zu funktionieren
Anregungen/Stolpersteine zu den Schritten welche ihr sofort seht?
Anregungen wie man die Umsetzung der einzelnen Schritte angehen würde?
Ein paar weitere Fragen:
Durch welche Doku sollte ich mich noch durchwühlen? Ich habe mir schon das GitHub Wiki zu Gemüte geführt, habe mich schon mit jemanden der noch mehr von C/C++ versteht durch den Code gegraben.
Welche Toolchain nehmt ihr her für die Änderung der XML-Dateien? Wird das wirklich per Hand editiert? Der OpenKNXproducer ist ja auch "nur" ein Hilfstool welches die XML's checkt und in eine knxprod umwandelt. (Soweit ich das richtig verstanden habe😅)
Was macht die knxprod.h? Ich verstehe, dass hier die Information liegen muss, welche parameter welche "id" haben, aber wie wird im programmcode drauf zugegriffen? Die defines die ich hier finde, findet man die in den XML-Dateien wieder? Kann ich die defines einfach im programmcode verwenden und die Software im Hintergrund kümmert sich automatisch um das laden und speichern in den flash? Wenn ich einen parameter aus diesem .h File in den XML's suche, dann finde ich diesen Bezeichner nirgends.
Also generell bin ich noch etwas aufgeschmissen wie der Code die Identifier mit der knxprod "verknüpft"
Was ist eine BAU/Bus Access Unit und was sind die unterschiedlichen Ausführungen dahinter (zum Beispiel "Bau07B0")? Muss ich mir dazu überhaupt Gedanken machen?
Ein kleines bisschen Erklärung zu mir noch:
Ich bin hauptsächlich Hardwareentwickler für alles was irgendwie Analog- und Digitalhardware ist. Mit C/C++ kenne ich mich eigentlich ganz gut aus, allerdings bin ich hier definitiv kein Profi der im "täglichen Gebrauch" programmiert.
Aufgrund von, sagen wir mal "übermäßigen Enthusiasmus", ist mir in der Arbeit das Aufbauen und Betreuen der kompletten KNX-Haussteuerung zugefallen (~350 KNX Geräte mit allem was ein moderner Neubau halt so hat)
Dieses Taster-Projekt ist allerdings ein rein privates Projekt für meine Haussteuerung zuhause.
Anbei noch Bilder von meinem Hardware Konzept (noch nicht fertig)
image.pngimage.png
Das schematic vom Touch-Board hänge ich ebenfalls mal an, am Interface-Board mit dem RP2040 arbeite ich grade noch.
So, viel geschrieben ich bin generell immer noch viel verwirrt. Mal sehen was bei rum kommt
Danke schon mal.
- cad435
.
Kommentar