ZWCUL & STACKABLE_CC

[A.Harrenberg]

Hi Rudi,

Noetig ist zu viel gesagt: ist einfach, und im Zweifel initialisert alles neu. Ich war unsicher am Anfang, und habe ein bisschen "defensiv" Programmiert. Wie lange dauert ein reset? Du kannst natuerlich mit SIDLE experimentieren, falls es zu besseren Ergebnissen fuehrt, dann uebernehme ich es.

wenn Du da keinen triftigen Grund mehr weißt dann werde ich mal damit experimentieren.
Vom Resetbefehl bis zum Beginn des Registerschreibens dauert es ca. 100 µs, das Schreiben der Register dauert dann ca. 370 µs, danach kommt dann eine Pause von 4 ms (hast Du hierfür auch noch eine Idee warum Du die eingefügt hast?), dann kommt das Umschalten in RX, das dauert auch noch mal 80 µs.
Alles in allem dauert das ganze ca. 5,3 ms, was natürlch hauptsächlich durch das Delay von 4ms kommt bevor zxxRX() aufgerufen wird.
Wenn man nur nach Idle wechselt, den Buffer löscht, alle Register neu schreibt und wieder RX enabled müsste man mit ~ 1,2 ms auskommen. Wenn man sich auf die PKTLEN beschränkt dürfte auch 1ms machbar sein.

Was soll ich sonst in der Zeit tun? Delay ist eine Endlosschleife, ob die innere Schleife kuerzer ist oder nicht, ist doch egal.

Zeitlich wird das kaum Unterschied machen. Mein Ansatz wäre so lange zu warten bis der Buffer (fast) voll ist oder die erwartete Anzahl Zeichen angekommen sein müsste und würde dann auslesen. Auslesen über SPI ist ja noch fast 40x schneller als der Empfang der Daten. Ist aber wie gesagt nicht relevant, mich hatte nur interessiert ob es einen besonderen Grund gibt nur auf ein Zeichen zu warten.

Ich bin jetzt zu faul zum Nachschauen , aber ich meine diese Laenge gehoert zum ZWave Protokoll, und wird nicht vom CC1101 ueberprueft. Und irgendwer muss es ja tun.

Yep, "len" ist aus dem ZWave-Protokoll, len-8 wird dann aber in PKTLEN geschrieben. Meiner Meinung nach müsste der CC dann bei erreichen der Grenze auch aufhören zu emfangen und erst wieder auf das SyncWort warten. Das scheint er aber ganz offensichtlich nicht zu tun.

Ja, aber vermutlich weniger als Dir Ich meine das CC1101 besteht auf relativ haeufige Kalibrierung (ein Nebeneffekt vom Reset). Einer meiner Theorien, warum der ZWDongle im Nachbar-Thema nach eine Weile nix mehr empfaengt: es hat sich nicht kalibriert. Senden kann (je nach Einstellung) dagegen helfen. Oder (wieder mit passenden Parameter) nach SIDLE wechseln.

Habe das State Diagramm von CC noch nicht wirklich studiert, meiner Meinung wird durch zccRX() auch eine Kalibrierung angestossen, daher dauert es auch ~800µs bis das Ding wieder empfangsbereit ist. Ohne Kalibrierung müsste der in 75µs wieder bereit sein. Ob diese Kalibrierung wirklich nötig ist kann ich momentan mangels Messung/Erfahrung nicht sagen, kann mir aber nicht vorstellen das es sooo viel ausmacht.
Ich muss mich da mal ein wenig mehr einlesen und danach versuchen Messungen zu machen um zu sehen ob der PLL dann wirklich schneller ist.

Weiss nicht genau, was du meinst, wenn das die Flanken sind: SlowRF arbeitet damit, und das geht wg. Interrupt-Ungenauigkeit geschaetzt bis 2-4kBaud Datenrate gut. Hatten schon mehrere die Idee, die Interrupt-Zeiten bis FHEM zu schicken, und die Daten da zu dekodieren, mW ohne Erfolg.

Laut Datenblatt kann der cc auf den GDO Pins eine asynchrone serielle Ausgabe oder auch eine synchrone serielle Ausgabe machen. Ich will das auch nicht a la "Slow RF" auswerten, sondern mit dem LogicAnalyzer in HW ansehen wollen. Bisher kann ich da allerdings nur Datenmüll entziffern, in sehr seltenen Fällen sehe ich einen Burst von 0x55 Werten was unserem invertierten SyncByte entspricht. Das nachfolgende 0x0F bzw. 0xF0 kann ich aber schon nicht mehr entziffern. Die Invertierung im Protokoll bei 40k und 100k ist zum Debuggen auch unschön, dazu muss ich nämlich immer alle Werte aus dem Logikanalyzer nachträglich invertieren um das mit den dekodierten Werten zu vergleichen... Leider bietet mein Programm diese Option nicht schon in der Auswertung ,-)

Ich schau mal bei "Slow RF" was die da machen und wie die den cc programmiert haben.

Jetzt muss ich nur mal beobachten ob der MapleCUL (oder auch der CUL) sich mal wieder weghängen und mal schauen ob sich das auch noch herausbekommen lässt.

Gruß,
Andreas.

[rudolfkoenig]

Pause von 4 ms (hast Du hierfür auch noch eine Idee warum Du die eingefügt hast?)

Ich meine es von rf_moritz.c uebernommen zu haben. Da steht was von // 4ms: Found by trial and error

[A.Harrenberg]

Hi Rudi,

Ich meine es von rf_moritz.c uebernommen zu haben. Da steht was von // 4ms: Found by trial and error

ok, danke für den Hinweis.
Werde das erst mal so lassen und im ersten Schritt mal versuchen im Betrieb ohne den Reset auszukommen. Wenn das Ding beim ersten Initialisieren 4ms braucht ist das ja nicht weiter schlimm...

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

hier mal wieder was Neues zur Info:

Als ich eben nach Hause kam hat einer der MapleCUL (40k) nicht mehr reported... Der normale CUL war zufällig auf 40k, daher konnte ich sehen das dort "Traffic" war aber eben keine Werte von dem z40k Maple kamen.

Der Maple an sich reagierte normal, der 100k MapleCUL hat auch noch Werte ausgespukt, ich habe dann mal die register ausgelesen, die waren soweit ok, das einzig merkwürdige war das Register 0x2B AGCTEST, das stand auf 0x7F, normal steht das auf 0x3F und soll laut Doku nicht beschrieben werden. Ob das Register während des Betriebs auch andere Werte anzeigen kann konnte ich bisher nicht herausbekommen. Die Beschreibung des Registers lautet "For test only. Do not write to this register"...

Dummerweise habe ich keine Messung mit dem LogicAnalyzer gemacht ob der GDO2 Pin noch irgendwie reagiert sondern habe mal ein dummy-wert gesendet. Danach wurden sofort wieder Werte übertragen.
Ich hatte schon ein paar Mal das keine Werte mehr kamen, meist habe ich dann ein reopen gemacht oder den Maple resettet... Das gleiche hatte ich aber auch schon bei dem CUL, ich gehe daher davon aus das es sich hier nicht um ein Problem mit der a-culfw oder dem Maple handelt, sondern um ein generelles Problem wie wir mit dem CC1101 umgehen.

Ich bastel mir noch ein paar weitere Funktionen in die a-culfw bzw. in den ZWCUL um auch die Statusregister >0x30 auszulesen und dann mal ein paar Funktionen um Abläufe mit SRES, SCAL, SRX, STX etc. antriggern zu können.

Ich muss mir auch noch mal ansehen wie wir zwischen RX und TX umschalten, ob wir da direkt hin-und-her schalten oder ob wir über IDLE gehen und dann eine neue SCAL auslösen oder nicht. Irgendwie hat das Senden ja das Empfangsproblem gelöst...

Gibt es ähnliche Rückmeldungen beim CUL auch mit anderen Protokollen? Wenn das wirklich daran liegt das man lange auf RX bleibt und keine neue Kalibrierung macht und das Ding dann irgendwie wegläuft müsste man ja nur über einen Timer ab und zu mal IDLE-SCAL-RX aufrufen. Das dürfte aber recht schwer nachzustellen sein. Ich werde mir auch mal Logmeldungen in rf_zwave_init einbauen um zu sehen ob/wann der CC1101 initialisiert wird.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Telekatz,

ich hoffe Du bekommst das hier mit...

Welche Time und Interrupts sind den beim Maple-Mini bereits bereits, bzw. welche sind "frei"? Ich muss zugeben das ich mir das noch nicht so richtig angesehen haben, aber ich denke das Du für SlowRF da an CC0/CC1/CC2 was "vorgesehen" hast, oder?

Wenn ich das richtig verstehe kann der Maple bis zu 16 Interrupts, das dürfte dann wohl mehr oder weniger kein Problem darstellen, oder? Timer habe ich mir noch nicht angesehen, hier ist aber auch noch nicht klar ob ich wirklich einen Timer brauche.

Danke schon mal,
Andreas.

[Telekatz]

Der Maple nutzt aktuell die Timer TIM1-TIM3. TIM4 brauche ich dann noch für SlowRF an CC2. Übrig ist dann nur noch der System Tick Timer.
Zusätzlich werden noch die Interrupts für USB, UART1-3, EXTI0 und EXTI4 verwendet.

[A.Harrenberg]

Hi,

ok, Interrupts scheinen ja wirklich nicht das Problem zu sein, muss mir die Belegung der EXT lines aber mal im Detail anschauen, nicht das dann genau doch

Ist denn TIM1-TIM3 auch für die SlowRF Varianten "vorgesehen"? Falls ich Timer benötige, könnte ich doch die nutzen die Du auch für die jeweiligen CC "vorgesehen" hattest. Es liest sich ja so das TIM4 für CC2 ist, welche sind dann für CC0 und CC1? Solange ich mich an das Schema halte wäre ja alles iO.

Kannst Du mir mal eine Stelle irgendwo im Code nennen wo ein Interrupt mit dem ganzen HAL-Gedöns configuriert wird?

Danke,
Andreas.

[Telekatz]

TIM1 bedient den periodischen Interrupt in clock.c. Falls du einen Timer benötigst, denke ich, dass man für clock.c auch den System Tick Timer verwenden kann und TIM1 dadurch frei wird.

TIM2, TIM3 und TIM4 ist dann für CC0, CC1 und CC2 vorgesehen.

Konfiguriert werden die Interrupts in den entsprechenden HAL Dateien im STM32 Ordner (hal_timer.c, hal_gpio.c, hal_usart.c). die Interrupt Handler sind in stm32f1xx_it.c im MapleCUN Verzeichniss.

[A.Harrenberg]

Hi,

TIM1 bedient den periodischen Interrupt in clock.c. Falls du einen Timer benötigst, denke ich, dass man für clock.c auch den System Tick Timer verwenden kann und TIM1 dadurch frei wird.

TIM2, TIM3 und TIM4 ist dann für CC0, CC1 und CC2 vorgesehen.

Ich würde dann schon auch TIM2/3/4 nutzen, da läuft dann ja kein SlowRF gleichzeitig auf dem "Slot"

Konfiguriert werden die Interrupts in den entsprechenden HAL Dateien im STM32 Ordner (hal_timer.c, hal_gpio.c, hal_usart.c). die Interrupt Handler sind in stm32f1xx_it.c im MapleCUN Verzeichniss.

Ah, ok, schaue ich mir dann heute Abend mal an. Ist schon 'ne Weile her das ich mal "ernsthaft" Microcontroller programmiert habe, mal sehen ob ich daraus schlau werde. Muss aber auch erst mal den code schreiben und den mal gepollt auf Funktion testen, bevor ich den dann in den Interrupt hänge.

Ich habe bei meinen Tests übrigens mal das LAN-Modul abgesteckt (da ich mit dem lose rumliegenden Modul einen Kurzschluss auf meinem überfüllten Schreibtisch ausgelöst hatte...) und habe dabei festgestellt das jetzt die CC-Module (bzw. die rf_zwave_func) nahezu doppelt so schnell/häufig aufgerufen werden. Der LAN-/Netzwerkcode scheint also eine ganz schöne Latenz zu verursachen, und das obwohl ja nicht mal ein Kabel drin steckt. Muss ich mir bei Gelegenheit auch mal ansehen was da so passiert und ob ich evtl. darauf achten/reagieren muss was so passiert.

Danke,
Andreas.