Alternative culfw

Begonnen von bjoernh, 15 März 2015, 12:01:06

Vorheriges Thema - Nächstes Thema

jw1hal

#1755
Hallo,

Zitat von: RaspiLED am 25 November 2018, 12:22:50Du hast keinen neuen Room IT?
Hab ich, da gibt es das:Internals:
   00         f0
   CFGFN     
   DEF        F000FFFF10 0F F0
   IODev      CUL_433
   NAME       IT_F000FFFF10
   NR         904
   STATE      off
   TYPE       IT
   XMIT       f000ffff10
   XMITdimdown 00
   XMITdimup  00
   XMITon     0f
   .attraggr:
   .attrminint:
   CODE:
     1          f000ffff10
   READINGS:
     2018-11-24 09:08:33   protocol        V1
     2018-11-24 21:57:03   state           off
Attributes:
   IODev      CUL_433
   room       IT


Kann man "an" und "aus" schalten, das Symbol (Lampe) schaltet auch "an" und "aus", aber die eine Steckdose von drei, die ich im fest TV eingebaut habe, macht nichts.

Soll es sich dabei doch um die 3 Steckdosen handeln? Ich habe es eigentlich ausgeschlossen, weil "an" und "aus" nichts macht. Wenn das eine der drei Steckdosen ist, wo sind dann die anderen zwei? Schließlich habe ich auf der Fernbedienung alle 6 Tasten mehrfach gedrückt.

Zitat von: RaspiLED am 25 November 2018, 12:22:50Na dann, auf zur Signalduino Firmware Soll ich Dir einen geflashten Signalduino rübersenden?
Ist der komplett? Was soll der kosten? Kannst du mir ja per PN mitteilen. So richtig verstehe ich´s noch nicht, was das eigentlich sein soll, bzw. wie das Ding aussieht. Was ich bisher so gelesen habe, ist es ein Stick, wie meine Nano´s, nur dass man dafür noch einen extra Empfänger und einen extra Sender oder auch einen extra kombinierten Sender/Empfänger braucht, welche man da anschließen muss. Sind wohl auch so ganz kleine Platinen mit ner kleinen Antenne dran.

Was macht dann das Ding? Schließt man das nur zum Zweck des Testes an den PI an, kann das immer dran bleiben oder soll es den 433er Nano ganz ersetzen? Das sind so die Fragen, die so ein Laie, wie ich habe, weil ich diesbezüglich, trotz vielen Lesens noch nicht wirklich schlau darüber geworden und von daher etwas verunsichert bin.

Ich habe übrigens auch noch:Internals:
   CFGFN     
   CODE       CUL_TCM97001_Unknown
   CUL_433_MSGCNT 65
   CUL_433_RAWMSG s0F00237A58DC;  432: 3936
   CUL_433_TIME 2018-11-24 23:04:45
   DEF        CUL_TCM97001_Unknown
   LASTInputDev CUL_433
   MSGCNT     65
   NAME       Unknown
   NR         3814
   RSSI       -92
   STATE      Code: 0F00237A58
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1543097085
   .attraggr:
   .attrminint:
   READINGS:
     2018-11-24 23:04:45   state           Code: 0F00237A58
Attributes:
   model      Unknown
   room       CUL_TCM97001

Das müsste wohl auch so ein Temperatursensor sein, weil einer von meinen auch vom Type "CUL_TCM97001" ist.

Das sind meine:Internals:
   .lastTimebattery 1543087219.06274
   .lastTimechannel 1543087516.87218
   .lastTimehumidity 1543160485.33362
   .lastTimemode 1543089336.50718
   .lastTimestate 1543160485.03897
   .lastTimetemperature 1543160485.03897
   CFGFN     
   CHANGED   
   CODE       CUL_TCM97001_134
   CUL_433_MSGCNT 5334
   CUL_433_RAWMSG s86004ADDA8E4;  512: 9104
   CUL_433_TIME 2018-11-25 16:45:35
   DEF        CUL_TCM97001_134
   LASTInputDev CUL_433
   MSGCNT     5334
   NAME       Sensor_GT_WT_02_134
   NR         7252
   RSSI       -88
   STATE      T: 7.4 H: 100
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1543160735
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   READINGS:
     2018-11-24 20:20:19   battery         ok
     2018-11-24 20:25:16   channel         1
     2018-11-25 16:45:35   humidity        100
     2018-11-24 20:55:36   mode            normal
     2018-11-25 16:45:35   state           T: 7.4 H: 100
     2018-11-25 16:45:35   temperature     7.4
Attributes:
   alias      Wetterstation Jan Außensensor
   event-min-interval .*:300
   event-on-change-reading .*
   group      22_Sensoren
   model      GT_WT_02
   room       00_Diabeck,09_Balkon,20_Sensoren
Internals:
   .lastTimebattery 1543160653.72661
   .lastTimebatteryState 1543160653.72661
   .lastTimechannel 1543160653.72661
   .lastTimestate 1543160482.71579
   .lastTimetemperature 1543160482.71579
   CFGFN     
   CHANGED   
   CODE       SD_WS07_T_1
   CUL_433_DMSG P7#2B804DF000
   CUL_433_MSGCNT 1575
   CUL_433_RAWMSG 2FD
   CUL_433_TIME 2018-11-25 16:46:07
   DEF        SD_WS07_T_1
   LASTInputDev CUL_433
   MSGCNT     1575
   NAME       Sensor_SD_WS07_T_1
   NR         7406
   STATE      T: 7.7
   TYPE       SD_WS07
   bitMSG     00101011 1 000 000001001101 1111 00000000
   lastMSG    2B804DF000
   lastReceive 1543160767
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   READINGS:
     2018-11-25 16:46:07   battery         ok
     2018-11-25 16:46:07   batteryState    ok
     2018-11-25 16:46:07   channel         1
     2018-11-25 16:46:07   state           T: 7.7
     2018-11-25 16:46:07   temperature     7.7
Attributes:
   alias      Wetterstation Diana Außensensor
   event-min-interval .*:300
   event-on-change-reading .*
   group      22_Sensoren
   room       00_Diabeck,09_Balkon,20_Sensoren


Und das vermutlich die von den Nachbarn:Internals:
   .lastTimebattery 1543067153.45058
   .lastTimechannel 1543067153.45058
   .lastTimehumidity 1543087203.16289
   .lastTimemode 1543067153.45058
   .lastTimestate 1543087203.16289
   .lastTimetemperature 1543087203.16289
   CFGFN     
   CHANGED   
   CODE       CUL_TCM97001_57
   CUL_433_MSGCNT 31
   CUL_433_RAWMSG s39803DDDE8F3;  528: 9104
   CUL_433_TIME 2018-11-24 20:20:03
   DEF        CUL_TCM97001_57
   LASTInputDev CUL_433
   MSGCNT     31
   NAME       USensor_GT_WT_02_57
   NR         3781
   RSSI       -80.5
   STATE      T: 6.1 H: 100
   TYPE       CUL_TCM97001
   lastH      0
   lastT      1543087203
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   READINGS:
     2018-11-24 14:45:53   battery         low
     2018-11-24 14:45:53   channel         1
     2018-11-24 20:20:03   humidity        100
     2018-11-24 14:45:53   mode            normal
     2018-11-24 20:20:03   state           T: 6.1 H: 100
     2018-11-24 20:20:03   temperature     6.1
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   group      23_Sensoren_unbekannt
   model      GT_WT_02
   room       20_Sensoren
Internals:
   .lastTimebattery 1543160131.16402
   .lastTimebatteryState 1543160131.16402
   .lastTimechannel 1543160131.16402
   .lastTimehumidity 1543160131.16402
   .lastTimestate 1543160131.16402
   .lastTimetemperature 1543160131.16402
   CFGFN     
   CODE       SD_WS07_TH_1
   CUL_433_DMSG P7#0F0056F4B0
   CUL_433_MSGCNT 1723
   CUL_433_RAWMSG 2DB
   CUL_433_TIME 2018-11-25 16:35:31
   DEF        SD_WS07_TH_1
   LASTInputDev CUL_433
   MSGCNT     1723
   NAME       USensor_SD_WS07_TH_1
   NR         3613
   STATE      T: 8.6 H: 75
   TYPE       SD_WS07
   bitMSG     00001111 0 000 000001010110 1111 01001011
   lastMSG    0F0056F4B0
   lastReceive 1543160131
   .attraggr:
   .attreocr:
     .*
   .attrminint:
     .*:300
   READINGS:
     2018-11-25 16:35:31   battery         low
     2018-11-25 16:35:31   batteryState    low
     2018-11-25 16:35:31   channel         1
     2018-11-25 16:35:31   humidity        75
     2018-11-25 16:35:31   state           T: 8.6 H: 75
     2018-11-25 16:35:31   temperature     8.6
Attributes:
   event-min-interval .*:300
   event-on-change-reading .*
   group      23_Sensoren_unbekannt
   room       20_Sensoren
Internals:
   CFGFN     
   CODE       THWR288A_d1_2
   CUL_433_DMSG 50EA4C20D14408E0330480
   CUL_433_MSGCNT 107
   CUL_433_RAWMSG mAAAAAAAACCCAD2D3554D3532D35354D5554AAD2D53555555F1
   CUL_433_TIME 2018-11-25 16:20:47
   DEF        THWR288A_d1_2
   IODev      CUL_433
   LASTInputDev CUL_433
   MSGCNT     107
   NAME       USensor_THWR288A_d1_2
   NR         1194
   STATE      T: 8.4 BAT: low
   TYPE       OREGON
   .attraggr:
   .attrminint:
   READINGS:
     2018-11-25 16:20:47   battery         low
     2018-11-25 16:20:47   batteryState    low
     2018-11-25 16:20:47   state           T: 8.4 BAT: low
     2018-11-25 16:20:47   temperature     8.4
Attributes:
   IODev      CUL_433
   group      23_Sensoren_unbekannt
   room       20_Sensoren


Die ersten beiden Fremden, vermutlich von den Nachbarn, ähneln sich aber auch in der Bezeichnung und unterscheiden sich nur an den letzten paar Zeichen der Bezeichnung ("_134"<=>"_57" und "_T_1"<=>"_TH_1"), so dass ich annahm, das sind auch meine, nur fehlerhaft ausgelesen. Ich hatte aber da gesehen, dass laut Zeitstempel später auch noch was kam. Also Entweder haben die Nachbarn fast die gleichen Dinger oder es wird öfter fehlerhaft ausgelesen, so dass dies auch noch teilweise aktualisiert wird (siehe Plots).
Der Unbekannte:
CUL_TCM97001_Unknown     TYPE: CUL_TCM97001

Meine zwei:
GT_WT_02_134             TYPE: CUL_TCM97001
SD_WS07_T_1              TYPE: SD_WS07

vermutlich von den Nachbarn:
GT_WT_02_57              TYPE: CUL_TCM97001
SD_WS07_TH_1             TYPE: SD_WS07
THWR288A_d1_2            TYPE: OREGON


Das sind auch so Dinge, aus denen ich (noch) nicht schlau werde.

PS: Ich weiß, wieder viel zu viel ....



Gruß jw1hal
Raspberry Pi 3 Model B Rev 1.2; Linux 4.9.59-v7+; Raspbian GNU/Linux 9 (stretch); CUL433 (VTS 0.29 CSM868); CUL 868 (VTS 0.29 CSM868); 6x BrennenstuhlRCR1000N; 8x ZAP; 3x EmilLux; 10x Sonoff Basic (Tasmota 5.10.0f); 5x HM-CC-RT-DN; 9x HM-SEC-SCo; 8x HM-SEC-SCo, 7x HM-LC-Sw1PBU-FM; Fritz!Box 7362 SL

RaspiLED

#1756
Hi,
A) Signalduino ist eine andere Firmware, die auch auf Deinem nanoCUL läuft, aber auch auf anderen Hardwarevarianten.
B) Der Hauptunterschied zwischen CUL und Signalduino ist: CUL muss alles selbst kennen, Signalduino empfängt und gibt an FHEM zum übersetzen ab - dadurch hört/sieht man mehr mit dem Signalduino. Kann aber nicht ,,zeitnah" antworten, wie es für Homematic nötig ist.
C) Ja per PN
D) IT Profis ran ;-)
E) Deine Thermometer sehen doch gut aus! Die Nummer hinten ist die ID, jedes Thermometer nimmt sich eine neue ID beim Batterie einlegen.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

KölnSolar

ZitatRSSI       -92
wohl ne ganze Ecke vom nanoCUL entfernt(Je höher der absolute Wert, desto weiter weg oder schlechter in der Sendeleistung)
ZitatRSSI       -88
nicht gut, aber besser
ZitatSTATE      T: 7.4 H: 100
und wohl eher draußen
ZitatSTATE      T: 7.7
   TYPE       SD_WS07
wohl auch draußen, aber ohne RSSI(liegt dann vermutlich am Modul)
ZitatRSSI       -80.5
   STATE      T: 6.1 H: 100
bisher am nächsten zum CUL(oder sendet stärker), wohl auch draußen
ZitatSTATE      T: 8.4 BAT: low
   TYPE       OREGON
Das ist ein Oregon Scientific, und wohl auch wieder draußen

Zitatoder es wird öfter fehlerhaft ausgelesen, so dass dies auch noch teilweise aktualisiert wird
Das ist natürlich möglich. Das musst Du über event monitor und Batterie einlegen herausfinden, also in den event monitor gehen und dann Batterie raus und wieder rein. Mir bekannte Sensoren haben eine LED, die kurze Zeit später aufleuchtet und fast gleichzeitig sollte sich dann im event monitor etwas tun.
Grüße Markus
PS: Als Newbie ist es vielleicht besser, wenn Du ein eigenes Thema eröffnest.  ;)




RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

vbs

Hab nochmal etwas geforscht zu meinem Problem von hier:
https://forum.fhem.de/index.php/topic,35064.msg862953.html#msg862953

Das Problem ist ja, dass /dev/ttyACM2 irgendwann aufhört zu funktionieren. Ich hab da nochmal etwas rumgeforscht:

Als das Problem jetzt wieder aufgetreten ist, hab ich mal FHEM komplett beendet und die Schnittstelle mit "screen" geöffnet und mal "usbmon" im Kernel aktiviert. Interessant ist:

  • Datenempfang auf /dev/ttyACM2 funktioniert weiterhin. Sehe ich im usbmon und auch als Ausgabe in "screen"
ffff9bd177ce5d40 3771731114 S Bi:011:05 -115 128 <
ffff9bd177ce5500 3771731116 S Bi:011:05 -115 128 <
ffff9bd177ce58c0 3771731117 S Bi:011:05 -115 128 <
ffff9bcb461d8cc0 3771731122 S Co:011:00 s 21 22 0003 0004 0000 0
ffff9bcc42ff4600 3771871639 C Bi:011:05 0 1 = a0
ffff9bcc42ff4600 3771871834 S Bi:011:05 -115 128 <
ffff9bcc42ff4c00 3771871843 C Bi:011:05 0 1 = f9
ffff9bcc42ff4c00 3771871845 S Bi:011:05 -115 128 <
ffff9bcb461d8cc0 3771871931 C Co:011:00 0 0
ffff9bcc42ff5a40 3773521900 C Bi:011:05 0 1 = 20
ffff9bcc42ff5a40 3773521963 S Bi:011:05 -115 128 <
ffff9bcc42ff4300 3773523589 C Bi:011:05 0 1 = f9
ffff9bcc42ff4300 3773523640 S Bi:011:05 -115 128 <
ffff9bcc42ff4f00 3774671870 C Bi:011:05 0 1 = 44
ffff9bcc42ff4f00 3774671938 S Bi:011:05 -115 128 <
ffff9bcc42ff4540 3774672768 C Bi:011:05 0 1 = 21
ffff9bcc42ff4540 3774672817 S Bi:011:05 -115 128 <
ffff9bd177ce4240 3776840193 S Bo:011:05 -115 1 = 76
ffff9bcc42ff55c0 3780541884 C Bi:011:05 0 1 = 84
ffff9bcc42ff55c0 3780541929 S Bi:011:05 -115 128 <
ffff9bcc42ff5200 3780543595 C Bi:011:05 0 1 = d4
ffff9bcc42ff5200 3780543622 S Bi:011:05 -115 128 <
ffff9bcc42ff5bc0 3783520092 C Bi:011:05 0 1 = 04
ffff9bcc42ff5bc0 3783520154 S Bi:011:05 -115 128 <
ffff9bd177ce4000 3783521045 C Bi:011:05 0 1 = d0
ffff9bd177ce4000 3783521097 S Bi:011:05 -115 128 <

Beschreibung des Formats:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt

Nach dem Öffnen des Devices (also nach dem Start von "screen"), kann ich genau ein Byte versenden, danach geht nix mehr. Ich drücke eine Taste und eine Bulk-Out ("Bo") Zeile erscheint:
ffff9bd177ce4240 3776840193 S Bo:011:05 -115 1 = 76

Danach verklemmt sich offenbar irgendwas. Es werden keine weiteren Tastendrücke bzw. Bytes mehr per USB versenden. Empfangen der Daten läuft aber interessanterweise weiter.
Beim Öffnen und auch beim Schließen der Schnittstelle läuft da einiges an Kommunikation über USB. Das sagt mir aber nicht viel. Aber auch interessant ist, dass beim Versuch "screen" zu beenden, das Programme für viele Sekunden hängt und sich erst dann beendet.


Sieht im usbmon so aus (mit meinen Kommentaren eingefügt), die Zeitstempel zB 145135651 sind Mikrosekunden:

> screen wird gestartet (bei 145 Sekunden)
ffff9bcc42ff4c00 145135651 C Bi:011:05 0 1 = 00
ffff9bcc42ff4c00 145135659 S Bi:011:05 -115 128 <
ffff9bcc42ff5a40 145137370 C Bi:011:05 0 1 = a4
ffff9bcc42ff5a40 145137420 S Bi:011:05 -115 128 <
ffff9bcc42ff4300 145139082 C Bi:011:05 0 1 = b1
ffff9bcc42ff4300 145139131 S Bi:011:05 -115 128 <
ffff9bcc42ff4f00 145140301 C Bi:011:05 0 1 = f9
ffff9bcc42ff4f00 145140351 S Bi:011:05 -115 128 <
> hier drücke ich nun mehrer Tasten. Es wird nur einmal "0x67" versendet
ffff9bd177ce4240 145732086 S Bo:011:05 -115 1 = 67
> danach beende ich screen kurz nach Zeitstempel 145732086. Jetzt hängt alles und 20 Sekunden später (bei 162527666) fängt wieder irgendwas auf dem USB-Bus an zu passieren. aber langsam.
ffff9bcc42ff4540 162527666 C Bi:011:05 0 1 = 80
ffff9bcc42ff4540 162527725 S Bi:011:05 -115 128 <
ffff9bcc42ff55c0 162528596 C Bi:011:05 0 1 = f8
ffff9bcc42ff55c0 162528646 S Bi:011:05 -115 128 <
ffff9bcc42ff5200 173675709 C Bi:011:05 0 1 = 44
ffff9bcc42ff5200 173675769 S Bi:011:05 -115 128 <
ffff9bcc42ff5bc0 173676684 C Bi:011:05 0 1 = 29
ffff9bcc42ff5bc0 173676734 S Bi:011:05 -115 128 <
ffff9bcc42ff5440 179366253 C Ii:011:06 -2 0
ffff9bd177ce4240 180023956 C Bo:011:05 -2 0
ffff9bcc42ff4600 180366613 C Bi:011:05 -2 0
ffff9bcc42ff4c00 181024145 C Bi:011:05 -2 0
ffff9bcc42ff5a40 181366996 C Bi:011:05 -2 0
ffff9bcc42ff4300 182024594 C Bi:011:05 -2 0
ffff9bcc42ff4f00 182367828 C Bi:011:05 -2 0
ffff9bcc42ff4540 182527855 C Bi:011:05 -2 0
ffff9bcc42ff55c0 182528925 C Bi:011:05 -2 0
ffff9bcc42ff5200 182530272 C Bi:011:05 -2 0
ffff9bcc42ff5bc0 182532266 C Bi:011:05 -2 0
ffff9bd177ce4000 182533323 C Bi:011:05 -2 0
ffff9bd177ce4780 182534667 C Bi:011:05 -2 0
ffff9bd177ce43c0 182536350 C Bi:011:05 -2 0
ffff9bd177ce4fc0 182538283 C Bi:011:05 -2 0
ffff9bd177ce5d40 182540293 C Bi:011:05 -2 0
ffff9bd177ce5500 182541283 C Bi:011:05 -2 0
ffff9bd177ce58c0 182543289 C Bi:011:05 -2 0
> dann hier ist alles durch und "screen" beendet sich endlich


Sobald ich das Device einmal disconnecte und wieder connecte ist alles wieder in Butter. Ich bin da echt etwas überfragt. Kenn mich in den Details des USB-Protokolls nicht aus. Kann aus meiner Sicht ein Problem im CDC-AMC-Treiber sein, oder in VmWare oder sogar in der acul-Firmware?

Irgendeine Idee dazu? :/

Telekatz

Ich habe den MapleCUL mit HM-MOD-UART jetzt zwei Tage auf meinem Testsystem und seit gestern auf meiner normalen FHEM Installation laufen gelassen. Jeweils auf einem Raspberry Pi. Lief ohne Probleme durch. Ich würde an deiner Stelle FHEM mal auf einem anderen System installieren.

vbs

#1760
Also ich denke ich bin dem ganzen etwas näher gekommen. Eh ich mich jetzt in Spekulationen verlieren: ich kann es auf jeden Fall bei mir jetzt innerhalb weniger Sekunden reproduzieren auf einem anderen System (zwar komplett anderer PC und anderer CUL, aber gleiche Software. Also wieder Ubuntu als VM unter Win10). Hab dafür die FW leicht angepasst, so dass diese permanent Daten auf ttyACM2 sendet (muss dann kein HM-UART angeschlossen sein). Wenn man das Device öffnet, die Daten liest und gleichzeitig auch permanent Daten schreibt, dann kommt mein System nach ein paar Sekunden in den Zustand.
Es scheint sich irgendwas zu verklemmen, wenn gleichzeitig Daten gelesen und geschrieben werden. Race Condition?

Magst du das vielleicht bei dir auch mal ausprobieren?

Müsstest dafür nur diese Firmware hier nutzen:
https://github.com/verybadsoldier/a-culfw/tree/simdata

Oder hier auch fertig kompiliert als Binary:
https://github.com/verybadsoldier/a-culfw/raw/simdata/culfw/Devices/MapleCUN/MapleCUNx4_W5100_BL.bin

Und dann auf dem Linux dieses Testprogramm laufen lassen (cdctest.cpp):
https://pastebin.com/rVwZHpUG

Laufen lassen mit:
./cdctest /dev/ttyACM2

Er das Ding öffnet nur das Device (blockierend) und liest alle Daten ein (read). Schreibt jedoch immer auch blockierend in das Device.

Bei mir läuft das nur einige Sekunden und laut Wireshark bleiben dann auf dem USB-Bus die ACKs für Bulk-Pakete aus, so dass dann die Schnittstelle blockiert, wenn das Programm versucht, weitere Daten zu schreiben:

...
Write OK #1127
Read 5
Write OK #1128
Read 5
Write OK #1129
Read 5
Write OK #1130
Read 5
Write OK #1131
Read 5
Write OK #1132
Read 5
Write OK #1133
Read 5
Write OK #1134
Read 5
Write OK #1135
Read 5
Write OK #1136
Read 5
Write OK #1137
Read 5
Write OK #1138
Read 5
Write OK #1139
Read 5
Write OK #1140
Read 5
Write OK #1141
Read 5
Write OK #1142
Read 5
Write OK #1143
Read 5
<hier bleibt's stehen und blockiert>


Also er liest und schreibt ohne Probleme für ein paar Sekunden. Und dann auf einmal blockiert das write und das ganze hängt. "select" meldet auch schon kurz vorher, dass der file descriptor nicht mehr schreibbar ist. Schreiben klappt dann aber trotzdem noch ein paar Mal bevor es dann blockiert.
Das Gerät ist dann genau in dem Zustand, wie es auch in meinem FHEM-Fehlerfall ist. Wenn man das Programm dann beendet, können auch hinterher weiterhin Daten gelesen per (wenn man z.B. ein "cat" oder "screen" drauf macht), aber beim Versucht, Daten zu schreiben, blockiert das Device einfach.

vbs@ubuntu:~/Projects/cdctest/Debug$ cat /dev/ttyACM2
abcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcde


Wäre mal interessant, ob das bei dir auch auftritt auf echter Hardware. Ich hab momentan doch wieder die aculfw im Verdacht, muss ich sagen.

EDIT:
Achso ich hatte übrigens bei meinen Tests nur einen nackten MapleMini am USB hängen. Nichts weiter angeschlossen

vbs

Hm, also ich hab das jetzt mal auf einem echten Rechner unter einem aktuellen Ubuntu und auch unter Debian getestet: tritt dabei auch auf. Deutet für mich alles darauf hin, dass es sich um ein Problem in der acul Firmware handelt.

Telekatz

Ich denke, ich hab da was gefunden. Versuch mal die angefügte Version.

vbs

Das Problem scheint bekannt zu sein und ist hier ziemlich gut beschrieben:
https://community.st.com/s/question/0D50X00009XkfIBSAZ/stm32cube-usb-cdc-possible-bug-found-rx-tx-race-condition

Kann ich den Code mal sehen bitte?

vbs

Mach ich was falsch? Die Firmware bootet bei mir nicht und ich bekomme keine ACM-Devices?


Telekatz

Zitat von: vbs am 01 Dezember 2018, 22:04:41
Mach ich was falsch? Die Firmware bootet bei mir nicht und ich bekomme keine ACM-Devices?
Man sollte halt immer erst ein "make clean" machen, wenn man ein neues Target erstellt. Anbei die funktionierende Version.

vbs

#1767
Also das funktioniert so weit, denke ich.

Jedoch scheint das jetzt ein Stück langsamer zu laufen als vorher. Mit der alten Variante haben 1000 write-Aufrufe (je 7 Byte) ca. 7 Sekunden gedauert. Mit der neuen Firmware dauert das jetzt ca. 29 Sekunden. Das Testprogramm simuliert ja sehr viel Last und man wird da vermutlich einfach oft den Moment treffen, dass TX gerade aktiv ist und dadurch gebremst. Bei wenig Last wird's keinen Unterschied machen, aber wenn da viel Daten rüber gehen, kann das zu Latenzen führen, fürchte ich.

Ich war schon ziemlich erstaunt, wie lax ST selber im Code mit dieser Busy-Situation umgeht. Sehr viele Funktionen geben gar keinen Rückgabewert zurück obwohl sie es sollten und/oder werten Rückgabewerte einfach nicht aus. Dadurch wird oft einfach das HAL_BUSY nicht korrekt gehandhabt mMn.

In der aculfw schlummert da meiner Meinung nach auch noch ganz konkret eine weitere Race Condition, die sich genau so auswirkt wie die vorherige und den CDC-Empfang zum Erliegen bringt (ich meine, die auch schon mindestens einmal "in Echt" beobachtet zu haben):
https://github.com/heliflieger/a-culfw/blob/master/culfw/STM32/hal_usart.c#L335

Die Funktion ruft "HAL_UART_Transmit_IT" auf, welche auch wieder "HAL_LOCK" verwendet. Im Busy-Fall kehrt die Funktion dann entsprechend sofort mit "HAL_BUSY" zurück ohne eben die UART-Daten abgesendet zu haben. Entsprechend wird dann in der Folge auch der UART-Interrupt nicht getriggert und damit erfolgt auch kein weiterer Aufruf mehr von "CDC_Receive_next". Also wieder Ende an der Stelle.

Gibt da evtl. noch einen anderen Ansatz: und zwar das direkte Auswerten der HAL_BUSY-Rückgabewerte. Damit kann man mMn recht gezielt feststellen, wenn wirklich ein Befehl abgebrochen wurde, weil das Handle nicht gelockt werden konnte. Das passiert dann offenbar wesentlich seltener und damit blieb bei meinen Tests die Latenz stabil. Ich hab das mal prototypisch versucht umzusetzen:
https://github.com/verybadsoldier/a-culfw/commit/d85b0d96c5d16fc8c1c27bbed18545755b72ac2f

Was würdest du davon halten? Wäre sicherlich mindestens auch noch Feinschliff notwendig. Bin mir vor allem nicht so sicher bei dem Code hier, der die o.g. zweite Race Condition fixen soll:
https://github.com/verybadsoldier/a-culfw/commit/d85b0d96c5d16fc8c1c27bbed18545755b72ac2f#diff-20666428942ba3e99519cc4f7352598a

Falls die UART-Daten aufgrund von HAL_BUSY nicht abgesetzt werden konnte, werden die Daten-Pointer gesichert und dann später über die main-Loop versendet. Bin mir nicht so sicher, wo der Pointer her kommt, wie stabil der ist bzw. ob man das so machen sollte.

EDIT:
Das mit den 7 s oben stimmt nicht ganz. Das bezieht sich nicht auf die vorherige Firmware, sondern auf einen Test mit der Firmware aus meinem Link. Mit dem alten Stand konnte ich ja keinen vergleichbaren Test machen wegen dem Hänger.

Telekatz

Für den USB Teil habe ich jetzt noch die Prüfung auf HAL_BUSY eingebaut.

Beim UART ist das über USB nicht notwendig, da die  HAL_UART_Transmit_IT Funktion aus einer USB Interrupt Funktion heraus aufgerufen wird. Die USB und UART Interrupts werden mit der selben Priorität ausgeführt und können sich deshalb nicht gegenseitig unterbrechen. Eine Race Condition könnte hier nur über Ethernet vorkommen, da der Ethernet Empfang nicht Interrupt gesteuert ist. Aber da wäre es einfacher, vor dem Aufruf der HAL_UART_Transmit_IT Funktion einfach den UART Interrupt zu deaktivieren.


vbs

#1769
Bin noch am Testen aber sieht soweit gut aus. Habe ca. 14 Mio. write-Requests durch jeweils mit Zufallsabständen von 0 bis 10 ms. Bisher alles stabil!

Achso: Hat auch wieder die alte (geringe) Latenz!