On Sat, 1 Aug 2015 19:43:42 -0700, you wrote: >Sounds like the two of you have it "surrounded". Good info Harvey :)
Thanks. Came from deciphering the data sheet and figuring out what they *really* meant. I do a similar thing as the capes with an Xmega design (got a bunch of them, and they come in packages I can deal with). Some pin multiplexing is done, but the configuration EEPROM is used as a system resource to any other processor in the system (it's multiprocessor by intent), and additional data storage when needed. Much of the configuration data is in the processors EEPROM store, which allows a graphics board (generic, supports 128x64 up to VGA with the same chip) to be built for a particular display, keep the programming "off site" and have the programming updated without losing the customization. Internal EEPROM can be memory mapped and is thus easier to access. AT24CXXXX driver should work for just about any of the chips. Harvey > >On Sat, Aug 1, 2015 at 7:16 PM, Harvey White <ma...@dragonworks.info> wrote: > >> 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 <mac...@msn.com> 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 beagleboard...@googlegroups.com. >> >>> > 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 beagleboard+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.