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.

[u20p17]

wie Ing-Dom schon schrieb unterstützt der esp32 TWAI und dementsprechend würde ein CAN Transiever (z.B. sn65hvd230) ausreichen. Wenn ich das Datenblatt vom Reciever richtig interpretiere sollte dieser max 'nur' 17mA benötigen - sollte sich also leicht ausgehen. (Seite 7 --> Icc Supply current: https://www.ti.com/lit/ds/symlink/sn...252FSN65HVD230

[Ing-Dom]

sollte dieser max 'nur' 17mA benötigen

das ist der Strom den den Transceiver selbst braucht - ohne den Strom den er braucht um den High Pegel am CAN zu treiben.

Und das sind nochmal rund 50mA (siehe 8.3).

[u20p17]

Ich glaub da wird ein bisschen was durcheinandergebracht 🙂Output current = Strom im Lastpfad (CAN-Bus), Supply current = Strom aus 3.3 V Versorgung --> Die beiden sind physikalisch gekoppelt, aber nicht identisch.

Die ~17 mA sind der Versorgungsstrom vom IC selbst (ICC). Die ~40–50 mA aus dem Datenblatt sind aber nicht zusätzlicher Stromverbrauch, sondern die Ströme an den CAN-Pins (also was der Treiber in den Bus reinschiebt bzw. rauszieht).
Wenn du dir das Diagramm „Supply Current (RMS) vs Frequency“ im Datenblatt anschaust, siehst du den realen Strom bei aktivem Bus – der liegt eher so bei ~15–22 mA, selbst mit 60-Ω-Terminierung.
Die ~50 mA wären eher ein Grenz-/Momentanwert vom Treiber, nicht etwas, was du dauerhaft auf den 3.3-V-Strom draufrechnest 👍

(Ich lasse mich gerne eines besseres belehren - aber so interpretiere ich das Datenblatt...)

[cad435]

Ing-Dom Ich bin jetzt tatsächlich davon ausgegangen, dass da ein RP2040 werkelt...

Wie der ESP32 an der Nano-BCU dauerhaft funktioniert ist mir sowieso etwas schleierhaft, da sich das teil beim Wifi-TX auch gern mal um die 300mA gönnt und das wäre selbst mit DC1+DC2 von der Nano BCU kombiniert zu viel.

Aber gut, anscheinend gehts, daher will ich da gar nicht meckern Die zusätzlichen features sinds wert.

War es nicht so, dass die KNX-Spec vorschreibt, ein jeder Teilnehmer möge sich doch bitte mit maximal 200mW aus dem Schwarz/Roten Adernpaar begnügen?



Ing-Dom Klar, der Fanin hat erstmal nichts mit den 100mA des DCDC Wandlers zu tun, das war von mir so gedacht, das sind zwei unterschiedliche constraints, aber das restriktivere muss beachtet werden.


und ich bin ehrlich gesagt kein fan von allem was AD/LTC ist, da die IC's von denen zwar in der Regel wirklich gut sind, aber meiner Meinung nach echt überteuert und in der Regel maximal spezialisiert.

Immer wenn AD oder LTC im Baustein Prefix steht, dann kannst du mit +10€ in der BOM rechnen und einkaufen ist auch ab und an schwierig.

Da würde ich persönlich einen "quasi standard" immer vorziehen, aber das ist meine persönliche Präferenz.

[mumpf]

Wie der ESP32 an der Nano-BCU dauerhaft funktioniert ist mir sowieso etwas schleierhaft, da sich das teil beim Wifi-TX auch gern mal um die 300mA gönnt und das wäre selbst mit DC1+DC2 von der Nano BCU kombiniert zu viel.

Auch wenn ich von HW nichts verstehe - Ing-Dom meint unsere HW, das ist der ESP32 am LAN, kein WLAN.

Gruß, Waldemar

[Ing-Dom]

Wie der ESP32 an der Nano-BCU dauerhaft funktioniert ist mir sowieso etwas schleierhaft, da sich das teil beim Wifi-TX auch gern mal um die 300mA gönnt

mit Wifi-TX tut er auch nicht ganz einfach..

Manch einer hat sich zwar mit dicken Elkos und einer deutlicen Überlastung der BCU was gebaut, aber ich rate davon ab und bin sicher dass die BCU das auch dauerhaft nicht mitmacht.

Du kannst dich hier einlesen: https://knx-user-forum.de/forum/proj...eg1-goes-esp32

[cad435]

mit Wifi-TX tut er auch nicht ganz einfach..

Ahhh, na gut, das geht dann eher. LAN im Schaltschrank ist eh deutlich sinnvoller

Manch einer hat sich zwar mit dicken Elkos und einer deutlicen Überlastung der BCU was gebaut

Ne bitte nicht... da würde ich auch definitiv davon abraten.



Würde aber glaube ich tatsächlich gehen wenn man die Nano BCU auf DC2 mit 24V konfiguriert und einen dedizierten Buck von den 24V auf 3.3V Nachschaltet.
Da sollte man die 1W TX Leistung dann auch raus kriegen (und falls uns beim CAN die Leistung ausgeht, könnte man mit dem weg ggf. eine lösung bekommen die die NanoBC nicht killt)

Du kannst dich hier einlesen: https://knx-user-forum.de/forum/proj...eg1-goes-esp32

Ich gucks mir mal an und denk nach. Den CAN-Controller in der MCU zu haben wäre definitv cooler, muss mir mal die Leistungs-Budgets ausrechnen...

Edit: Welche KiCAD schaltung im Hardware Repo ist der ESP-Controller? ich sehe nur "App-ETH" und "IPController-RP2040" was irgendwie passen würde, aber kein "IPController-ESP32" 🤔

[Ing-Dom]

Ich habe gestern länger mit Alex ( cad435 ) über eine mögliche Lösung diskutiert.

Wir sind dann schlussendlich unter Betrachtung verschiedener Ansätze auf folgenden Lösungsvorschlag gekommen:

Isolierte CAN Applikationsplatine für den REG1-ControllerESP => Lib UNterstützung ist besser, CAN ist integriert.

Die Versorgung der CAN-Applikation, die in Verbindung mit der nötigen DC/DC Wandlung doch ein paar mA braucht, ließe sich nur mit Kompromissen mit der BCU machen.

Daher ist dann die Idee entstanden, dass sich die CAN-Platine selbst aus dem KNX-Buspotential (dass beim REG1-ControllerESP alternativ zur Vcc2 zur App geführt werden kann) über passender Filterung und Stepdown 12V erzeugt, diese dann mit einem Standard isolierten DC/DC (B1203S-1W) die Versorgung für den Transceiver erzeugt. Als CAN Transceiver ein Standard SN65HVD230 und für die Isolation der Signale ein Adum1201 bzw. ein Klon..

Meinungen dazu?

[coko]

Isolierte CAN Applikationsplatine für den REG1-ControllerESP => Lib UNterstützung ist besser, CAN ist integriert.

Wie meist Du das? Ist die Unterstützung für ESP32 besser als für RP2040? alanz hatte ja mit RP2040 begonnen https://knx-user-forum.de/forum/proj...42#post2086942 oder passt das begünstigt durch die "Sonderlösungen" von Hoval besser?

[cad435]

Der ESP32 hat den CAN-Controller integriert (Stichwort "TWAI", "Two Wire Automotive Interface"). Das erspart den externen Controller.
Espressiv nennt den wahrscheinlich nur deshalb TWAI, da sie sonst irgendwelche royalty-fees bezahlen müssten - der gleiche Grund, warum I2C manchmal als "SMBus" bezeichnet wird

Die Librarys für den Internen CAN/TWAI Controller sollen anscheinend auch besser sein und du hast halt einfach ein Teil weniger was dir Probleme machen kann.

Und du sparst dir die 10Mhz SPI Leitungen über die Schnittstelle zwischen Reg1 Controller und Reg1-App, welche generell über die Stiftleiste einfach nicht schön ist.


Edit: Was mir gerade eben beim lesen der TWAI Seite noch aufgefallen ist: der TWAI Controller kann KEINE CAN-FD Frames! Diskussion ob man das unterstützen soll/muss/ überhaupt braucht lasse ich mal offen.

[mags]

Man sollte wohl nicht einen solchen Thread starten und dann über ein verlängertes Wochenende weg fahren 😁 Aber schön zu sehen, dass sich einige Leute hier so stark engagieren!

Meinungen dazu?

Für mich persönlich hört sich das super an. Allerdings bin ich Hardware-Laie und maße ich mir nicht an, hier für die breite Nutzerschaft zu sprechen.

Vom Setup würde sich das wohl stark mit dem decken, was ich derzeit auf meinem Breadboard gesteckt habe. Nämlich einem REG1 mit ESP32 sowie einem SN65HVD230 CAN Transceiver.

Nach meinem Verständnis wird am Ende der Entwicklung keine universelle Applikationsplatine herauskommen, welche mit beiden REG1 Varianten (ESP32 / RP2040) funktioniert, sondern nur für eine der beiden. Daher wäre es natürlich ideal, dass wir auf den Chip setzen, welchen wir für die jetzigen und zukünftigen Projekte als am besten geeignet ansehen.

Seitens der Software können wir (zumindest den Hoval Use Case) die Aufgabe mit beiden Chips realisieren.

Ich starte mal eine Liste zur Diskussion, bzw. zum Erweitern:

Pro ESP32:
* Integrierter CAN-Controller (weniger Komponenten auf Applikationsplatine notwendig)
* Höhere Rechenleistung
* <starke_argumente_hier_einfügen>

Pro RP2040:
* <starke_argumente_hier_einfügen>

Edit: Was mir gerade eben beim lesen der TWAI Seite noch aufgefallen ist: der TWAI Controller kann KEINE CAN-FD Frames! Diskussion ob man das unterstützen soll/muss/ überhaupt braucht lasse ich mal offen.

Für den Hoval Use Case brauchen wir wohl keine CAN-FD Frames. Wie stark verbreitet diese in anderen CAN Anwendungen sind, ist mir leider nicht bekannt.

[cad435]

Man sollte wohl nicht einen solchen Thread starten und dann über ein verlängertes Wochenende weg fahren 😁 Aber schön zu sehen, dass sich einige Leute hier so stark engagieren!

Ja irgendwie ist das ein bisschen eskaliert...

Für den Hoval Use Case brauchen wir wohl keine CAN-FD Frames. Wie stark verbreitet diese in anderen CAN Anwendungen sind, ist mir leider nicht bekannt.

Leider kann ich zu der Verbreitung im "Nicht-Automotive" Umfeld auch nichts beitragen.