Skip to content
  • MySensors
  • OpenHardware.io
  • Categories
  • Recent
  • Tags
  • Popular
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Brand Logo
  1. Home
  2. Development
  3. Routing table saving vs EEPROM write cycle limitations

Routing table saving vs EEPROM write cycle limitations

Scheduled Pinned Locked Moved Development
3 Posts 2 Posters 1.1k Views 3 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • andrewA Offline
    andrewA Offline
    andrew
    wrote on last edited by
    #1

    Hi All,

    I'm new to this forum and I love the solutions demonstrated here both on HW and SW level.
    I just started to read/understand the MySensors API and I might have an interesteing finding on the topic.

    As I see, the routing table is periodically saved to the EEPROM based on the following code snippets:

    MyConfig.h

    /**
    * @def MY_ROUTING_TABLE_SAVE_INTERVAL_MS
    * @brief Interval to dump content of routing table to eeprom
    */
    #ifndef MY_ROUTING_TABLE_SAVE_INTERVAL_MS
    #define MY_ROUTING_TABLE_SAVE_INTERVAL_MS    (10*60*1000ul)
    #endif
    

    MyTransport.cpp

    ...
            #if defined(MY_RAM_ROUTING_TABLE_ENABLED)
                    if (hwMillis() - _lastRoutingTableSave > MY_ROUTING_TABLE_SAVE_INTERVAL_MS) {
                            _lastRoutingTableSave = hwMillis();
                            transportSaveRoutingTable();
                    }
            #endif
    ...
    void transportSaveRoutingTable(void) {
            #if defined(MY_RAM_ROUTING_TABLE_ENABLED)
                    hwWriteConfigBlock((void*)&_transportRoutingTable.route, (void*)EEPROM_ROUTES_ADDRESS, SIZE_ROUTES);
                    TRANSPORT_DEBUG(PSTR("TSF:SRT:OK\n"));  //  save routing table
            #endif
    }
    

    So, is this means that the enforced routing table backup to the EEPROM (even if it is not updated) will kill the EEPROM around 1.9 years (10 min saving period means 144 savings per day, thus the 100k EEPROM write life cycle will be reached in 694 days)?

    If I'm right then is it worth to update the API and increase the default saving time in the MyConfig.h (to save a lot of users whom do not know these function in depth and just use the default code) or add some additional code which allows the EEPROM update only when the routing table is updated?

    Or I just miss something and it is handler properly.

    Regards,
    Andrew

    YveauxY 1 Reply Last reply
    1
    • andrewA andrew

      Hi All,

      I'm new to this forum and I love the solutions demonstrated here both on HW and SW level.
      I just started to read/understand the MySensors API and I might have an interesteing finding on the topic.

      As I see, the routing table is periodically saved to the EEPROM based on the following code snippets:

      MyConfig.h

      /**
      * @def MY_ROUTING_TABLE_SAVE_INTERVAL_MS
      * @brief Interval to dump content of routing table to eeprom
      */
      #ifndef MY_ROUTING_TABLE_SAVE_INTERVAL_MS
      #define MY_ROUTING_TABLE_SAVE_INTERVAL_MS    (10*60*1000ul)
      #endif
      

      MyTransport.cpp

      ...
              #if defined(MY_RAM_ROUTING_TABLE_ENABLED)
                      if (hwMillis() - _lastRoutingTableSave > MY_ROUTING_TABLE_SAVE_INTERVAL_MS) {
                              _lastRoutingTableSave = hwMillis();
                              transportSaveRoutingTable();
                      }
              #endif
      ...
      void transportSaveRoutingTable(void) {
              #if defined(MY_RAM_ROUTING_TABLE_ENABLED)
                      hwWriteConfigBlock((void*)&_transportRoutingTable.route, (void*)EEPROM_ROUTES_ADDRESS, SIZE_ROUTES);
                      TRANSPORT_DEBUG(PSTR("TSF:SRT:OK\n"));  //  save routing table
              #endif
      }
      

      So, is this means that the enforced routing table backup to the EEPROM (even if it is not updated) will kill the EEPROM around 1.9 years (10 min saving period means 144 savings per day, thus the 100k EEPROM write life cycle will be reached in 694 days)?

      If I'm right then is it worth to update the API and increase the default saving time in the MyConfig.h (to save a lot of users whom do not know these function in depth and just use the default code) or add some additional code which allows the EEPROM update only when the routing table is updated?

      Or I just miss something and it is handler properly.

      Regards,
      Andrew

      YveauxY Offline
      YveauxY Offline
      Yveaux
      Mod
      wrote on last edited by
      #2

      @andrew said:

      Or I just miss something and it is handler properly.

      The hwWriteConfigBlock() function only writes bytes that actually changed to eeprom.
      This means that as long as the routing table is static, no eeprom writes will be performed.

      http://yveaux.blogspot.nl

      1 Reply Last reply
      2
      • andrewA Offline
        andrewA Offline
        andrew
        wrote on last edited by
        #3

        Oh, I see. That make sense.
        Thank you for the reply!

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        13

        Online

        11.7k

        Users

        11.2k

        Topics

        113.0k

        Posts


        Copyright 2019 TBD   |   Forum Guidelines   |   Privacy Policy   |   Terms of Service
        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • MySensors
        • OpenHardware.io
        • Categories
        • Recent
        • Tags
        • Popular