On Sat, 1 Aug 2015 18:27:14 -0700 (PDT), you wrote: >I have a quick question about supported i2c eeprom types. > >From the user side is there a way to query/list supported types (ie. >24c256)?
The 24C256 is 32K * 8, and as such, needs a 16 bit address. This particular chip ignores the most significant bit of the address. With this same addressing model, the maximum capacity would be 64K, which would use all 16 bits, and would be a 24C512. The 24C1024 will need 3 address bytes, not two, and unless the driver knows to put in that third address byte, the maximum addressable range is 64K. Further, there are several ways of writing data, either page mode or byte mode. Byte mode needs an address for each byte. Page mode must be written so that the data does NOT cross an absolute page boundary, otherwise it wraps without an error and you get bad data written. Page size does vary amongst the various chips in the family. You write a page (or part of a page) without wrapping, and then the chip refreshes and writes the new page. Reading must be done by starting a write (chip address and 16 address bits), a repeated start, and then the chip address as read. Data can be read as long as the read sequence is active, page boundaries are not significant here. If no address is provided, the previous address is used as a start and automatically incremented each byte read. So basically, 24C01, 24C02, 24C04, 24C08, 24C16, 24C32, 24C64, 24C128, 24C256 and 24C512 can all be handled with 16 bit addresses. The 24C1024 and above need the 24 bit address driver. If the driver knows the page size, then all of these chips can be written by the same driver. Reading can handle any of these chips. Had to write a driver for these chips a few weeks back. Pretty much anything in the 24C series below a 24C1024 can be read and written by the same driver if you know the parameters. 1024 and above can be handled if the driver is smart enough. No idea how the existing driver is written, but this is what's involved. Harvey >Conversely, is there a way to define a new type from user space and add it, >maybe through i2c-1/new_device? > >Documentation other than the SRM? > >Thanks! > > >On Thursday, July 30, 2015 at 8:42:05 AM UTC-7, Michael Carr wrote: >> >> Hi Robert, Jason and William, >> >> Sorry for not pulling the device tree files, I've been out of town. I hope >> the files help someone in the future if they purchase a mikroBus cape. >> >> This morning I found that the mikroBus cape is using a Microchip 24AA01 >> (1K, 128 x 8) eeprom not a 24C256. Two questions came to mind after I found >> this out. >> >> 1.) The Microchip 24AA01 doesn't use A0 ~ A2 (Don't Care). Responds to any >> 0x5X address. Potential cape addressing conflicts here. >> 2.) The non-B version clock is limited to 100Khz. >> >> Is the default clock for i2c bus 1 > 100khz? Ex. 400Khz 1000Khz? Can I >> force it to 100 Khz? >> >> Yep, having problems writing to the eeprom. The schematics don't agree >> with the delivered board. >> Looks like they intended to use the 24C256 but in manufacturing they used >> the 24AA01 instead. >> >> Mike >> >> >> On Monday, July 27, 2015 at 10:27:54 AM UTC-7, RobertCNelson wrote: >>> >>> Thanks! Pushed as part of: >>> >>> >>> https://github.com/RobertCNelson/bb-kernel/commit/c43f83c076c30cfbd98d4c00f962ca22a9563933 >>> >>> >>> On Thu, Jul 16, 2015 at 10:59 AM, Michael Carr <[email protected]> wrote: >>> > Hi Robert, >>> > >>> > I've ordered a MikroBus cape from MikroElektronica. They have a device >>> tree >>> > source file to support the cape. May I pass it along to you to add to >>> > github? >>> > >>> > The eeprom on the card is empty and I will need to generate the >>> contents. >>> > Does anyone have a tool to create/read/write eeprom contents via >>> cloud9? I >>> > tried running eeprom-web.js and I get a cloud9 error. >>> > >>> > Thanks, >>> > Mike >>> > >>> > -- >>> > For more options, visit http://beagleboard.org/discuss >>> > --- >>> > You received this message because you are subscribed to the Google >>> Groups >>> > "BeagleBoard" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to [email protected]. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Robert Nelson >>> https://rcn-ee.com/ >>> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
