ARDUINO am KNX

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

[l0wside]

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

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

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

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]

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 .

[Ing-Dom]

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.

Saucool! Den Berker-Sensoreinsatz halte ich auch für unpassend. Hast du auch ein passendes Gehäuse im Auge? Das darf man nicht vernachlässigen.
Gut in UP-Dosen passt z.B. das hier: http://www.conrad.de/ce/de/product/531270
Platinengröße (~45x30) müsste vom Gefühl her ausreichen.

[tuxedo]

Ich bestehe nicht auf den Sensoreinsatz. Kann auch was anderes sein. Hauptsache es passt. Da ich bei mir Holzständerwände habe, habe ich sowieso ausreichend Platz in der Wand ;-)

Bzgl. Repo:

Ich kann in der Github KNX-on-Arduino Organisation ein Repo anlegen und mit dem befüllen was bei dir aktuell drin liegt.

Oder du transferierst dein Repo zur Organisation:
https://help.github.com/articles/tra...-a-repository/

... und forkst es für dich wieder.

Das mit dem Transfer wäre wohl die sauberste Sache.

Vorteil der Organisation: Mehr als nur einer kann die Sache (Pull-Requests z.B.) verwalten. So bleibt's nicht am einzelnen hängen.

[tuxedo]

Hab mal ein wenig gebastelt was die abstraktion vom ganzen programmiermodell anbelangt:

Sample-Projekt
https://github.com/tuxedo0801/KnxTpU...4b4b065d6f4ff2
Neue KnxDevice Files:
https://github.com/tuxedo0801/KnxTpU...d725b8992fee46


ist noch lange nicht fertig, aber es kompiliert schon mal und beinhaltet ca. 80% dessen was ich schon anderweitig gebastelt hatte.

[tuxedo]

Bin gerade wieder ein bisschen an der Implementierung dran.
Hab da gesehen dass ich wohl etwas an der Struktur (Stichwort KNX_COMMAND_ESCAPE und KnxExtendedCommandType) umstellen müsste. Würde das gerne "diskutieren".
Wenn die Github-Organisation schon eine Code-Repo hätte, dann würde ich es da tun.

JuMi2006
Ich will dich ja nicht drängen, aber wie sieht's aus mit der zusammenlegung des Repos? Magst du das in die Wege leiten?

---
Das eigentliche Problem ist, dass es laut Doku wohl keinen wirklichen "KNX_COMMAND_ESCAPE" gibt. Ich hatte den glaub ich so zwischendrin mal eingebaut, aber das passt nicht richtig wenn man das weiter ausbauen will....

[update]
Wenn man wirklich _alles_ unterstützen wollte, müsste man wohl tatsächlich die Struktur ändern. Aber die MemRead/MemWrite Kommandos scheinen wohl doch die zu sein, die nicht im "extended" drin sind. Passt also.... noch!

[tuxedo]

JuMi hat das Repo übertragen und ich bastel schon wieder an der MemWrite Implementierung. Hab mal angefangen meine bisherigen Ergebniss und Erkenntnisse im Wiki aufzuzeichnen:

https://github.com/KNX-on-Arduino/Kn...o-Erkenntnisse

Den Code hierfür muss ich noch einchecken. Aber wenn jemand was dazu weiß: Nur her mit den Infos.

[tuxedo]

Ich komm nicht weiter .....

Wenn ich mit Calimero ein ein MemWrite mache, dann will er zuerst eine Property abfragen.
Also hab ich mich jetzt mal auf die Property-geschichte konzentriert.

Was ich im Busmonitor ud im Source von Calimero sehen kann ist, dass zuerste ein "connect" stattfindet. Den will Calimero zuerst beantwortet haben bevor es mit dem PropertyRead-request weiter geht. Aber das geht schief. Nämlich weil der Arduino die Connect-Anfrage nicht kennt und beantwortet.

Dummerweise werden die Connect-telegramme als grouWrite Telegramme erkannt?!

Hier mal der Vergleich zwischen einem Connect und einem tatsächlichen GroupWrite:

Connect:

Processing ...
--> KNX command write
buffer[0] hex=B0     bin=10110000
buffer[1] hex=FF     bin=11111111
buffer[2] hex=1     bin=1
buffer[3] hex=FF     bin=11111111
buffer[4] hex=14     bin=10100
buffer[5] hex=50     bin=1010000
buffer[6] hex=80     bin=10000000
buffer[7] hex=8A     bin=10001010
buffer[8] hex=3     bin=11
buffer[9] hex=44     bin=1000100
buffer[10] hex=BC     bin=10111100
buffer[11] hex=0     bin=0
buffer[12] hex=0     bin=0
buffer[13] hex=0     bin=0
buffer[14] hex=0     bin=0
buffer[15] hex=0     bin=0
buffer[16] hex=0     bin=0
buffer[17] hex=0     bin=0
buffer[18] hex=0     bin=0
buffer[19] hex=0     bin=0
buffer[20] hex=0     bin=0
buffer[21] hex=0     bin=0
buffer[22] hex=0     bin=0
Repeated: 0
Priority: 0
Source: 15.15.1
Target Physical: 15.15.20
Control Data: bin=0
Routing Counter: 5
Payload Length: 1
Command: hex=2 bin=10
First Data Byte  hex=A    bin=1010
Checksum matches
Processing ... *DONE*

GroupWrite:

Processing ...
--> KNX command write
buffer[0] hex=BC     bin=10111100
buffer[1] hex=11     bin=10001
buffer[2] hex=0     bin=0
buffer[3] hex=3F     bin=111111
buffer[4] hex=7     bin=111
buffer[5] hex=F2     bin=11110010
buffer[6] hex=0     bin=0
buffer[7] hex=80     bin=10000000
buffer[8] hex=FF     bin=11111111
buffer[9] hex=E7     bin=11100111
buffer[10] hex=DD     bin=11011101
buffer[11] hex=0     bin=0
buffer[12] hex=0     bin=0
buffer[13] hex=0     bin=0
buffer[14] hex=0     bin=0
buffer[15] hex=0     bin=0
buffer[16] hex=0     bin=0
buffer[17] hex=0     bin=0
buffer[18] hex=0     bin=0
buffer[19] hex=0     bin=0
buffer[20] hex=0     bin=0
buffer[21] hex=0     bin=0
buffer[22] hex=0     bin=0
Repeated: 0
Priority: 3
Source: 1.1.0
Target Group: 7/7/7
Control Data: bin=0
Routing Counter: 7
Payload Length: 3
Command: hex=2 bin=10
First Data Byte  hex=0    bin=0
Data Byte 2      hex=FF    bin=11111111
Checksum matches
Processing ... *DONE*

Ich hab extra mal in beiden Fälle den kompletten buffer-Inhalt mit ausgeben lassen.
Aber ich seh den Unterschied nicht...

Bisher habe ich mich an folgender Protokolldoku entlang gehangelt: http://www.mikrocontroller.net/attac...schreibung.pdf

Aber ich komme auf keinen grünen Zweig. Im Arduino-Code ist in Telegram.h schon ein Enum für den Connect vorgesehen:

// KNX Control Data (for UCD / NCD packets)
enum KnxControlDataType {
    KNX_CONTROLDATA_CONNECT = B00,      // UCD
    KNX_CONTROLDATA_DISCONNECT = B01,   // UCD
    KNX_CONTROLDATA_POS_CONFIRM = B10,  // NCD
    KNX_CONTROLDATA_NEG_CONFIRM = B11   // NCD
};

Aber speziell der Connect-Typ findet keine Anwendung. Der Enum an sich wird zusammen mit buffer[6] benutzt:

KnxControlDataType KnxTelegram::getControlData() {
    return (KnxControlDataType) (buffer[6] & B00000011);
}

Also die rechten zwei Bits. Hab mir das aus ausgeben lassen (siehe im Log die Zeile "Control Data", Angabe ist binärer String).

In beiden Fällen (connect/groupwrite) ist das B00 ...

Das verwirrende: Laut Code sind es die rechten zwei Bits aus buffer[6]. Laut oben genannter Doku ist buffer[6] aber das "Byte 6" und dessen rechten zwei Bits aber Teil des entsprechenden Kommandos?!?!? (vgl. Doku Seite 9 / Abschnitt 2.5.1)

Selbst wenn ich dann raus gefunden habe wo sich die beiden Nachrichten voneinander wie abgrenzen: Ich hab noch kein Plan wie die Connect-Antwort auszusehen hat.

Der Calimero Code ist zwar toll, aber so aufgeblasen und über viele Klassen verteilt, dass ich da nur schwer die passende Stelle finde.

Selbst wenn ich die Property-Sache erstmal ignoriere und weiter zu MemWrite gehe: Ohne sauberen connect komme ich auch da nicht weiter...


Any ideas?

[tuxedo]

Vielleicht sollte man sich mal das hier genauer anschauen??
https://github.com/franckmarini/KnxDevice

Vllt. ist das Problem ja hier schon gelöst.

[tuxedo]

Bin dabei die Lib zu Testzwecken etwas auszublasen damit ich mal verstehe was der TPUART von sich gibt wenn ich auf der anderen Seite mit Calimero versuche Daten zu schreiben. Der "CONNECT" ist immer noch "sagenumwoben" und im Arduino-Code noch gar nicht "aufgetaucht", weshalb wohl auch so ziemlich alles fehl schlägt was über die "verbindungslose" Multicast-Verbindung eine "tatsächliche" P2P-Verbindung braucht.

Liest hier vielleicht jemand mit der sich mit dem TPUART-Protokoll auskennt und kann was zum Programmiervorgang memwrite/memread bzw. propwrite/propread sagen?

P.S. Die letzte genannte Lib kann das auch nicht. Die ist nur etwas "hübscher" implementiert. Aber dort ist ebenfalls alles hardcodiert.

[tuxedo]

Hat schon mal jemand erfolgreich die KNX-Lib über ein Software-Serial laufen lassen?