Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jeffaries
    @jeffaries
    I didn't plan to manually write the EEPROM... it was supposed to be part of an automatic toolchain that would write the sketch than the EEPROM
    Giovanni Blu Mitolo
    @gioblu
    if the first 4 bytes of 2 different MACs are the same
    jeffaries
    @jeffaries
    @gioblu , this is not important, once the Master acknowledge the slave, it keeps a map of id+RID
    id+MAC
    Giovanni Blu Mitolo
    @gioblu
    yes, if you do so its fine
    my concern was, you have an incomplete MAC used as GUID/RID that is the same of another device already in list
    the device not in list asks for an id
    the master finds that MAC already in the list and will not accept the unlisted slave
    jeffaries
    @jeffaries
    That's why I was basically thinking of a S/N that would be written during the production of the device (upload of the sketch, than, upload of the SPIFF or EEPROM). This way, I can make sure that the S/N is unique for my systems
    Giovanni Blu Mitolo
    @gioblu
    yes that is probably safer
    Fred Larsen
    @fredilarsen
    Unless the dynamic addressing is changed to support the bytes of a MAC?
    Giovanni Blu Mitolo
    @gioblu
    yes
    it could be done
    jeffaries
    @jeffaries
    One question... what about the devices without network?
    Giovanni Blu Mitolo
    @gioblu
    if you have MCUs that does not own a MAC that could be a problem
    jeffaries
    @jeffaries
    Atmel devices like ATTiny84...
    I use softwarebitbang... so I don't need them to have network
    Fred Larsen
    @fredilarsen
    Would have to assign these serially then. That could be skipped on devices with a MAC.
    If you have the burning of the number to EEPROM automated, it makes little difference to you, though. But others that have to do it manually could appreciate to skip this step, and still burn equal code to many devices.
    jeffaries
    @jeffaries
    I cannot agree more Fred ;)
    It would be great
    Giovanni Blu Mitolo
    @gioblu
    I would be happy to include your request and suggestions
    in the newcoming classes
    aligned with v12.0
    that @jeffaries will use for his project
    jeffaries
    @jeffaries
    @gioblu keep your current roadmap. You do a so great (and enormous) work... I would feel bad to add extra work ;)
    I will continue for the moment with the current version ;)
    Giovanni Blu Mitolo
    @gioblu
    thank you for your compliments
    and please report if you have any issue
    Klaus
    @KlausNZ
    Hey folks,
    I use some kind of dynamic addressing with my attiny85 chips. I use a 2 byte id that can be set through config which will be mapped to a dynamic bus id. All chips are flashed with the same codebase. On startup I calculate a pseudo random id (seed) based on the former calculated id and reading some pins analog input values. Then store this new id in eeprom as base for next calculation.
    I can share the code if you like.
    Giovanni Blu Mitolo
    @gioblu
    Ciao @KlausNZ
    I am for sure curious to read the code :) thank you
    Klaus
    @KlausNZ
    #define    RANDOM_SEED_ADDRESS    0x00
    
    uint16_t   _random_number = 0;
    
    uint16_t lfsr16_next(uint16_t n) {
      return (n >> 0x01U) ^ (-(n & 0x01U) & 0xB400U);
    }
    
    void random_init(uint16_t seed) {
      uint16_t a1 = analogRead(A1); if (a1 == 0) a1 = 1;
      uint16_t a2 = analogRead(A2); if (a2 == 0) a2 = 1;
      uint16_t a3 = analogRead(A3); if (a3 == 0) a3 = 1;
      uint16_t a  = seed * a1 * a2 * a3;
      _random_number = lfsr16_next(eeprom_read_word((uint16_t *) RANDOM_SEED_ADDRESS) ^ a);
      eeprom_write_word((uint16_t *) RANDOM_SEED_ADDRESS, _random_number);
    }
    
    uint16_t randomize(void) {
      return (_random_number = lfsr16_next(_random_number));
    }
    
    setup {
      random_init(micros());
      _mySeed = randomize();
    }
    Probably not beautiful, but it works on my atTiny85. Every boot a new (semi) random number
    Giovanni Blu Mitolo
    @gioblu
    ciao @KlausNZ sorry for the late response, I got sucked in the release related hassle
    soon v12.0 will be out :)
    It seems fine, I see you write in the eeprom the new random id every restart? Consider that the eeprom has a maximum amount of writes, then it breaks. If the device is not restarted often or at a fixed cyclic interval, it should be fine!
    Klaus
    @KlausNZ
    No worries. Theoretical there is no reboot other than installing new software or a powercut. As they are fed by car batteries in the garage, the latter is kinda unlikely. And changing 250 nodes software in a quick cycle is very unlikely as I'm lazy in these things...
    Giovanni Blu Mitolo
    @gioblu
    good job :)
    I am curious to see the setup when will be operational!
    I am still flooded by work and tests on the protocol, and still wiring coming out of the walls
    Klaus
    @KlausNZ
    Hehe.
    Early version are running in several parts of the house. I'm on leave this week and wanted to progress quite a bit, but lying down with 40 degree right now...
    Klaus
    @KlausNZ
    Feels like being able to bake new led driver boards right in my hand
    Giovanni Blu Mitolo
    @gioblu
    :)
    @KlausNZ have you recently compiled code on ESP8266?
    have you noticed any compilation error?
    Klaus
    @KlausNZ
    No haven't done anything with esps lately (actually for a long time)
    You suspect some difficulties with your new code?
    Giovanni Blu Mitolo
    @gioblu
    ciao @KlausNZ sorry, no another user was complaining about a compilation error, but it seems that occurs on platformIO
    I should take some time and take more familiarity with it