ARDUINO am KNX

[JuMi2006]

Auf den Berker Sensoreinsatz bekommst Du nie und nimmer nicht den TPUART1 und den Atmega nebst Klemmen usw. drauf. Von einer Galvanischen Trennung mit entsprechenden Bauteilen mal zu schweigen.

Gern kann man das Repo gemeinsam pflegen, ich habe da eh nur wenig Zeit. Ich habe auch schon einiges an kleinen Sketch-Bausteinen für Programmier-LED und Taster, muss das nur raussuchen - und sowas dauert bei mir im Moment irgendwas zwischen 2 und 5 Tagen .

[tuxedo]

das bekommst Du aber nicht auf eine so kleine Platine.

Auf was beziehst du dich da jetzt? Auf den Größeunterschied TPUART 1 vs TPUART2?
Oder auf die Platinengröße für den Berker-Sensoreinsatz?

Ich versuche gerade den Atmega32u4 (Leonardo) mit USB-Port, Programmiertaster, Programmier-LED und KNX-Klemme auf eine Runde Platine zu pressen die in eine UP-Dose passt.
Das sieht sehr erfolgversprechend aus. Mal sehen was das am Ende kostet.

Wenn du da Hilfe brauchst, sag bescheid. Eagle-Grundkenntnisse hab ich. Mir fehlt es hier nur etwas an der Praxiserfahrung (praktikable Leiterbahnenabstände und größen, Pad-Durchmesser, ...).

Wie schauts mit dem Github-Projekt aus?

Wollen wir da ein gemeinsames Repo pflegen? Oder willst du erstmal deins als das Basis-Repo weiter führen?

Hast du schon mit den Arduino-Skeleton für das KNX-Device angefangen? Bin hier auch gerade dabei weiter zu machen. Passende Code-Abschnitte für Programmier-Knopf und -LED, sowie setzen der PA hab ich schon. Müsste das nur mal in Form bringen so dass man es universal einsetzen kann.
Aber primär versuche ich noch memwrite zu implementieren.

Gruß
Alex

[JuMi2006]

Die Heißlift beim QFN36 brauchst Du eigentlich nur fürs Bottom-Pad. Theoretisch könnte man das auch über GND-Vias von unten löten (Lötpaste).
Ansonsten nehm ich die Heißluft beim TPUART2 eigentlich nur zum fixieren und mach die Lötstellen danach klassisch. Bei gutem und ausreichendem Flussmittel kann man so auch die Pins des QFN36 löten.
Damits schneller geht hatte ich mir nen Reflow-Ofen aus nem Pizza-Ofen gebaut ... damits nicht Off-Topic wird natürlich mit Arduino-Steuerung -> https://knx-user-forum.de/forum/%C3%B...low-pizza-ofen

EDIT:
tuxedo, das bekommst Du aber nicht auf eine so kleine Platine. Ich versuche gerade den Atmega32u4 (Leonardo) mit USB-Port, Programmiertaster, Programmier-LED und KNX-Klemme auf eine Runde Platine zu pressen die in eine UP-Dose passt.
Das sieht sehr erfolgversprechend aus. Mal sehen was das am Ende kostet.

[tuxedo]

Eigentlich kann ich mit dem Lötkolben umgehen. Das kleinste das ich bisher mit dem Lötkolben gemacht/versucht habe, war SO-08. Das hat bestens geklappt.
Würde mir auch kleineres zutrauen.

Vom TPUART (oder wars der 2er?) hab ich hier irgendwo gelesen dass die Fehlerquote/der Ausschuss beim selber-löten sehr hoch sein soll ?! Deshalb hat mich da das löten abgeschreckt. Aber wenn ich mir jetzt so den TPUART (1) IC so anschaue, dann lässt der sich wohl tatsächlich prima selbst löten. Denke dann war es de 2er den man nicht so toll selbst löten kann (Heißluft...).

Dass es den AVR aus dem Leonardo z.B. auch in TQFP gibt wusste ich noch nicht.
Dann wäre ja alles beisammen zum selbst löten.


Wäre nur die Frage: Reicht der 1er aus? Scheinen sich ja primär in der Versorgungsspannung und der Bus-Belastung (10mA vs. bis zu 50mA) zu unterscheiden... Wobei 50mA deutlich besser klingen als 10mA...

[l0wside]

[habe Unfug geschrieben, wo ist der Löschen-Knopf?]

[Ing-Dom]

TPUART + ATmega32u4 selber löten... Wohl eher nicht. Deshalb wird es schon ein wenig teurer als 10EUR. Wenn man mal so rechnet:

Also den TPUART im SOIC - kein Problem. Mit ein klein wenig Löterfahrung bekommt man das hin.
TPUART 2 im QFN36 wird tricky, das gebe ich zu. Aber auch das geht, entweder mit Heißluft oder mit verlängerten Pads (hab ich aber noch nie gemacht)
Den AVR gibts im TQFP44, das hat ein 0.8er Pitch. Das ist definitiv lötbar. Ich hab letztens zum ersten mal einen FT232RL (SSOP28, Pitch 0.65) gelötet, das ging echt gut.

[tuxedo]

Bzgl. Github und der Organisation:

Als "Neuling" bzw. Nicht-Member sieht man nur die Repositories die angelegt wurden (hab jetzt mal ein "documentation"-Repo angelegt, damit überhaupt mal was sichtbar ist), sowie die Team-Member die ihre sichtbarkjeit selbst auf "public" gestellt haben.
Wie das geht steht hier: https://help.github.com/articles/pub...on-membership/

[tuxedo]

Mit dem öffentlich meinte ich die Member. Diese werden nicht angezeigt, wenn man nicht Teil der Gruppe ist. Wie kann man denn da als Neuling beitreten wenn man nicht anderweitig Kontakt hat wie wir über das Forum?

Hmm, gute Frage. Müsste ich mal schauen. Kannst mit deinem Account ja mal eine Test-Organisation anlegen. Dann kann ich schauen wie ich da rein komme.

Ja, das wäre schon ne gute Sache. 50€ wäre aber für meinen Geschmack zu teuer. Gefertigte Platinen in der Größe sollten für unter 10€ selbst bei kleinen Stückzahlen machbar sein. Mit etwas Masse dahinter auch Richtung 2-3€. Und die Bauteile kosten ja nix bis auf den TPUart. Die Bestückung wird eher das Problem.

TPUART + ATmega32u4 selber löten... Wohl eher nicht. Deshalb wird es schon ein wenig teurer als 10EUR. Wenn man mal so rechnet:

Arduino Leonardo/Micro bei Ebay: so um die 7EUR aus China
Siemens BCU: Knapp 30EUR (inkl. Versand)

Bist du schon bei fast 40EUR für ein Einzelstück

Wenn man das für nur 10EUR mehr so klein hin bekommt, dass es auf eine weniegr als 5x5cm große Platine passt und alles wichtige auf eine Stiftleiste herausgeführt ist: Das wäre top.

Sammelbestellungen sind okay (um den Preis zu drücken). Aber wenn man erstmal 1/4 Jahr warten muss bis sich genug Leute gefunden haben?!

Ich finde aber mit einem Pro Mini + zerlegtem Siemens BTM und einer Adapterplatine kann man auch fast alles realisieren. Da ich einen 3.3V Arduino einsetzen möchte (die meiste Peripherie ist 3.3V, man vermeidet viele Probleme) werde ich auf der Adapterplatine noch einen Levelshifter integrieren. Ich bau da mal einen Prototypen auf Lochraster und stelle das hier ein. Es wird auf jeden Fall so kompakt, dass es in eine tiefe UP-Dose passt

Für UP-Dose und wirklich einfache Dinge ist das ideal, ja. Allerdings hab ich gerne ne USB-Buchse. Deshalb sind gerade 5 Nanos zu mir unterwegs.

[Ing-Dom]

Mit dem öffentlich meinte ich die Member. Diese werden nicht angezeigt, wenn man nicht Teil der Gruppe ist. Wie kann man denn da als Neuling beitreten wenn man nicht anderweitig Kontakt hat wie wir über das Forum?

Am tollsten würde mir es gefallen, wenn wir ein Arduino-Board (mit Power eines Leonardo oder so) fertig angeschlossenem KnxTpUart hinbekommen.

Mein "Traum" wäre es, eine zwei Basisplatinen zu haben:

1) Sowas in der Größe wie den Berker-Sensor-Einsatz: Board mit Arduino + KNX-TpUart und diverse IO-Pins steckbar für eine individuelle Huckepack-Platine
2) Eine Basis-Platine, mit selber austattung, aber für ein Reg-Leergehäuse ...

Eigentlich unterscheiden sich die Platinen nur im Form-Faktor. Wenn das aber noch zu einem Preis von <50EUR/Stück möglich wäre (ggf. mit teil-selbstbestückung), wäre das absolut bombe... Damit würden sich Schaltaktoren und Co. mit wenig Aufwand selbst basteln lassen. Und wenn die Software dazu noch was taugt... *hammer*

Ja, das wäre schon ne gute Sache. 50€ wäre aber für meinen Geschmack zu teuer. Gefertigte Platinen in der Größe sollten für unter 10€ selbst bei kleinen Stückzahlen machbar sein. Mit etwas Masse dahinter auch Richtung 2-3€. Und die Bauteile kosten ja nix bis auf den TPUart. Die Bestückung wird eher das Problem.

Ich finde aber mit einem Pro Mini + zerlegtem Siemens BTM und einer Adapterplatine kann man auch fast alles realisieren. Da ich einen 3.3V Arduino einsetzen möchte (die meiste Peripherie ist 3.3V, man vermeidet viele Probleme) werde ich auf der Adapterplatine noch einen Levelshifter integrieren. Ich bau da mal einen Prototypen auf Lochraster und stelle das hier ein. Es wird auf jeden Fall so kompakt, dass es in eine tiefe UP-Dose passt!

[tuxedo]

Da wir noch kein Wiki haben, dokumentier ich mal hier:

Ich hab nachgeschaut wie das mit dem MemWrite funktioniert. Als Basis dient die Calimero-KNX-Lib für Java (Klasse ManagementProcedursImpl, ab Zeile 428).

Ein MemWrite macht folgendes:

Wenn "verifyByServer"-Flag gesetzt ist:

* readPropertyDesc ---> Das Enum hierfür gibt's schon im Arduino: KNX_EXT_COMMAND_PROP_DESC_READ
Object=0 // DEVICE_OBJECT_INDEX
Property=0 //DEVICE_CONTROL
Index=0
Sieht man im ETS Busmonitor: DeviceDescriptorRead
---> Muss entsprechend beantwortet werden. Was da drin stehen muss ist noch unklar. Calimero verwirft das aber so oder so.

* readProperty ----> Gibts im Arduino auch schon: KNX_EXT_COMMAND_PROP_READ
Object=0 // DEVICE_OBJECT_INDEX
Property=0 //DEVICE_CONTROL
Start=1
Elements=1
Das Ergebnis wird mit 0x04 "verODERt". KOmmentar dazu aus dem Calimero-Source:

// bit 2 is set for automatic management server verification (responds on
// memory write with a response containing the written data)

Das veroderte Ergebnis wird dann an die gleiche Stelle als Property zurückgeschrieben. Wenn ich den Kommentar richtig verstehe, dann dient das dazu dem KNX Gerät zu sagen: "Schick mir alles als bestätigung zurück was ich dir ein deinen Speicher schreiben will"

Für unseren Fall evtl. irrelevant?? Aber es wäre wohl kein großer Aufwand das so zu tun.

Danach wird das byte[] zusammengezimmert das dann gesendet wird. Und das ist der eigentlich interessante Abschnitt, weil der bestimmt wie man auf Arduino-Seite die Daten aus dem Telegram zu lesen hat.
Hier wird es etwas aufwendiger:

Zum einen wird ein byte[] aufgebaut das später gesendet wird. Zum anderen wird aber vorher das Gerät noch gefragt, wie groß die Häppchen (ASDU-Länge) sein dürfen die wir ihm schicken. Dazu wird wieder eine Property gelesen:

Object = 0
Property = 56 // MAX_APDU_LENGTH
Start = 1
Elements = 1

Das Ergebnis ist 1 byte, unsigned. Wohl gemerkt: APDU. Wir suchen aber ASDU ... Und das ist per Definition (???) 3 bytes kürzer.
Es gibt auch eine Default-APDU Länge von 15, für den Fehlerfall beim Abfragen der Property.
Falls unser Arduino diese Property also nicht kennt, würde der Default greifen. Besser wäre es aber, er wüsste es.

Dann kommt das byte[] mit den Daten dran:

         | 0    | 1     | 2 3 4 5            | 6 7 8 9      |10 11 12 13 |14..31|
         | code | flags | dataBlockStartAddr | startAddress | endAddress | data |
         | 0x20 | ...   | ...                | ...          | ...        | ...  |

code ist fest auf 0x20 eingestellt.
Flags wird mit dem berechnet (verifyWrite ist ein boolean den man beim Start der Methode angeben muss, siehe oben):

        int flags = 0x01;
        flags |= verifyWrite ? 0x02 : 0;

dataBlockStartAddr ist fest auf 0x0000
startaddress ist die die wir selbst angeben. Also die Adresse im EEPROM ab der geschrieben werden soll.
endAddress ergibt sich aus der Länge der zu schreibenen Daten und der Startadresse
data sind dann die Daten selbst. Calimero scheint hier keine Längenbegrenzung vorzuschreiben?!

Einmal das Array zusammengesetzt, wird das Array blockweise geschrieben. Die Blöcke sind so groß wie zuvor ASDU abgefragt bzw. ausgerechnet wurde.

Nach jedem Block kann (wenn verifyWrite gesetzt wurde) der Block zurückgelesen und vergleichen werden ob auch alles sauber angekommen ist.

Das war's dann auch schon.

Sprich: Die ersten 14 byte die wir auf der Seite des Arduino erhalten, definieren Startaddresse und Endaddresse, und somit wissen wir, wieviel wir geschickt bekommen und wieviel wir zu schreiben haben.

Ich seh schon. Das wird spassig das in Arduino-Code zu gießen...

[tuxedo]

Lad mich bitte dazu ein, habe mich eben bei Guthub angemeldet.

Hab ich soeben getan.

Wollen wir das nicht evtl. öffentlich machen?

Wie definierst du öffentlich: Das Projekt IST öffentlich. Man müsste nur das Repository erstellen, oder von einem der Forks, bzw. JuMi "Origin" zur Organisation transferieren.
Bis dahin ist die Organisation noch "leer".

Das Haupt-Repo von JuMi liegt hier: https://github.com/JuMi2006/KnxTpUart

[Ing-Dom]

Lad mich bitte dazu ein, habe mich eben bei Guthub angemeldet.
Wollen wir das nicht evtl. öffentlich machen?

[tuxedo]

Gefällt mir auch, dass es hier weitergeht!
Die Lib hat definitv Potential, Arduino hat hier eine kritische Maße erreicht dass es echt viele Lösungen schon gibt und die HW ist auch spottbillig

Am tollsten würde mir es gefallen, wenn wir ein Arduino-Board (mit Power eines Leonardo oder so) fertig angeschlossenem KnxTpUart hinbekommen.

Mein "Traum" wäre es, eine zwei Basisplatinen zu haben:

1) Sowas in der Größe wie den Berker-Sensor-Einsatz: Board mit Arduino + KNX-TpUart und diverse IO-Pins steckbar für eine individuelle Huckepack-Platine
2) Eine Basis-Platine, mit selber austattung, aber für ein Reg-Leergehäuse ...

Eigentlich unterscheiden sich die Platinen nur im Form-Faktor. Wenn das aber noch zu einem Preis von <50EUR/Stück möglich wäre (ggf. mit teil-selbstbestückung), wäre das absolut bombe... Damit würden sich Schaltaktoren und Co. mit wenig Aufwand selbst basteln lassen. Und wenn die Software dazu noch was taugt... *hammer*



Aber das ist wohl schon sehr "advanced". Back to the roots ...

Repo ... Hat JuMi schon bei Github ins leben gerufen
Forum ... sowas in der Art bietet Github doch auch?
Wiki ... ebenfalls über Github verfügbar

Name ... Ja, da hab ich auch schon drüber nachgedacht. Hatte mir viele Kombinationen überlegt. Das meiste war nicht aussprechbar oder hat nicht gut geklungen oder hätte ggf. Namenskonflikte mit KNX gegeben. Bin letzendlich bei "Karduino" gelandet. Kurzform für "KNX on Arduino".

[update]
Auf die Gefahr hin dass ich voreilig bin: Ich hab mal Nägel mit Köpfen gemacht und auf Github eine "Organisation" eingerichtet und die mir bekannten dazu eingeladen.
---> https://github.com/KNX-on-Arduino

[Ing-Dom]

Gefällt mir auch, dass es hier weitergeht!
Die Lib hat definitv Potential, Arduino hat hier eine kritische Maße erreicht dass es echt viele Lösungen schon gibt und die HW ist auch spottbillig.

Ich würde und werde hier auch gerne mitarbeiten, ich denke aber dass wir hier nicht weiterkommen ohne ein bischen Organisation und Disziplin.
Mit 4-5 Entwicklern hätten wir doch ein Basis wenn wir uns wirklich zusammentun und nicht jeder seine eigenen Brötchen bäckt.

Wie wäre es denn mit einem eigenen Projekt auf github, sourceforge etc.. mit Repo, Forum, Wiki usw? Ein bischen Doku hat ja auch noch nicht geschadet.
Ein eindeutiger Name, eindeutige Versionen usw wären ja auch nicht verkehrt.

[mode]

Gefällt mir sehr gut, da leicht verständlich und Abstaktionsebenen vom Atmel auf den PC überführt. Dazu noch der Verzicht auf Strings und wir bekommen eine wunderbare leichtgewichtige Lib, die auch noch Platz für umfangreiche Applikationen lässt.