Hello again everyone!
Can someone give me a rough idea on how much faster a microcontroller would be if the software is written in C vs. in the Arduino Engine?
I am sure this will depend a lot on the actual program, but I am just looking for a general idea whether it is just a bit faster or twice as fast or a hundred times faster?
Maybe someone has some experience in this and can comment on it, it would be much appreciated! 
Thanks a lot!
Tom
I have a feeling you're misunderstanding something. Or I am. The Arduino IDE compiles C/C++ code, and the binary is what gets sent to the Arduino. The ATMEL uC is running binary, compiled, native machine instructions...
HTH
Arduino Engine?
What is the Arduino Engine? DO you mean the IDE?
The language in the IDE is C++ an OO relative of C, if you need more performance assembly can be faster although it is hard to beat the compiler.
Often a good thought about the datastructures and algorithms used can speed up most applications. If not it might be time to consider a more powerful platform
He may be referring to the Arduino abstraction library.
I'm sorry, I wasn't very clear the first time.
I was referring to the Arduino abstraction library vs. low level AVR_libc code.
I don't know that a general answer can be reasonably given. Do you have a more specific operation in mind?
At this point I am just trying to get an idea of the magnitude of improvement that could be gained by low level programming vs high level Arduino code.
If you have any experiences and could mention some examples I'd appreciate it!
a++;
Not much to be gained.
digitalWrite (myPin, HIGH);
Potentially quite lot to be gained.
And all shades in between.
Premature optimization is premature.
Write your code.
If it isn't fast enough, optimize it.
TomS:
At this point I am just trying to get an idea of the magnitude of improvement that could be gained by low level programming vs high level Arduino code.If you have any experiences and could mention some examples I'd appreciate it!
The answer is too dependent on your specific application program to give any kind of useful answer. Certainly fundamental I/O tasks such as digitalRead() and digitalWrite() can be made faster using direct port manipulation. You are free to not use any arduino library functions that slow your application down and roll your own to suit your requirements. So maybe if you state your application requirements we can better see where your best improvements might be found. There will always be some applications that an arduino just cannot handle without external hardware additions, but it's pretty amazing what can be done with proper software design.
Lefty
digitalWrite() and similar functions are about 20x slower than the fastest possible C code to write to pins, but that's largely because they aren't really doing the same things, rather than inherent inefficiencies. There was a lot of discussion here: http://arduino.cc/forum/index.php/topic,4324.0.html
It's still fast enough to toggle a pin at over 100kHz...
westfw:
digitalWrite() and similar functions are about 20x slower than the fastest possible C code ...
Thanks a lot, that's the kind of information I was looking for to get a rough idea on what order of magnitude we are dealing with here.
It is important that you also read the other information provided and absorb it as well. Just taking one number, the worse case scenario of 20 to 1 and using that to ".. get a rough idea on what order of magnitude .." may push you to towards incorrect design decisions. Be sure you understand that using the IDE you can also write a direct port manipulation function that will update much faster than digitalWrite but is still part of the IDE.
As someone else said .. write the code then optimize .. knowing you can implement direct port manipulation and other performance increasing updates as you find where you need such optimizations.
Note: If you have been working with the .NET solutions and wonder if the arduino layer is similar in being a run time level layer that turns your code into a slug, arduino is not the same animal.
Hope that helps - best of luck.
Thanks a lot for your advice as well marklar.
I wasn't referring to any specific design as of now, which is why I was looking for that rough number.
Now I can at least somewhat put the potential of speed improvement through low level coding into perspective with other changes in design.
Thanks again!
Tom
TomS:
I wasn't referring to any specific design as of now, which is why I was looking for that rough number.
Now I can at least somewhat put the potential of speed improvement through low level coding into perspective with other changes in design.
Sorry Tom, but what you just wrote is complete garbage. You seem to completely misunderstand what the libraries are doing, what high-level and low-level on the Arduino mean. The first and foremost condition to start optimisation is to have specific requirements, a specific design and a specific implementation. If you miss any of those, talking about optimisation is just wasting time and only proves how clueless you are to others.
So unless you're an empty-headed manageroid whose link to reality is exclusively through content free PowerPoint presentations with high buzzword density, please reconsider and don't do such a half-arsed job. And in case you fall in the latter category, you'd be better off to copy pictures from your favourite girlies- or hunks-magazine onto the slides, they're just as relevant to the topic at hand but more pleasing to look at.
Thanks for listening.
Korman
Indeed. Such is the danger of providing an "answer" to such a question.
The problem here usually come from taking too narrow a view of things.
e.g. As has been noted, "digitalRead" and "digitalWrite" are many times slower than direct port manipulation, but you may well be only using them for a tiny proportion of a typical progam loop's cycle time.
If you were to concentrate time and effort on optimising them out, you may well be disappointed to find that you cycle time has barely improved because, for example, much of the rest rest of the code is taken up with floating point arithmetic or even slower analogue reads.
Worse still, your "optimisation" efforts are suddenly not portable to a different platform.
Having a bad day at work are we?
lloyddean:
Having a bad day at work are we?
Not really, more like an average day. And as I have to deal day in day with managers, sales and project leads coming with technical questions they read about in the latest glossy magazine, I sort of get the type too often. Here at least I have the chance to improve the world a little by preventing that kind of crap being produces once. Not a big success, true, but one takes what on can.
Korman
"Thanks a lot, that's the kind of information I was looking for to get a rough idea on what order of magnitude we are dealing with here."
But you aren't getting an order of magnitude. Are you even reading what everyone else is posting? Any speed improvements depend entirely on what you are trying to do. You were given one VERY SPECIFIC example of 1 function. The caveat was that it isn't even a direct comparison.
Please pay attention to what is being said. Numbers given to your answer are very meaningless because it is such a broad question.