Release: 1.0.0 beta4a

[tuxedo]

Wir haben diese Woche als Zwischenschritt zu Beta5 eine Version 1.0.0 beta4a der KONNEKTING Device Library released. Diese ist in sehr weiten Teilen zu beta4 kompatibel. Zur Programmierung verwendet man nach wie vor die Suite in Version 1.0.0 beta4.

Wer beta4a nutzen möchte, schaut am besten mal in seiner Arduino IDE in den Library Manager. Dort steht die Version bereits bereit.

Weitere Details folgen dann im Wiki: https://wiki.konnekting.de/index.php/Project_status

Gruß
Alex

[andi11]

bin mal gespannt, was sich da geändert hat

[Eugenius]

andi11 , du hast gleich die Aufgabe, deine Wünsche zu testen: 644p Reset und ProgButton ohne Interrupt

[Eugenius]

Was gibt es neues in beta4a:

• kleine Bugfixes
• eine neue init-Funktion, siehe Beispiel: https://github.com/KONNEKTING/Konnek...h_without_pins
  • ProgButton ist jetzt optional (erfordert nicht mehr einen interruptfähigen Pin)
  • ProgLED muss nicht zwingend eine LED sein. Es wird einfach eine Funktion aufgerufen mit dem Programmierstatus. Benutzer kann eigene Implementierung machen (z.B. LEDs blinken lassen, auf einem Bildschirm anzeigen, vibrieren...)
• Support für STM32 Arduino Core wurde integriert
• Wir haben Reset-Routine angepasst. Theoretisch sollen jetzt alle AVRs ohne Anpassungen funktionieren. Offiziell werden nur diese zwei AVRs supported: ATmega328p und ATmega32u4

Was muss man beachten:

• durch eine Korrektur in den Memoryfunktionen haben wir int zu byte geändert (es sind nur die betroffen, die Funktionspointer auf einen externen EEPROM/FLASH nutzen).
  • byte readMemory(int index) {..}
  • void writeMemory(int index, byte val) {..}
  • void updateMemory(int index, byte val) {..}
• wegen Vorbereitung auf beta5 hat sich ein Array von byte auf int vergrößert. Es sind ALLE betroffen (sonst lässt sich der Sketch nicht kompilieren):
  • const int KonnektingDevice::_numberOfParams = sizeof (_paramSizeList); // do not change this code
  • ACHTUNG: da wir die Suite und somit den CodeGenerator noch nicht aktualisiert haben, wird ein byte generiert. Man muss also manuell auf int ändern.

Bekannte Bugs:

• ESP8266 funktioniert nicht mehr. Es war aber auch schon bei beta4 so. Das Problem liegt tief in der ESP8266 Core. Vermutung: durch die WLAN Funktionalität wird die loop-Schleife und somit wird Knx.task() nicht schnell genug ausgeführt und somit gehen einzelne Telegrammbytes verloren.

[andi11]

bin mal gespannt, was sich da geändert hat

Danke, werde ich machen, sobald ich den Fehler bei meinem Aktor gefunden habe der die Raffstores steuert, und mich noch bissl ärgert

[ChriD]

Bei meinen STM32'lern will es nicht so recht
https://github.com/KONNEKTING/Konnek...rary/issues/58

EDIT: Vergiss es! Mein Fehler!

[ChriD]

Frage zur neuen Init Methode.
Was ist wenn ich gerne einen ProgButton haben will aber auch die LED Funktion ?
Also die LED Funktion + Prog Button
Get das jetzt schon oder soll ich mir da in der Lib noch ne zusätzliche init Methode machen? (Bzw. wie kommt man ohne Prog taster in den prog modus?)

EDIT: Ach ich kann mir ja den Interrupt selber basteln und dann das toggleProgState darin aufrufen...

[tuxedo]

"Fast" ...

https://github.com/KONNEKTING/Konnek...evice.cpp#L221

progIndicatorFunc
	* function pointer to the function to toggle programming mode

Du musst der Init-Methode einen Funktionspointer geben, den Konnekting nutzen kann um den Programmiermodus darzustellen.

Das ist dann typischerweise genau die Funktion, die auch getriggert wird wenn du deinen "selbstkreierten" ProgButton physikalisch ansprichst.

Beispielsweise wenn du keinen echten Prog-Button hast der einen Interrupt auslöst, sondern das ganze über Display/Menü machst. Oder wenn man irgend einen Knopf 3x drücken muss um den ProgModus zu starten.

In dieser Funktion kannst du dann eine LED oder sonstwas (Anzeige im Display z.B. oder ein Piepser) ansteuern.

Um in der Lib den Prog-Mode anzuknipsen, kannst du toggleProgState() aufrufen.

[Eugenius]

Ein Beispiel gibt es als DemoSketch:
Eine Funktion die ProgStatus visualisiert:
https://github.com/KONNEKTING/Konnek...t_pins.ino#L87
Eine Funktion die den ProgMudus setzt:
https://github.com/KONNEKTING/Konnek..._pins.ino#L152

Ein anderes Beispiel (komplexer):
Funktion, die den ProgModus toggelt:
https://github.com/Adminius/GridSens...dsensor.h#L136
diese wird durch einen Button aufgerufen:
https://github.com/Adminius/GridSensor/blob/master/gridsensor.h#L170

Funktion, die ProgModus visualisiert (R,G,B LEDs blinken nach einander):
https://github.com/Adminius/GridSens...ter/rgb.h#L102
und die Variable progMode, die ProgModus im Sketch symbolisiert wird durch den Funktionspointer gesetzt:
https://github.com/Adminius/GridSens...dsensor.h#L132
Funktionspointerübergabe:
https://github.com/Adminius/GridSens...dsensor.h#L165

[Eugenius]

andi11 schon mal dazu gekommen? Ich würde gern issue abschließen

[andi11]

Zum testen auf der Hardware bin ich noch nicht gekommen.
Was mir auffällt (Ist ja ne ganze Mege geändert :
In "meiner" KnxTpuart.cpp ist bei mir das hier auskommentiert

 for (i = 4; _assignedComObjectsNb >> i; i++) divisionCounter++;

Ursache ist die Unterhaltung von hier https://knx-user-forum.de/forum/proj...01#post1060201
Ist das absolete?
Ist das verwenden einer Gruppenadresse für 2 Comobjects möglich? Ich hab das für meine Taster reingepfuscht. War ja ursprünglich das das komplett andere Commobject Handling für Beta 5 geplant.

Issue Thema Reset kann geschlossen werden, hab mir den Source dazu angeschaut.

[Eugenius]

Das Thema mit 2 gleichen GAs wird erst mit beta5 kommen, ist also noch nicht umgesetzt...