ARDUINO am KNX

[wintermute]

Die müssen sowieso bei parasitärem Betrieb erstmal Energie speichern...

Mal bloed gefragt: wieso eigentlich parasitaer? Ziehen die dann weniger Strom?

gruesse

[JuMi2006]

Ich glaub man muss hier klar unterscheiden ob ich der Anwendungsfall auf die Wiederverwertung von vorhandenen Sensoren bezieht oder ob ein komplett neues "Produkt" her muss.
Den 2482-100 hab ich jedenfalls noch nicht am laufen ... aber keine Ahnung obs an der Schaltung oder dem Code liegt.

[greentux]

Parasitär, weil man dann nur einen Draht ("1-wire") neben Masse braucht.
Wenn der Sensor beispielsweise unter der Badewanne am VL hängt und man 1m weiter eine Dose hat, ist sowas nicht mehr zu ändern

[ThorstenGehrig]

Hm - ich habe mal den 2438 (nicht von Wiregate, eins von Hobbyboard) angeschlossen und leider nicht zum Laufen bekommen.
Dann habe ich mich mal mit dem DHT22 befasst. Der kostet <10€, Messtolleranz +-2%. Daher kann ich die Frage von Wintermute nun nachvollziehen...

Ich mal mir jetzt mal einen DHT22 bestellt...

@Greentux: misst du die RH unter der Badewanne? Ist das eine indirekte Leckage-Detektion??

Gruß
Thorsten

[wintermute]

@Greentux: misst du die RH unter der Badewanne? Ist das eine indirekte Leckage-Detektion??

Das ist eine berechtigte Frage
Aber danke, ich verstehe jetzt den Sinn hinter der parasitaeren Sache...

Ich habe vorhin noch ein ganz klein wenig rumgespielt und die Standard-1wire-Lib fuer den Arduino beisst sich scheinbar wirklich mit der KNX-Sache. Das Prinzip bei der seriellen Kommunikation beim Arduino ist halt staendig an der Schnittstelle zu haengen und zu reagieren sobald was passiert. Die 1wire-Lib spielt da gehoerig mit rein

Mal so konzeptlos in den Raum gefragt: wenn das mit I2C und 1wire nicht funktioniert (falls es bei dem konkreten Problem ueberhaupt abhelfen wuerde) - man koennte auch einfach einen zweiten Arduino Mini rein fuer 1wire abstellen und den die Werte auslesen lassen. Der "KNX-Arduino" koennte dann zB via SPI bereits verfuegbare Werte abfragen was die Laufzeit vermutlich recht positiv beeinflussen duerfte... klar, sind Mehrkosten (wenn auch vernachlaessigbar), ein paar mA mehr Strom und ein wenig mehr Raumbedarf. Die Alternative waere, die 1wire-Sache neu aufzuziehen - wenn das ueberhaupt Sinn macht, das Auslesen scheint mir doch recht timing-kritisch zu sein und eben auch ziemlich lang zu dauern

Fuer mich ist das momentan jedenfalls wirklich ein Problem - neben der VirtualWall gehts da am selben uC bloss um 3 DS1820 und schon jetzt gehen regelmaessig Pakete verloren wenn die waehrend des Auslesens eintrudeln

gruesse :: Michael

[l0wside]

Fuer mich ist das momentan jedenfalls wirklich ein Problem - neben der VirtualWall gehts da am selben uC bloss um 3 DS1820 und schon jetzt gehen regelmaessig Pakete verloren wenn die waehrend des Auslesens eintrudeln

Wenn ihr wollt, stelle ich meine komplett Interrupt-basierten Routinen für Onewire zur Verfügung. Die sind zwar für MSP430 geschrieben, sollten sich aber recht einfach portieren lassen.
Sie benötigen einen Timer, der beim Hochzählen zwei und beim Überlauf einen dritten Interrupt auslösen kann. Notwendige Anpassungen sind dann eigentlich nur die Konfiguration des Timers, der Aufruf des Interrupts und das Auslesen/Umschalten des Portpins.

Damit sollte das Problem erledigt sein. Ich habe nur keine Ahnung, wie man das auf den Arduino bringt.

Genervter Kommentar am Rande: Es gibt haufenweise I2C- und Onewire-Routinen im Netz. Kern aller dieser Routinen (auch des TI-Demo-Codes) ist irgend ein delay(). Was zum Teufel soll das? Das ist zwar für die erste Inbetriebnahme toll, weil es schnell läuft. Für ernsthaften Betrieb ist es aber schlicht ungeeignet. Ich habe mir den Kram notgedrungen selbst geschrieben.

Max

[greentux]

Ich habe unter der Badewanne zum einen einen I/O für Leckage, zum anderen einen Temp für Belegterkennung liegen.
Beides sinnvoll.

[wintermute]

Kern aller dieser Routinen (auch des TI-Demo-Codes) ist irgend ein delay(). Was zum Teufel soll das?

Hi Max,

das ist bei der 1wire Lib fuer den Arduino noch etwas anders, da gibts neben den delays noch eine andere Besonderheit. Hier der Auszug aus dem Changelog dem ich die Probleme auf die Fahne schreibe:

Disable interrupts during timing critical sections
(this solves many random communication errors)
Disable interrupts during read-modify-write I/O

Also alles was sich irgendwie auf Interrupts verlaesst wird durch die 1wire-Lib drastisch gestoert. Ich bin mir recht sicher, dass meine angesprochenen Probleme daher kommen.

Dein Code koennte sicher eine Bereicherung sein, allein mir fehlt die Zeit das umzubasteln und - vor allem - zu testen
Ich hoffe da kann jemand anders in die Bresche springen...

gruesse :: Michael

[Tessi]

Das ist aber ein grundsätzliches Problem bei konkurrierenden Echtzeitanwendungen. Sobald ein Task zur Vermeidung eigener Timingprobleme weitere Interrupts sperrt bekommen deren Tasks ggf. massive Timingprobleme.
Man muss also priorisieren (sofern der Controller das auch unterstützt) und das System so auslegen, das niederpriore Interrupts eben auch dann noch funktionieren, wenn sie durch alle höherprioren mit deren maximaler Laufzeit unterbrochen werden. Geht das nicht, so muss man das Design und/oder die Wahl der Hardware überdenken.
Es hat schon seinen Grund, warum fast alle modernen Bussysteme die wirklich zeitkritischen Dinge in Hardware erledigen und zum Controller hin hinreichend große Pufferspeicher besitzen um zu der Seite hin eben auch mit Unterbrechungen klar zu kommen. Wer das in Software "simulieren" will braucht im Prinzip je Kanal und Richtung einen Controller...
Und wenn es ganz deterministisch sein soll, arbeitet der dann ohne Interrupts und pollt mit einem funktionierenden Scheduling - und damit kann er dann nur eben wenig "gleichzeitig" tun. C'est la vie...

[wintermute]

Das ist aber ein grundsätzliches Problem bei konkurrierenden Echtzeitanwendungen.
...
Geht das nicht, so muss man das Design und/oder die Wahl der Hardware überdenken.
...
C'est la vie...

Ja, korrekt - daher schrieb ich auch ob es nicht sinnvoll waere, die KNX-Geschichte von einem dedizierten Arduino abhandeln zu lassen und die Kommunikation mit Sensoren oder sowas von einem zweiten.

Aber davon ab: interrupts abschalten und dann einen delay "abzuarbeiten" ist nun wirklich... naja

gruesse

[l0wside]

Disable interrupts during timing critical sections
(this solves many random communication errors)
Disable interrupts during read-modify-write I/O

Ich krieg die Motten. Klar kommen Interruptkollisionen vor, aber bei mir haben die bisher keine grundlegenden Probleme verursacht. Kommt natürlich auch drauf an, was in den ISRs steht - wenn die nicht auf Tempo getrimmt sind, kann es böse haken.

Wenn ihr die Probleme loswerden wollt, packt noch einen DS2482 aufs Board, der kostet einen Euro und ist als SOIC8 gut zu löten. Angesprochen wird er über I2C. Achtung, der kann nur 5V, keine 3,3V.

Ich finde das I2C-Protokoll, das Maxim implementiert hat, zwar nicht besonders toll, aber immerhin ist man die Timing-Probleme am Onewire los. Wäre das eine Option?

Ansonsten gibt es auch noch I2C-basierte Temperatursensoren, allerdings nicht bedrahtet. Problem: diese Sensoren messen eher die Leiterplattentemperatur. Wenn jemand einen I2C-Temperatursensor will: ich schicke gegen Porto gerne ein oder zwei (im MSOP8) zu.

Max

[wintermute]

Wenn ihr die Probleme loswerden wollt, packt noch einen DS2482 aufs Board, der kostet einen Euro und ist als SOIC8 gut zu löten.
...
Wäre das eine Option?

Hi Max,

ich glaube JuMi probiert mit dem 2482 rum - oder hat das zumindest mal getan...
Ansonsten finde ich das eigentlich nicht wirklich hip. Ich halte den Arduino Ansatz fuer so gelungen weil er eben einfach ist und nicht nur fuer Experten zu verstehen - das Dingen richtet sich ja ausdruecklich an die "nicht-Experten".
Man kann einfach hingehen und sagen "och, ich haett jetzt gern 40 PWM-Ausgaenge" oder "ich will mal RFID machen" und findet sofort fertige Schaltungen und Sketche dafuer, das meiste ist dann auch ohne SMD auf Lochraster aufbaubar. In Kombination mit der KNX-Lib kann man so quasi alles recht fix an den Bus bekommen.
Aber scheinbar sind einige Sachen so "unkooperativ" gebaut, dass das garnicht so allumfassend flexibel ist wie ich mir das naiverweise mal gedacht hatte

Im "Arduino-Sinne" gedacht waere der Aufbau mit einem dedizierten KNX-Arduino vermutlich am logischsten - aber irgendwie auch doof
Der Vorteil gegenueber einem dedizierten 1wire-Controller waere aber natuerlich, dass man insgesamt deutlich flexibler waere. Theoretisch zumindest...

gruesse

[l0wside]

n finde ich das eigentlich nicht wirklich hip. Ich halte den Arduino Ansatz fuer so gelungen weil er eben einfach ist und nicht nur fuer Experten zu verstehen - das Dingen richtet sich ja ausdruecklich an die "nicht-Experten".

Ja, passt zu meinem Eindruck. Der Arduino kann sehr schnell eine singuläre Aufgabe (z.B. Onewire auslesen) lösen. Wenn es komplexer wird, kommt er dafür sehr schnell an seine Grenzen.
Es freut mich trotzdem, dass hier mit dem Arduino tatsächlich etwas Neues und Innovatives entsteht. Wenn ich noch mal unterstützen kann: gerne.

Max

[Tessi]

Das ist aber bei allen kleinen und einfach gestrickten Controllern so, das kann man auch nicht ändern. Wer Dinge wirklich parallel ausführen will benötigt dafür dezidierte Hardware plus zusätzliche Hardware damit jene Hardware miteinander kommunizieren kann, ohne das dies ihren eigentlichen Hauptjob beeinträchtigt.
Wobei Flexibilität immer ihren Preis hat, sowohl finanziell als auch energetisch.

[Robert]

Das ist aber bei allen kleinen und einfach gestrickten Controllern so, das kann man auch nicht ändern. Wer Dinge wirklich parallel ausführen will benötigt dafür dezidierte Hardware plus zusätzliche Hardware damit jene Hardware miteinander kommunizieren kann, ohne das dies ihren eigentlichen Hauptjob beeinträchtigt.
Wobei Flexibilität immer ihren Preis hat, sowohl finanziell als auch energetisch.

Der Atmel (und jeder andere "einfach gestrickte" Controller) würde sich bei korrekter Programmierung über KNX (19200 baud, ASIC, kein Bitbanging) und Onewire (per Bitbanging) schief lachen.

Leider hängt da aber eine "glorreiche Abstraktion" zwischen.

Kann man natürlich durch massives Overprovisioning lösen - muss man aber nicht.