ARDUINO am KNX

[wintermute]

Wer mehrere unabhängige und teilweise extrem zeitkritische Tasks (Bitbanging erfordert je nach Gegenstelle Reaktionen im Bereich weniger µs und das auch noch mit vergleichsweise hoher Frequenz) quasi parallel und ohne Beeinträchtigung untereinander auf einem kleinen Controller ohne entsprechende Hardwareunterstützung erfolgreich implementieren will ist entweder wirklich ein sehr guter Programmierer oder steht von Anfang an auf verlorenem Posten...

Das mag ja alles richtig sein, aber ich finde so langsam wird es zu akademisch

Wir reden von einem 16MHz Controller, der konkret 2 Aufgaben zu bewaeltigen hat: eine 9600baud Schnittstelle bearbeiten (wobei ihm noch 64byte Puffer zur Seite stehen) und "nebenbei" auf Anforderung 1wire Sensoren auslesen - also insgesamt geht es um 3 digitale Pins. Das das technisch machbar ist kann man sich nicht nur leicht ausrechnen, das wurde auch schon bei anderen Projekten hier im Forum gezeigt.

Und der Begriff der Gleichzeitigkeit spaetestens seit Einstein ein Vorstellungsirrtum

[Tessi]

Das kann man ja, nur machen es einige Leute eben auf eine sehr unprofessionelle Art & Weise. So ist die 1wire Lib IMHO ein Beispiel fuer sehr sorgloses und einfach schlechtes Programmieren.
Man kann jeden uC und auch jeden PC "kaputtprogrammieren" wenn man das will (oder einfach nicht besser kann).

Richtig man muss es können, und das ist nicht so trivial wie es sich hier offenbar einige vorstellen. Sicher kann man einiges besser programmieren, aber man darf nicht vergessen, die meisten sind diesbezüglich Laien und machen das als Hobby. Sie sind froh, wenn die Software das wenige macht, was sie für sich gerade brauchen. Das das verträglich mit allem und jedem anderen Stück Software ist, ist weder beabsichtigt noch testbar - und von den meisten auch gar nicht zu leisten.

Wer mehrere unabhängige und teilweise extrem zeitkritische Tasks (Bitbanging erfordert je nach Gegenstelle Reaktionen im Bereich weniger µs und das auch noch mit vergleichsweise hoher Frequenz) quasi parallel und ohne Beeinträchtigung untereinander auf einem kleinen Controller ohne entsprechende Hardwareunterstützung erfolgreich implementieren will ist entweder wirklich ein sehr guter Programmierer oder steht von Anfang an auf verlorenem Posten...

[Tessi]

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.

Nö, leider ist es selten so einfach. Jede Aufgabe für sich ist zunächst trivial. Aber wenn es an die parallele Barbeitung geht...

Bitbanging ist für sich gesehen noch keine Herausforderung, allerdings erreicht man selten die gleiche zeitliche Präzision als mit entsprechender Hardware, man muss mit stärkerem Jittern leben, meist geht das aber. Nur lastet man für die Zeit der Übertragung den Controller je nach Leistung stark bis voll aus. Keinesfalls verkraftet das Bitbanging einen Interrupt ohne dabei sein Timing massiv zu verfälschen, was fast immer Übertragungsfehler erzeugt. Also sperrt man in den kritischen Phasen alle Störquellen. Ein hängender Receive Buffer full oder Transmit Buffer empty Interrupt einer UART oder SPI führt aber eben so sicher zum Datenverlust oder Übertragungsfehler. Bei kleinen Controllern sind die Buffer aber regelmässig zu klein um mit Verzögerungen bei deren Handling klar zu kommen. Deswegen kracht es immer wieder wenn die Datenübertragung über mehrere Schnittstellen gleichzeitig erfolgen soll und dafür keine dedizierte Hardware vorhanden ist, die den Core entlastet und größere Toleranzen im Datenhandling erlaubt.

[wintermute]

Ich denke das wenn man das Arduino ohne die Arduino Funktionen programmiert wie eine normale MCU dann wäre alles kein Problem.

Das kann man ja, nur machen es einige Leute eben auf eine sehr unprofessionelle Art & Weise. So ist die 1wire Lib IMHO ein Beispiel fuer sehr sorgloses und einfach schlechtes Programmieren.
Man kann jeden uC und auch jeden PC "kaputtprogrammieren" wenn man das will (oder einfach nicht besser kann).

Und sowas wie "Arduino-Funktionen" gibt es garnicht, btw
Ein Arduino ist ein Atmel mit einem anderen Bootloader und einer eigenen IDE - nicht mehr und nicht weniger...

gruesse

[mayrjohannes]

Ich denke er will damit sagen das die MCU ansich mehr als Leistungsstark genug für die Anforderungen ist, aber durch die Arduino API so viel Overhead und Implementierungen von Funktionen die nicht 100% auf einander abgestimmt sind, dazukommt das man doch wieder an die Grenzen der MCU kommt.
Ich denke das wenn man das Arduino ohne die Arduino Funktionen programmiert wie eine normale MCU dann wäre alles kein Problem.

[JuMi2006]

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

Ich muss mal ganz blöd fragen. Was meinst Du damit? Meine Erfahrung mit Mikrokontrollern geht gegen Null.

Gruß

[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.

[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.

[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

[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]

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]

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

[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]

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

[greentux]

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