Entwicklungsblog Beta5/Final 1.0.0

[andi11]

damit hast du natürlich recht.
Aber die Baudrate ist 9600bit/s und nicht byte, und damit braucht ein bit so Pi mal Daumen 1ms. => An sich ausreichend.

Allerdings ist die Frage ob das überhaupt was bringt, denn ob ein Byte empfangen wurde liegt ja schon bei kleinen 8bit AVRs in einem Register und lässt sich damit theoretisch schneller abfragen als die Überprüfung ob genug Zeit vergangen ist.

Puffer komplett leer räumen wäre für neuere Controller vermutlich besser, aber ob die kleinen 8bitter das schon immer schaffen? Durch den externen Aufruf des KNX Tasks hat man hier etwas mehr Spielraum bei der Programmierung.

[Ing-Dom]

9.600bits/s

stimmt natürlich. kbaud ist ja die Symbolrate. Peinlich.

rdings ist die Frage ob das überhaupt was bringt, denn ob ein Byte empfangen wurde liegt ja schon bei kleinen 8bit AVRs in einem Register und lässt sich damit theoretisch schneller abfragen als die Überprüfung ob genug Zeit vergangen ist.

Puffer komplett leer räumen wäre für neuere Controller vermutlich besser, aber ob die kleinen 8bitter das schon immer schaffen? Durch den externen Aufruf des KNX Tasks ha

Also die AVRs haben einen Empfangspuffer in der Serial-Klasse. Da schreibt ohne zutun des User eine ISR die bytes in den RAM. Größe lässt sich über Ringbuffer.h steuern.
Bei den kleinen AVRs muss man nattülich mit RAM aufpassen.
Aber die sind eh nicht mehr unser Fokus, mit V1.0.0 denke ich sowieso deprecated.

SAMDs haben ja nach Core-Version einen RAM-Buffer oder eben nicht. Das wurde erst nachträglich eingebaut und Adafruit etc.. haben es ggf. übernommen oder auch eben nicht. Somit sind es beim SAMD ggf. nur ein Byte Hardware Buffer. (korrigiert mich, so verstehe ich das Datasheet).
mumpf du hattest doch damit mal gekämpft bzgl extended frames.


Der RP2040 hat 32byte rx buffer in hardware. Das reicht wohl für das langsame KNX.


Ich denke halt an die Situation, wo der Controller mal ggf. nicht alle 400µs gerufen wurde sondern ggf. etwas länger braucht. Somit staut sich dann etwas im rx buffer, wird dann aber nur sehr zögerlich verarbeitet, weil maximal 1 byte pro 400µs gelesen wird, obwohl ggf. schon das ganze Telegramm im Buffer liegt.
D.h. ich könnte es eigetlich SOFORT verarbeiten, warte aber 0,4 *23 ca. 10ms.
Das ist doch wenig sinnvoll ?

[Eugenius]

Wenn du meinst, dass es besser ist nicht zu warten, dann nur zu. Wir haben ja damals eine existierende Lib genommen und da war es so implementiert.
Es ist ja ganz einfach zu testen, setze 400 auf 1 oder 0 und schaue was passiert

[Ing-Dom]

Na klar, ich hatte aber auch irgendwie im Kopf, das du dich mal damit beschäftigt und was optimiert hast.
Und weiterhin findet sich ein Kommentar

// TODO: check for rx_state in tpuart and call rxtask repeatedly until telegram is received?!

Daher wollte ich vorher mal fragen welche Erkentnisse ihr da schon habt. man muss ja nicht alles doppelt machen.

[Eugenius]

Mit beta 4b habe ich eigentlich genau diesen Kommentar erledigt... es wird aus dem Buffer alles auf einmal gelesen, so, dass 400us für Task() nicht mehr zwingend sind. Aber, wenn Task sehr selten ausgeführt wird, dann wird ACK nicht rechtzeitig gesendet

[Ing-Dom]

stimm, durch das do-while wird alles aus dem buffer gelesen. Aber sehr langsam - 1byte pro 400µs. Wenn da 10 Byte im buffer hängen blockiert task() für 4ms, oder?

[STSC]

Wir nähern uns aber definitiv der public-beta-5.
Damit findet dann der Feature-Freeze statt und es wird nur noch auf Stabilität geschaut bis es dann zum final release kommt.

Stay tuned.

Wie geht es eigentlich mit Konnekting weiter? Im GitLab tut sich leider schon länger relativ wenig.

[tuxedo]

Es.tut sich prima was in den Branches. Sind schon seit längerem im internen beta5 Test bevor wir in den public Test gehen. Problem ist aktuell Zeit zu finden.

Werde mir die Lage noch ein bisschen anschauen, und wenn es im internen Test nicht schneller voran geht, geht's einfach so in den public Test.

An der Stelle also keine Sorge, da tut sich was, aber a) ist es nicht immer sichtbar, und b) geht es leicht der gerade zeitlich etwas langsam.