KNX mit RP2040 / Pi Pico

[jeff25]

DIe Idee einer neuen Dunstabzugshauben steuerung hatte ich auch, ich hatte die Idee alles per KNX zu steuern aber auch die normalen taster anzuschliessen diese bedienung dann aber auch als status auf den knx zu senden.

[Albatros62]

Das schreit nach einem neuen Thread

[Ing-Dom]

Das schreit nach einem neuen Thread

https://knx-user-forum.de/forum/%C3%...aubensteuerung

Kann man das Gehäuse, dass du benutzt, eigentlich irgendwo kaufen? Ich kann mich dunkel erinnern, dass es aus einem 3D-Drucker stammt, ich vermute aber nicht aus deinem. Oder nimmst du es evtl. in den Makerstuff auf?

DAS Gehäuse gibts nicht, das ist für jedes KUPS Gerät eine spezifische Anpassung. Ja, es ist aus meinem 3D-Drucker. Konstruiert hat es bigbear2nd

Der Plan ist das Gehäuse passend zu einem Gerät mit anzubieten, ja. Generisch ist schwierig, Man braucht ja Aussparungen für die Klemmen.
Und das STL, für die die selber Drucken möchten.

[odysee_2002]

Wo könnte man den Code finden, wie du eine Applikation auf den RP runterlädst?
Das würde ich gerne in den ESP8266 einbauen..😉

Du hast angedeutet, dass du Hilfe gebrauchen könntest, in welcher Form?
(Die Frage ist auch, ob man einem Profi noch groß helfen kann)

Hast du den RP bestücken lassen oder selbst gelötet?

Gruß

[Ing-Dom]

Wo könnte man den Code finden, wie du eine Applikation auf den RP runterlädst?
Das würde ich gerne in den ESP8266 einbauen..😉

auf meiner Festplatte Das hilft dir aber für den ESP gar nichts, das ist sehr hardwarenah und ganz spezifisch für den RP2040 gemacht.
Mal ein Ausschnitt:

void __no_inline_not_in_flash_func(flash_range_erase_an d_program)(uint32_t flash_offs, const uint8_t *data, size_t count) {
#ifdef PICO_FLASH_SIZE_BYTES
hard_assert(flash_offs + count <= PICO_FLASH_SIZE_BYTES);
#endif
invalid_params_if(FLASH, flash_offs & (FLASH_PAGE_SIZE - 1));
invalid_params_if(FLASH, count & (FLASH_PAGE_SIZE - 1));
void (*connect_internal_flash)(void) = (void(*)(void))myrom_func_lookup(myrom_table_code( 'I', 'F'));
void (*flash_exit_xip)(void) = (void(*)(void))myrom_func_lookup(myrom_table_code( 'E', 'X'));
void (*flash_range_program)(uint32_t, const uint8_t*, size_t) =
(void(*)(uint32_t, const uint8_t*, size_t))myrom_func_lookup(myrom_table_code('R', 'P'));
void (*flash_range_erase)(uint32_t, size_t, uint32_t, uint8_t) =
(void(*)(uint32_t, size_t, uint32_t, uint8_t))myrom_func_lookup(myrom_table_code('R', 'E'));
void (*flash_flush_cache)(void) = (void(*)(void))myrom_func_lookup(myrom_table_code( 'F', 'C'));
assert(connect_internal_flash && flash_exit_xip && flash_range_erase && flash_range_program && flash_flush_cache);
flash_init_boot2_copyout();

__mycompiler_memory_barrier();

connect_internal_flash();
flash_exit_xip();
flash_range_erase(flash_offs, count, FLASH_BLOCK_SIZE, FLASH_BLOCK_ERASE_CMD);
flash_range_program(flash_offs, data, count);
flash_flush_cache(); // Note this is needed to remove CSn IO force as well as cache flushing
flash_enable_xip_via_boot2();
}

Ich werde irgendwann wenn der SNS-8xTH an den Start geht die FW dazu veröffentlichen, aktuell ist das noch in keiner Form zum veröffentlichen.

Hast du den RP bestücken lassen oder selbst gelötet?

NATÜRLICH bestücken lassen! Bei den Preisen vom JLCPCB tu ich mir doch kein QFN mit 0.4er Pitch an...

Du hast angedeutet, dass du Hilfe gebrauchen könntest, in welcher Form?
(Die Frage ist auch, ob man einem Profi noch groß helfen kann)

Was heißt Hilfe, es würde mich freuen wenn man Synergien nutzen kann.
Sei es der RP2040 als gemeinsame Basis um sich auszutauschen oder noch 3 Schritt weiter und z.B. eine eigene Applikation auf Basis der KUPS Controllerplatine.
Oder z.B. zusätzliche Sensoren für den SNS-8xTH...

Ich mache mir jetzt aber nichts vor, die meisten wollen entweder nur nachbauen oder machen gleich was ganz anders - weil man sich auf ganz grundlegende Dinge nicht einigen kann. Und das ist auch ok, ist bei mir nicht anders. Ich mach das ja weils mir Spaß macht, da will ich keine großen Kompromisse eingehen.

[Ing-Dom]

so ganz grundsätzlich läuft der Firmware-Update über KNX TP1 nun.
Realisiert mit Kaenx.Konnekt und ExtendedMemoryWrite und thelsin/knx Stack.

Was mir noch gar nicht gefällt ist die Geschwindigkeit.
Für ein 64Byte großes Paket + Response brauche ich ca. 1s.
Die RP2040 FW ist aber schon als "blinky" ca. 64k groß, mit knx stack, etwas Applikation und Update sind es dann 128k.

Das macht dann Upload-Zeiten von 30min...

Kann natürlich für unzugänglich eingebaute Geräte trotzdem eine Option sein.
Bei mir kommt dazu, dass bei hoher Buslast nach 2min die Gira-Ruchmelder anfangen zu piepsen blödes Gira-Gelumpe.

[thewhobox]

Ing-Dom Kenn mich mit dem RP2040 nicht aus, aber was mir so spontan einfällt:
- Verify Mode deaktivieren und erst am Schluss alles über CRC oder so überprüfen
- Ist der Anfang der FW vll immer gleich? (evtl vorher per Property einstellen ob komplette FW oder erst ab nem bestimmten Offset)
- Sind viele 0x00 oder 0xFF drin, die man vll überspringen könnte?
- MemoryExtWrite ünterstüzt bis 255 Bytes, was ist bei dir die Limitierende größe?

[Ing-Dom]

- Verify Mode deaktivieren und erst am Schluss alles über CRC oder so überprüfen

hab ich mal gemessen, das bringt ca. 20% mehr Speed (64k). Bei größeren Paketen eher weniger.
Nachteil wenn man die CRC erst am Ende prüft: man muss von vorne beginnen.
Aktuell ist ein neues Paket (Memory-Adresse entsprechend inkrementiert) vom PC auch das Zeichen dafür, dass die letzte zurückgemeldete CRC korrekt war. Wenn nicht, wird das Paket wiederholt.

- Ist der Anfang der FW vll immer gleich? (evtl vorher per Property einstellen ob komplette FW oder erst ab nem bestimmten Offset)

nein leider nicht. ggf sind da gleichteile drin, aber dann nicht an gleicher Stelle. Die zu erkennen und das zu behandeln würde sehr aufwändig.

- Sind viele 0x00 oder 0xFF drin, die man vll überspringen könnte?

nein

- MemoryExtWrite ünterstüzt bis 255 Bytes, was ist bei dir die Limitierende größe?

Es macht den Algoryhtmus deutlich einfacher wenn die Paketgröße ein restloser Teiler des Pagesize (256byte) ist.
Mit 255 fehlt also 1 byte bei 128byte musste ich feststellen dass die Wahrscheinlichkeit dass ein Ack nicht kommt oder so ansteigt. Warum, muss ich mir noch anschauen.


Leider kann ich nur auf meinen Live-Bussystem testen weil ich nur da ein IP-Interface habe.
Auf dem Testnetz hab ich ein RasPi/knxd IP Interface, aber da erkennt das Modul die ExtMemWrite-Telegramme nicht (korrekt). Im Wireshark sehen sie gut aus, ich denke also da ist was faul am knxd (oder meinem Setup).
Smurf kann der knxd long frames? Oder gibts da bekannte Fehler?

[Sisamiwe]

Das macht dann Upload-Zeiten von 30min...

Enertex bietet auch die Möglichkeit eines Firmwareupdates über den Bus. Dazu gibt es ein entsprechendes Tool von Enertex. Das Update der Firmware meiner Powersupply mit einer Dateigröße von 233kB hat auch ca. 30min gedauert.

[STSC]

Leider musste ich feststellen das der arduino-pico core keine rx/tx buffer im ram hat, nur die 32 byte in hardware. Etwas wenig, vor allem wenn man an extended frames denkt.

Ist das eigentlich ein Problem? Ansonsten scheint der RP2040 gut für KNX geeignet zu sein.

[Ing-Dom]

nein, in der Realität ist das überhaupt kein Problem.

Kurze Rechnung: KNX braucht ca. 1,35ms pro Byte.
Mit 32Byte buffer reicht es (theoretisch) den buffer nur ca. alle 40ms zu leeren.
Das ist reichlich Zeit und für ACKs innerhalb der Spec muss man eh viel schneller sein.

Ansonsten scheint der RP2040 gut für KNX geeignet zu sein.

das finde ich auch!

[Ing-Dom]

Mittlerweile ist auch der Adafruit ItsyBitsy RP2040 ganz gut in DE erhältich:
https://eckstein-shop.de/Adafruit-It...EaAu40EALw_wcB

Damit könnte man alte Design die für den ItsyBitsy M0 ausgelegt waren realtiv einfach auf den RP2040 heben, ich denke da z.B. an meine REG-Dimmer


Und hier nochmal ein Link zu einem anderen Faden wo es auch um den RP2040 ging:
https://knx-user-forum.de/forum/%C3%...pi-pico-rp2040

[Ing-Dom]

Ich bin gerade auf der Suche nach einer passenden Plattform für Unterputz-KNX-Sensoren und da passen deine Vorarbeiten wirklich super. Was spricht eigentlich dagegen,das Modul komplett ohne Gehäuse zu benutzen?
Mir schwebt ein Universalsensor mit Umgebungssensoren (Temperatur, Luftgüte), einem Lichtsensor (Menge und Farbe) sowie einem Radar/Kamera-Präsenzsensor vor. Nicht unbedingt alles auf einmal aber zumindest wäre die Option dafür wäre schön. Meinst du das gibt irgendwelche Probleme, z.B. Erwärmung, EMV. Ist klar irgend was ist immer, aber hast du da schon negative Erfahrungen gemacht?

Ohne Gehäuse? Kann man schon machen, ich bin kein Fan davon, ich hab das gerne aufgeräumt und ohne Staub und Dreck aus den UP-Dosen und ohne Kurzschlussgefahr wenn irgendwo ein blanker Draht rumgeistert. Von ESD mal ganz abgesehen.
Daher habe ich einen 3D-Drucker (kost ja nix mehr) und hab mich auch in CATIA reingefuchst..

Zum Rest kann ich wenig sagen, aber schau dir doch mal das Sensormodul von Masifi an, das klingt sehr nach dem was du machen willst.

[brainmine]

Ing-Dom
Hallo zusammen,
ich bin wirklich begeistert, welche Fortschritte das OpenKNX Projekt gemacht hat! Nochmasl meinen Respekt an allen Mitwirkenden.
ich habe mein erstes Board mit einem RP2040 bestellt und versuche es zum laufen zu kriegen (noch unter Arduino). Ich verwende den Thesinbg KNX Stack und die earlephilhower Bibliothek. Ich bin soweit, dass ich gültige Frames empfangen und Acknowledgen kann. Was aber nicht funktioniert, ist das Programmieren der Physikalischen Adresse. Die Programmierl Led geht an und über print erhalte ich die Meldung das der Prog Mode läuft. Aber ETS sendet ewig ein Broadcast read
Hat jemand eine Idee voran das liegen könnte?

[yawniek]

ähnliche Situation hier nur, dass ich versuche den ganze geschichte mit den Modulen aufzusetzen wie im WIKI beschrieben.
Ist aber härter als gedacht. Wäre cool wenns ein komplettes end2end tutorial gäbe das eine Toolchain mit modulen erstellt