Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39

[tpm88]

Angehängt die Korrektur von 00_CUL.pm nebst geänderter Erkennung der Timestamp Option zum Test.

Hallo Ansgar, Martin,

die letzte Korrektur läuft bei mir perfekt (Testsuite 2x fehlerfrei durchlaufen). Diese Versionen (CULv3 99.65  und 00_CUL.pm) aus dem vorherigen Post werde ich erst mal so beibehalten.

Gute Arbeit, danke
Tobias

[noansi]

Hallo Tobias, hallo Martin,

anghängt noch eine 00_CUL.pm Variante, die entsprechend Martins Vorschlag doch alle TimeStamps zur Delaykorrektur nutzt.

Gefühlt läuft die noch etwas besser, als die letzte.

@Tobias: Könntest Du die bitte auch nochmal testen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und Danke, Ansgar.

[tpm88]

Hallo Ansgar, Martin

anghängt noch eine 00_CUL.pm Variante, die entsprechend Martins Vorschlag doch alle TimeStamps zur Delaykorrektur nutzt.

Gefühlt läuft die noch etwas besser, als die letzte.

Kann ich nicht bestätigen - die vorherige Variante  (http://forum.fhem.de/index.php/topic,24436.msg214758.html#msg214758) läuft bei mir besser.

Code: [Auswählen]

set wz_Thermostat getConfig
set wz_Thermostat burstXmit

Beim getConfig auf den RT-DN gefolgt vom burstXmit habe ich jetzt reproduzierbar einen Resend und meistens (immer?) folgende Warnungen im Logfile:

Code: [Auswählen]

2014.11.07 11:50:03 3: CUL_HM set wz_Thermostat getConfig
2014.11.07 11:50:04 3: CUL_HM set wz_Thermostat burstXmit
2014.11.07 11:50:11 1: PERL WARNING: Argument "8D" isn't numeric in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 2480.
...
2014.11.07 12:07:39 3: CUL_HM set wz_Thermostat getConfig
2014.11.07 12:07:39 3: CUL_HM set wz_Thermostat burstXmit
2014.11.07 12:07:41 1: PERL WARNING: Argument "D9" isn't numeric in numeric eq (==) at ./FHEM/10_CUL_HM.pm line 2528.

Der hmInfo configCheck mault nach Auftritt einer obigen Warnung dann auch jeweils "missing Register list" an.

Code: [Auswählen]

fhem> set hm configCheck

configCheck done:

 missing register list
    wz_Thermostat_Climate:      RegL_01:

Nach einem weiteren getConfig auf den entsprechenden Kanal ist dann alles wieder in Ordnung.

Gruß
Tobias

[noansi]

Hallo Tobias, hallo Martin,

dann wieder angehängt die Variante mit delay Korrektur nur nach Empfangs TimeStamps.

Diesmal mit Kommentar im Quelltext zum Credits Stand in der TimeStamp.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar

[tpm88]

Hallo Ansgar, Martin,

ich habe jetzt mit der aktuellen Kombi (00_CUL und CULv3 FW mit Timestamps) ein Firmware Upgrade auf einen HM RT-DN versucht. Das geht aber schief, weil die 1% Regel zuschlägt. Vorher hatte ich stundenlang über die CUL keine Kommandos ausgesendet - der Stundenzähler muß also bei 0 gestartet sein.

Code: [Auswählen]

2014-11-08 16:51:58 CUL_HM wz_Thermostat CMDs_FWupdate
2014-11-08 16:51:58 CUL_HM wz_Thermostat set_fwUpdate /opt/fhem/FHEM/firmware/RT_DN/hm_cc_rt_dn_update_V1_4_001_141020.eq3
2014-11-08 16:52:02 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f1301a00b048828274400caf1103421f220dec88647c79f8d69973b009fed97d7ac8e1add2edcf85e0aa0fef5ee690b80
2014-11-08 16:52:02 CUL myCULv3 UNKNOWNCODE 813204xx0101a001f1301a00b04c028274f00caf1103421f22044aa778ef813d0f02bac8854a9d1bec01d42ad51456f135a4c5
2014-11-08 16:52:05 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f1301a00b060428278b00caf1103421f2201b29a46f107728d54de3ce89770152ac68daf2ac6dc35ebb613382f02d1780
2014-11-08 16:52:05 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f1301a00b063a28279500caf1103421f220f98f9cb28781d18ad354bd0ec1fcbfd616609cf74c80
2014-11-08 16:52:06 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b066d28279e00caf1103421f220d02393eb7513858dd66854799d0dc533dbd58daa1e615c1
2014-11-08 16:52:06 CUL myCULv3 UNKNOWNCODE 812704xx0101a001f1301a00b0676201fa220caf1103421f220ef59c6b2aac691dc41fec2c0d53480
2014-11-08 16:52:09 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b07dd2827da00caf1103421f22083a6e5a2044ab79300eb455a11dd24e0f6b86994fb775780
2014-11-08 16:52:11 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f1301a00b08152827e500caf1103421f220a9d114dd6863e9a63cb7537e7110e236afe91542e280
2014-11-08 16:52:12 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09702827f800caf1103421f2203645e73e4fe946f1458f9b4fd9f4ba27d9131f132c0d80
2014-11-08 16:52:12 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09a328270100caf1103421f220c58b26437ee72b784a5bf9cf0a0ba5ccada165a8e7d87
2014-11-08 16:52:13 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f1301a00b09e028270e00caf1103421f2205dcff1b9f644c5eb5042249dfbbdb562eb3a348792e380
2014-11-08 16:52:20 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f1301a00b0d752827b800caf1103421f2203c8244d3c8b6529b4226654b491aba303a68c155af4a6be
2014-11-08 16:52:22 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b0e492827de00caf1103421f220769b7145cfa33337dfe0ca4d63ad612ee58b1a8409cff8b6fb1e04b2ed4b80
2014-11-08 16:52:22 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b0e51201fe220caf1103421f220727dc5b9108609ae6fd27bd347ab
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b0ebd201ff620caf1103421f22035328f5903ab0d35a2872ebe3ada
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 813104xx0101a001f2301a00b0eea2827fc00caf1103421f220af9d0606ce251cd99c34f4df6368125acbf407c89b0756335
2014-11-08 16:52:23 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b0ef3201f0020caf1103421f2200354318aa7753737eed4e283855bf4f3a26cfd37c47080
2014-11-08 16:52:24 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b0f3628270500caf1103421f220946304debe62f8564832dd7b657aee7f3fd587e48480
2014-11-08 16:52:24 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b0f6d28270f00caf1103421f220556e0e9aca89e7746b9cef8ff430a20d27fc6d1e7d80
2014-11-08 16:52:25 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b0fa528271a00caf1103421f220b9bc5ba199bb259bd8afb431c81517bd7a58e90087cc5
2014-11-08 16:52:26 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b104928273900caf1103421f22021c097ca13e168badd9423acff4268a684ecd7056a31ab2e5d5d72d87d7780
2014-11-08 16:52:26 CUL myCULv3 UNKNOWNCODE 812e04xx0101a001f2301a00b107f28274300caf1103421f220233253166953ba4733511b720a384c634b2783d26a80
2014-11-08 16:52:27 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b10ea28275600caf1103421f2201e8d2b7e74bb2821753275a04e3c6721108d990c261eeb071a5032893e7f80
2014-11-08 16:52:27 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b10f3201f5a20caf1103421f2201370f65778d3243ec3aa9781c45
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b11c228277e00caf1103421f220a42bb529cdb2b00891d360288d7814dd635ba613ba9055f06172c56d469880
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f2301a00b11cb201f8220caf1103421f2204dfb3435e1e9665626574ad775a
2014-11-08 16:52:29 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b11f928278900caf1103421f2201cdbe03307150a08f04f6a88e4a0aa2b1285c8f22ac06
2014-11-08 16:52:30 CUL myCULv3 UNKNOWNCODE 812c04xx0101a001f2301a00b123428279500caf1103421f22051dea0a0f0b219fc24de576bdaaa317f5189544
2014-11-08 16:52:31 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f2301a00b12962827a500caf1103421f2206757b16b747ab89294c96ab0e407f90d607509c11fd5af900e98d665667780
2014-11-08 16:52:31 CUL myCULv3 UNKNOWNCODE 812d04xx0101a001f2301a00b12cb2827af00caf1103421f220a8cea62ab47b8cdd3f03287c948ab7832528c08180
2014-11-08 16:52:32 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f2301a00b13362827c300caf1103421f2202586748598960c12737178327981544fd00f140524a66ad
2014-11-08 16:52:33 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f2301a00b13a72827d900caf1103421f220cc0820bbe63082746b9c6ebe2a58896a1544b21123a91
2014-11-08 16:52:34 CUL myCULv3 UNKNOWNCODE 812f04xx0101a001f3301a00b14112827ec00caf1103421f220b2aa37854f8ede2c530f60888985899c30a8373a968b9
2014-11-08 16:52:35 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b148428270000caf1103421f220fffd39d1f36a51f69148b4be145f0898b3fd4a9e05d49f38f04ab74a488f80
2014-11-08 16:52:35 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b14f428271600caf1103421f220466768e3eef7b5bf590b99d716bb10c5fba9dbd528908f7dccdab695902f80
2014-11-08 16:52:36 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f3301a00b152828271f00caf1103421f22062ed0d7f0e4956dabe3c9f8f15d8291d72d547e89f4ecd80
2014-11-08 16:52:37 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b15c428273b00caf1103421f220cb819b5613d2e094b7de372514305232ba89b5b59996e398175123ce922b80
2014-11-08 16:52:38 CUL myCULv3 UNKNOWNCODE 813004xx0101a001f3301a00b166528275900caf1103421f220091b1d039e69d19bc78e42a2eba1d07b035bb00978fa4f9
2014-11-08 16:52:39 CUL myCULv3 UNKNOWNCODE 813704xx0101a001f3301a00b16d128276d00caf1103421f2205f88bc20551010c9b29c47f11cce91800bf8b88266ea8f4faca47d49c6da80
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE 812604xx0101a001f4301a00b177e201f9020caf1103421f220bc435e618f649a1ade810bd0ec6
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:41 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:42 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:42 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:46 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:47 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:47 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:51 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:52 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:52:57 CUL myCULv3 UNKNOWNCODE LOVF
2014-11-08 16:53:02 CUL_HM wz_Thermostat fwUpdate: fail:Block91
2014-11-08 16:53:02 CUL_HM wz_Thermostat CMDs_done_FWupdate
Gruß,
Tobias

[martinp876]

. Das geht aber schief, weil die 1% Regel zuschlägt

sollte wohl nicht.
ist die Änderung der Geschwindigkeit einkalkuliert? der update wird u.a. mit highspeed gemacht um diese Regel nicht zu verletzen.
Das muss unbedingt geändert werden.

unknown code ist ebenfalls nicht ok. Da fehlt der Kenner "A" für HM

[noansi]

Hallo Tobias, hallo Martin,

der Credits10ms Zähler wird auf 1800 (statt 900 wie zuvor) begrenzt. Es stehen also (nach entspr. Ansparzeit ohne Senden) maximal 1800 x 10ms Sendezeit zur Verfügung, um "am Stück messages" senden zu können.

Gesendet wird aber in Paketen (messages), so dass die Anzahl Pakete schon allein durch den Credits10ms counter begrenzt wird. Aber...

Vor jeder messages (Paket) wird aber auch noch eine Präambel gesendet. Ist das Burst Bit im zu sendenden Paket gesetzt, dann wird eine 360ms Präambel gesendet (zum Aufwecken). Ansonsten wird eine 10ms Präambel vor jeder message gesendet.
Für die eigentliche Message fallen immer mindestens 10ms (kleinste angebrochene Einheit) an.

@Martin: Du schaltest auf FUP Mode, nehme ich an?

D.h. mit Burst bit werden 36+1=37 credits verbraucht und ohne Burst bit 1+1=2 credits.

Wenn das Gerät mit Burst Bit bei jeder message geweckt werden muss, schlagen nach spätestens 48 messages (ohne eventuelle Acks?) die credits zu.
Wenn das Gerät nur am Anfang aufgeweckt werden muss (Burst Bit nur beim ersten Paket), dann aber wach bleibt, wären (ohne eventuelle Acks?) 881 messages möglich, bis die credits zuschlagen.
@Martin: 10_CUL_HM.pm muss das Burst Bit entsprechend setzen (oder löschen).

Da offenbar noch Pakete empfangen und bestätigt werden, schlägt die credit Begrenzung dann entsprechend früher zu.


Im FUP Modus bestimmt also nur die

Burst Zeit in ms/10 + 1

die jeweils zu verbrauchenden Credits (die eigentliche Sendenachricht steckt in dem +1).

Ohne FUP Modus sind es

(Burst Zeit in ms + zu sendende Bytes * 8bit * 0.1ms/bit) / 10 + 1

credits, die nach Berechnung in der Firmware pro message verbraucht werden (+1 für angebrochene Zeit bzw. Rundungsfehler).


@Martin: Wie wird eine Firmware gesendet? Bleibt das Gerät wach, wenn es die erste Firmware message erhalten hat?
Die UNKNOWNCODE Meldungen sagen mir erst mal nichts. Ich nehme nur an, dass es Quittungen vom Gerät sein sollen?
Die Firmware würde hier nur "A" schlabbern, wenn der TTY-Sendepuffer an den Hostrechner überläuft und damit die Daten nicht schnell genug via Schnittstelle an den Hostrechner übermittelt werden können. Ggf. müsste da noch ein busy wait rein, um bei vollem TTY-Puffer entsprechend zu warten.

In jedem Fall muss die Creditsauswertung vor und während eines Firmwareupdates in 10_CUL_HM.pm und/oder 00_CUL.pm erfolgen, was derzeit nicht implementiert ist.

Frimware Update kann ich leider mangels Hardware nicht testen.

Gruß, Ansgar.

[noansi]

Hallo Martin,

angehängt eine Testversion der Firmware CUL_V3.hex und 00_CUL.pm (beides nebst Quellcode in der zip Datei).

Bitte beachte, dass ich die Definition des groben Credit10ms flags geändert habe (vgl. 00_CUL.pm Kommentare in parse), damit die ungenutzten codes bei Bedarf sinnvoller erweiterbar sind.

Tobias hat damit nun die hm_cc_rt_dn_update_V1_4_001_141020.eq3 erfolgreich geflasht und dafür etwas mehr als 900 credit10ms verbraucht.
Wenn Du also testen möchtest, dann checke bitte erst die credit10ms (1800 ist Obergrenze entsprechend 100%), bevor Du einen Flash Versuch unternimmst.

Ich habe die Präambel im FUP Modus auf 1ms reduziert, was offenbar gut geht und rechne die credits mit subcredits10ms. Damit reichen die credits für das RT_DN update.
Es sind dabei etwa 91000 Bytes übertragen worden, wenn ich mich nicht verechnet habe, Nutzdaten ca. 68000 Bytes

Nun müsstest Du für ein Update bei mangelnden Credits entweder (im Hintergrund) warten bis genug credits für ein gewünschtes Funkupdate vorhanden sind oder eine Fehlermeldung zu mangelnden credits ausgeben.

@Tobias: kannst Du bitte nochmal testen, danke!

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

PS: Es ist sind weiterhin auch meine nur teilweise getesteten Slow-RF Änderungen drin. Da sind noch unschärfen möglich.

[noansi]

Hallo Martin, hallo Tobias, hallo weitere Testwillige,


anghängt eine neue Testversion für Firmware und 00_CUL.pm.

In 00_CUL.pm ist mir noch ein Fehler in Parse bezüglich der $dmsg Länge aufgefallen, was insbesondere für Nicht-ASKSIN Protokolle teilweise fatal war.

In der Firmware habe ich noch die Interrupt Reentranz für USB verbessert (denke ich jedenfalls  ). Die Firmware ist für CUL_V3 und COC jeweils als HEX in der zip Datei.

Edit: Anhang gelöscht, da update siehe unten.


Gruß,

Ansgar.

PS: Es ist sind weiterhin auch meine nur teilweise getesteten Slow-RF Änderungen drin. Da sind noch Unschärfen möglich.

[tpm88]

Hallo Ansgar,

auch diese letzte Kombi funktioniert in meiner HM-Umgebung perfekt.

Testfall getConfig bei  RT-DN Thermostaten: Keine pending commands, MISSING ACKs, Resends etc...
Testfall HM Firmware Update beim RT-DN: funktioniert jetzt fehlerfrei ohne LOVL, falls der credit10ms counter beim Start >= ca. 1000 ist

Gruß
Tobias

[noansi]

Hallo Tobias,

danke für Deine Tests!

Da derzeit keine größeren Firmwareupdates bei eq3 zum Download zu sehen sind, ist das erst mal der worst case, der mit den Credits von 1800 durch geht.
Sieht also bisher alles gut aus.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

da die Tests positiv verlaufen, mach ich mal den Anfang mit Updatewünschen.

Als erstes ein Änderungswunsch in clock.c. Die alte Zählweise hat bei den Sekunden den Haken, schon mal Sekunden zu überspringen, wenn der Prozessor länger als 8ms für einen kompletten Hauptschleifendurchlauf benötigt. Das hat auch den Nachteil, das credits10ms gelegentlich nicht hochgezählt werden.
Konkret in ASKSIN passiert so was gelegentlich beim Umschalten auf Senden, da dabei auf einen freien Sendekanal gewartet wird, was durchaus etwas dauern kann.
Daher habe ich den zyklischen Zähler in einen Intervall-Zähler geändert, siehe Code. Das sollte so weniger Sekunden verlieren und damit weniger credits vergeuden.
Wenn Dir ein Grund bekannt ist, der dagegen spricht, es so zu ändern (also lieber eine Sekunde verlieren aber dafür im Sekundentakt bleiben), ich könnte auch ohne diese Änderung leben. In meinen Testgeräten (CUL_V3 un COC) habe ich noch keine Probleme damit feststellen können (allerdings bei COC auch Onewire ungenutzt).

Außerdem ist ein Ergänzungswunsch zu einer get_timestamp Funktion, die die aktuellen Ticks Timer0-Interruptsicher liest, enthalten. Das benötige ich später, um die TimeStamps bei ASKSIN sauber auslesen zu können. Bisher kann ein Timer0 Interrupt, der ausgerechnet beim Nicht-Interrupt-Lesen der Ticks zuschlägt zu falsch gelesenen ticks-Werten führen, wenn beim Hochzählen im Interrupt Byteüberläufe auftreten.
Ich habe es aber auch in clock.c schon genutzt, wie Du am Code siehst.
Sofern HAS_GET_TIMESTAMP nicht definiert ist, bleibt das aber noch beim Alten.
HAS_GET_TIMESTAMP wäre dann noch in board.h zum testen zu definieren. Bei CUL_V2 würde es wohl (derzeit) zu Speicherproblemen führen.
Ich habe in clock.h daher vorbereitet, dass es aktiv wird, wenn später die TimeStamp per #define aktiviert wird.

DH8 kommt später mit den display Änderungswünschen, tut aber dank #ifdef derzeit auch nicht weh.

Ich hoffe, Du bist mit diesen Änderungen einverstanden.

Edit: Anhang gelöscht, da update siehe unten.

Gruß und danke,

Ansgar.

[noansi]

Hallo Rudolf,

der nächste Änderungswunsch betrifft display.c.

Die Hex Ausgabe ist auf 32 bit Integer Zahlen mit padding "aufgebohrt", wenn HAS_DISPLAY_32BIT_HEX8 definiert ist und damit wird auch DH8 über display.h zur Verfügung gestellt. DH8 erwartet als Übergabewert dann einen Zeiger auf eine uint32_t Zahl.
Der Vollständigkeit halber kann mit HAS_DISPLAY_16BIT_HEX4 auch noch ein DH4 aktiviert werden, dass dann eine uint16_t Zahl als Übergabewert erwartet. Bei genügender Nutzung macht das Speichertechnisch Sinn.

Damit ist die clock Änderung auch mit dem noch fehlenden DH8 versorgt.

Ohne #defines bleibt es beim Alten. Wie bei clock.h sind zukünftige Timestamp Abhängigkeiten schon in der .h berücksichtigt.

Eine wesentliche Änderung betrifft die Ausgabe über USB oder Seriell. Hier habe ich ein Blockierendes Senden ergänzt, wenn der TTY Puffer voll läuft. Der Grund liegt in den letzten Tests mit den Homematic Updates. Dabei sind Zeichen der Sende TimeStamp Quittung mit CUL verloren gegangen, weshalb diese Änderung erforderlich wurde.

Ich hoffe, Dir ist kein Fall bekannt, wo das stört und Du kannst es so einbauen.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

eine weitere Änderung betrifft ttydata.c.

Darin ist mir aufgefallen, dass es bei COC mit dem großen TTY Puffer mit 8 bit Pufferzeiger nicht mehr zuverlässig passt. Das ist ein stiller Bug, der derzeit nur nicht auffällt, weil reguläre Kommandos nicht so lang sind. Mit dem zukünftigen "Ap" Kommando für den Ping würde der aber dumm auffallen können oder wenn derzeit irrtümlich zu lange Kommandos an COC abgesetzt werden.

Außerdem noch eine kleine Optimierung in callfn, die ein bischen schneller beim Dekodieren sein sollte.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.

[noansi]

Hallo Rudolf,

eine weitere Änderung betrifft serial.c.

Beim Empfang über die serielle Schnittstelle wurde nach meinem Verständnis der Atmel Dokus UCSR0A und UDR0 in falscher Reihenfolge ausgelesen, so dass der Empfangsstatus nicht zum gelesenen Empfangsbyte gehört. Der Atmel Sample Code in der Doku entspricht ebenfalls meiner Änderung.

Außerdem habe ich das Lesen und das Schreiben aus/in die TTY Puffer in den Interrupt Routinen ausprogrammiert, um für Slow-RF das Empfangstiming etwas zu optimieren (COC ist dabei bei mir schlechter als CUL, was aber störtechnisch vermutlich vor allem an der Nähe zur RasPi-Platine liegt).

uart_init ist derzeit nicht ganz sauber, wenn man mal die Baudrate ändern möchte.

Edit: Anhang gelöscht, da update siehe unten.

Gruß, Ansgar.