Changing the address of the Attiny

[UPDATE] I've soldered up another Lameboy and checked the behaviour in Arduino, tried sending data to 0x0d but nothing happened. I've then set the address to 0x0d and it works with that address. Seems like it won't be written to the EEPROM on init but later checks the EEPROM for an address. (btw., I've edited the range for scanning from 1-255 to 0-127). It's probably still a different experience with python.

Thanks to Radomir @ɖҿϝիɟթվ who read through the cyz_rgb code and found the procedure, it's now possible to set the adress of the blinkM clone to a "real" legal value. This is how you'd do that in Arduino. After that it's stored into the EEPROM of the attiny. I'll do that for the next kits that go out.

void setAdress(byte a)
{
  // A X D0 0D X
  Wire.beginTransmission(0x00);
  Wire.write('A');
  Wire.write(a);
  Wire.write(0xd0);
  Wire.write(0x0d);
  Wire.write(a);
  Wire.endTransmission();
}

Discussions

davedarko wrote 02/20/2018 at 22:26

weird thing though:
I had three devices on my scan
- 0x38 expander
- 0x80 "attiny"
- 0xB6 expander again because of stupid arduino lbrary that goes to 255

After setting the new address and changing that library to go to 127, I have three devices now
- 0x0D attiny (set after I've set it to 0x22 before that)
- 0x38 expander
- 0x80 attiny again

So maybe changing it might be a good idea, at least so that it's stored in the eeprom.

Are you sure? yes | no

davedarko wrote 02/20/2018 at 22:27

will investigate tomorrow, when I build another one

Are you sure? yes | no

deʃhipu wrote 02/20/2018 at 23:14

Well, 0x80 is just 0x00 (all call address), because that scanner scans 255 addresses, and I²C addresses are 7-bit, so only go up to 127. Similarily, 0xB8 (it was b8, not b6) is just a repeated 0x38.

Addresses 0-7 and 120-127 are reserved and you shouldn't use them or funny things will happen. Wikipedia has a handy list of addresses you can choose from: https://en.wikipedia.org/wiki/I%C2%B2C#Non-reserved_addresses_in_7-bit_address_space

Are you sure? yes | no

davedarko wrote 02/20/2018 at 23:28

the main point I tried to say: before that it didn't show in the Arduino scan, now it shows in the scan. Before that it was only 0x80 that gave a response, now it's 0x80 AND the set id.

Are you sure? yes | no

deʃhipu wrote 02/20/2018 at 23:31

It still doesn't show on scans from MicroPython. Probably because Arduino does empty reads, and MP does empty writes.

Are you sure? yes | no

deʃhipu wrote 02/20/2018 at 22:17

Just to clarify, the code already has a legal value for the address, which is 0x0D (or as the meatbags like to call it, thirteen), it just doesn't come up in scanning, because it doesn't ACK empty writes. It could be actually a good improvement to the library to add this explicitly, so that scanning works as expected.

Are you sure? yes | no

R3.1 boards in the wild

CircuitPython on the Lameboy

Discussions

Become a Hackaday.io Member