Bug Fixes and the software I2C implementation are coming soon to this library. Testing is due tomorrow.
Bug Fix in HardWire:
Previously it was not possible to leave off flags, this was not intended and has been fixed now. So when creating a HardWire instance, it is possible to do this:
HardWire TestPort(1);
This will created a instance using I2C1 at the standard I2C (100kHz) speed.
I'm posting this up now for people to start testing with the new Wire library. Due to my workload of late (including getting some casual work!), I hadn't had a chance to work on the library until last night.
Here's the new library, WireBase: http://www.crennsmind.com/Code/Maple/Libraries/WireBase/WireBase-alpha-120520.zip
And here is some example code for the ADXL345:
http://www.crennsmind.com/Code/Maple/Libraries/WireBase/Wire_Test.pde
As you can see in the example code, to use the software library, you need to include the TwoWire library (which relies on the WireBase library that was available since the previous release) and create an instance of TwoWire. If no arguments are passed to TwoWire constructor, the default pins (SCL is 21 and SDA is 20) are used. You can optionally give the constructor arguments for SCL and SDA as follows:
TwoWire <VarName>(<I2C SCL Pin Number>,<I2C SDA Pin Number>);
Unfortunately there is a known bug currently where multi-byte reads are not done correctly. I'm still tracking the cause of the bug currently.
As previously mentioned, HardWire is no longer needs to be given any flags in it's constructor.
If you have any questions, please reply here, I'll get back to you as soon as possible. I'll be attempting to fix the aforementioned bugs in the library. The code has not been finalised and has not been commented as of yet.
Fun thing is, fixing that NACK bug doesn't seem to affect the multi-byte read. As for getting the ack, I'm not fully sure whether it is or isn't needed, but removing it has not affected the system, but I haven't been looking at that bit on my oscilloscope.
I noted there is a 'bug' with how Stops are done as there needs to be a low to high transition on the SDA line which had the possibility of not being done, but this has now been fixed. I may not get to attempt to fix this until after Friday since I have an assignment due then. I also noted that the Wire (that's included with the maple IDE) library that is being used, does not support clock skew. I'll be going into more detail at a later stage.
No, just use it. I made the timing changes first, because the multi byte read did not work with my ITG3200. It also did not work with the better timing and clock stretching. I later discovered that the initial wire code sent a NAK after each byte read, which prevented the chip internal address counter to increment on this chip. A BMA180 did increase the address counter, btw.. This bug is already fixed in your library, and I saw just the missing clock change in the i2c_send_nack() function.
I have the delay and bit change in the other order than you have, which might cause the difference somewhere.
My wire version is tested on a ITG3200, BMA180, HMC5843, HMC5883, BMP085 and MS5611 and works on a F1 at 72MHz and F4 at 168MHz. The timing is set up for 400kHz clock rate, the F1 is a bit slower.
Unfortunately, I can't just use it due to how the new library is structure. I did a port last night as it required minimal changes (except for the 2 different delays for SCL and SDA). I did a test and still having issues with my ADXL345 doing a multibyte read, I'll test it more this weekend with better timing. I did note that the delays in your code were a bit faster.
I'm sure, if I switch to HardWire (which uses the exact same WireBase as TwoWire), there isn't an issue, and I've verified with a scope the ADXL isn't sending any data back to the Maple. I don't doubt your library works correctly if it's by itself, but there seems to be a timing issue with mine that I'm still working on. The most likely culprit is the SDA timing being the same as SCL timing, but this shouldn't be an issue, but I noted that it seems to be and also noted that it's different in your code.
I realised today why my library was returning 0 for the 2nd byte when doing multi-byte reads. I wasn't releasing the SDA line before reading, I missed that when I was comparing ala42's Wire library and mine. I'll be releasing the new library soon after some clean up, feature adding and commenting code.
And here's the current beta snapshot!
http://www.crennsmind.com/Code/Maple/Libraries/WireBase/WireBase-beta-120526.zip
There are a couple of minor changes and a bug fix (which was mentioned previously). The main change currently is the ability to change the delays (which is only semi-useful currently as it only gets upto 161kHz max) in the software so it's partially able to go closer to the I2C Fast speed standard. It will default automatically to the I2C Standard speed if no input is giving. The constructor for TwoWire now looks like this:
TwoWire <VarName>(<I2C SCL Pin Number>,<I2C SDA Pin Number>,<I2C Speed Setting>);
You do not have to have a speed setting, and your speed options currently are:
-SOFT_STANDARD
-SOFT_FAST
There is also some restrictions to the library, but generally it should work to how most users expect it to work. I'll cover the restrictions either tomorrow or in a later post. Feedback is welcome and please note, this is not a finalised library yet.
blackswords
Member
I think I found a bug in the Library.
I have something like that in my code :
HardWire IMUWire(1, I2C_FAST_MODE);
but the program fails because of this line in i2c_master_enable function :
ASSERT(!(dev->regs->CR1 & I2C_CR1_PE));
Wouldn't it be better to reset the peripheral before continuing instead of crashing the program?
blackswords
Member
I found a fix. My HardWire instance was global so it was initialized before the init() function. Now I create it after the setup with this :
IMUWire = new HardWire(1, I2C_FAST_MODE);
and I have no crash, just only zero values read. Can you check my read/write functions and tell me if I'm doing something wrong? The different values (registers, addresses,..) used are ok, I used them in the past.
You must log in to post.
