Fragen zum Multi Interface und eigenem Sketch

[Sonnengruesser]

Hallo Eugenius ,
ich baue grade einen sketch von ProMicro auf das Multi Interface um. Folgende Fragen hab ich:
-) wie kann ich die digital-IOs direkt ansprechen ("Namen" der I/O Pins)? In deinem Schematic heißen die ja A2, D6, D7, etc. Das versteht der compiler aber nicht... D6 ist 6, A2 ist A2 - manchmal sieht man den Wald vor Bäumen nicht...
-) in deinen Firmwares auf Github hast du #include "wiring_private.h" inkludiert. Wo finde ich die? ist klar...
-) Bei HW1.2 musste ich einen EEPROM_Offset berechnen, damit ich den freien Speicherbereich feststellen konnte. Kann ich hier direkt auf den externen Speicher von 0 weg schreiben oder muss ich hier auch einen Offset berücksichtigen?
-) welches Board muss ich in der Arduino IDE auswählen? Wäre gut die Info auch in den Beispielsketches zu finden.

Danke erst mal.
VG Christoph

[Eugenius]

Hi,
Offset braucht man immer, da Konnekting Libryry viele Einstellungen speichert (KOs, GAs,...).
Dafür gibt es eine Funktion:
https://github.com/KONNEKTING/Konnek...evice.cpp#L878

d.h. einfach im Sketch aufrufen:

int offset = Konnekting.getFreeEepromOffset();

In der Arduino IDE muss du für Multi Interface "Arduino/Genuino Zero (Native USB Port)" auswählen

[Sonnengruesser]

Hi Eugenius,
danke für die vorigen Tipps, hab ich so eingebaut.

Ich hab jetzt ein ganz anderes Problem. Nach dem uploaden eines sketches aus der Arduino IDE erscheint der COMport nicht mehr im Win-Gerätemanager und wird auch in der IDE nicht mehr angezeigt. Es scheint als hätte ich den Bootloader überschrieben. Deshalb meine Fragen:

Edit: Ursache gefunden, eine inkludierte library hat das irgendwie geschafft...
Die Frage bleibt trotzdem:

-) Wie kann ich den Bootloader ohne Atmel ICE wiederherstellen?
Hat sich geklärt - mit einer Drahtbrücke 2x kurz hintereinander den "Reset"-Kontakt am JTAG Stecker auf GND verbinden, dann bleibt er im bootloader mode. Anschließend funktioniert der upload ganz normal.

Sorry für die Fragerei und schon mal danke für die Hilfe!
VG Christoph

[Sonnengruesser]

Eugenius, jetzt hab ich doch noch eine "Prinzipfrage". Oder ist das eher was für tuxedo?

Aktuell ist die KonnektingLib so aufgebaut, dass bei einem Fehler beim Konnekting.Init() ein Reset des µC durchgeführt wird. Das führt beim MI (SAMD21) dazu, dass beim Programmieren aus der Arduino IDE ohne KNX-Verbindung ca. alle 10s eine neue COM-Schnittstelle angelegt wird.
Das führt bei mir dazu, dass ich jedes Mal bevor ich einen Konnekting-Sketch uploaden kann, einen Blink-Sketch uploaden muss, weil mir sonst die COM-Schnittstelle abhanden kommt (Compilieren dauert zu lange).

Mein Wunsch: Auch nach einem Fehler im Konnekting.Init in den loop() zu kommen. Dafür müssen vermutlich die Errorstates vom Transceiver separat ausgewertet werden (nicht nur OK vs. NichtOK). Erst dann ist auch ein "Handbetrieb" für die Aktoren möglich. Oder gibt es das schon und ich habs bloß übersehen?
VG
Christoph

[Eugenius]

Hi, das Problem mit den COM-Ports habe ich auch.
Mein USB-Hub macht bei vielen SAMD-Reboots nicht mit. Dann muss ich meinen Hub vom Stromnehmen.
Aber normallerweise schaft man bis der Reboot kommt den Sketch hochzuladen. Man kann überlegen ob man da evtl. eine längere Pause einbaut.

SAMD Bootloader kann man nicht so einfach zerschießen oder überschreiben. Ich habe es zumindest noch nicht geschafft
Ansosten schnell 2 mal hintereinander RESET Pin gegen GND kurzschließen. (P.S. Multi Interface ist nicht zur Entwicklung gedacht... deswegen gibt es keine Reset-Taste)

[tuxedo]

Ich hab auf meinem Controller "ModularisM0+" für das Reg-Gehäuse auch keinen extra Reset-Taster, trotz dass ich damit entwickle.
Überlege mir aber einen auf den SWD-Port Aufsteckbaren Reset-Taster zu basteln :-)

[Sonnengruesser]

schnell 2 mal hintereinander RESET Pin gegen GND kurzschließen

Drahtbrücke liegt immer in Reichweite
Aber eigentlich übertrage ich nur einen Sketch vom Development board HW1.2 auf das MI - mit allen Problemen die so auftreten wenn man von AVR auf ARM wechselt...

[tuxedo]

Aktuell ist die KonnektingLib so aufgebaut, dass bei einem Fehler beim Konnekting.Init() ein Reset des µC durchgeführt wird. Das führt beim MI (SAMD21) dazu, dass beim Programmieren aus der Arduino IDE ohne KNX-Verbindung ca. alle 10s eine neue COM-Schnittstelle angelegt wird.

Das Problem liegt normalerweise an einer fehlenden KNX Verbindung: Die LIb versucht bis zu 10x die BCU zu resetten um mit einem sauberen Stand bei der Kommunikation zu beginnen. Schlägt das nach dem 10. mal fehl, wird der Arduino durch den Watchdog-Timer neu gestartet, was dann logischerweise zur Folge hat, dass der Bootloader neu anläuft und damit auch die serielle Schnittstelle des Arduino neu initialisiert wird.

Ich würde das so belassen. Denn im Fehlerfall ist es kein Fehler "von vorne" zu beginnen.
Eventuell kann man sich ein anderes/besseres Prozedere für die "selbstheilung" des System überlegen. Bis dato war das aber nicht notwendig.

[Sonnengruesser]

Ich hab den Reset jetzt mal so gelassen. HAbe irgendwann festgestellt, dass aufgrund der galvanischen Trennung zwischen KNX (MI) und der Treiberstufe sowieso nix funktioniert, sobald der Bus weg ist. Ein richtiger "Handbetrieb" ohne den Bus kann ich also sowieso nicht umsetzen.

Jetzt hab ich noch ein anderes Problem - vielleicht bin ich auch einfach nur zu blöd...
Ich will die Außentemperatur vom Bus im MI verwenden. Die Temp ist DPT9.001.
Den Empfang der Daten sehe ich im Debug, allerdings ist der zurückgelieferte Wert nicht richtig. Ich weiß, dass Debug.print Probleme mit float-Werten hat, also hab ich versucht mir mit dtostrf() weiterzuhelfen. Leider will er mir dtostrf nicht kompilieren...
Anderer Versuch war, die den Float Wert *100 und als Int ausgeben, dann kommt aber immer 0 raus.

Hat jemand einen Tipp für mich, wie ich sicherstellen kann, dass der Wert richtig ankommt?
Danke!

[tuxedo]

Wie sehen denn die 4 Bytes aus? Wie hast du versucht zu lesen?

Codebeispiel mit Beispiel Konsolenausgabe ist immer eine gute Idee.

[Sonnengruesser]

Problem gelöst!

Nur die Werte DPT1.0xx können wie folgt gelesen werden:

uint8_t Variable = Knx.read(COMOBJ_xxx)

Alle Werte außer DPT1.0xx müssen mit einer anderen Funktion gelesen werden. Z.B. ein Temperaturwert DPT 9.001 - intern eine Variable vom Typ float:

Knx.read (COMOBJ_xxx,  float Temperaturwert)

Ein entsprechendes Beispiel in den example sketches könnte nicht schaden.

[Masifi]

das müsste doch

float temperaturwert = Knx.read (COMOBJ_xxx)

lauten !?

[Sonnengruesser]

Eben nicht.
Für Byte-Werte gibt es diese "Kurzfunktion". Die kann aber nur Bytewerte zurückliefern.
Für alle anderen Werte muss du diese andere Version verwenden. Dann kannst du als zweiten Parameter jeden beliebigen Variablentyp angeben (natürlich muss der zum DPT passen).

Edit: Details sind in der KnxDevice.cpp nachzulesen

[tuxedo]

Wenn ich mich irre steht das auch so in der Doku... Rtfm ;-)

[Masifi]

Stimmt :-) das wusst ich schon gar nicht mehr !!!

So habe ich es früher mal gemacht:

  switch (index)
  {
    case 0 : /*object index 0 has been updaed*/               break;

    case 1 : /*object index 1 has been updated*/ Aktor1_CH1  = Knx.read(1); RecieveMessage = true; break;
    case 2 : /*object index 2 has been updated*/ Aktor1_CH2  = Knx.read(2); RecieveMessage = true; break;
    case 3 : /*object index 3 has been updated*/ Aktor1_CH3  = Knx.read(3); RecieveMessage = true; break;
    case 4 : /*object index 4 has been updated*/ Aktor1_CH4  = Knx.read(4); RecieveMessage = true; break;
    case 5 : /*object index 5 has been updated*/ Aktor1_CH5  = Knx.read(5); RecieveMessage = true; break;
    case 6 : /*object index 6 has been updated*/ Aktor1_CH6  = Knx.read(6); RecieveMessage = true; break;

    case 20: /*object index 20 has been updated*/ Knx.read(20,TempAussen); RecieveMessage = true; break; 
    case 21: /*object index 21 has been updated*/ Knx.read(21,HumAussen ); RecieveMessage = true; break; 
    case 22: /*object index 22 has been updated*/ Knx.read(22,TempWohn);   RecieveMessage = true; message_Wohn_count++; break; 
    case 23: /*object index 23 has been updated*/ Knx.read(23,HumWohn);    RecieveMessage = true; break;
    case 24: /*object index 24 has been updated*/ Knx.read(24,TempSchl);   RecieveMessage = true; message_Schl_count++; break; 
    case 25: /*object index 25 has been updated*/ Knx.read(25, HumSchl);   RecieveMessage = true; break;
    case 26: /*object index 26 has been updated*/ Knx.read(26,TempBad);    RecieveMessage = true; message_Bad_count++; break; 
    case 27: /*object index 27 has been updated*/ Knx.read(27,HumBad);     RecieveMessage = true; break;

    case 30 : /*object index 30 has been updaed*/ Motion_Gang = Knx.read(30); break;

    default: break;      
  }

Die Temp/HUM Werte waren damals auch alle Float