Ich hab' da mal wieder was gebastelt.

Es hat mich schon längere Zeit gestört, dass es kein einfaches USB-KNX-Interface in der Selfbus-Welt gibt. Klar kann man sich ein IP-Interface bauen, aber das ist nunmal ein komplexes Teil, besonders für einen Einsteiger. Ich vermute mal die meisten Einsteiger kaufen sich dann doch ein kommerzielles, vielleicht gebrauchtes Interface.



Also habe ich ein USB-Interface realisiert. Und wo ich gerade dabei war, habe ich ein paar Extras eingebaut.

Das IF hat verschiedene Betriebsmodi, die über einen Taster ausgewählt werden:

• Nur USB-KNX Interface, das entspricht der Funktion eines klassischen Interfaces. Dafür stellt es ein USB-HID Device dar.

In den anderen Modi meldet sich das Gerät als USB-Composite Device an und hat dann gleichzeitig ein HID-Interface und ein CDC-Interface, eine serielle Schnittstelle. (Einschränkung: Bei mir kann nur ETS 5.6 etwas mit einem Composite Device anfangen, ETS 5.5 findet dann schlicht keine Schnittstelle.) Die virtuelle serielle Schnittstelle kann für mehrere Funktionen genutzt werden:

• KNX-Monitor: Der KNX-Traffic wird in lesbarer Form auf der seriellen Schnittstelle ausgegeben.
• USB-Monitor: Hier werden die HID-Pakete, die zwischen ETS und KNX ausgetauscht werden, ausgegeben. Das ist eher eine Debug-Funktion.
• Programming Interface: Die virtuelle serielle Schnittstelle wird jetzt an einer von USB galvanisch getrennten Schnittstelle als Programmierinterface für ARM-Controller zur Verfügung gestellt. Damit kann man ohne weitere Hardware andere Selfbus-ARM-Baugruppen über FlashMagic programmieren. Auf dem Foto der Baugruppe ist der Programmierstecker der mit dem Kragen.

In dem Formfaktor, den ich jetzt erst mal aufgebaut habe, wird auf der KNX-Seite die TS-ARM, das "Eingangsmodul ARM" verwendet. Es wird auf die Basisplatine aufgesteckt. Auf der USB-Seite wird ein LPC11U24 als Mikrocontroller verwendet. Beide Seiten sind galvanisch voneinander getrennt, wie in der KNX-Spec gefordert. Natürlich könnte man den KNX-Teil auch fix auf der Basisplatine integrieren. So konnte ich einfach meine vorhandene TS-ARM aufstecken.

Der Formfaktor und noch viel mehr das zugehörige Gehäuse sind momentan ein eher mäßiger Kompromiss. Bei geschlossenen Gehäuse sieht man weder eine der LEDs, man kommt nicht an den Programmierstecker und kann die Taste nicht betätigen. Es ist also eher eine Aufbewahrungsschachtel. Ich wollte erst mal nicht mehr Aufwand in die mechanische Konstruktion stecken.

Ein nettes Feature ist es, dass zum Programmieren der Baugruppe keinerlei Programmierhardware benötigt wird. Der USB-uC erscheint über USB als Massenspeicher, wenn er leer ist (oder ein Jumper gesteckt wird). Und zur Programmierung des KNX-uC werden zwei Jumper umgesteckt, dann kann er über die virtuelle serielle Schnittstelle via USB programmiert werden.

Hi Florian,

danke für die Infos zu deinem neuen Baby.
Interessant finde ich insbesonders die Möglichkeit, auch mit dem Ding zu programmieren.

Wenn ich aber an eine USB Schnittstelle denke, fällt mir der Beitrag von GeminiServer ein: geraete-dev-f6/knx-schnittstelle-mit-tpuart-t448-10.html

Das fand ich auch ganz charmant: ein sehr einfach aufzubauendes IP-Interface, welches sehr zuverlässig funktioniert, erweitert um eine USB-Schnittstelle. Ist das nicht in weiten Teilen dasselbe?
Ich muss zugeben, dass ich das noch nicht ausprobieren konnte. Hört sich aber für mich sehr ähnlich an.

Grüße
Christian

Das kann man aber nicht direkt an einen PC anschließen und mit einer halbwegs aktuellen ETS benutzen. Die ETS verlangt ein USB HID-Device, über das ein EMI-Protokoll läuft.

Bei der "KNX Schnittstelle mit TPUart" wird das TPUART-Interface lediglich über eine virtuelle serielle Schnittstelle nach USB gewandelt. Wie ich das verstehe wandelt der KNXD das dann z.B. auf einem RaspberryPi in ein KNX-über-IP Interface. Aktuelle KNX-Versionen unterstützen die alten seriellen Schnittstellen nicht mehr direkt.

Ich habe die Schaltplan-, Layout- und BOM-Daten in's Github Repository eingespielt:
https://github.com/selfbus/hardware-incubation/tree/master/misc/USB-Interface%20ARM

Die Firmware folgt noch...

Und die Sourcen:
https://github.com/selfbus/software-arm-incubation/tree/master/misc/USB-Interface-bcu1

Hello
I have some problems with the compilation:

'TFifoErr' is not a class or namespace GenFifo.cpp / USB-IF_Usb / src line 36 C / C ++ Problem

any suggestions

thank you

TFifoErr is declared in "GenFifo.h". That sounds like the compiler did not find the file. Are there any warnings in the compiler messages before the error?

Do you use the .project / .cproject project files from the git repository?

Please have a look in the project properties / C/C++ build / Settings
At "MCU C++ Compiler" / "Includes" in the include paths there should be listed (among others) ${ProjName}/inc and ${ProjName}/inc/nxp

I confirm the presence of / inc and / inc / npx in "includes", I added BCU_TYPE = 10 to "preprocessor" and now I get a different error
"Type 'uint8_t' does not name a type BufferMgr.cpp / USB-IF_Usb / src line 52 C / C ++ Problem ",

yet there seems to be nothing missing!

The BCU_TYPE should not change a thing as the USB microcontroller does not use the sblib and does not know any different bcu types (it is hard-coded to BCU1 at the moment).

A quick google on you error message points to the used C++ language standard. For "enum class" and the direct use of uint8_t you need at least the C++ 2011 standard. What IDE version do you use? I use the MCUXpresso IDE v10.1.1. If your is much older, it might help to manually set the version. Settings -> Tool Settings -> MCU C++ Compiler -> Dialect. Try C++11 or newer. My setting is "Compiler default" which works for me. But the "default" might be different for older versions of the IDE.

yes, it was actually a compiler problem, I had LPCXpresso v. 7.8.0242 and switching to MCUXpresso I solved the problem of compiling USB-IF_Usb

I'm not very clear about the usefulness of this device but i hope i can use it to transfer the applications from ETS.
thanks a lot
Pasquale