Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
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: 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
Tags:
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Hallo Christian und alle anderen Beteiligten,
ich möchte hier einfach mal meinen riesigen Dank an Euch aussprechen.
Ich bin sehr an so einem Modul interessiert, habe auch einiges an selbst beigebrachten Wissen bzgl. Nutzung und Anschluss, aber einen solche Gesamtplanung könnte ich definitiv NICHT bewerkstelligen.
Umso dankbarer bin ich Euch für die Einbringung Eurer Freizeit.
Das nur mal so am Rand
Noch einen frohen Ostermontag.
Heiko
ich möchte hier einfach mal meinen riesigen Dank an Euch aussprechen.
Ich bin sehr an so einem Modul interessiert, habe auch einiges an selbst beigebrachten Wissen bzgl. Nutzung und Anschluss, aber einen solche Gesamtplanung könnte ich definitiv NICHT bewerkstelligen.
Umso dankbarer bin ich Euch für die Einbringung Eurer Freizeit.
Das nur mal so am Rand
Noch einen frohen Ostermontag.
Heiko
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Hallo Christian,
ich möchte mich hier Heiko anschließen: Ganz tolle Arbeit!
Weiterhin stehe ich bereit erste Samples zu testen.
Auch wenn ich Gefahr laufe mich zu wiederholen, ahbe ich noch zwei Fragen:
ich möchte mich hier Heiko anschließen: Ganz tolle Arbeit!
Weiterhin stehe ich bereit erste Samples zu testen.
Auch wenn ich Gefahr laufe mich zu wiederholen, ahbe ich noch zwei Fragen:
- Ist die Software für I/O schon fertig?
- Offeriert das I/O Modul auch I2C über die Steckerleiste? Zumindest hatte ich, nach kurzem überfliegen des aktuellen Design, nicht den Eindruck, dass dies der Fall ist. Wie ist hier geplant I2C komfortabel zugänglich zu machen? Mein Anwendungsfall wäre das Auslesen der Luftfeuchte.
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Hi Marinux,
äähhhh... also: ja, ich hab dich schon noch auf dem Schirm, ich schicke dir auch demnächst ein Sample mit allen Bauteilen zu.
Zum Thema Software muss man sagen: da gibt es bisher nur die Variante, die IN16-BIM112 Firmware anzupassen. Ich habe hier zwar schon einige Sensoren herumliegen, aber ich habe noch nicht damit gespielt. Es gibt etwas von mariosk8s für z.B. einen I2C Lichtsensor, aber ich denke, da muss man nochmal drüber arbeiten, wenn I2C in größerer Breite für verschiedene Sensoren genutzt werden soll.
I2C herausführen: ist auf dem PCB mit Schraubklemmen als eigene Klemme geplant. Ich versuche gerade auch auf dem kleinsten PCB noch Pins mit hinein zu bringen, damit man nicht löten sondern direkt stecken kann. Absicherung und Pullups sind ja schon mit drauf. Dürfte heute fertig werden.
äähhhh... also: ja, ich hab dich schon noch auf dem Schirm, ich schicke dir auch demnächst ein Sample mit allen Bauteilen zu.
Zum Thema Software muss man sagen: da gibt es bisher nur die Variante, die IN16-BIM112 Firmware anzupassen. Ich habe hier zwar schon einige Sensoren herumliegen, aber ich habe noch nicht damit gespielt. Es gibt etwas von mariosk8s für z.B. einen I2C Lichtsensor, aber ich denke, da muss man nochmal drüber arbeiten, wenn I2C in größerer Breite für verschiedene Sensoren genutzt werden soll.
I2C herausführen: ist auf dem PCB mit Schraubklemmen als eigene Klemme geplant. Ich versuche gerade auch auf dem kleinsten PCB noch Pins mit hinein zu bringen, damit man nicht löten sondern direkt stecken kann. Absicherung und Pullups sind ja schon mit drauf. Dürfte heute fertig werden.
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Oder den Multi-Sensor-AKtor zu verwenden, den man sich halt derzeit noch aus dem DEV-OOP-Branch selbst compilieren muss. Kann nach derzeitigem Stand neben simplen EIn/Ausgängen an jedem Port auch DHT11/22, CCS811und SHT2x. Wer mehr Ports will kann aucn mit PCA9555D per I2C erweitern. Weitere Sensoren sind schon vorgesehen, aber mangels eigener Testmöglichkeit und/oder Zeit noch nicht fertig.
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Bzgl. der IN16-BIM112 Firmware würde dann, nach meinem Verständnis, erst einmal der Betrieb als Input Modul funktionieren. Output und I2C wären dann zukünftige Erweiterungen, richtig?Doumanix hat geschrieben: ↑19. Apr 2022, 17:38
Zum Thema Software muss man sagen: da gibt es bisher nur die Variante, die IN16-BIM112 Firmware anzupassen. Ich habe hier zwar schon einige Sensoren herumliegen, aber ich habe noch nicht damit gespielt. Es gibt etwas von mariosk8s für z.B. einen I2C Lichtsensor, aber ich denke, da muss man nochmal drüber arbeiten, wenn I2C in größerer Breite für verschiedene Sensoren genutzt werden soll.
Das I2C prinzipiell aus dem ARM herausgeführt wird, hatte ich gesehen. Nur einen steckbaren Zugang hatte ich vermisst Cool, dass du das noch optimieren willstDoumanix hat geschrieben: ↑19. Apr 2022, 17:38 I2C herausführen: ist auf dem PCB mit Schraubklemmen als eigene Klemme geplant. Ich versuche gerade auch auf dem kleinsten PCB noch Pins mit hinein zu bringen, damit man nicht löten sondern direkt stecken kann. Absicherung und Pullups sind ja schon mit drauf. Dürfte heute fertig werden.
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Ja cool, der Branch war mir noch nicht aufgefallen. Das scheint ja die ganze Bandbreite von dem Abzudecken was ich mir unter dem UP-IO-Modul immer vorgestellt/gewünscht hatte. Respekt und ich freue mich schon das mit einem Sample zu vertesten in folgenden Szenarien:gnampf hat geschrieben: ↑19. Apr 2022, 18:17Oder den Multi-Sensor-AKtor zu verwenden, den man sich halt derzeit noch aus dem DEV-OOP-Branch selbst compilieren muss. Kann nach derzeitigem Stand neben simplen EIn/Ausgängen an jedem Port auch DHT11/22, CCS811und SHT2x. Wer mehr Ports will kann aucn mit PCA9555D per I2C erweitern. Weitere Sensoren sind schon vorgesehen, aber mangels eigener Testmöglichkeit und/oder Zeit noch nicht fertig.
- Fenster: An jedem Fenster habe ich ein UP Dose mit Verkabelung für Fensterkontakt und Glasbruchmelder. Zusätzlich würde ich gerne pro Raum in einer Dose die Luftfeuchte erfassen zwecks Bodenkühlung.
- Garage: Steuern der Garagentore über Taster-Schnittstelle und messen des Öffnungsgrades des Garagentors mit dem Distanzsensor VL53L0X: https://www.pololu.com/product/2490/specs
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Hi @all,
erstmal Großes Lob an Christian für deinen Einsatz das Modul so durchzuziehen und dabei vieles zu hinterfragen und zu optimieren. Die Bilder sehen ja richtig vielversprechend aus, bin schon gespannt wenn ich den ersten ARM darauf grillen kann.
Wer beim Testen mitmachen will, ist dazu natürlich herzlich eingeladen und dem jenigen kann ich nur wärmstens den Bus-Updater (Wiki) ans Herz legen. So ein Firmware-Update über den Bus geht in 3-10 Minuten (je nach Größe der Firmware und Auslastung des Busses) und macht das Testen am produktiven Bus deutlich einfacher.
Viele Grüße
Denis
erstmal Großes Lob an Christian für deinen Einsatz das Modul so durchzuziehen und dabei vieles zu hinterfragen und zu optimieren. Die Bilder sehen ja richtig vielversprechend aus, bin schon gespannt wenn ich den ersten ARM darauf grillen kann.
Das liegt daran, dass der DEV-OOP Branch noch relativ jung ist. Er funktioniert auch nur zusammen mit dem DEV-OOP Branch der software-arm-lib. Hintergrund ist, dass wir versuchen die Selfbus Library u.a. in Teilen auf Objektorientierte Programmierung (daher auch OOP) umzustellen. Ich habe erst die Tage alle Apps dazu angepasst und die ersten (2x in16-bim112, 1x rol-jal-bim112, 1xraincenter-bim112) seit heute bei mir auf dem Hausbus. Von einem produktiven Einsatz würde ich allerdings noch abraten, da es sicherlich noch hier und da ein paar Bugs geben wird.
Wer beim Testen mitmachen will, ist dazu natürlich herzlich eingeladen und dem jenigen kann ich nur wärmstens den Bus-Updater (Wiki) ans Herz legen. So ein Firmware-Update über den Bus geht in 3-10 Minuten (je nach Größe der Firmware und Auslastung des Busses) und macht das Testen am produktiven Bus deutlich einfacher.
Viele Grüße
Denis
5x in16-bim112 ARM | 1x rol-jal-bim112 ARM | 2x MSA | 1x raincenter-bim112 ARM | 8x Kombisensor LPC | 1x out8 LPC | 2x 2in2out LPC
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
ja, das Fenster-Thema sollte, sofern du dich für die DHT oder SHT entscheidest, schon abzudecken sein.
Was die Garage angeht: wenn es zu dem Teil Arduino-Bibliotheken geben sollte... prinzipiell habe ich eine Einbindung solcher Bibliotheken auf dem Plan, um das ganze nicht neu erfinden zu müssen. Allerdings solltest du mal schauen, ob das Modul wirklich was taugt.... ist das Tor so klein, dass 2m reichen? Fraglich auch, wie Umgebungslichtempfindlich das wohl ist.
@Darthyson:
ARM schießen ist MEIN Job!!!!11111elf
Und je mehr Tester für OOP, Multi-Sensor-Aktor, etc. zur Verfügung stehen, desto besser. Im Endeffekt war auch die alte Lib ja eigentlich nicht für den Produktiveinsatz zu empfehlen wenn man sich anschaut, was im Rahmen des DEV-Timing-Branches da alles gemacht wurde.
Was die Garage angeht: wenn es zu dem Teil Arduino-Bibliotheken geben sollte... prinzipiell habe ich eine Einbindung solcher Bibliotheken auf dem Plan, um das ganze nicht neu erfinden zu müssen. Allerdings solltest du mal schauen, ob das Modul wirklich was taugt.... ist das Tor so klein, dass 2m reichen? Fraglich auch, wie Umgebungslichtempfindlich das wohl ist.
@Darthyson:
ARM schießen ist MEIN Job!!!!11111elf
Und je mehr Tester für OOP, Multi-Sensor-Aktor, etc. zur Verfügung stehen, desto besser. Im Endeffekt war auch die alte Lib ja eigentlich nicht für den Produktiveinsatz zu empfehlen wenn man sich anschaut, was im Rahmen des DEV-Timing-Branches da alles gemacht wurde.
Re: Neues UP-Multi-IO-Modul mit abgesicherten IOs, EEPROM, I2C-Anbindung, ...
Yep, du hast recht. Ich hatte mich verschrieben. Ich habe hier zuhause den VL53L1X : https://www.pololu.com/product/3415
Distance up to 4m
Distance up to 4m