Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Verfasst: 17. Apr 2022, 01:13
Hi @ll,
ich weiß nicht, ob man es Osterüberraschung nennen kann, aber zumindest ist es ein Update zu dem Thema "Neues UP-Multi-IO-Modul". Die Zeit rennt, wenn man sowas nebenbei machen will ... aber ich denke, die investierte Zeit lohnt sich.
Eigentlich müsste man hieraus mehrere Beiträge machen (werde ich auch die nächste Zeit), denn die Entwicklung des Moduls hatte so einige Quereinflüsse und zog einige Grundsatzdiskussionen und (hoffentlich) -verbesserungen nach sich.
IO-Modul
Zunächst zum Modul selbst: nach weiteren 3 Runden mit Test PCBs würde ich sagen, dass sich das bisher kleinste Modul (mit Micromatch) seinem Ziel nähert. Auch die Variante mit den besprochenen Schraubklemmen habe ich in einer Variante "fertig", möchte aber Feedback von der ersten Variante abwarten.
Es gab zunächst offensichtliche Flüchtigkeitsfehler zu beheben (EIB IN und OUT auf dem Breakoutboard vertauscht
ayyy!), aber es gab auch härtere Nüsse zu knacken. So sieht mein letzter Prototyp aus, wobei hier noch der 2er Pin für +3V und GND auf der Modulplatine an einer anderen Stelle sitzen als auf dem Breakout-Board (BB) - daher die Kabel.
Breakout-Board
Interessant wurde das Layout des BB. Schließlich sollte es nicht nur die aktuellen Teil-Schaltungen (Busanbindung, Stromversorgung) in ein BB verlagern, sondern nach Möglichkeit auch noch verbessern. Einerseits wurde die Sendeschaltung ein wenig überarbeitet, damit über eine große Abwärmefläche und entsprechend robusten Widerständen deutlich mehr Abwärme abtransportiert werden kann, als mit der bisherigen Sendestufe. Ziel ist es, mit einer gleichzeitigen Überarbeitung der Selfbus-Lib, Longframes zu unterstützen und damit einen deutlich höheren Durchsatz am Bus zu erreichen, was insbesondere für ein "Over the Air"- oder zumindest "Over the Bus"-Update der Firmware sehr von Vorteil wäre.
Gleichzeitig hatte ich aber ein wenig mit der Stromversorgung gekämpft. Es gibt einige Varianten der Versorgung in unseren aktuellen Modulen, alle funktionieren, aber so richtig festgelegt wurde (zumindest schriftlich) nichts, wie sie denn typischerweise verwendet werden sollte ("optimale" Anordnung, Ein-Ausschaltverhalten).
Die TS ARM Schaltung und die Rauchmelder-Schaltung verwenden bspw. gar keinen Spannungsteiler, um den Buck bei einer definierten Spannung ein- / oder auszuschalten. Die Werte auf der 4TE Controllerschaltung werden wir wohl in Kombination mit der Busspannungserkennung überarbeiten, um so ein einheitliches und definiertes Abschaltverhalten über alle zukünftigen Geräte zu bekommen.
Außerdem hatte ich mich ein wenig damit beschäftigt, wie eine möglichst "saubere" Stromversorgung etabliert werden könnte, mit möglichst wenig Einfluss auf die Modulplatine, die ja direkt unter dem BB sitzt, und mit möglichst kleinem Ripple. Ich verschone euch mit den Details - nur soviel: angefangen hatte ich mit massiven Störeinflüssen und 120-150mV Ripple
.
Sah noch schlimmer als hier aus:
Aktueller Stand ist das mit ca. 15mV RIpple, was sogar noch ein klein wenig besser aussieht als die eh schon gute Variante auf dem Rauchmeldermodul 
:
Repository-Überarbeitung
Um Selfbus ein wenig klarer zu strukturieren und die Entwicklung einfacher zu machen, haben wir so nebenbei auch Tonnen an Nachrichten ausgetauscht (unnützes Wissen nebenbei: der Slack-Nachrichtenzähler steht aktuell bei 18.300), wie wir das in Zukunft handhaben könnten mit Repos, Branches, Commits, etc. Daher findet man meine aktuellen IO Modul- und BB-Entwürfe bisher auch nur in meinem persönlichen Repository, um nicht noch mehr Verwirrung zu stiften. Die dort verprobte Variante, jedes PCB in einem eigenen Branch zu pflegen, werden wir übrigens wahrscheinlich verwerfen
Ich hoffe, dass wir die Umstrukturierung bald durchziehen können. Ich persönlich bin fest davon überzeugt, dass eine neue Struktur das Projekt viel leichter verständlich macht - und das nicht nur für Neueinsteiger.
SB-Lib Überarbeitung
Das hat nichts mit dem IO-Modul und auch gar nichts mit dem zu tun, was ich beitrage, aber da davon hier so gut wie nichts im Forum geschrieben wird, möchte ich nochmal drauf hinweisen, dass mehrere Leute die Lib stark verbessern. Sowohl Fehler ausmerzen, als auch neue Funktionen einbauen.
In Kombination mit diesem von Olli verlinkten knxprod-Editor, könnte da noch einiges gehen, dieses Jahr!
Zumindest darf nun wirklich bald mal getestet werden - und ich hoffe, dass damit nicht nur das Modul, sondern auch die Überarbeitung der Lib nochmal ordentlich auf Herz und Nieren geprüft wird.
Hier noch die Links zu den PCBs:
Breakout-Board: https://github.com/Doumanix/hardware/tr ... out-Boards
IO Modul (Micromatch): https://github.com/Doumanix/hardware/tr ... 0-%2035x25
Viele Grüße & Frohe Ostern
Christian
ich weiß nicht, ob man es Osterüberraschung nennen kann, aber zumindest ist es ein Update zu dem Thema "Neues UP-Multi-IO-Modul". Die Zeit rennt, wenn man sowas nebenbei machen will ... aber ich denke, die investierte Zeit lohnt sich.
Eigentlich müsste man hieraus mehrere Beiträge machen (werde ich auch die nächste Zeit), denn die Entwicklung des Moduls hatte so einige Quereinflüsse und zog einige Grundsatzdiskussionen und (hoffentlich) -verbesserungen nach sich.
IO-Modul
Zunächst zum Modul selbst: nach weiteren 3 Runden mit Test PCBs würde ich sagen, dass sich das bisher kleinste Modul (mit Micromatch) seinem Ziel nähert. Auch die Variante mit den besprochenen Schraubklemmen habe ich in einer Variante "fertig", möchte aber Feedback von der ersten Variante abwarten.
Es gab zunächst offensichtliche Flüchtigkeitsfehler zu beheben (EIB IN und OUT auf dem Breakoutboard vertauscht
ayyy!), aber es gab auch härtere Nüsse zu knacken. So sieht mein letzter Prototyp aus, wobei hier noch der 2er Pin für +3V und GND auf der Modulplatine an einer anderen Stelle sitzen als auf dem Breakout-Board (BB) - daher die Kabel.
Breakout-Board
Interessant wurde das Layout des BB. Schließlich sollte es nicht nur die aktuellen Teil-Schaltungen (Busanbindung, Stromversorgung) in ein BB verlagern, sondern nach Möglichkeit auch noch verbessern. Einerseits wurde die Sendeschaltung ein wenig überarbeitet, damit über eine große Abwärmefläche und entsprechend robusten Widerständen deutlich mehr Abwärme abtransportiert werden kann, als mit der bisherigen Sendestufe. Ziel ist es, mit einer gleichzeitigen Überarbeitung der Selfbus-Lib, Longframes zu unterstützen und damit einen deutlich höheren Durchsatz am Bus zu erreichen, was insbesondere für ein "Over the Air"- oder zumindest "Over the Bus"-Update der Firmware sehr von Vorteil wäre.
Gleichzeitig hatte ich aber ein wenig mit der Stromversorgung gekämpft. Es gibt einige Varianten der Versorgung in unseren aktuellen Modulen, alle funktionieren, aber so richtig festgelegt wurde (zumindest schriftlich) nichts, wie sie denn typischerweise verwendet werden sollte ("optimale" Anordnung, Ein-Ausschaltverhalten).
Die TS ARM Schaltung und die Rauchmelder-Schaltung verwenden bspw. gar keinen Spannungsteiler, um den Buck bei einer definierten Spannung ein- / oder auszuschalten. Die Werte auf der 4TE Controllerschaltung werden wir wohl in Kombination mit der Busspannungserkennung überarbeiten, um so ein einheitliches und definiertes Abschaltverhalten über alle zukünftigen Geräte zu bekommen.
Außerdem hatte ich mich ein wenig damit beschäftigt, wie eine möglichst "saubere" Stromversorgung etabliert werden könnte, mit möglichst wenig Einfluss auf die Modulplatine, die ja direkt unter dem BB sitzt, und mit möglichst kleinem Ripple. Ich verschone euch mit den Details - nur soviel: angefangen hatte ich mit massiven Störeinflüssen und 120-150mV Ripple
.Sah noch schlimmer als hier aus:
:
Um Selfbus ein wenig klarer zu strukturieren und die Entwicklung einfacher zu machen, haben wir so nebenbei auch Tonnen an Nachrichten ausgetauscht (unnützes Wissen nebenbei: der Slack-Nachrichtenzähler steht aktuell bei 18.300), wie wir das in Zukunft handhaben könnten mit Repos, Branches, Commits, etc. Daher findet man meine aktuellen IO Modul- und BB-Entwürfe bisher auch nur in meinem persönlichen Repository, um nicht noch mehr Verwirrung zu stiften. Die dort verprobte Variante, jedes PCB in einem eigenen Branch zu pflegen, werden wir übrigens wahrscheinlich verwerfen
Ich hoffe, dass wir die Umstrukturierung bald durchziehen können. Ich persönlich bin fest davon überzeugt, dass eine neue Struktur das Projekt viel leichter verständlich macht - und das nicht nur für Neueinsteiger.
SB-Lib Überarbeitung
Das hat nichts mit dem IO-Modul und auch gar nichts mit dem zu tun, was ich beitrage, aber da davon hier so gut wie nichts im Forum geschrieben wird, möchte ich nochmal drauf hinweisen, dass mehrere Leute die Lib stark verbessern. Sowohl Fehler ausmerzen, als auch neue Funktionen einbauen.
In Kombination mit diesem von Olli verlinkten knxprod-Editor, könnte da noch einiges gehen, dieses Jahr!
Zumindest darf nun wirklich bald mal getestet werden - und ich hoffe, dass damit nicht nur das Modul, sondern auch die Überarbeitung der Lib nochmal ordentlich auf Herz und Nieren geprüft wird.
Hier noch die Links zu den PCBs:
Breakout-Board: https://github.com/Doumanix/hardware/tr ... out-Boards
IO Modul (Micromatch): https://github.com/Doumanix/hardware/tr ... 0-%2035x25
Viele Grüße & Frohe Ostern
Christian
