I2C - Wire versus HardwareI2C versus Arduino Uno

LeafLabs Garden » Support » Maple Hardware Support

I2C - Wire versus HardwareI2C versus Arduino Uno

(22 posts) (5 voices)

Started 3 years ago by poslathian
Latest reply from crenn

12 Next »

poslathian
LeafLabs
manitou tried to post this earlier but there seems to be some problems with bbpress?

Here is a quick compare of bit-banging I2C with Wire lib versus the hardware I2C of i2c.h on the maple (IDE v0.0.12) accessing the I2C 24LC128 EEPROM. The Wire sketches are based on an Arduino sketch. The EEPROM supports page writes and auto-increment read's.
```
software I2C
Bytes   write   read   (microseconds)
10       3655   3826
20       6408   6069
30       9164   8315

   hardware I2c 100KHz     400KHz
Bytes   write   read      write  read   (microseconds)
10       1193   1306        308   336
20       2095   2202        535   561
30       2997   3100        761   791
64       6063   6262       1568  1551

   arduino uno
Bytes   write   read   (microseconds)
10       1340   1616
20       2340   2640
30       3360   3644
```
Here are the simple sketches used in tests. They use different pins for SDA/SCL.

soft I2C http://pastebin.com/snBnZwyX

hardware I2C http://pastebin.com/T7Kv91r1

Note the EEPROM write requires at least a 5ms delay to allow the write to complete. When I tried to read the EEPROM without this delay, I got I2C protocol errors. This thread was helpful in understanding maple I2C errors:
http://forums.leaflabs.com/topic.php?id=28

I may try maple DMA for I2C, though performance is already at KHz rate.

------ Reference -----

Arduino sketch
http://arduino.cc/playground/Code/I2CEEPROM

24LC128 datasheet
http://ww1.microchip.com/downloads/en/devicedoc/21191m.pdf
Posted 3 years ago #
crenn
Moderator

I'm curious to why you didn't use the HardWire library included with the current Libmaple and there is a version for IDE v0.0.12.

Posted 3 years ago #
manitou
Member

crenn:

Well, I actually tried Wire-120630.zip with IDE v0.0.12 in software mode with the soft I2C code above -- SDA/SCL pin assignments in TwoWire(scl,sda) differed from old Wire begin(sda,scl). But even after fixing that, code didn't seem to write/read the EEPROM. I need to go back and try to figure it out, I was hoping it would just work...

Posted 3 years ago #
crenn
Moderator

The pins were changed from the old wire library to allow for the compatibility of some Arduino shields. However the API was changed because of the design of the library. If the SoftWire library isn't working, that's a problem and I'll look into it tonight. The best I can do is try a Microchip 24AA00 128 bit EEPROM that I have.

Posted 3 years ago #
manitou
Member
Re: args to TwoWire, I was really referring to the order of the parameters TwoWire(scl,sda), whereas the old Wire.begin(sda,scl) -- picky picky

I did a few more tests. If I enable HardWire on IC2 port 2, my simple test code seems to work.
```
hardware I2c 100KHz     400KHz  (crenn's HardWire)
Bytes   write   read      write  read   (microseconds)
10       1200   2329        314   612
20       2110   4139        545  1071
30       3015   5949        779  1530
```
For the TwoWire mode, I still get strange output (scope shows SDA/SCL wiggling as expected,
close to 100KHz). If I disable the EEPROM write's in the setup() then the read's seem to work,
and to indicate the write's had worked in the previous run. But with the write's in the setup(), i get strange values back from the read's ???
Posted 3 years ago #
crenn
Moderator

Can you post your simple test code? If there is a problem with SoftWire, that's a major issue and needs to be fixed. I'll be looking at the code today. The rate Software I2C works at is 88.5KHz.

One thing I find interesting is that the reads take about twice as long than not using Wire base... Think I need to look into that.

I supppose the API can be changed so that is switched, however I don't think it will change much since the majority of users will notice the change.

Posted 3 years ago #
manitou
Member
I just pasted in your conditional headers into the arduino (soft I2C) sketch mentioned above, but here is the pde on pastebin
http://pastebin.com/UdLRTjGG

If you select HardWire, it seems to work, but the soft version only works the first pass through the loop then returns FF and 0's ?? Assuming the first pass numbers are good, here are timings
```
crenn's I2c standard     fast  (TwoWire mode)
Bytes   write   read      write  read   (microseconds)
10       1557   2775        787  1426
20       2738   4898       1382  2523
30       3919   7024       1969  3616
```
Posted 3 years ago #
crenn
Moderator

I found out yesterday I do have a 24FC1025 which should work (mostly) the same as the 24LC128 so I hope to run a test tonight to find out what is happening.

Posted 3 years ago #
crenn
Moderator

This is the output I got for TwoWire (consistently except for the timings which varied between tests of course.) Maybe write 0xFF in the first few blocks and test again?

hit a key Memory written blk write 1968 74 this is data from the eeprom 68 69 blk read 1786 loop read 3603 74 this is data from the eeprom 68 69 blk read 1785 loop read 3601

I also found there was a small problem with the i2c_eeprom_read_buffer function in that it read the data twice (as there was an extra I2cPort.endTransmission() at the end of the function). These are the results I got from testing with a Microchip 24FC1025.
crenn's I2c standard fast (TwoWire mode) Bytes write read write read (microseconds) 10 1558 1466 778 764 20 2735 2415 1376 2403 30 3916 3365 1968 1786
hardware I2c 100KHz 400KHz (crenn's HardWire) Bytes write read write read (microseconds) 10 1199 1316 310 346 20 2103 2226 540 581 30 3009 3136 770 816

And this is the code I've been using:
http://pastebin.com/EmNcWsDB

Posted 3 years ago #
manitou
Member

Thanks. Who knew? Removing the extra endTransmission() fixed the strange read values in the latter passes of the loop.

Posted 3 years ago #

manitou
Member

For your amusement, here are some more I2C EEPROM block write/read times

Beaglebone  I2C @ 100Khz
bytes   write   read   (microseconds)
10       1320   1669
20       2245   2559
30       3128   3374

 Raspberry Pi  I2C @ 100KHz
10       1268    1449
20       2185    2357
30       3074    3268

  Parallax STAMP PBASIC bit banging and SHIFTOUT (16KHz)
10    47400  37800
20    82200  63000
30   117600  87600

  Parallax propeller  bit-banging
          spin            PASM
10    8147    5815     393   425
20   11797    9273     649   689
30   15447   13491     913   953

The PASM is tunable to faster than 400KHz, values above were with default delay of 52 cycles.

Of course the Beaglebone and Raspberry use the Linux metaphor, "everything is a file", so I2C access is with file read/write.

Posted 3 years ago #

crenn
Moderator

I will possibly patch up the library so that cannot occur (ie a transmit must be setup before endTransmission works).
Also, I'm wondering if the I2C buffers should be bumped upto 64 bytes instead of the 32 bytes they are currently, it takes up a bit more RAM but I feel that could be quite helpful.

Posted 3 years ago #
manitou
Member

I hacked maple-ide-v0.0.12/hardware/leaflabs/cores/maple/i2c.c to add DMA to I2C read and write. The DMA doesn't really speed up the I2C at either 100KHz or 400KHz, but I guess it would free up the CPU to do other things. I only did limited testing with I2C EEPROM.

Just for the record, the I2C results noted earlier in this thread (and other tests for maple/DUE/teensy/UNO) are now on github,

https://github.com/manitou48/DUEZoo

Posted 2 years ago #
crenn
Moderator

Are those read values for the Due at 400kHz correct? Something doesn't seem right with that.

Posted 2 years ago #

gbulmer
Moderator

crenn - are you talking about the values in I2Cperf.txt? Yes I agree with you.

The Due seems to be within 2% of Maple for 400kHz, which seems reasonable, but the 100kHz read for 10 and 20 bytes are exactly the same number (3124), and much bigger than seems reasonable.

arduino        UNO                          DUE
           100KHz          400KHz         100Khz      400Khz
Bytes   write   read    write  read    write read   write read (microseconds)
10       1340   1480     448   504      1197 3124    308   338
20       2340   2500     780   840      2104 3124    540   571
30       3360   3512    1112  1176      3014 3127    775   806

I2C - Wire versus HardwareI2C versus Arduino Uno

Reply »