Beta4 - Fortschrittsthread

[eghetto]

Du kannst dich schon drauf verlassen. Du musst nur sicherstellen dass die Daten schnell genug geholt werden ;-)
Oder du musst dein Gerät nur in eine Richtung ausprägen:

ENTWEDER
Sensor --> dann empfängt es wenig bis gar nix, sondern sendet nur
ODER
Aktor --> dann muss es keine Sensoren lesen und damit nix senden, sondern nur Schaltbefehle annehmen, sprich lesen. Und Ausgänge schalten kostet quasi keine Zeit.

Naja, für meine (derzeitig geplanten) Einsatzgebiete würde eigentlich ein reiner Sender vollkommen ausreichen. Nichtsdestotrotz ist das Bild von der "Eierlegenden-Wohlmich-Sau" nun geringfügig getrübt. So ist das manchmal - das Leben ist kein Wunschkonzert.

Wie auch immer: Freu mich dennoch auf alles, was noch kommen mag!

Vielen Dank für deinen Einsatz soweit - vor allem für die ausführliche und die transparente Kommunikation!

[tuxedo]

Sobald ich den Software stand wieder fehlerfrei am laufen hab, werde ich mal schauen ob ich den Telegrammempfang nicht so umbauen kann, dass ein Telegramm am Stück empfangen wird. Da sollte die Problematik "etwas" entschärfen.
Würde ich das ganze auf einem modernen Prozessor entwickeln, wäre das kein Thema: Ein Thread für den Empfang/das Senden und einer für die Sensorik. Aber auf dem Arduino geht das nunmal nicht. Im Embedded-Bereich ist da eben alles ein wenig aufwendiger.

Theoretisch könnte man auch einen RaspberryPi Zero benutzen. Der ist zwar ein wenig größer, aber hat da mehr Power und kein Stress. Nur kann man den nicht aus dem Bus mit Strom versorgen und die ganze Komplexität eines Betriebssystems auf SD-Karte kommt eben hinzu...Und das will man auch nicht wirklich.

[tuxedo]

Bin da eben mehr oder weniher zufällig drüber gestolpert:

zusätzlicher UART über I2C/SPI:

https://www.sparkfun.com/products/retired/9981

Der verwendete IC hat einen 64byte (!!!) FIFO Puffer für die Sende und Empfangsrichtung. Das ist schon recht viel. Da passen ein paar KNX Telegramme rein.

Ist aber sicherlich nicht das gelbe vom Ei wenn man für den UART nochmal zusätzlich einen IC braucht. Auf der anderen Seite wäre so ein FIFO mit 64byte schon ganz praktisch.

[tuxedo]

Hab mir eben einen Arduino UNO zum debuggen mit meinem Atmel ICE bestellt. Könnte Samstag schon da sein. Mal schauen.
Ohne anständiges debuggen komm ich aktuell nicht weiter.
Sind hier nur HW Bastler oder hat's hier auch Arduino-Software-Profis?

[tuxedo]

So, mein UNO ist eingetroffen. Damit ich nicht immer alles zusammenstecken muss, hab ich mir ein Arduino-Konnekting-Entwickler-Shield gebastelt:

IMG_20160722_091824.jpg

Prog-Button und Prog-LED sind auf dem Prototyp Shield quasi schon drauf und mussten nur richtig angeschlossen und elektrisch entprellt werden. Als KNX Zugang dient ein "ausgepackter" Siemens BCU, der einfach aufgesteckt wird. Senkrecht steckt ein RS232-USB Adapter (mit FTDI) der für das entgegen nehmen der seriellen Debug-Meldungen zuständig ist. Rechts steckt ein Atmel ICE debugger dran, der per debugWire den Code zusammen mit Atmel Studio debuggen kann.

Das blöde an der Sache: Ich krieg meinen Test-Sketch in Atmel Studio fehlerfrei importiert. Aber jegliche Library-Anhängigkeiten werden dabei offensichtlich ignoriert. Sprich: ich kann's nicht compilieren. Bin da aber dran. Sobald das geht, kann ich hoffentlich mit der Fehlersuche anfangen...

Das alles zieeeeeht sich wie Kaugummi.

[heckmannju]

steckt ein RS232-USB Adapter (mit FTDI) der für das entgegen nehmen der seriellen Debug-

ist das mit dem FTDI wichitg?

[tuxedo]

Die "guten" haben einen FTDI Chip drauf. Die "billigen" haben einen CP2102, und die "schlechten" haben einen CH340G.

Zwischen FTDI und Cp2102 hab ich, bis auf den Preis, noch keinen Unterschied bemerkt. Funktionieren beide sehr gut. Einen mit CH340G würde ich nicht kaufen. Da ist die Treibersituation unter Windows schlechter und mit den Arduino Nanos die den verbaut haben gabs ja auch schon Probleme.

Was bei der Anschaffung eines solchen Adapters aber praktisch/wichtig ist: Umschaltbar zwischen 3.3V und 5V ... Bei mir ist das über einen Jumper gelöst. Andere haben einen kleinen Schalter drauf.

[heckmannju]

Hi,
ich hab da schon alles mögliche in ebay gesehen ab welchen preis kann es den ein echter FTDI Chip sein. Weis das jemand?
VG
Jürgen

[tuxedo]

Das ist schwer zu sagen. Also bei 2-3EUR wäre ich skeptisch. Bei 5-10EUR und nicht aus China dürfte man auf der sicheren Seite sein. Die betonung liegt aber auf "dürfte"... Im fälschen sind die Chinesen wirklich gut.

Du kannst aber auch ruhigen gewissens einen mti CP2102 nehmen. Hab ich hier genauso im Einsatz. Die bekommst du teilw. für unter 1EUR inkl. Versand.

[tuxedo]

So, nach langem hin und her kann ich nun mit dem Atmel Studio debuggen... Juhu.

Man muss nur wissen wie...

Tipp 1:
(Betrifft wohl die wenigsten hier Nicht unter Linux bauen und unter Windows debuggen! Das führt zu nicht auflösbaren Pfaden für die Source-Files
Mit der Arduino IDE unter Windows alles bauen, und dann in der Konsole der Arduino IDE nach der ".elf" Datei schauen. Die kann man dann in Atmel Studio mit "File -> Open -> Open Object File For Debugging" öffnen. Im "Solution Explorer" kann man dann Breakpoints setzen. Noch als DebugTool den Atmel ICE auswählen und dann über das Menü den Debugger starten und schon geht's.
Bin aktuell auf eine "Besonderheit" gestoßen die ich noch nicht weiß wie ich sie debuggen soll. Vermutlich ein Timing-Problem... mal schauen.

[tuxedo]

Ich glaub ich hab die Ursache:

Es wird der Destructor von KnxComObject aufgerufen und speicher frei gemacht. Dabei gehen immer die ersten zwei bytes flöten... Das sind genau die bytes, die in der Action stehen, die die zu sendenden Daten enthält..

Vielleicht ist hier ja ein C Experte der mir ein bisschen unter die Arme greifen kann:

// KnxComObject comObj = (objectIndex == 255 ? _progComObj : _comObjectsList[objectIndex]);
// if (!comObj.isActive()) {
// return KNX_DEVICE_COMOBJ_INACTIVE;
// }
// byte length = comObj.GetLength();

if (!(objectIndex == 255 ? _progComObj.isActive() : _comObjectsList[objectIndex].isActive())) {
return KNX_DEVICE_COMOBJ_INACTIVE;
}

byte length = (objectIndex == 255 ? _progComObj.GetLength() : _comObjectsList[objectIndex].GetLength());

Der auskommentierte Teil scheint die Ursache für den Fehler zu sein:

Ich halte das Com-Objekt als "Objekt", statt es, wie im nicht-auskommentierten Abschnitt einfach nur zu referenzieren.
Hab den nicht-auskommentierten Abschnitt noch nicht getestet, aber ich bin sicher damit geht's.

Da ich ähnliches an vielen anderen Stellen noch so mache, wäre es toll, wenn ich das nicht alles so "kompliziert aussehend" umbauen müsste.

Kann mir jemand einen Tipp geben wo ich im Auskommentierten Abschnitt was ändern muss damit beim verlassen des Scopes der Destructor nicht aufgerufen wird?
ich brauch hier doch sicher einen Pointer auf die Objekte... aber mit den Pointern stehe ich als alter Java'ianer auf Kriegsfuß ..

Gruß
Alex

[tuxedo]

So, neuer Tag, neues Glück.

Nachdem ich AtmelStudio nun durchschaut habe, konnte ich die fehlenden Libs dem Projekt hinzufügen und den gesamten Code mit AtmelStudio sowohl bauen, als auch auf den Uno aufspielen. Debuggen hat dann auch prima funktioniert und die Code-Änderung zeigt Wirkung.

Es geht voran...

[tuxedo]

Das Problem mit dem Destructor konnte ich auch lösen. So langsam freunde ich mich mit den Pointern an (aber mögen tu ich sie trotzdem nicht).

Des Rätsels Lösung:

 KnxComObject* comObj = (objectIndex == 255 ? &_progComObj : &_comObjectsList[objectIndex]);
byte length = comObj->GetLength();

Mit "*" hat man nur einen Pointer auf das Objekt bzw. dessen Instanz, statt ein neues Objekt (gleicher Art und Einstellung) in den RAM zu legen. Und mit "&" holt man die "Adresse" einer Instant und füttert damit den Pointer.
D.h. es ist kein neues Objekt, sondern nur eine Referenz auf ein bestehendes. Damit wird der Destructor auch nicht aufgerufen (weil die Objekt-Instanz nicht nur in diesem lokalen Scope lebt).
Da man nun aber mit Pointern arbeitet, muss man "->" statt "." für einen Funktionsaufruf nutzen. Und das war dann auch schon die ganze "Magie"...

Seit Wochen konnte ich nun das erste mal wieder ein Device über die Suite programmieren.

Der Umbau hat nun folgenden Vorteil gebracht:

Statt wie bisher

KnxComObject KnxDevice::_comObjectsList[] = {
    /* don't change this */ Tools.createProgComObject(),
                            
    // Currently, Sketch Index and Suite Index differ for ComObjects :-(
                            
    /* Sketch-Index 1, Suite-Index 0 : */ KnxComObject(KNX_DPT_1_001, COM_OBJ_LOGIC_IN),
    /* Sketch-Index 2, Suite-Index 1 : */ KnxComObject(KNX_DPT_1_001, COM_OBJ_SENSOR),
};
const byte KnxDevice::_numberOfComObjects = sizeof (_comObjectsList) / sizeof (KnxComObject); // do no change this code

kann man sich nun das erstellen des Programmier-KOs sparen und der Index passt nun zu dem in der Suite:

KnxComObject KnxDevice::_comObjectsList[] = {
    /* Index 0 */ KnxComObject(KNX_DPT_1_001, COM_OBJ_LOGIC_IN),
    /* Index 1 */ KnxComObject(KNX_DPT_1_001, COM_OBJ_SENSOR),
};
const byte KnxDevice::_numberOfComObjects = sizeof (_comObjectsList) / sizeof (KnxComObject); // do no change this code

Das heißt nun aber auch, dass man seinen Sketch anpassen muss (z.B. KO Index jeweils um 1 verringern) um mit beta4 arbeiten zu können.
Wird hier und da noch ein wenig anpassungen geben, aber das ist wohl die größte (und leider bisher aufwendigste) Änderung.

Was ich euch leider noch nicht ersparen kann, ist die zusätzliche Zeile mit "_numberOfComObjects"... Aber wenn ich dafür einen Weg finde, dann kommt das auch noch weg.

[tuxedo]

Und wieder gibt es Neuigkeiten für die beta4 der Suite:

Die Standardsprache habe ich von deutsch auf englisch umgestellt. Wird ein deutschsprachiges Betriebssystem erkannt, wird auf automatisch auf deutsch umgestellt. In allen anderen Fällen bleibt die Anwendung auf englisch.

Daneben habe ich an der Erkennung der KNX Verbindung gearbeitet, bzw. arbeite noch daran (ein Screenshot aus meiner Entwicklungsumgebung):

Bildschirmfoto vom 2016-08-06 08-06-07.png

In ersten Tests wird eine Routing-Schnittstelle zuverlässig erkannt. Nützlich ist das vor allem für diejenigen, die mehrere Netzwerkschnittstellen haben und KNX Routing nutzen.
Wie und ob ich eine IP-Schnittstelle erkennen kann, muss ich noch testen. Könnte aber sein dass das nicht mehr in beta4 kommt.

[henfri]

Klasse. Danke!