ARDUINO am KNX

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

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

[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

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

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

[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

[idefix6]

ich würde hier gerne eine Platine machen auf die ein Atmel drauf ist (der mit Arduino unterstützt wird) und einen Anschluss für KNX hat.
Also der Buskoppler Chip und der AVR auf einer Platine und in einer Größe, damit es in ein Unterputzgehäuse passt.
Man könnte dann noch ein paar IOs vorsehen, allerdings wird da dann nicht mehr so viel Platz sein.

Also Arduino scheint ja meist der ATMega328 zum Einsatz zu kommen. Allerdings hat dieser nur eine serielle Schnittstelle und fällt deswegen eigentlich aus.

Ich hab gelesen das es auch mit einem ATMega644 gehen soll?

Ich selber kenne mich sehr gut mit Atmels aus, allerdings hatte ich noch nicht die Notwendigkeit gesehen, mich mit Arduino zu beschäftigen, da ich die ganze Hardware habe und den Arduino Bootloader deswegen nicht brauche. Da bräuchte ich dann ein bisschen Unterstützung von den Arduino Profis.

Würde da Interesse bestehen?

[Robert]

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

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

Entschuldige meine direkte Art, aber ich glaube du verdienst nicht dein Geld damit.

"Bit-Banging" heißt mitnichten, dass man mit Schleifen das Timing erzeugt bzw. Zyklen zählt. Jeder AVR kann mit Hilfe von Output-Compare-Matches bzw. Input-Captures auch bei Bitbanging alle Interrupts laufen lassen (bzw. braucht diese sogar um dann die gelatchten Timingwerte zu lesen oder die nächsten Output-Compare-Werte zu schreiben und die Flanke ggfl. umzuschalten. Hierbei nebenbei per ISR auch einen UART-Datenstrom zu bedienen ist lachhaft einfach.
Die kleinste Zeiteinheit bei Onewire bei normalen Tempo ist eine "1" (1-15us). 1us ist sicher bei unseren Heimnetzwerken nicht sinnvoll, eher werden es 10us sein. 10us sind bei 20MHz 200 Takte, ergo ausreichend um:

Schreiben:
- Timer an, 1us Auflösung reicht völlig, fallende Flanke (oder sogar "Toggle-On-Compare-Match" je nach Verfügbarkeit)
- Interrupt: gucken ob 1 oder 0, entsprechend Timer +10 oder +60
- Interrupt: gucken ob 1 oder 0, entsprechend Timer +60 oder +10
nächstes Bit

Wer 1us-Timing haben will nimmt halt an diesem Punkt für die "1" ein ISR und packt 20 NOPs rein.

Noch rafinierter geht es, wenn man eine PWM mit 70us Zykluszeit initialisiert und die On-Zeit zwischen 10us und 60us umschaltet. So bekommt man nur ein Overflow-Interrupt pro Zyklus und hat zwischen den Interupts 1400 Instruktionen Zeit für das Vorrausberechnen des nächsten Zyklus und andere Dinge.

Lesen:
- Input Capture auf fallende Flanke
- ICP-Interrupt: Compare-Match auf gelatchten Wert + 30
- OC-Interrupt: Lesen

Alles ganz ohne Jitter.

Ausgelassen sei das Zusammenklimpern der Bits zu Bytes. Dafür sind reichlich Takte vorhanden, insbesondere wenn man ein GCC Listing lesen und benutzen kann.

Beim UART des TPUART (der läuft mit 19200 baud):
8N1 sind 11 * 52 us = 572us -> 11000 Takte! Da werden wohl mal bei all dem Onewire-Interrupt paar dabei sein um den 1-Byte-FIFO in einem Interrupt zu leeren bzw. den TX-FIFO zu bestücken...

Das es so geht zeigen irrsinnig viele AVR-Projekte.

Das wars zu dem Thema von mir.

[Robert]

ich würde hier gerne eine Platine machen auf die ein Atmel drauf ist (der mit Arduino unterstützt wird) und einen Anschluss für KNX hat.

Expandiert freebus wieder? Kein diskreter PHY?

[idefix6]

Expandiert freebus wieder?

Ja, wenn hier Interesse besteht, würde ich mir mal die Arduino Platform anschauen, kann ja nicht so schwer sein.

Brauchen halt einen Atmel, der 2 UARTs hat (z.B. ATMega644) und mit 3,3V läuft.

[wintermute]

Brauchen halt einen Atmel, der 2 UARTs hat (z.B. ATMega644) und mit 3,3V läuft.

Wieso der zweite UART? Zum Programmieren?

[idefix6]

Wieso der zweite UART? Zum Programmieren?

ja, ein UART für den KNX der zweite für den Arduino Bootloader, damit man das Programm in den AVR bekommt ohne ein ISP zu brauchen.

[wintermute]

ja, ein UART für den KNX der zweite für den Arduino Bootloader, damit man das Programm in den AVR bekommt ohne ein ISP zu brauchen.

Ich persoenlich wuerde es paraktischer finden einen fertigen Mini auf Leisten zu stecken und den zum Programmieren einfach rauszuziehen. Denn nur mit den 2 Pins fuer den UART isses ja nicht getan, da fehlt dann ja mindestens nochmal nen Pegelwandler und der passt eh nicht mehr aufs Board (vermute ich). Man muesste also eh irgendwas drauf/rein/drunterstecken um zu Programmieren, dann koennte man auch gleich den ganzen Arduino aus der Platine nehmen.
Dazu kommt, dass ein fertiger Mini in China bloss ein paar Euro kostet, sicherlich weniger als der 644er und man nicht noch extra nen Programmer braucht um erstmal den Bootloader reinzubekommen...

Ausserdem - da bin ich aber nicht 100%ig sicher - waere der 644er nicht mit der aktuellen Arduino IDE kompatibel, nur mit einer aelteren Version.
Also wieso nicht einfach 2 Buchsenleisten aufs Board und einen fertigen Mini reinstecken? So mach ich das bei mir auch immer

Aber noch ne Frage: wieso nur 3.3V? Braeuchte man bei diskretem Aufbau nicht ohnehin einen Regler? Und waers dann nicht egal ob 3.3 oder 5V?

gruesse

[idefix6]

Aber noch ne Frage: wieso nur 3.3V? Braeuchte man bei diskretem Aufbau nicht ohnehin einen Regler? Und waers dann nicht egal ob 3.3 oder 5V?

Das mit den 3,3V hat zwei Gründe:
1. Alle Busankoppler ICs (z.B. den NCN) arbeiten mit 3,3V. Wenn man jetzt den AVR mit 5V betreiben wollte, muss man die Pegel wandeln
2. Bei 3,3V braucht der AVR viel weniger Strom, was mehr Luft beim Verbrauch lässt. Du bist ja beim Verbrauch auf 10mA pro KNX Gerät beschränkt.

[l0wside]

Das mit den 3,3V hat zwei Gründe:
1. Alle Busankoppler ICs (z.B. den NCN) arbeiten mit 3,3V. Wenn man jetzt den AVR mit 5V betreiben wollte, muss man die Pegel wandeln
2. Bei 3,3V braucht der AVR viel weniger Strom, was mehr Luft beim Verbrauch lässt. Du bist ja beim Verbrauch auf 10mA pro KNX Gerät beschränkt.

3,3V ist in diesem Bereich definitiv Standard.
Mit dem Schaltregler allerdings werden aus 10mA@30V dann 60mA@5V. Das sollte auch für einen ATMega reichen - oder?

Max