http://forums.leaflabs.com/topic.php?id=2855 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:07:04 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22864 Mon, 11 Mar 2013 15:40:40 +0000 crenn 22864@http://forums.leaflabs.com/ <p>The Soft I2C is using DigitalWrite instead of using direct IO manipulations, there possible is a few other bottle necks as well. It's something I need to fix as well as some other bugs (which I have forgotten about which were found in this thread). The Software I2C is running about 88 kHz off the top of my memory. Since I have a logic analyser now, I can give a more precise measurement. </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22863 Mon, 11 Mar 2013 10:51:18 +0000 gbulmer 22863@http://forums.leaflabs.com/ <p>manitou - <em>"there are URL's to the test code in the first posting of this thread"</em>.<br /> Ooops - Thanks!-)</p> <p>It might make it easier for folks to use your test code (for example if they want to improve code) if the code were in one of your github repos. Just a thought.</p> <p>I am still puzzled why the Maple soft I2C is so much slower than hardware I2C. I'd expect the software and hardware I2C read times to be similar because I am pretty sure Maple can bit-bang at a lot better than 400kHz. However, I'm not going to worry about it; I'm confident someone will explain :-) </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22862 Mon, 11 Mar 2013 10:17:17 +0000 manitou 22862@http://forums.leaflabs.com/ <p>there are URL's to the test code in the first posting of this thread ... </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22861 Mon, 11 Mar 2013 10:12:33 +0000 gbulmer 22861@http://forums.leaflabs.com/ <p>manitou - that is a pretty interesting set of stats. Do you intend to publish the programs used to get the I2C measurements?</p> <p>I am a bit surprised about Maples slow software I2C. I'd expect it to pump bytes into an EEPROM at 100kHz as quickly as hardware I2C (using a lot more CPU cycles). </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22859 Mon, 11 Mar 2013 09:32:33 +0000 bnewbold 22859@http://forums.leaflabs.com/ <p>IIRC we have a patch floating around for faster libmaple SPI speeds; mbolivar would know better but he's away this week. </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22856 Mon, 11 Mar 2013 08:33:26 +0000 manitou 22856@http://forums.leaflabs.com/ <p>Ooops, good eyes. I failed to edit buffer size in read block for 100Khz DUE test. git page has been updated.</p> <p>thanks </p> http://forums.leaflabs.com/topic.php?id=2855&page=2#post-22850 Sun, 10 Mar 2013 20:42:42 +0000 crenn 22850@http://forums.leaflabs.com/ <p>Yeah, that's the values I'm talking about. It's very strange if the read values for 100kHz are that consistant regardless of the actual data being sent. It's something I'm wondering if it was a bug or whether there was a mistake of some description. If it's a bug, I might take a look. </p> http://forums.leaflabs.com/topic.php?id=2855#post-22849 Sun, 10 Mar 2013 20:39:12 +0000 gbulmer 22849@http://forums.leaflabs.com/ <p>crenn - are you talking about the values in I2Cperf.txt? Yes I agree with you.</p> <p>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.</p> <pre><code>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</code></pre> http://forums.leaflabs.com/topic.php?id=2855#post-22846 Sun, 10 Mar 2013 20:06:03 +0000 crenn 22846@http://forums.leaflabs.com/ <p>Are those read values for the Due at 400kHz correct? Something doesn't seem right with that. </p> http://forums.leaflabs.com/topic.php?id=2855#post-22841 Sat, 09 Mar 2013 13:00:27 +0000 manitou 22841@http://forums.leaflabs.com/ <p>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.</p> <p>Just for the record, the I2C results noted earlier in this thread (and other tests for maple/DUE/teensy/UNO) are now on github,</p> <p><a href="https://github.com/manitou48/DUEZoo" rel="nofollow">https://github.com/manitou48/DUEZoo</a> </p> http://forums.leaflabs.com/topic.php?id=2855#post-14115 Fri, 14 Sep 2012 23:20:09 +0000 crenn 14115@http://forums.leaflabs.com/ <p>I will possibly patch up the library so that cannot occur (ie a transmit must be setup before endTransmission works).<br /> 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. </p> http://forums.leaflabs.com/topic.php?id=2855#post-14083 Fri, 14 Sep 2012 14:41:43 +0000 manitou 14083@http://forums.leaflabs.com/ <p>For your amusement, here are some more I2C EEPROM block write/read times</p> <pre><code>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</code></pre> <p>The PASM is tunable to faster than 400KHz, values above were with default delay of 52 cycles.</p> <p> Of course the Beaglebone and Raspberry use the Linux metaphor, "everything is a file", so I2C access is with file read/write. </p> http://forums.leaflabs.com/topic.php?id=2855#post-14058 Fri, 14 Sep 2012 09:25:04 +0000 manitou 14058@http://forums.leaflabs.com/ <p>Thanks. Who knew? Removing the extra endTransmission() fixed the strange read values in the latter passes of the loop. </p> http://forums.leaflabs.com/topic.php?id=2855#post-14005 Fri, 14 Sep 2012 04:40:55 +0000 crenn 14005@http://forums.leaflabs.com/ <p>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?</p> <blockquote><p><code>hit a key<br /> Memory written<br /> blk write 1968<br /> 74<br /> this is data from the eeprom<br /> 68<br /> 69<br /> blk read 1786<br /> loop read 3603<br /> 74<br /> this is data from the eeprom<br /> 68<br /> 69<br /> blk read 1785<br /> loop read 3601</code></p></blockquote> <p>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.<br /> <code>crenn's I2c standard fast (TwoWire mode)<br /> Bytes write read write read (microseconds)<br /> 10 1558 1466 778 764<br /> 20 2735 2415 1376 2403<br /> 30 3916 3365 1968 1786</p> <p>hardware I2c 100KHz 400KHz (crenn's HardWire)<br /> Bytes write read write read (microseconds)<br /> 10 1199 1316 310 346<br /> 20 2103 2226 540 581<br /> 30 3009 3136 770 816</code></p> <p>And this is the code I've been using:<br /> <a href="http://pastebin.com/EmNcWsDB" rel="nofollow">http://pastebin.com/EmNcWsDB</a> </p> http://forums.leaflabs.com/topic.php?id=2855#post-13889 Thu, 13 Sep 2012 19:05:42 +0000 crenn 13889@http://forums.leaflabs.com/ <p>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. </p>