Neue Firmware für HM_LC_Sw1PBU_FM mit getrenntem Aktor, Taster + Wechselschalter

[frank]

Raw-messages sniffen mit "attr logIDs <hmid>" ?

am besten die hmid vom schalter, den du testest.

[Mr. P]

Kein Problem... jeder von uns hat ja noch ein Privatleben 

Sorry, komm die Tage zu gar nichts. Steh kurz vor meiner Abschlussprüfung und leider noch einiges zu tun... daher auch nicht so richtig viel Privatleben.

wenn du autocreate aktiv hast, sollte ein 5 sekündiges drücken der configtaste, das device automatisch anlegen. zur sicherheit sniffe mal den vorgang.

Vielen Dank fürs Übernehmen.

[jsloot]

Sorry, komm die Tage zu gar nichts. Steh kurz vor meiner Abschlussprüfung und leider noch einiges zu tun... daher auch nicht so richtig viel Privatleben.
Vielen Dank fürs Übernehmen.

Kein Ding... dann viel Erfolg bei deinen Prüfungen 

[jsloot]

Da mir die Readings level und pct ins Auge stechen. Kann ich damit jetzt eigentlich auch dimmen?

[Mr. P]

Nein...
Ist einfach so in der Bibliothek drinnen... Macht die originale FW übrigens nicht anders.

[nexulm]

am besten die hmid vom schalter, den du testest.

So, habe nun auf die hmid des Schalter 2A338A (=FU_Schalter gesnifft)

Das Ergebnis ist, dass nur über FHEMweb ein-/ausgeschaltet werden kann. Die Tastendruckkommandos kommen nicht richtig durch.
Kann ich den verwendeten HMLAN (ca. 4m Luftlinie entfernt) noch weiter loggen/debuggen?

Weitere Ideen?

Code Auswählen Erweitern

2015.04.23 21:33:12 0: HMLAN_Send:  XX_LANInterface S:+2A338A,00,01,00
2015.04.23 21:33:12 0: HMLAN_Send:  XX_LANInterface S:SE7C50A19 stat:  00 t:00000000 d:01 r:E7C50A19 m:F1 A001 257626 2A338A 04040000000001
2015.04.23 21:33:12 0: HMLAN_Parse: XX_LANInterface R:RE7C50A19 stat:0001 t:0AA71300 d:FF r:FFCB     m:14 805E 2A338A 257626 0000000000000000000000
2015.04.23 21:33:17 0: HMLAN_Send:  XX_LANInterface S:SE7C51EE9 stat:  00 t:00000000 d:01 r:E7C51EE9 m:F1 A001 257626 2A338A 04040000000001
2015.04.23 21:33:17 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA728DC d:FF r:FFC9     m:F1 A010 2A338A 257626 0282008300840085008600870088008900
2015.04.23 21:33:17 0: HMLAN_Parse: XX_LANInterface R:RE7C51EE9 stat:0001 t:0AA728E1 d:FF r:FFC9     m:F1 A010 2A338A 257626 0282008300840085008600870088008900
2015.04.23 21:33:18 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA72B92 d:FF r:FFC9     m:F2 A010 2A338A 257626 028A008B008C000000
2015.04.23 21:33:18 0: HMLAN_Send:  XX_LANInterface S:SE7C52317 stat:  00 t:00000000 d:01 r:E7C52317 m:F2 A001 257626 2A338A 0403
2015.04.23 21:33:19 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA72E4B d:FF r:FFC9     m:F2 A010 2A338A 257626 0100000000
2015.04.23 21:33:19 0: HMLAN_Parse: XX_LANInterface R:RE7C52317 stat:0001 t:0AA72E50 d:FF r:FFC9     m:F2 A010 2A338A 257626 0100000000
2015.04.23 21:35:44 0: HMLAN_Send:  XX_LANInterface S:+2A338A,00,01,00
2015.04.23 21:35:44 0: HMLAN_Send:  XX_LANInterface S:SE7C75D94 stat:  00 t:00000000 d:01 r:E7C75D94 m:F3 A011 257626 2A338A 0203000000
2015.04.23 21:35:44 0: HMLAN_Parse: XX_LANInterface R:RE7C75D94 stat:0001 t:0AA9673D d:FF r:FFC2     m:F3 8002 2A338A 257626 0103000000
2015.04.23 21:35:46 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA96CD8 d:FF r:FFC3     m:16 A410 2A338A 257626 0603000000
2015.04.23 21:35:46 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA96F95 d:FF r:FFC5     m:17 A410 2A338A 257626 0604000000
2015.04.23 21:35:56 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA9937D d:FF r:FFC6     m:18 B040 2A338A 2A338A 0100
2015.04.23 21:35:57 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA997AA d:FF r:FFC6     m:18 B040 2A338A 2A338A 0100
2015.04.23 21:35:58 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA99BD7 d:FF r:FFC6     m:18 B040 2A338A 2A338A 0100
2015.04.23 21:36:03 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA9B086 d:FF r:FFC6     m:19 805E 2A338A 257626 000000000000000C000000
2015.04.23 21:36:07 0: HMLAN_Send:  XX_LANInterface S:+2A338A,00,01,00
2015.04.23 21:36:07 0: HMLAN_Send:  XX_LANInterface S:SE7C7B5EF stat:  00 t:00000000 d:01 r:E7C7B5EF m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:07 0: HMLAN_Parse: XX_LANInterface R:RE7C7B5EF stat:0008 t:00000000 d:FF r:7FFF     m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:07 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:09 0: HMLAN_Send:  XX_LANInterface S:SE7C7BE31 stat:  00 t:00000000 d:01 r:E7C7BE31 m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:10 0: HMLAN_Parse: XX_LANInterface R:RE7C7BE31 stat:0008 t:00000000 d:FF r:7FFF     m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:10 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:13 0: HMLAN_Send:  XX_LANInterface S:SE7C7CFC3 stat:  00 t:00000000 d:01 r:E7C7CFC3 m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:14 0: HMLAN_Parse: XX_LANInterface R:RE7C7CFC3 stat:0008 t:00000000 d:FF r:7FFF     m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:14 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:18 1: PERL WARNING: Useless use of a variable in void context at (eval 181968) line 1.
2015.04.23 21:36:18 1: PERL WARNING: Useless use of a variable in void context at (eval 181970) line 1.
2015.04.23 21:36:18 1: PERL WARNING: Useless use of a variable in void context at (eval 181972) line 1.
2015.04.23 21:36:18 1: PERL WARNING: Useless use of a variable in void context at (eval 181974) line 1.
2015.04.23 21:36:19 0: HMLAN_Send:  XX_LANInterface S:SE7C7E5DE stat:  00 t:00000000 d:01 r:E7C7E5DE m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:20 0: HMLAN_Parse: XX_LANInterface R:RE7C7E5DE stat:0008 t:00000000 d:FF r:7FFF     m:F4 A001 257626 2A338A 030E
2015.04.23 21:36:20 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:22 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AA9FA7F d:FF r:FFC6     m:1A 805E 2A338A 257626 0000000000000000000000
2015.04.23 21:36:27 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AAA0F91 d:FF r:FFC6     m:1B B040 2A338A 2A338A 0200
2015.04.23 21:36:28 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AAA13BE d:FF r:FFC6     m:1B B040 2A338A 2A338A 0200
2015.04.23 21:36:29 0: HMLAN_Parse: XX_LANInterface R:E2A338A   stat:0000 t:0AAA17EC d:FF r:FFC7     m:1B B040 2A338A 2A338A 0200
2015.04.23 21:36:38 0: HMLAN_Send:  XX_LANInterface S:SE7C83200 stat:  00 t:00000000 d:01 r:E7C83200 m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:39 0: HMLAN_Parse: XX_LANInterface R:RE7C83200 stat:0008 t:00000000 d:FF r:7FFF     m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:39 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:41 0: HMLAN_Send:  XX_LANInterface S:SE7C83ACE stat:  00 t:00000000 d:01 r:E7C83ACE m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:41 0: HMLAN_Parse: XX_LANInterface R:RE7C83ACE stat:0008 t:00000000 d:FF r:7FFF     m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:41 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:45 0: HMLAN_Send:  XX_LANInterface S:SE7C84B29 stat:  00 t:00000000 d:01 r:E7C84B29 m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:46 0: HMLAN_Parse: XX_LANInterface R:RE7C84B29 stat:0008 t:00000000 d:FF r:7FFF     m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:49 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A
2015.04.23 21:36:50 0: HMLAN_Send:  XX_LANInterface S:SE7C86146 stat:  00 t:00000000 d:01 r:E7C86146 m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:51 0: HMLAN_Parse: XX_LANInterface R:RE7C86146 stat:0008 t:00000000 d:FF r:7FFF     m:F5 A001 257626 2A338A 030E
2015.04.23 21:36:51 0: HMLAN_Parse: XX_LANInterface no ACK from 2A338A


Kann an der Button-Config noch etwas falsch sein bzw. kann dieser nicht direkt ohne HM-LAN-CFG oder CUL gekoppelt werden. Ist doch auch hardwareseitig auf der gleichen Platine. Meine Rolladenaktuatoren (gleiche Hardware!?!) agieren zumindest alle fehlerfrei direkt bei Tastendruck.

Code Auswählen Erweitern


Internals:
   CFGFN      /etc/fhem/flur.cfg
   DEF        2A338A01
   NAME       FU_Schalter_Btn_01
   NR         1220
   STATE      Short (to FU_Schalter)
   TYPE       CUL_HM
   chanNo     01
   device     FU_Schalter
   peerList   self03,
   Readings:
     2015-04-21 23:55:21   R-dblPress      0 s
     2015-04-21 23:55:21   R-longPress     0.3 s
     2015-04-22 12:30:44   R-self03-expectAES off
     2015-04-22 12:30:44   R-self03-peerNeedsBurst on
     2015-04-21 23:55:21   R-sign          off
     2015-04-24 00:52:31   RegL_01:          04:00 08:00 09:00 00:00
     2015-04-24 00:52:45   RegL_04:self03    01:01 00:00
     2015-04-24 00:52:32   peerList        self03,
     2015-04-23 23:48:20   state           Short (to FU_Schalter)
     2015-04-23 23:48:20   trigger         Short_1
     2015-04-23 23:48:20   trigger_cnt     1
   Helper:
     peerIDsRaw ,2A338A03,00000000
     Role:
       chn        1
     Shadowreg:
Attributes:
   group      Licht
   model      HM-LC-Sw1PBU-FM-CustomFW
   peerIDs    00000000,2A338A03,
   room       Flur_EG

[nexulm]

...eine blöde Frage:
Ist die Reihenfolge beim Bootloader-Flashen entscheidend zwischen 1. Fuses setzen und 2. Bootloader flashen?

Möglicherweise habe ich erst den Bootloader per avrdude geflasht und anschliessend die Fuses mit avrdude wie im Wiki beschrieben gesetzt.

Ich überlege gerade ob ich einen meiner nicht korrekt funktionierenden Taster wieder öffne und den Bootloader neu flashe, wobei mir gerade einfällt dass dies auch OTA möglich ist, also baue ich einfach mal den Bootloader als eq3 file.

Kann dies wohl meine mir unerklärlichen Probleme lösen?

[frank]

Kann dies wohl meine mir unerklärlichen Probleme lösen?

ich glaube nicht. wichtig ist die reihenfolge mit den fuses schon. aber der bootbereich ist im original-schalter auch bereits 8k. aber probieren geht über studieren. 

ich habe gerade mal mit den raw-messages von meinem schalter verglichen. auffällig ist bei dir, dass dein schalter die eigenen infos über funk sendet. also an sich selbst. das peering mit sich, sollte das eigentlich unterbinden und die infos intern verarbeiten. es sieht so aus, als sei mit dem peering etwas faul und es wird angenommen, dass der gepeerte chn3 zu einem externen device gehört. die frage ist nun, wodurch ist das möglich. da es bei allen deinen schaltern passiert, muss es etwas systematisches sein. poste mal den codeausschnitt, wo du die schalterinfos in der firmware geändert hast.

[nexulm]

ich habe gerade mal mit den raw-messages von meinem schalter verglichen. auffällig ist bei dir, dass dein schalter die eigenen infos über funk sendet. also an sich selbst. das peering mit sich, sollte das eigentlich unterbinden und die infos intern verarbeiten. es sieht so aus, als sei mit dem peering etwas faul und es wird angenommen, dass der gepeerte chn3 zu einem externen device gehört. die frage ist nun, wodurch ist das möglich. da es bei allen deinen schaltern passiert, muss es etwas systematisches sein. poste mal den codeausschnitt, wo du die schalterinfos in der firmware geändert hast.

Meine Änderungen in der Register.h sehen wie folgt aus (s. auch Diff im Anhang):

Code Auswählen Erweitern

//- settings of HM device for HM class -------------------------------------------------------------------------------------
const uint8_t devParam[] PROGMEM = {
/* Firmware version 1 byte */  0x15, // don't know for what it is good for
/* Model ID         2 byte */  0xF0, 0xA9, //0x00, 0x6C // model ID, describes HM hardware. we should use high values due to HM starts from 0
/* Serial ID       10 byte */  'L','E','Q','0','2','4','4','1','2','3', // serial ID, needed for pairing
/* Sub Type ID      1 byte */  0x10, // not needed for FHEM, it's something like a group ID
/* Device Info      3 byte */  0x41, 0x01, 0x00 // describes device, not completely clear yet. includes amount of channels
};

//const uint8_t  HMID[3]     = { 0x20, 0x7C, 0x41 }; // 207C41 // very important, must be unique. identifier for the device in the network
const uint8_t  HMID[3]     = { 0x2A, 0x33, 0x63 };     // 208557
const uint8_t  maxRetries  = 3; // how often a string should be send out until we get an answer
const uint16_t timeOut     = 700; // time out for ACK handling


Darüber hinaus habe ich in der Asksin_HM_LC_Sw1PBU_FM.ino nur zu Testzwecken für lowCurrent Verbraucher minImpulsLength von 5000 auf 500 geändert!
Wobei ich (noch) nicht in allen Tastern die LowCurrent Variante geflasht habe. Allerdings habe ich auch beim FU_Schalter keinen Unterschied bzgl. Systemverhalten bei mir zwischen der Firmware mit minImpulsLength=5000 und minImpulsLength=500 feststellen können.

Zudem habe ich im Bootloader entsprechend das define für HM_SERIAL und HM_ID jeweils entsprechend für den jeweiligen Taster angepasst. Darüber hinaus habe ich dann das define DEBUG 1 auf #define DEBUG 0 gesetzt (s. Anhang Bootloader_changes.png)!

[frank]

langsam gehen mir die ideen aus! 

deine code-änderungen sehen soweit ok aus. beim bootloader würde ich aber zusätzlich die modelID auch noch auf 0xF0A9 setzen, falls die daten irgendwann einmal von der fw automatisch übernommen werden können sollten. 

im code habe ich gerade die defaulteinstellungen vom peering gesehen:

Code Auswählen Erweitern

  // Default actor single: 02:00 03:00 04:32 05:64 06:00 07:FF 08:00 09:FF 0A:01 0B:14 0C:63 82:00 83:00 84:32 85:64 86:00 87:FF 88:00 89:FF 8A:21 8B:14 8C:63 00:00

das scheint bei dir ja auch nicht zu funktionieren. also müssen im eeprom irgendwelche seltsamen daten sein. da du über fhem resettet hast, wäre es vielleicht noch einen versuch wert, direkt am device zu resetten. 2 mal ca 5 sekunden lang drücken. anschliessend erst einmal einen taster peeren und dann sniffen.

ansonsten noch einmal von vorne beginnen => fuses setzen, bootloader flashen, fw flashen.

beim compilieren sind ja sicherlich keine fehler aufgetreten? mit welcher ide/betriebssystem baust du fw's? welche avrdude version?

Wobei ich (noch) nicht in allen Tastern die LowCurrent Variante geflasht habe. Allerdings habe ich auch beim FU_Schalter keinen Unterschied bzgl. Systemverhalten bei mir zwischen der Firmware mit minImpulsLength=5000 und minImpulsLength=500 feststellen können.

du hast auch sehr geringe lasten. vielleicht müsste der wert noch tiefer sein. entscheidend ist halt, dass chn4 den richtigen lampenstatus anzeigt.

[nexulm]

langsam gehen mir die ideen aus! 

Uih, ich hoffe mit dem bisherigen vorbildlichen Support komme ich/wir zum Ziel.

deine code-änderungen sehen soweit ok aus. beim bootloader würde ich aber zusätzlich die modelID auch noch auf 0xF0A9 setzen, falls die daten irgendwann einmal von der fw automatisch übernommen werden können sollten. 

Falls ich den Bootloader wirklich neu baue, würde ich dies tun. Allerdings würde ich den am liebsten OTA flashen. Wobei ich dies bisher nur mit der Firmware gemacht habe. Bei durchstöbern der Readme.md in den Bootloader sourcen war mir vorhin allerdings nicht klar warum ob ich srec_cat wirklich auch für den Bootloader nutzen muss.
Ich müsste ja -so mein Verständnis- erstmal mit hex2bin ein Binary erzeugen und dann bin2eq3.php nutzen.
Möglicherweise kann man aber direkt mit hex2eq3 auch den Bootloader bauen!?!

das scheint bei dir ja auch nicht zu funktionieren. also müssen im eeprom irgendwelche seltsamen daten sein. da du über fhem resettet hast, wäre es vielleicht noch einen versuch wert, direkt am device zu resetten. 2 mal ca 5 sekunden lang drücken. anschliessend erst einmal einen taster peeren und dann sniffen.

Werde ich nochmal versuchen, sicher ist sicher.

ansonsten noch einmal von vorne beginnen => fuses setzen, bootloader flashen, fw flashen.

Ich hätte jetzt den Prozess Fuses setzen weggelassen, da die korrekt sind. Höchstens in der Reihenfolge zuerst Bootloader per avrdude flashen und dann Fusese gesetzt vertauscht.
Da sollte doch nun auch ein Bootloader OTA flash das Gleiche bewirken, oder?

beim compilieren sind ja sicherlich keine fehler aufgetreten? mit welcher ide/betriebssystem baust du fw's? welche avrdude version?

Ich kann mich nicht an Fehler erinnern. Meine Umgebung ist eine virtuelle Linux Maschine (Virtualbox) mit Kubuntu (14.04). Für den Bootloader habe ich einfach den 8k make-Befehl genutzt (wie empfohlen) und für die Firmware habe ich die Standard Arduino-IDE von Kubuntu genutzt.
avrdude v5.10
du hast auch sehr geringe lasten. vielleicht müsste der wert noch tiefer sein. entscheidend ist halt, dass chn4 den richtigen lampenstatus anzeigt.

[frank]

Bei durchstöbern der Readme.md in den Bootloader sourcen war mir vorhin allerdings nicht klar warum ob ich srec_cat wirklich auch für den Bootloader nutzen muss.

weil alle eq3 dateien vom bootloader nach dem ota-update auf checksumme geprüft werden. alles was ota kommt, auch der neue bootloader. wenn das ok ist, kopiert anschliessend ein teil des aktiven bootloaders (mini-bootloader) den neuen in den bootbereich. dieser minibootloader bleibt immer der selbe. es sei denn, man flasht den bootloader wieder über spi.

Möglicherweise kann man aber direkt mit hex2eq3 auch den Bootloader bauen!?!

na klar, im wiki sollten die optionen beschrieben sein.

Meine Umgebung ist eine virtuelle Linux Maschine (Virtualbox) mit Kubuntu (14.04). Für den Bootloader habe ich einfach den 8k make-Befehl genutzt (wie empfohlen) und für die Firmware habe ich die Standard Arduino-IDE von Kubuntu genutzt.
avrdude v5.10

das ist gänzlich anders als bei mir. win7/ide1.05/winavr2010. keine ahnung, ob das entscheidend ist.

ob du nun mit fuses, oder ohne und vertauscht oder nicht.... egal, weil eigentlich müssten auch die original fuses stimmen, denke ich. dein bootloader hat die fw geladen und diese gecheckt und gestartet. im prinzip tut ja auch alles, nur nicht korrekt.
mit avrdude kann man glaub ich auch den eeprom testen und löschen. wäre noch ne idee. bei mir hat avrdude immer ne meldung gebracht, dass eeprom erased wurde. vielleicht wurde dieser schritt bei dir nicht gemacht. keine ahnung, deswegen die idee, alles von vorne nach anleitung neu flashen. stochern im dunkeln. 

[nephdrasil]

Hi vielleicht kann mir irgend jemand weiterhelfen.
Ich bekomme es einfach nicht hin die Serial, die Model-ID und die HMID aus dem Bootloader auszulesen.

devParam und HMID habe ich (Dirk) wie folgt definiert:

Code Auswählen Erweitern


#define ADDRESS_SECTION_START  0x7FF2
#define FIRMWARE_VERSION 0x15
#define DEVICE_TYPE 0xFF, 0xFF
#define DEVICE_SERIAL 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
#define FRAME_TYPE 0x10
#define DEVICE_INFO 0x41, 0x10, 0x00
#define DEVICE_ADDRESS 0xFF, 0xFF, 0xFF

uint8_t devParam[] = {
         FIRMWARE_VERSION,
         DEVICE_TYPE,
         DEVICE_SERIAL,
         FRAME_TYPE,
         DEVICE_INFO
      };

const uint8_t HMID[3] = {DEVICE_ADDRESS}


Die Funktionen die genutzt wird ist die folgende:

Code Auswählen Erweitern

void getDataFromAddressSection(uint8_t *buffer, uint8_t bufferStartAddress, uint16_t sectionAddress, uint8_t dataLen) {
   for (unsigned char i = 0; i < dataLen; i++) {
      buffer[(i + bufferStartAddress)] = pgm_read_byte(sectionAddress + i);
   }
}

in Zusammenspiel mit dieser Funktion:

Code Auswählen Erweitern

getDataFromAddressSection(devParam, 1,  ADDRESS_SECTION_START + 0, 2); Liest DEVICE_TYPE

Code Auswählen Erweitern

getDataFromAddressSection(devParam, 3,  ADDRESS_SECTION_START + 2, 10); Liest die DEVICE_SERIAL

Code Auswählen Erweitern

getDataFromAddressSection(HMID, 0,  ADDRESS_SECTION_START + 2, 10); Liest die DEVICE_ADDRESS


Leider bekomme ich aufgrund des const vor HMID folgenden Fehler:

invalid conversion from 'const uint8_t* {aka const unsigned char*}' to 'uint8_t* {aka unsigned char*}' [-fpermissive]

Bin ich auf dem Richtigen weg oder ist es die falsche vorgehensweise? Wie behebe ich den aufgtauchten Fehler.
Ich bin etwas am verzweifeln. Egal was ich mache es funktioniert nicht.

[frank]

Wie behebe ich den aufgtauchten Fehler.

entferne das "const". dirk declariert abhängig vom fall, ob diese daten benutzt werden sollen oder nicht. wenn nicht, sind sie eben auch konstant. verbraucht bestimmt weniger speicherplatz.

beim lesen der hmid musst du die adresse ändern:

Code Auswählen Erweitern

getDataFromAddressSection(HMID, 0,  ADDRESS_SECTION_START + 12, 3);

Code Auswählen Erweitern

ADDRESS_SECTION_START
ist beim wettersensor 0x7FF0 und nicht 0x7FF2. das gilt aber für 32k speicher. der schalter hat 64k daher ist die startadresse 0xFFF0. siehe zb makefile vom bootloader.

[nephdrasil]

Vielen Dank frank,

das führt jetzt aber zu anderen Fehlern.

const beduetet meines Wissens nach das die Variable nicht verändert werden kann.

Ich gebe es für heute auf. Komme einfach mit meinem Wissen nicht weiter. Also doch hart codieren.