LeafLabs Garden » Topic: Official Wire & I2C Libraries

LeafLabs Garden » Topic: Official Wire & I2C Libraries http://forums.leaflabs.com/topic.php?id=1255 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:20:20 +0000 http://bbpress.org/?v=1.0.2 <![CDATA[Search]]> q http://forums.leaflabs.com/search.php crenn on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-10764 Sun, 20 May 2012 03:24:12 +0000 crenn 10764@http://forums.leaflabs.com/ Hi gke, I've been working on the new Wire library lately and I'm wondering if I can pull some of your changes into the software side of the library, mainly to speed up the library (and fix some issues). Not sure if you're still around the forums, but I'll see if I can't grab your attention via youtube as well. Regards, crenn. gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-7601 Thu, 12 Jan 2012 19:18:20 +0000 gke 7601@http://forums.leaflabs.com/ Thanks. I will probably step back a bit from the Wire stuff to get board maps and STM32F4 stuff done. I will update (10 minutes) the Wire.zip file which now uses PIN_MAP rather than the explicit pin numbers. Still ugly but better than it was. The i2c routines probably should be in their own class but .... Greg crenn on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-7587 Thu, 12 Jan 2012 06:52:37 +0000 crenn 7587@http://forums.leaflabs.com/ <blockquote>Unfortunately, the I2C on STM32F1xx is a bit weird. If you glance at the Revision History at the back of the RM0008 manual for the STM32F1xx, pretty much every one of the 14 document revisions contain changes and clarification on the I2C peripheral. I think Crenn is very likely the most knowledgeable I2C contributor, ahead of the official library.</blockquote> Perry is possibly the best one to talk to about I2C as he did the low level I2C implementation I do believe which is what I'm using. I don't fully understand the limitations of the I2C peripheral as I haven't read through the the errata sheet fully. I also haven't been around as moving out is taking longer than I thought and now that I'm mostly moved out (there is a bit more coming this weekend which signals the end of the 'big move'), I'll be getting around to trying to rewrite the Wire implementation, although I'll probably be referring back to this thread when the Software Wire implementation is completed. gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-7581 Wed, 11 Jan 2012 23:11:09 +0000 gke 7581@http://forums.leaflabs.com/ <a href="http://www.eganfamily.id.au/Family/Misc/Wire.zip" rel="nofollow">http://www.eganfamily.id.au/Family/Misc/Wire.zip</a> The pulse timing probably needs some checking but later ... gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-7580 Wed, 11 Jan 2012 21:17:32 +0000 gke 7580@http://forums.leaflabs.com/ Thanks poslathian. Still tunneling into the libraries etc but I was trying to stay up in the IDE layer otherwise I may as well just drop all the way down to the STM libraries. @gbulmer. Yes it was the software I2C/Wire I was interested in. The revised Wire.{cpp,h} are running at 400KHz with gpio calls and at about 280KHz with digital read/writes. Not interested in the I2C hardware as my app has nothing else to do while reading sensors etc. Hopefully another iteration today. Other duties are distracting me :). Greg poslathian on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255&page=2#post-7558 Wed, 11 Jan 2012 12:01:24 +0000 poslathian 7558@http://forums.leaflabs.com/ gke - regarding you post about good old makefiles - we could not agree more. The IDE and the maple "toolchain" are pretty decoupled, and you can use Maple just as effectively using make + your favorite editor. Check out <a href="http://leaflabs.com/docs/unix-toolchain.html" rel="nofollow">http://leaflabs.com/docs/unix-toolchain.html</a> Regarding the overhead associated with this or that call (like digitalWrite). We went as far as we thought reasonable in stripping out random overhead. For example, on some platforms calls to digitalWrite check the pinMode and other crap every time. But at the end of the day, the wirish library, which is the high level Arduino stuff, is designed for usability. The lightweight, powerful stuff is underneath in a library called libmaple, which you are more than welcome to use! Feel free to browse all the code here: <a href="http://github.com/leaflabs/libmaple/" rel="nofollow">http://github.com/leaflabs/libmaple/</a> gbulmer on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7539 Mon, 09 Jan 2012 20:09:58 +0000 gbulmer 7539@http://forums.leaflabs.com/ gke - maybe I have misunderstood the issue. I thought you were having problems getting the soft I2C interface to run fast enough. It looks the speed of DemoWire_gke, i.e the speed of the soft I2C interface, is dominated by the speed of <code>Wire.endTransmission()</code> which actually does the work to shift the bits. <code>Wire.endTransmission()</code> appears to be dominated by i2c_shift_out and its sibling functions (e.g. i2c_get_ack) They use digitalWrite, so they are the ones that need improving. None of the changes I can see in the zip file <a href="http://www.eganfamily.id.au/Family/Misc/DemoWire_gke.zip" rel="nofollow">http://www.eganfamily.id.au/Family/Misc/DemoWire_gke.zip</a> change those functions, so (applying Amdahl's Law) nothing else will cause much of a change. What have I missed? gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7535 Mon, 09 Jan 2012 16:12:00 +0000 gke 7535@http://forums.leaflabs.com/ Hi ala2, My edit was a little off. It is now working with your suggestion and up to 360KHz so we are getting closer to 400KHz :). Thanks Greg #define I2CSDALow {gpio_write_bit(&gpioc, 5, 0);SCLLowPadT;} #define I2CSDAFloat {gpio_write_bit(&gpioc, 5, 1);SCLLowPadT;} #define I2CSCLLow {gpio_write_bit(&gpioc, 13, 0);} #define I2CSCLFloat {gpio_write_bit(&gpioc, 13, 1);SCLHighT;} gbulmer on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7534 Mon, 09 Jan 2012 12:27:18 +0000 gbulmer 7534@http://forums.leaflabs.com/ gke - Is this really not getting over 200KHz? Is it correct to assume most of the problems are in the actual bit bashing like i2c_shift_out, i2c_shift_in, etc? If those are the problem areas, it looks like you're going to need faster versions of: - digitalWrite - digitalRead - pinMode You might be able to save a bit of work by 'global edit and replace' those into the base functions like <code>i2c_shift_out</code>, maybe use some macro-bashing: e.g. <pre><code>#define SDAPIN (20) #define SCLPIN (21) #define SDAPINFAST ... // bit band address #define SCLPINFAST ... //bit band address #define SDAPIN_DDIR ... // data direction stuff ... #define myDigitalWrite(pin, val) if (pin==SDAPIN) {fastDigitalWrite(SDAPINFAST, val);} \ else if (pin==SCLPIN) {fastDigitalWrite(SCLPINFAST, val);} else digitalWrite(pin, val); ... // etc</code></pre> (I'm avoiding thinking about the state of education today, :-( gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7533 Sun, 08 Jan 2012 23:04:11 +0000 gke 7533@http://forums.leaflabs.com/ Thanks ala42. I did try what you suggested but the lines need to be flipped from input to output mode it seems just as on the original PIC processor. If you do a read port on one that is set to output you get the output register value not the input. @gbulmer I lived in Manchester UK for several years and our kids experienced primary in 1994 when we were there again on sabbatical. Yes it is a shambles and I find it depressing when I visit which to date has been often. The rapidly growing layer cake is now so widespread I believe it may be impossible to reverse. Why put down to conspiracy what can be explained by simple (or is that complex) incompetence. Cheers Greg ala42 on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7527 Sun, 08 Jan 2012 15:11:06 +0000 ala42 7527@http://forums.leaflabs.com/ Had a short look at your code: #define I2CSDALow {digitalWrite(this->SDAPin, LOW);pinMode(this->SDAPin, OUTPUT_OPEN_DRAIN);SCLLowPadT;} #define I2CSDAFloat {pinMode(this->SDAPin, INPUT);SCLLowPadT;} #define I2CSCLLow {digitalWrite(this->SCLPin, LOW);pinMode(this->SCLPin, OUTPUT_OPEN_DRAIN);} #define I2CSCLFloat {pinMode(this->SCLPin, INPUT);SCLHighT;} Very bad idea to set the pin mode each time. Set both lines to OUTPUT_OPEN_DRAIN once and touch them never again. gbulmer on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7526 Sun, 08 Jan 2012 10:12:31 +0000 gbulmer 7526@http://forums.leaflabs.com/ Greg - <blockquote>... The number of people who know what is inside the various boxes on which we depend is falling. In Australia we have dropped to less than 50% choosing Science subjects in school prior to applying for a university place. The subjects are not weighted by difficulty in calculated their score so softer options are preferred.</blockquote> Start Rant: The UK school system is even more "ingeniously" damaging than that. What we do is rank schools on the exam marks achieved by the children, and give rewards to the school and staff based on improving that rank. Those ranks are published every year for all to see. So a Head Teacher must improve the numbers. AFAIK, if they don't, they get replaced. We have also gone away from the old exam marking system which deliberately assumed a 'normal' distribution on exam marks, and adjusted marks across subjects to align all subjects and across years. Instead we use the raw exam score. This allows the possibility that students can get higher marks every year (which has happened in the UK since the late '90's), and makes comparison across subjects harder. Hence it reduces the apparent need for rigourous comparison of performance across years (marks are improving!), makes it harder to do anyway, and allows governments to claim they have improved education standards. Genius! Because schools are ranked by these exam results, they have a pretty easy algorithm to improve rank; if one subject gives a higher average exam mark, the school encourages pupils to take that subject, and if another subject gets poorer averages, then that subject just gets dropped. This has happened to Electronics A-Level in my area; there are no state schools teaching it, and the teacher I know has taken early retirement, so it is almost irrevocable. I often say to people, if you believed in conspiracies, and were to conceive of a very simple, low cost way, to cripple a country, what would you do? I think you'd tinker with its educational system in exactly the way we have. Over the long term it destroys its industrial base; either the science and technology subjects get very easy, to compete for students - bad - or the subjects get dropped - very bad. Of course, I am not suggesting we have any conspiracy. When human incompetence and greed (money or power) are sufficient to explain something, then there is no need to suggest a conspiracy. End Rant I'll try to have a look at your I2C, but I need to get something to eat :-) gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7524 Sun, 08 Jan 2012 02:47:45 +0000 gke 7524@http://forums.leaflabs.com/ Yes I agree that IDEs like Maple and Arduino are an easy entry point for newbie's and also for those a little older. The number of people who know what is inside the various boxes on which we depend is falling. In Australia we have dropped to less than 50% choosing Science subjects in school prior to applying for a university place. The subjects are not weighted by difficulty in calculated their score so softer options are preferred. As promised my VERY rough cut of the code with timings in comments are at: <a href="http://www.eganfamily.id.au/Family/Misc/DemoWire_gke.zip" rel="nofollow">http://www.eganfamily.id.au/Family/Misc/DemoWire_gke.zip</a> I have only just graduated to "classes" so bear with me. My favourite language was Pascal and my forced use of C was quite recent. I had avoided them to date as I was not comfortable with what the compiler may be doing to instantiate them. It is also entirely possible that I have missed something simple of course resulting in the low I2C clocking rates :). My app is using the STM32F4 so I do need to do a little work to knit those in. I will look at crenna's code again tonight. Cheers Greg gbulmer on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7518 Sat, 07 Jan 2012 13:44:23 +0000 gbulmer 7518@http://forums.leaflabs.com/ Free IDEs are important to me because I spend time encouraging non-programmers to get into programming. I believe it is extremely important that people understand the underpinning technology of our modern world. I am a STEM ambassador in schools, but also run events for adults. It is also critical to me that people can continue beyond those experiences, and propagate their enthusiasm without cost or constraint. <blockquote>It would be good to know what Arduino are going to do for their Due Arm environment. </blockquote> I assume, the Arduino IDE will remain largely the same, but the libraries and examples will be upgraded. The underlying compiler and linker toolchain will be based on one of the Open Source packages built around GNU's gcc ARM variant, (probably CodeSourcery or YAGARTO?). IMHO LeafLabs do a pretty good job of bundling up a decent ARM toolchain within the Maple IDE. IIRC, several people have posted on these forums that they have used the toolchain under other IDEs. It is quite likely that the IDE and raw toolchain, except for the loader, will work with Maple, Mbed, Olimexuino, PSoC5, TI... Of course, the peripheral libraries contain a lot of manufacturer and device specific work, and AFAIK, ARM's CMSIS hasn't been completed. IMHO CMSIS is a bid daunting for beginners, so it is less attractive than the Wiring/Maple libraries for my purposes. gke on "Official Wire & I2C Libraries" http://forums.leaflabs.com/topic.php?id=1255#post-7515 Sat, 07 Jan 2012 07:38:20 +0000 gke 7515@http://forums.leaflabs.com/ I have spent the day off looking at other tool chains including those from companies charging upwards of $10K for what is just connecting up gcc and a few other tools. Underneath it is the good old Makefile hierarchy to glue it all together. 40th Anniversary of Unix just rolled over so ... Like you (GBulmer) the Arduino like IDEs are attractive and even more so because they are free and thus can be used by those to which source code can be distributed - in this case UAVX one of the zillion or so multicopter control codes out there. Nice fun hardish real-time control environment. Your observations are right on the money and it seems we have a similar background. Mine was in the area of parallel processing (dataflow/datadriven architectures) back in the 70s way way when parallel architectures were not at all excepted. I am comfortable working from the "electrons" up to the compiler construction etc. As you say lots of eyes looking but not many of us who are happy floating up and down through the abstraction layers. It would be good to know what Arduino are going to do for their Due Arm environment. As for my quick I2C hack. I will post some fragments tomorrow - late here and the code is on the only PC in the house upstairs. The delays that were in on the mbed are all commented out. Timing was done using a Salae analyser. Cheers Greg