It's a just an I2C EEPROM with some bytes preprogrammed and write protected. But it only uses an 8-bit I2C address since it is only a 2kb device or 256 bytes with the MAC at addresses $FA..$FF. If it's in Spin then just adapt an I2C EEPROM driver in the OBEX by commenting out the extra address byte.
I just generate a random 32-bits and lock that into EEPROM and set the upper 16-bits of the OUI to $02FF for my WIZNet stuff. No need for a separate chip really.
CON
SCLPIN = pin number of SCL pin of 24AA02E48 chip
OBJ
i2c : "basic_i2c_driver.spin"
PUB
i2c.Initialize(SCLPIN)
i2c.ReadPage(SCLPIN, $A0, $FA | i2c#OneAddr, @buff, 6)
wiz.SetMac(buff[0], buff[1], buff[2], buff[3], buff[4], buff[5])
Where buff was a buffer that was used for some other purpose that I repurposed .
And that's it!
The driver does not consume a cog, it's just a call.
A note that the 24AA02E48, despite having A0/A1/A2 address pins, ignores the A0/A1/A2 address pins, and thus is always addressed at I2C address A0, and so it cannot wired in parallel with the boot EEPROM, as they then have the same address. There are other variants of the chip that do not ignore the A0/A1/A2 address pins.
You can wire it in parallel by using the old trick of reversing the scl and sda lines for your device. It looks like that driver is assuming that sda follows scl though, so you might tweak the driver to accept both scl and sda.
Seems like an awful lot of bother to go through just for a MAC address for a one-off. Just write an address to upper EEPROM and then there is no need for a special chip unless you are producing a vast quantity, and then there are other ways.
Hi Peter, you're right, it is, but my threshold level for "a lot of bother" is a PCB. If I'm doing a PCB, then I get awfully righteous about a lot of things I wouldn't otherwise bother about Or I'm putting the thing in someone else's place on their network on a permanent basis.
Yes, by all means allow for it and swapping the scl/sda lets you use the same I2C pins too. However by just writing the MAC to 6 bytes in upper EPROM, it is effectively "permanent" since the Prop loader doesn't directly erase or access that part of EEPROM.
Is this just a one off? All the more reason to not or ever bother with an extra chip!
If it were a big production item it would make sense though.
Yes, by all means allow for it and swapping the scl/sda lets you use the same I2C pins too. However by just writing the MAC to 6 bytes in upper EPROM, it is effectively "permanent" since the Prop loader doesn't directly erase or access that part of EEPROM.
Is this just a one off? All the more reason to not or ever bother with an extra chip!
If it were a big production item it would make sense though.
Or if uniqueness is a must you can buy the chip, take the IP and write it in upper EEPROM. .. no extra HW required ...
I use the 24AA02E48 a lot. If you want to share the same SCL/SDA pis with the boot EEPROM you can use the 24AA025E48 derivate which has some extra adress pins so that the device adress can be selected different from the boot EEPROM.
I use this code to read the MAC address:
OBJ
i2c: "Basic_I2C_Driver"
PUB InitNetwork
ReadBytes (i2c#BootPin, $A4, $FA, @own_mac, 6)
...
PUB ReadBytes (SCL, devSel, addrReg, dataPtr, num)
'' Read in a block of i2c data. Device select code is devSel. Device starting
'' address is addrReg. Data address is at dataPtr. Number of bytes is count.
'' The device select code is modified using the upper 3 bits of the 19 bit addrReg.
'' Return zero if no errors or the acknowledge bits if an error occurred.
i2c.Start(SCL) ' Select the device & send address
i2c.Write(SCL, devSel | i2c#Xmit)
i2c.Write(SCL, addrReg & $FF) ' Only one address byte for 24AA02E48
i2c.Start(SCL) ' Reselect the device for reading
i2c.Write(SCL, devSel | i2c#Recv)
repeat num-1
byte[dataPtr++] := i2c.Read(SCL, i2c#ACK)
byte[dataPtr] := i2c.Read(SCL, i2c#NAK)
i2c.Stop(SCL)
You have to connect A=GND and A1=VCC of the 24AA025E48 for this to work. The adress bits are in bits 2..1 of the device select code ($A4). $FA is the internal adress where the MAC is located in the ROM.
Comments
I just generate a random 32-bits and lock that into EEPROM and set the upper 16-bits of the OUI to $02FF for my WIZNet stuff. No need for a separate chip really.
Where buff was a buffer that was used for some other purpose that I repurposed .
And that's it!
The driver does not consume a cog, it's just a call.
A note that the 24AA02E48, despite having A0/A1/A2 address pins, ignores the A0/A1/A2 address pins, and thus is always addressed at I2C address A0, and so it cannot wired in parallel with the boot EEPROM, as they then have the same address. There are other variants of the chip that do not ignore the A0/A1/A2 address pins.
Seems like an awful lot of bother to go through just for a MAC address for a one-off. Just write an address to upper EEPROM and then there is no need for a special chip unless you are producing a vast quantity, and then there are other ways.
Is this just a one off? All the more reason to not or ever bother with an extra chip!
If it were a big production item it would make sense though.
Or if uniqueness is a must you can buy the chip, take the IP and write it in upper EEPROM. .. no extra HW required ...
I use this code to read the MAC address: You have to connect A=GND and A1=VCC of the 24AA025E48 for this to work. The adress bits are in bits 2..1 of the device select code ($A4). $FA is the internal adress where the MAC is located in the ROM.