Hi, 2012/4/24 mattschinkel <[email protected]>: > Let's see the new lib and go from there. Will do.
> > Why can't it support more then one eeprom? Because it buffers data to delays write commands when possible. Doing so for multiple eeproms requires multiple sets of buffers and pointers, and the code to handle this. For the rare case, not worth the effort IMO. As a matter of fact, it is possible to support multiple eeproms with the lib, but this requires the user to flush the buffers before switching. Even different types of eeproms are supported this way. The main limitation is one i2c bus. This limitation is provided by the i2c library. Regards, Joep > > Matt. > > On Apr 24, 9:13 am, Joep Suijs <[email protected]> wrote: >> Hi Matt, >> >> Thanks for the offer. >> If we replace the current libs, it won't be easy to support more than >> one i2c eeprom per system. Is this something worth having, enough to >> have different libs? In this case, we could add the extension _basic >> to the names of the current libs. >> >> We could consider this to be a configuration option too. But since it >> will also change the API, this might cause confusion. >> >> Joep >> >> 2012/4/24 mattschinkel <[email protected]>: >> >> >> >> >> >> >> >> > Feel free to edit my lib as you please and add your name as author. >> >> > If you prefer to not use mine at all, that's ok with me as well. Just >> > replace it. I see no need for 2 similar libs. >> >> > Matt. >> >> > On Apr 23, 6:19 am, Joep Suijs <[email protected]> wrote: >> >> Hi guys, >> >> >> I am working on a more advanced version of the 24lcxx libs. The name >> >> of the current basic version is eeprom_24lcxxx.jal (e.g. >> >> eeprom_24lc256.jal) >> >> >> The things that will be different in the new libraries: >> >> >> + page write is supported (up to 128 times faster, my estimate is >> >> sequential filling an 24lc512 takes 2.5 secs instead of 6 minutes) >> >> + advanced handling of required delay-after-write, so no (possible >> >> unnecessary) delay of 5 ms after each write >> >> + more devices supported (2, 4, 8, 32, 64 and 128kx8 are on my list; >> >> don't have all devices to test though). >> >> + success/error indication is propagated back to the user. >> >> - the library uses more resources (flash and ram) >> >> - only one device per application is supported (well... you could use >> >> more, but that is more complex) >> >> >> I have two questions: >> >> - Would such a library set be a valuable addition to jallib? >> >> - if so, how should we call these libs? >> >> >> Regards, >> >> Joep >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "jallib" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group >> > athttp://groups.google.com/group/jallib?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
