culfw@ARM

[max333]

Ich benutze die Toolchain gcc-arm-none-eabi-5_2-2015q4-20151219-win32.exe und will nur für den CUBe das File erzeugen, dazu habe ich make im CUBe Verzeichnis gestartet.

[Telekatz]

Nimm mal die Version 4.8 der Toolchain, die im Eröffnungspost auch verlinkt ist.
Welche der erzeugten Dateien hast du danach geflasht? CUBE.bin oder CUBE_BL.bin?

[max333]

Bei mir wird nur eine CUBE_BL.bin erstellt, welche ich auch geflasht habe. Jedenfalls mit der 4.8 geht es jetzt, vielen DANK!

[cdn]

Ist es auch möglich den Stick als RFR zu nutzen? Ich habe es probiert nur leider ist es nicht möglich den raw entsprechend zu ändern wie hier beschrieben:

http://fhemwiki.de/wiki/RFR_CUL

Hmm ist das vielleicht untergegangen? Oder hat keiner eine Idee?

[Telekatz]

Die RF Router Funktion habe ich mal auskommentiert, weil sie bei meinem Cube Probleme beim Betrieb mit mehreren Transceivermodulen verursacht hat. Das war einfacher, als dem Problem auf den Grund zu gehen. Aber prinzipiell müsste die Router Funktion funktionieren, wenn man sie in der board.h wieder aktiviert. Getestet hab ich die Funktion allerdings nie.

[Tatsu]

Habe jetzt den zweiten CUBE geflasht in der Hoffnung, ihn als CUN im RAW Modus für Lacrosse Sensorik verwenden zu können. Ich habe verstanden, dass ich ihn dafür in den RAW Mode mit z.B. 'SET CUN_0 RAW Nr1' versetzen muss. Siehe dazu auch https://forum.fhem.de/index.php?topic=36565.

Allerdings verabschiedet sich der CUBE (V 1.20.06 a-culfw Build: 199) dann kurz darauf mit folgendem Logeintrag:

Code Auswählen Erweitern

2016.03.16 16:23:34 3: set CUN_0 raw Nr1
2016.03.16 16:24:00 1: 192.168.1.9:2323 disconnected, waiting to reappear (CUN_0)
2016.03.16 16:24:00 1: 192.168.1.9:2323 reappeared (CUN_0)
2016.03.16 16:24:00 3: CUN_0: Possible commands: BbCFiAZNEkGMKLUYRTVWXefltxz

Das passiert auch mit meinem zweiten CUBE (V 1.20.01 a-culfw Build: 176, via USB):

Code Auswählen Erweitern

2016.03.16 16:38:28 3: set CUL_0 raw Nr2
2016.03.16 16:38:30 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.03.16 16:38:31 3: Setting CUL_0 serial parameters to 9600,8,N,1
2016.03.16 16:38:31 1: /dev/ttyACM0 reappeared (CUL_0)

Stehe ich gerade auf der Leitung bzw. hat jemand eine Idee was da schief geht? Ich hatte gehofft, dass ich dafür nicht extra einen Jeelink Stick kaufen muss.

Ich würde natürlich ggf. mit #define LACROSSE_HMS_EMU u. lacrosse.c im Makefile etc. neu kompilieren, aber mit dem SET RAW (also RFNATIVE) sollte ich doch trotzdem ein Datenpaket vom Sensor  im Logfile sehen statt der Disconnects - oder sehe ich das falsch?

Danke für jeden Tipp!

[Telekatz]

Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:

Code Auswählen Erweitern

diff --git a/culfw/clib/rf_native.c b/culfw/clib/rf_native.c
index 3f973c0..9e308c2 100644
--- a/culfw/clib/rf_native.c
+++ b/culfw/clib/rf_native.c
@@ -219,13 +219,13 @@


void native_func(char *in) {
-  uint8_t mode = 0;
+  uint16_t mode = 0;

   if(in[1] == 'r') {                // Reception on
     
     // "Er<x>" - where <x> is mode
     if (in[2])
-      fromdec(in+2, &mode);
+      fromdec(in+2, (uint8_t *)&mode);

     if (!mode || mode>MAX_MODES) {
       DS_P(PSTR("specify valid mode number\r\n"));

[Tatsu]

Mach mal folgende Änderung in rf_native.c, dann sollte es funktionieren:

Wow das ging ja fix,danke erstmal Habs nur kurz testen können, aber scheint geholfen zu haben. Bisher kein Disconnect mehr
und ich sehe jetzt auch die Einträge die ich erwartet hätte:

Code Auswählen Erweitern


2016.03.16 22:38:19 2: CUN_0: unknown message N019C45956A1CAAAA0000975273
2016.03.16 22:38:28 2: CUN_0: unknown message N019C45956A1CAAAA0000E5A23B
2016.03.16 22:38:37 2: CUN_0: unknown message N019C45956A1CAAAA00004DAC9F
2016.03.16 22:38:45 2: CUN_0: unknown message N019C45956A1CAAAA00003D8F76


Ich würde als nächstes den LACROSSE_HMS_EMU mit reinnehmen, muss ich dabei auch etwas beachten (andere Protkolle raus wg. Speicherplatz o.ä.) ?

Danke & Gruß

Tatsu

[Telekatz]

Speicherplatz ist beim Cube noch genügend vorhanden. Da muss man nichts raus nehmen.

[Tatsu]

Hat funktioniert  Ein Lacrosse Temperatursensor (TX29-IT) ist nach 'SET RAW Nr1' direkt mit Autocreate als HMS Device erkannt worden und liefert seitdem alle 10 Sekunden neue Werte. Also genau das, was ich mir erhofft hatte. Jetzt komme ich dem Ziel, meine Fußbodenheizung mit Max Zwischenstecker zu schalten anhand der Lacrosse Temparaturwerte wieder ein Stückchen näher.

Bei der Gelegenheit habe ich auch gleich eine andere USB ID mitkompiliert, warum ich mich ja sowieso noch mit der Toolchain beschäftigen wollte. Meine "make" Zeiten waren schon eine ganze Weile her

Danke nochmal Telekatz!

[Tatsu]

Ich versuche jetzt nur noch verzweifelt diese 'unknown message' Einträge wegzukriegen. Obwohl die Sensoren mit dem HMS Lacrosse Emulator eingebunden sind und im RAW Mode auch Readings erzeugt und protkolliert werden, bleiben die Unknown Einträge erhalten. Anfangs dachte ich mir noch nichts weiter dabei, aber seit dem zweiten Sensor habe ich jetzt alle paar Sekunden gleich zwei Einträge und das fhem Log wird förmlich zugemüllt damit. Mit weiteren Sensoren würde es die ja dann noch vervielfachen.  Kann ich das auch irgendwie (in der a-culfw?) unterdrücken?

[Telekatz]

Code Auswählen Erweitern

set CUN_0 verbose 0

[Tatsu]

Code Auswählen Erweitern

set CUN_0 verbose 0

Super, danke! Da merke ich immer, wie sehr ich noch Anfänger bin. Danke für die Geduld

[Pythonf]

Ich habe einen HMUSB der mit hmland nicht mehr funktioniert habe. Ich wollte nun diese FW aufspielen, in der Hoffnung, dass ich den HMUSB wieder zum laufen bekomme. Ich hab die Jumper gesetzt und letztlich den Pull-UP Wiederstand verbunden. Im Geräte-Manager erhalte ich unter USB-Controller ein

Code Auswählen Erweitern

Unbekanntes USB-Gerät (Fehler beim Anfordern einer Gerätebeschreibung.)
Habt ihr eine Idee, was bzw. ob ich hier noch was machen kann?

Grüße
Fabian

[Telekatz]

Hast du die Jumper auch wieder entfernt?
Hast du den Widerstand nur in den USB Stecker geschoben, oder ihn auch gegen die Kontakte gedrückt, damit er sicher Kontakt hat?

Alternativ lässt sich der Bootloader auch über die serielle Debugschnittstelle ST1 aufspielen. Die Belegung von ST1 ist die Gleiche, wie beim Cube.