Hi William, > Should we modify thei2c_software library, when it is working fine like > it is? Both i2c_hardware and i2c_software share the same API. If faulty use of this API by jallib libraries gives code that works okay on i2c_software but not on i2c_hardware, there is an issue to resolve. Testing all i2c libraries with i2c_hardware is one option. Have (optional) code in i2c_software to detect this faulty use is an other. Changing i2c_hardware (and verify it works properly) also.
> In my view, it is the picmicro I2C master-mode controller > hardware itself, that is complicated and/or confusing. I never looked into this, but expect i2c controller also has the ability for other address sizes and multi-master setups. This makes the controller more powerfull and complex. > And so as a result, the i2c_hardware library will always need to be tested > separately from the i2c_software library. This is what we can learn from this issue: each i2c application (library) needs to be tested with i2c_hardware. If this works, i2c_software probably works to (but it never hurts to check ;). > What advantage does i2c_hardware library have over the i2c_software > library? If there isn't any advantage, we might consider dropping it, Apart from features mentioned (but not implemented by jallib yet)? It's probably faster, uses less cpu cycles (less delay when an interrupt comes along). Probably not significant in most apps, but why drop it in response to a bug in an other library? Quite a lot of effort is put in and it works okay on various PICs. > or replacing with a stub that includes i2c_software. Just change 'include i2c_hardware' to 'include i2c_software' and you're done! > William Joep PS Good to hear a bit more from you :) -- 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.
