OpenKNX REG1 CAN-Bus Applikationsplatine & Hoval Applikation/Firmware

[alanz]

Was ist die Motivation hinter den Lücken im Speicherlayout? (Hinweis: Das kannst Du später bei Updates noch ändern. Optimierungen sind natürlich vor allem bei speicherintensiven Modulen relevant)

Eine Mischung aus Unerfahrenheit, Unwissenheit und einer Aversion gegen ein fragmentiertes Speicherlayout. Da kann ich mit Sicherheit Unterstützung gebrauchen, wie man das gut und Updatefähig macht. Ich hatte am Anfang wesentlich weniger Parameter und hatte mich beim hinzufügen neuer Parameter darüber geärgert, die hinten anstellen zu müssen. Daher hatte ich beim zweiten "Versuch" großzügig Lücken gelassen. Der Weißheit letzter Schluss ist das sicher nicht.

Du hast Überlappung im Speicher (die 128 und 512 Bit Unions). Bei Nutzung der aktuellen Producer-Version solltest Du da auch Warrnungen, zukünftig auch Fehler erhalten, so lange Du diese nicht explizit unterdrückst weil beabsichtigt

War mir beim Update des Producers auch aufgefallen. Ist auf dem PR bereits gefixt.

" Jede Änderung senden" - für Einrücktung das Attribut IndentLevel im ParamRefRef nutzen

Danke für den Tip.

Die Parameter-Namen sind relativ lang. Zu lange Namen sind ein Problem beim ConfigTransfer, weil die ETS eine internen Längenbegrenzung hat

Was wäre hier eine sinnvolle maximale Länge?

Parameter-Namen nutzen wir für gewöhnlich CamelCase-Notation, das ist auch bei den Macros übersichtlicher, weil da dort _ als weiteres Trennzeichen verwendet wird.

👍

https://github.com/Blizzard26/OAM-KN...Module.cpp#L16 - da solltest Du die Definitionen aus OpenKNX verwenden: https://github.com/OpenKNX/OGM-Commo...lper.h#L10-L12

Das ist von dort kopiert. Hatte ich so gemacht, weil ich zeitweise ein Build-Flag hatte, um das Ganze auch ohne OpenKNX bauen und testen zu können. Das war einer der Punkte die ich vor dem Veröffentlichen (größtenteils) aufgeräumt hatte. Das kann damit jetzt also auch weg, wobei es aufgrund des #ifndef auch nicht (mehr) verwendet wird.

Wichtiger als die Länger ist der Informationsgehalt und die Fokussierung auf das nicht offensichtlche. LLMs neigen dazu sehr ausschweifende Texte zu produzieren, denen es aber gleichzeitig am Kernverständnis fehlt. Wenn ich das als Mensche lesen muss, dann ist das weniger zielführend als vom Entwickler der die echten Herausforderungen kennt.

Da gebe ich dir vollkommen recht. Wobei meine Erfahrung auch ist, dass sie mit den richtigen Vorgaben gute Ergebnisse liefern. Man muss Sie quasi wie einen Junior-Developer behandeln, der gerade neu dazugestoßen ist - dann können sie gute Ergebnisse liefern und das mit einem wahnsinnigen Tempo. Ich war auch skeptisch. Wir hatten auf der Arbeit aber vor ein paar Wochen einen geführten Hackathon mit Claude Code und das war echt ein Eye-Opener.

Was ich aber tatsächlich noch mal sinnvoll fände wäre ein Austausch zwischen den ähnlichen Projekten, wie schon oben vorgeschlagen https://knx-user-forum.de/forum/proj...83#post2087283

Bin ich gerne dabei. Wobei ich dazu sagen muss, das die Terminfindung bei mir nicht immer ganz einfach ist.

[cad435]

KNX zu CAN ist immer gut, da muss/darf/will ich doch glatt meinen Senf zum Thema Hardware hinzugeben 🤪

Ing-Dom wo hast du denn die 200mA Supply Current her? Beim SN65HVD230 sehe ich 17mA Supply-Current, plus das was er an Buslast kapazitiv treibt (aber das wird sich auch im einstelligen mA-Bereich halten) plus das was an den Terminierungswiderständen abfällt, das sind nochmal ~30mA.

Der MCP2515 als CAN-Controller braucht dann nochmal ~10mA lt. Datenblatt (SN65HVD230 + MCP2515 sollte die Kombination des Waveshare-Boards sein)
--> Den MCP2515 gibt es auch als China-Drop-in replacement unter der Bezeichnung XL2515 (wer hätte es gedacht, der absolute Standard-Controller hat einen China-klon)

Von den Kombinierten Transcreivern/Controllern würde ich in dem Fall eher abraten, da die "rohe" Datenübertragen RXCAN/TXCAN mit den 1Mbps bzw. 5Mbps deutlich einfacher zu isolieren geht, als die 10Mhz/20Mhz SPI zwischen Controller und MCU.

Isolierung würde ich jetzt etwas günstiges nehmen, 10Mbps ist jetzt heute auch kein Hexenwerk mehr. Der π121M31 sieht recht geeignet aus (ja ich find das irgendwie witzig, dass 2Pai einfach ein "π" als Prefix hat.)

Für die Spannungsisolierung würde ich wahrscheinlich einen ganz einfachen B1203S-1W Wandler (12V von der BCU rein, 3.3V Isoliert raus) verwenden. Der muss nicht viel können, 300mA an den 3.3V sollten für die isolierte Seite dann auch locker reichen.

Das große Problem ist hier denke ich die Versorgung aus dem Bus...
Tatsächlich ist mir bei der recherche jetzt sogar aufgefallen, das CAN-FD anscheinend sogar eher weniger Ruhestrom in den Controllern/Transceivern verbraucht als "normales" CAN. Ich vermute mal, das kommt daher, dass die Silizium-Die's von CAN-FD moderner sind als die "alten" Standard-CAN Die's

Transcreiver mit ~50mA wenn Daten gesendet werden, Controller nochmal 10mA dazu, geben wir für die Isolatoren nochmal 10mA dazu --> 70mA @ 3.3V --> ~230mW

auf die 230mW rechnen wir mal noch großzügig einen Verlustfaktor von 0.75 für die DCDC-Wandlung drauf, ergibt ~300mW.
Also außerhalb der Spec bewegt man sich da denke ich in jedem Fall. Ist jetzt die frage ob man das mit einem großen Label auf dem Silkscreen "300mW Bus consumption" gut sein lässt.


Durch den NCN5130 ist man hardwareseitig mit 100mA auf dem Ausgang vom DC2 limitiert. Dafür muss der FANIN-Pin des NCN5130 über 10kR GND gezogen sein. (ist er in der NanoBCU)
Absolut Maximum was die Hardware am DC2 bei 12V kann sind damit 1.2W. Das haut also locker hin



SPI Interface (4-pins) plus Interrupt + 2 spare IO's über die Reg1 Schnittstelle ist möglich.

Maximale SPI-Frequenz bei "Normalem" CAN ist 10MHz, bei CAN-FD 20MHz. Da würde ich zumindest mal messen ob die Signalintegrität über die Stiftleiste im Reg1 Modul noch gegeben ist, auf jeden Fall gehören aber in alle Leitungen mal Serienwiderstände vorgesehen (bestückt mit 0R) die man bei Bedarf zur Bedämpfung verwenden kann.


Man könnte sich jetzt noch überlegen ob man die 29V DC-Versorgung (Gelb-Weiße Klemme) auf der CAN-Seite anzapft. dazu müsste man dann an die REG1 Applikationsplatine noch den Anschluss für die Gelb-Weiße Klemme mit dazu bauen.

Der Versorgungspfad wäre in dem fall dann 29V Input --> Non-isolated DCDC auf 12V oder 5V --> Isolated DCDC 12V oder 5V auf 3.3V. Die CAN-Insel sollte auf jeden Fall komplett floatend Ausgelegt sein, da bei einem Universal-Board nicht klar ist wo die Bezugsmasse für den CAN herkommt. Industriell wird da normalerweise ein 3-Adriges Kabel verwendet mit explizitem CAN-GND.


- cad435

[Ing-Dom]

da muss/darf/will ich doch glatt meinen Senf zum Thema Hardware hinzugeben

ja gern! Hab da nicht wirklich Erfahrung mit CAN.

wo hast du denn die 200mA Supply Current her

Aus dem DB vom ADM3055E, Seite 4.

Ich hab mir mehrere ähnlich Bausteine angeschaut, auch von TI. Schwanken alle etwas, aber am Ende sind es ähnliche Regionen.
Und natürlich frisst hier der IC-integrierte DC/DC seine 50%, oder so.

Der MCP2515 als CAN-Controller

Warum ein MCP2515 ?
Der ESP hat doch CAN intern.
Da brauchts kein SPI.

Also außerhalb der Spec bewegt man sich da denke ich in jedem Fall.

KNX Spec meinst du? Da gibts keine starre Grenze für den Busstrom.

Durch den NCN5130 ist man hardwareseitig mit 100mA auf dem Ausgang vom DC2 limitiert. Dafür muss der FANIN-Pin des NCN5130 über 10kR GND gezogen sein. (ist er in der NanoBCU)

Der FANIN hat nichts mit dem 100mA Limit des DC/DC zu tun, sondern mit der Gesamtaufnahme.
10k FANIN = 40mA Busstrom.

Das Problem ist aber dass der REG1-ControllerESP VCC2 = 3.3V benötigt. Und auf jeder 3.3V Rail ca. 50mA braucht.'
Keine 100mA @12V (die waren eh unrealistisch, es wären eher max 50mA @12V) sondern 50mA @3.3V wären verfügbar.
Zumindest wenn der LAN-Teil aktiv ist, schaltet man den aus sind es 100mA @3.3V.

Alles andere würde gröbere Umstellungen bedeuten.

Mit dem RP2040 Controller wäre man flexibler.