LazyConfig / EEPROM usage

[papa]

Hoffe mal das funktioniert - ist nur Copy&Paste von weiter oben

[TomMajor]

zum Thema EEPROM kaputtschreiben, bei meinem 6fach S0-Stromzähler (HomeMatic, aber nicht AskSin++) mache ich das

Für das Ablegen der Zählerstände verwende ich einen Ringbuffer mit 12 Positionen (dabei nimmt eine Position alle 6 Zählerstände sowie ein Prüfsummen-CRC auf).
Damit wird der gleiche EEPROM Platz nur 2x am Tag geschrieben, bei 100000 spezifizierten Write/Erase-Zyklen des ATmega328P EEPROM beträgt dessen Lebensdauer >100 Jahre.

https://github.com/TomMajor/SmartHome/t ... ES-S0-CNT6

Als Anregung, vlt. kannst du es mal gebrauchen wenn du öfter in den EE schreiben willst.

[jp112sdl]

Als Anregung

An sowas (Ringbuffer) hatte ich beim Wasserzähler gar nicht gedacht, weil ich so auf den FRAM (der ja schon da war) fixiert war.
Da ich aber noch einen Zähler erfassen möchte, werde ich deine RingBuffer Lösung wohl dort mal integrieren.

[FUEL4EP]

Hallo Zusammen,

vielen Dank für Eure fantastisch gute Hilfe!

Bei einem anderen Sensor habe ich wohl auch ein Problem mit dem LazyConfig, wo ich nochmals Eure Hilfe brauche.
Dieser Sensor macht nicht extensiv Nutzen von EEPROM, sondern speichert nur einen weiteren Parameter in List0 ab:

Code: Alles auswählen

// die "freien" Register 0x20/21 werden hier als 16bit memory für das Update
// Intervall in Sek. benutzt siehe auch hb-uni-sensor1.xml, <parameter
// id="Sendeintervall"> .. ausserdem werden die Register 0x22/0x23 für den
// konf. Parameter Höhe benutztF
DEFREGISTER(Reg0, MASTERID_REGS, DREG_LEDMODE, DREG_LOWBATLIMIT, DREG_TRANSMITTRYMAX, 0x20, 0x21, 0x22, 0x23)
class SensorList0 : public RegList0<Reg0> {
public:
    SensorList0(uint16_t addr)
        : RegList0<Reg0>(addr)
   {
   }

    bool     updIntervall(uint16_t value) const { return this->writeRegister(0x20, (value >> 8) & 0xff) && this->writeRegister(0x21, value & 0xff); }
    uint16_t updIntervall() const { return (this->readRegister(0x20, 0) << 8) + this->readRegister(0x21, 0); }

    bool     altitude(uint16_t value) const { return this->writeRegister(0x22, (value >> 8) & 0xff) && this->writeRegister(0x23, value & 0xff); }
    uint16_t altitude() const { return (this->readRegister(0x22, 0) << 8) + this->readRegister(0x23, 0); }

    void defaults()
    {
        clear();
        ledMode(1);
        lowBatLimit(BAT_VOLT_LOW);
        transmitDevTryMax(6);
        updIntervall(240);
        altitude(84);             // height of sensor's location above sea level; adjust to your sensor's location in WebUI device / device/channel parameter page
    }
};

Offensichtlich sind die EEPROM Adressen 0x22, 0x23 nicht frei, sondern belegt. Das hat zur Folge, dass auch hier eine Peermessage mit der Adresse 0 rausgeschickt wird:

Vor Anlernen:

Code: Alles auswählen

10:40:49.954 -> msgcnt    : 7
10:40:49.954 -> msg flags    : 0
10:40:49.987 -> <- 15 07 86 70 F60401 000000 00 ED 01 17 27 9E 00 28 02 54 0C D3  - 1484
10:40:49.987 -> Peer message sent

Nach erneutem Anlernen:

Code: Alles auswählen

10:57:18.360 -> msgcnt    : 12
10:57:18.360 -> msg flags    : 0
10:57:18.360 -> <- 15 0C A2 70 F60401 15473D 00 F5 01 0D 27 9F 00 29 02 58 0C CA  - 22134
10:57:18.526 -> -> 0A 0C 80 02 15473D F60401 00  - 22259
10:57:18.526 -> waitAck: 01
10:57:18.526 -> Peer message sent

Frage: Wie ist es richtig, zusätzliche List0 Parameter zu definieren ohne dass es zu EEPROM Konflikten kommt?

Hier noch die Startsequenz im seriellen Monitor zur Vollständigkeit:

Code: Alles auswählen

10:15:49.468 -> AskSin++ V4.1.7 (Jan  3 2021 10:51:241)
10:15:49.501 -> BME280 sensor OK
10:15:49.501 -> BME280 offsets (all x10):
10:15:49.534 -> -T    : -1
10:15:49.534 -> -P    : -1
10:15:49.534 -> -H    : -1
10:15:49.534 -> Sensor setup done
10:15:49.534 -> Serial: BME280THP1
10:15:49.534 -> Clock SYSCLOCK
10:15:49.534 -> Address Space: 32 - 81
10:15:49.534 -> FFFFFFFF
10:15:49.534 -> Init Storage: CAFEAE79
10:15:49.734 -> CC init1
10:15:49.734 -> CC Version: 14
10:15:49.767 ->  - ready
10:15:49.800 -> tmBattery Voltage: 3303
10:15:49.800 -> Battery set low:  24
10:15:49.900 -> Battery set crit: 20
10:15:49.900 -> Config Changed: List0
10:15:49.900 -> ledMode: 1
10:15:49.900 -> lowBatLimit: 24
10:15:49.900 -> Battery set low:  24
10:15:49.900 -> transmitDevTryMax: 6
10:15:49.900 -> updCycle: 240

[jp112sdl]

Offensichtlich sind die EEPROM Adressen 0x22, 0x23 nicht frei, sondern belegt

Meinst du wirklich EEPROM Adresse 0x22 und 0x23 oder den Register-Index 0x22, 0x23:

Code: Alles auswählen

DEFREGISTER(Reg0, MASTERID_REGS, DREG_LEDMODE, DREG_LOWBATLIMIT, DREG_TRANSMITTRYMAX, 0x20, 0x21, 0x22, 0x23)

An letzterem ist nix verkehrt

Hier noch die Startsequenz im seriellen Monitor zur Vollständigkeit:

Ja da sieht man gut, dass dein Speicher frisch initialisiert wird

Code: Alles auswählen

10:15:49.534 -> Init Storage: CAFEAE79

Das Problem, dass dein Speicher immer wieder neu initialisiert wird, muss woanders herkommen

[FUEL4EP]

Hi Jérôme,

danke für Deine Analyse.

Wie kann ich da weitersuchen?

Der Code steht übrigens unter

https://github.com/FUEL4EP/HomeAutomati ... BME280.ino

Damit teste ich Deinen Vorschlag '<conversion type="sint4_sintx" physical_bytes="1" />' für die 1Byte große Offsetkompensation einzusetzen:

https://github.com/FUEL4EP/HomeAutomati ... ml#L77-L97

Es funktioniert so Es geht nur mit logical type="integer".

[FUEL4EP]

Hi Jérôme,

ich hab mal in meinen Code ein 'device().getList0().masterid())' eingebaut:

Code: Alles auswählen

virtual void trigger(AlarmClock& clock)
    {
        measure();
        
        device().battery().update();                            // get current battery voltage; measure every sampling cycle
        operatingVoltage1000 = device().battery().current();    // BatteryTM class, mV resolution
        DPRINT("battery voltage x1000 = ");       DDECLN(operatingVoltage1000);
        
        uint8_t msgcnt = device().nextcount();
        msg.init(msgcnt, temperature10, humidity10, airPressure10, dewpoint10, vaporConcentration100, operatingVoltage1000, device().battery().low());
        DPRINT(F("msg flags    : ")); DDECLN(msg.flags() & Message::BCAST);
        DPRINT(F("masterID   : ")); DDECLN(device().getList0().masterid());
        if (msg.flags() & Message::BCAST) {
            device().broadcastEvent(msg, *this);
            DPRINTLN("Broadcast message sent");
        } else {
            device().sendPeerEvent(msg, *this);
            DPRINTLN("Peer message sent");
        }

Damit bekomme ich:

Direkt nach dem Flashen:

Code: Alles auswählen

13:01:01.780 -> msgcnt    : 1
13:01:01.780 -> msg flags    : 4
13:01:01.780 -> masterID   : 0
13:01:01.780 -> <- 15 01 84 70 F60401 000000 00 F0 01 49 27 96 00 43 02 CE 0C B7  - 595
13:01:01.890 -> Broadcast message sent

Nach erneutem Anlernen:

Code: Alles auswählen

13:05:05.865 -> msgcnt    : 3
13:05:05.865 -> msg flags    : 4
13:05:05.865 -> masterID   : 15473D
13:05:05.899 -> <- 15 03 84 70 F60401 000000 00 F0 01 49 27 96 00 43 02 CD 0C CA  - 20807
13:05:05.899 -> Broadcast message sent

Nach Parametereingabe im WebUI:

Code: Alles auswählen

13:13:24.561 -> msgcnt    : 5
13:13:24.561 -> msg flags    : 4
13:13:24.561 -> masterID   : 15473D
13:13:24.598 -> <- 15 05 84 70 F60401 000000 00 F0 01 56 27 96 00 49 02 EA 0C C0  - 21127
13:13:24.598 -> Broadcast message sent

Dann bei msgcnt = 7 (so eingestellt für Debugzwecke):

Code: Alles auswählen

     
        if ((msgcnt % 5) == 2) {
            flags = BIDI | WKMEUP;
        }   
 

Code: Alles auswählen

13:21:43.352 -> msgcnt    : 7
13:21:43.352 -> msg flags    : 0
13:21:43.352 -> masterID   : 15473D
13:21:43.352 -> <- 15 07 A2 70 F60401 15473D 00 F1 01 3E 27 96 00 3E 02 B7 0C CA  - 21448
13:21:43.518 -> -> 0A 07 81 02 15473D F60401 00  - 21573
13:21:43.518 -> waitAck: 01
13:21:43.518 -> Peer message sent

Dann erneutes Flashen:

Code: Alles auswählen

13:23:55.704 -> msgcnt    : 1
13:23:55.704 -> msg flags    : 4
13:23:55.704 -> masterID   : 0
13:23:55.737 -> <- 15 01 84 70 F60401 000000 00 F6 01 31 27 97 00 3C 02 AD 0C C0  - 585
13:23:55.737 -> Broadcast message sent

Und siehe da die masterID ist verlorengegangen!

Woran kann das liegen?

[jp112sdl]

Dann erneutes Flashen:

Was wurde denn im Sketch zwischen den beiden "Flashen" verändert?
Wenn du was an den Listen änderst, wird auch das Storage neu initialisiert.

Flashst du per FTDI oder per ISP?
Wenn per ISP hast du die Fuse "preserve EEPROM through chip erase cycle" aktiviert?
Ansonsten ist dein EEPROM nach jedem Flashen leer (was auch in deiner vorherigen Nachricht auffiel 'FFFFFF')

[FUEL4EP]

Hi Jérôme,

BINGO, das war der entscheidende Hinweis:

Wenn per ISP hast du die Fuse "preserve EEPROM through chip erase cycle" aktiviert?

Ich flashe mit dem ISP Programmer.

Nach dem Setzen des EESAVE Bits mit avrdude

Code: Alles auswählen

avrdude -v -pm328p -P usb -c stk500v2  -b 9200 -Ulfuse:w:0xFF:m -Uhfuse:w:0xD6:m -Uefuse:w:0xFF:m

blieb die masterID nach dem Flashen erhalten. Problem gelöst! Hab wieder was dazu gelernt. Vielen Dank!

[jp112sdl]

oder z.B. innerhalb eines Channels durch

Code: Alles auswählen

device().getUserStorage().setByte(offset,data);

Geht bei mir nicht

Code: Alles auswählen

../HB-UNI-Sen-PC-WM.ino:355:28: error: 'as::Channel<as::AskSin<as::StatusLed<22>, as::NoBattery, as::Radio<as::LibSPI<8>, 6> >, UList1, as::EmptyList, as::List4, 4, UList0>::DeviceType {aka class as::Device<as::AskSin<as::StatusLed<22>, as::NoBattery, as::Radio<as::LibSPI<8>, 6> >, UList0>}' has no member named 'getUserStorage'
 

Das hier geht aber im setup():

Code: Alles auswählen

uint8_t b = sdev.getUserStorage().getByte(offset);