KNX mit RP2040 / Pi Pico

[Ing-Dom]

Hallo zusammen!

Schon seit der RP2040 angekündigt wurde war ich mir sicher, dass dies eine MCU mit Potential für die DIY-Welt mit KNX ist.
Der SAMD21 ist jetzt nicht schlecht, aber:
Die Verfügbarkeit ist mau, der Preis ist hoch, JLCPCB bestückt ihn nicht. Dafür ist er im TQFP erhältlich. Leistung ausreichend, wobei man bei sehr großen Geräten mit vielen KOs schon ans Limit kommt - ich denke hier z.B. an die Firmware von mumpf auf dem Raum-Sensormodul von Masifi.

Der RP2040 ist sagenhaft günstig (1$) und das Pi Pico Board (4-5$) auch. Und ist in vielen Belangen einem SAMD21 Board überlegen. (Takt, Cores, RAM).
Arduino-Support gibt es auch bereits.
Nachteile: externer Flash notwendig, relativiert etwas den Preis. QFN mit 0.4er Pitch und Massepad ist nicht toll zum selbst löten, außer für Robert jeff25
Aber: JLCPCB hat ihn aktuell in der Lib und er ist verfügbar.

Ich bin mir auch sicher, dass sobald er breit verfügbar ist ähnlich günstige Boards ("china clones") geben wird wie man das von den avr arduinos gewohnt war.
In-Circuit Debugging ist auch sehr günstig mit einem zweitem Pi Pico (picoprobe) möglich.


Ich hab heute mal support für den pi pico in die Konnekting Beta4b lib gehackt - läuft. Der communication_test sketch läuft schon und sendet.
Als nächstes der Flash. und ausgiebig testen.


Perspektivisch müsste man mal ein Board designen und fertigen lassen beim JLCPCB (kost ja fast nix...).
Das günstige Pi Pico Board ist leider zu groß für viele Anwendungen, das kleinere ItsyBitsy RP2040 teuer und schlecht verfügbar.

Unterstützung für den RP2040 im Stack von thesing wäre auch super. Gerade der hat ja etwas höhere Anforderungen an Flash und Ram. Michaelkeil du wolltest das angehen hast du schon was gemacht?


Mitstreiter willkommen...

[Ing-Dom]

Sodala.

Eine Beta4c mit support für den RP2040 ist fertig:
https://gitlab.com/SirSydom/Konnekti.../-/tree/rp2040

Läuft mit Arduino IDE 1.8.8 und Pi Pico Unterstützing von earlephilhower (https://github.com/earlephilhower/arduino-pico).
Die offizielle Pi Pico Unterstützung von Arduino ist mit mit mbed zu fett... und der liebe Earl hat sein Ding viel besser dokumentiert als Arduino das gemacht hat!


Noch ein paar schöne "Goodies" die der RP2040 bietet:

Firmware-Update über Bus wäre kein Problem. Das sowieso externe Flash ist groß genug bzw. kann groß genug gewählt werden (bis 16MB).
Mann kann also ein neues Binary im Flash ablegen, dann einen Code im RAM starten der das Flash umkopiert und neu starten.
Kein Rumgefuckel mit dem Bootloader nötig.

Apropo Bootloader. Der RP2040 hat seinen Bootloader fest eingebrannt (on chip rom), der nimmt per uf2 binaries an.
Man kann also die uf2 binaries (die beim build vorgang erzeugt werden!) unkompliziert verteilen und jeder DAU kann diese auf einen Pico draufspielen.
D.h. der 0815 Anwender braucht keine IDE, keine Libs, kein GAR NIX.
Auch wenn man daran denkt bestückte Boards zu verkaufen - beim SAMD21 müsste man über SWD den BL laden.
Beim RP2040 ist der BL eingebrannt, man kann also das Board ohne Weiteres vom Bestücker weitergeben.

Für mich ist klar, wo die Reise hingeht.

Bei der Peripherie ist er etwas dünner aufgestellt als ein SAMD21. (kein DAC, nur 4 ADC, kein Touch).

[tuxedo]

Top. Dann will ich den bald auch Mal ausprobieren. Ich muss jetzt unbedingt Zeit finden beta5, was eigentlich zum testen soweit ist, fertig als Paket zu schnüren.

Dünnere Peripherie stört mich nicht. Bin eh ein Freund davon per i2c das fehlende nachzurüsten.

[jeff25]

HI,

danke für die Blumen, ja den Prozessor bekomm ich schon auf die PCB wenn du ein paar Prototypen braucht incl masse Pad :-)

Gurß
RObert

[MGK]

Könnte man dann den KNX Stack auf einem Core laufen lassen und das eigene Programm auf dem anderen? Das würde ja viele zeitkritische Dinge entschärfen…

[Ing-Dom]

Könnte man dann den KNX Stack auf einem Core laufen lassen und das eigene Programm auf dem anderen? Das würde ja viele zeitkritische Dinge entschärfen…

Man muss überlegen - woran liegen den die Timing-Probleme.

- knx.task muss alle 400µs gerufen werden, damit die ACKs auf dem Bus rechtzeitig (im Sinne der KNX Spec) rausgehen.
- Macht man jetzt was in seiner Loop, was länger dauert als 400µs, dann wird der Abstand zu groß. Meist wenn Peripherie im Spiel ist - z.B. den Bildschirminhalt am SPI-TFT neu schreiben.

An sich ist das also kein Problem der verfügbaren Rechenzeit, sondern der Aufteilung.
Das Problem liese mit einem Scheduler schon lösen.
Sobald man halt Tasks unterbricht kommt halt das Thema Synchronisation ins Spiel, und da wirds dann halt kompliziert(er).
Das ich mich Low-Level damit beschäftigt habe ist auch schon mehr als 10 Jahre her und war im Studium..


Also Fazit: ja, könnte man machen. Mit ähnlichem Aufwand, als mit einem Scheduler zu arbeiten, ohne echten Benefit. Denn der eine 120Mhz ARM Core langweilt sich schon. Insofern wäre es aus meiner Sicht sinnvoller die Lib um einen Scheduler zu erweitern, das würde dann auch Vorteile für den SAMD21, ESP etc.. bringen.

Oder man nimmt sich einen fertigen Scheduler, wie z.B. FreeRTOS. Ports für CortexM0 existieren...

FreeRTOS mit lwIP hab ich mal auf einem ARMv7 eingesetzt als Basis für ein KNXNet/IP Device.. vor 14 Jahren.. man..

bisserl was zum thema DualCore auf dem RP2040:
https://www.heise.de/developer/artik...C-6000386.html

[Ing-Dom]

in den thelsing/knx stack hab ich ebenfalls support eingebaut:
https://knx-user-forum.de/forum/%C3%...25#post1670089

[Ing-Dom]

Hier noch ein Codeschnipsel für Konnekting mit RP2040.
Der arduino-pico core inkludiert eine EEPROM Simulation.

#elif ARDUINO_RASPBERRY_PI_PICO //RP2040 / Pi Pico

#include <EEPROM.h>

byte readMemory(int index)
{
return EEPROM.read(index);
}
void writeMemory(int index, byte val)
{
EEPROM.write(index, val);
}
void updateMemory(int index, byte val)
{
writeMemory(index, val);
}
void commitMemory()
{
EEPROM.commit();
}

#endif

Masifi

[Ing-Dom]

JLCPCB hatte zwischenzeitlich die ersten 500 Stück durch, hat aber aktuell wieder eine Rolle bekommen.
Prototyp meines RP2040-Controller mit NanoBCU ist auf dem Weg. Bin gespannt.

Controller2040.png

Die Idee hinter dem Controller ist, dass er in die von den KUPS-Geräten schon gezeigten 42x42mm Gehäuse mit abgeschrägten Ecken für den UP-Einbau passt und entweder direkt auf einem PCB gefertigt & bestückt wird ODER dass die Applikationspatine getrennt hergestellt wird und dann über die PIN-Leiste verbunden wird.
Grund: Stückzahlen für den Controller, der komplett bestückt werden soll.

Zwischenzeitlich konnte ich an meinem Ansatz zum Firmware-Update arbeiten, war nicht trivial weil die sdk funktionen zum flash schreiben nicht geeignet waren und ich meine eigenen schreiben musste, aber nun funktioniert es => Ich lade ein UF2 über Serial hoch, speichere es im flash zwischen.
Dann kopiere ich es - über das aktuell laufene programm an den Anfang vom flash und starte neu - geht

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.

[Albatros62]

Ich muss sagen, je länger ich über KUPS nachdenke, desto besser finde ich die Idee, nicht nur für UP-Geräte. Wenn man alles, was nicht auf dem Bild zu sehen ist, abtrennt, dann hat man eine Controllerplatine für ein Hutschienen-Gerät. Oder man steckt die Platine für Tests und Experimente auf ein Steckbrett. Da die Anschlüsse, passend zur Form des Gehäuses, auf der Applikationsplatine untergebracht werden müssen, müsste der KNX-Eingang auch an der Steckleiste liegen. Auch für Prog-Taste und Prog-LED müsste man sich etwas ausdenken, da sich die Controllerplatine ja mitten in einem Hutschienengehäuse wiederfinden könnte.
Wie sieht es eigentlich mit dem USB-Anschluss aus? Gibt es vielleicht eine Anschlussleiste, an der man ein USB-Breadboard anschließen kann? Dann kann jeder, der USB nicht benötigt, ihn einfach weg lassen.

[Ing-Dom]

Wenn man alles, was nicht auf dem Bild zu sehen ist, abtrennt, dann hat man eine Controllerplatine für ein Hutschienen-Gerät.

Theoretisch ja. Aber dafür ist es nicht designed, und ein Design für beides würde aus meiner Sicht schmerzhafte Kompromisse bedeuten.

Oder man steckt die Platine für Tests und Experimente auf ein Steckbrett.

Die Header sind alle 1.27mm. Da bräuchte man einen Adapter, wäre aber kein großes Thema.

Da die Anschlüsse, passend zur Form des Gehäuses, auf der Applikationsplatine untergebracht werden müssen, müsste der KNX-Eingang auch an der Steckleiste liegen. Auch für Prog-Taste und Prog-LED müsste man sich etwas ausdenken, da sich die Controllerplatine ja mitten in einem Hutschienengehäuse wiederfinden könnte.

wie gesagt, das wäre aus meiner Sicht ein Fauler Kompromiss. Für Hutschiene würde ich eine separate Controllerplatine sehen.
Hab ich momentan nicht im Fokus.

Wie sieht es eigentlich mit dem USB-Anschluss aus? Gibt es vielleicht eine Anschlussleiste, an der man ein USB-Breadboard anschließen kann? Dann kann jeder, der USB nicht benötigt, ihn einfach weg lassen.

Die links zu sehenden Pinheader sind ein Anschluss für eine kleine Adapterplatine auf der Anschlüsse für USB, Reset-Button, BootSel Button, 3.3V LDO und SWD Interface beinhaltet. (siehe https://knx-user-forum.de/forum/%C3%...67#post1654867)
Auf dem PCB war dafür einfach nicht genug Platz, bzw. wollte ich den Platz dafür nicht opfern.
Für das erstmalige Bespielen mit Firmware würde es jeder Anwender brauchen, spätere Updates sollen über KNX möglich sein.
Da reden wir aber von 3-4€ für das PCB und die Bauteile und man braucht es ja nur 1x.

[Albatros62]

Theoretisch ja. Aber dafür ist es nicht designed, und ein Design für beides würde aus meiner Sicht schmerzhafte Kompromisse bedeuten.

Eigentlich müsste es nicht anders designed werden. Die Controllerplatine wird einfach senkrecht auf die Applikationsplatine montiert, parallel zur linken Seitenwand.

Die links zu sehenden Pinheader sind ein Anschluss für eine kleine Adapterplatine auf der Anschlüsse für USB, Reset-Button, BootSel Button, 3.3V LDO und SWD Interface beinhaltet.

Das hatte ich übersehen. Genau so hatte ich mir das vorgestellt.

Ich dachte dabei an die Stückzahlen. Wenn man eine Controllerplatine hat, die sowohl für Hutschienengehäuse als auch für UP-Dosen eingesetzt werden kann, kommt man auf größere Stückzahlen und entsprechend günstigere Preise. Für Anfänger wäre das Board sicher auch interessant. Fehler aufgrund von Wackelkontakten sind dann ausgeschlossen. Entlastet auch die Experten bei der Hilfestellung .

[Ing-Dom]

Meine Prototypen sind da. Und ich bin stolz wie Oskar, dass augenscheinlich alles wunderbar funktioniert Ein Schuss, ein Treffer.

Hier mal die Controllerplatine (hier unbestückt, der bestückte Prototyp mit seiner Applikation ist noch geheim) im Größenvergleich zu Arduino Pro Mini, ItsyBitsy und PiPico sowie in seiner angedachten Anwendung:

IMG_20210806_090052826.jpg IMG_20210806_090530086.jpg

Die Idee dahinter: Beliebige Applikationen auch in sehr kleinen Stückzahlen zu ermöglichen, weil man diese separat fertigen (und ggf. bestücken) lassen kann. Auch könnte man bei der Applikation die bestückte Seite wählen, zusammen auf einem PCB wäre nur die Rückseite möglich.

Sollte es mal eine Applikation geben die sehr beliebt ist kann man natürlich auch mal eine Serie auflegen wo man beide auf einem PCB fertigen & bestücken lässt.
So ab 10-20 Stück wird das dann schon interessant.

Preislich wird es auch interessant: Ich denke bei genug Interesse kann ich so ein komplett SMD-bestückte Controllerplatine mit allen Bauteilen (ohne NanoBCU) für 10€ anbieten.

Also - falls jemand Interesse hat ein Gerät auf dieser Basis zu entwickeln, alleine oder mit mir, oder falls auch nur die Idee vorhanden ist (aber die Fähigkeiten zur Umsetzung fehlen) raus damit. Ich hab zwar selbst jede Menge Ideen, aber gar nicht soviele Einsatzmöglichkeiten Und irgendwie macht es einfach mehr Spaß was zu entwicklen, wenn andere auch was damit anfangen können. Mir zumindest.

[Albatros62]

Ich hab zwar selbst jede Menge Ideen, aber gar nicht soviele Einsatzmöglichkeiten Und irgendwie macht es einfach mehr Spaß was zu entwicklen, wenn andere auch was damit anfangen können. Mir zumindest.

Mir geht es ähnlich. Für mich selbst brauche ich eigentlich kein SmartHome.

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?

[tobiasr]

Also - falls jemand Interesse hat ein Gerät auf dieser Basis zu entwickeln, alleine oder mit mir, oder falls auch nur die Idee vorhanden ist (aber die Fähigkeiten zur Umsetzung fehlen) raus damit. Ich hab zwar selbst jede Menge Ideen, aber gar nicht soviele Einsatzmöglichkeiten Und irgendwie macht es einfach mehr Spaß was zu entwicklen, wenn andere auch was damit anfangen können. Mir zumindest.

Ganz konkret suche ich nach einer Möglichkeit eine doppel Abzugshaube mit KNX zu steuern. Sie hat zwei identische Steuerungen wobei die Bedienknöpfe (jeweils 6 Stück, welche über die selbe Ader auch einzeln gesteuerte Spannung für eine Beleuchtung erhalten) getrennt von der Lastansteuerung (einige Relais für Beleuchtung und 4 Stufen sowie Nachlauftimer) ist. Meine Idee wäre jetzt einen KNX-Controller zwischen Tasterplatine und Steuerungsplatine zu setzen. Softwareentwicklung könnte ich hinbekommen, Hardware mechanisch aufbauen auch. Mir fehlt aber die Kompetenz die Hardware zu entwickeln.

Da ja relativ viele hier im Forum Dunstabzugshauben umbauen, könnte ich mir vorstellen, dass ich nicht der einzige bin, der eine solche Steuerung benötigen könnte.