yes it is possible to test, program devices such as EEPROM using I2C - its also possible to communicate with generic I2C devices for non-programming applications - like temperature sensors etc..
write the vectors for read.write
what can be done is to create the read/write (page or byte) sub routines and then you can make the tets unit to do what functions you like
let me knowif you need any more advise - or contact your local Agilent rep
The device address pins of the EEPROMs are inputs and can be hardwired on the design if required - this therefore gives the eeprom a hardwired identity on the I2C bus.
So inside the eeprom vcl code - when we are first addressing the device we will just take the hardwired addresses as a given state - we need not drive these inputs - when it comes to writing data inside the eeprom , we are using memory addressing which is defined by the data driven on the bidir SDA bus.
So if the eeprom address pins are tied, its has a given device address identity - if not we can of course drive these pins to address the device, either way the 3070 can work it out and tied address pins will be given * during IPG runs.
write the vectors for read.write
what can be done is to create the read/write (page or byte) sub routines and then you can make the tets unit to do what functions you like
let me knowif you need any more advise - or contact your local Agilent rep
thanks, Jon
So inside the eeprom vcl code - when we are first addressing the device we will just take the hardwired addresses as a given state - we need not drive these inputs - when it comes to writing data inside the eeprom , we are using memory addressing which is defined by the data driven on the bidir SDA bus.
So if the eeprom address pins are tied, its has a given device address identity - if not we can of course drive these pins to address the device, either way the 3070 can work it out and tied address pins will be given * during IPG runs.
- hope that helps clarify - cheers