hey all
i did some tests trying to figure out the framerate of duemilanove
it seems it generally runs at 400,000fps until you try and do something
a digitalWrite takes 25 microseconds
a digitalRead takes about 3 microseconds
elliot
How did you come to those numbers? Are there any code that you can post here?
Framerate? Are you using the correct word?
I guess elliot is referring to the number of loops per second with no code in the loop
BTW, the figure for digitalWrite is closer to 2.5 microseconds
i dont know what you mean by 'correct'
i work mostly with visual technologies so framerate is the way i think about things.
the framerate lets me know how many times a system runs its mainloop per second
of course, as with any environment.
the framerate is susceptible to how complicated the problem is every frame. hence discussion about long it takes for every instruction to process
i'm defining 1 frame as one run of 'loop()'
arduino frame rate is what i searched for and didn't find anything. so i put this here for the next 'me' that's out there (hence me putting all the different ways of writing fps in the title of the post)
The arduino environment does "nothing" in between invocations of loop (one or two cycles of jump instruction, plus the function call overhead for loop() itself (it's not like there is some "operating system" that performs overhead calculations between loop() invocations), so the "frame rate" is entirely dependent on the code inside loop().
i dont know what you mean by 'correct'
Meaning FPS has no relevance to an Arduino unless you get it prepossessing and displaying graphics.
But as westfw mentioned the speed at which the Arduino proses data will vary based on how much data there is to proses. Much like a video card's FPS will vary based on how big and detailed the scene being processed is. But the term FPS isn't the proper term to used for benchmarking an Arduino.
i dont know what you mean by 'correct'
By correct he means the use of a word that will convey meaning to anyone other than yourself.
This is important if you are asking questions and expect people to understand you and give a correct response. You may develop a wholly new way of talking about things that are totally self consistent, but if nobody shares your paradigm you will not get anywhere.
So please try and learn the correct words so you can stop talking to yourself and talk to the rest of the world. That is what we all have done.
seems we started off on the wrong foot here :-[
let's reorganise this as an FAQ type question
Q. What is the frame rate of the Arduino?
A. 'framerate'? if you mean how many times the arduino can run it's main loop per second, then the answer depends on what you put in the loop.
Each instruction takes a finite amount of time, e.g. a digitalRead takes about 2microseconds. If you add up the time for all your instructions to be calculated and take 1/(total instruction time) then you'll get your 'framerate'.
If you have pretty much nothing in your mainloop, then you achieve around 400,000 'fps'.
The framerate then depends entirely on what you've got in your loop.
Q. When would it be relevant to use the word 'framerate' when referring to the execution speed on arduino?
-
when you're driving a visual system, e.g. a graphics array of LEDs or DMX signals.
-
when you're making a system that will work in tandem with a visual system, e.g. triggering physical actions that are synchronised with visual frames, or communicating with a system that has an intrinsic framerate.
hope that clears up my solipsism issue 
Is there any more information about Arduino performance profiling that can be linked from this post?
@Grumpy_Mike - you in Manchester UK. You checked out MadLab yet?
I don't think its ever been a requirement to use the 'correct' technical term when asking questions in this forum. But it does help if unusual jargon is avoided, and frame rate used to refer to Arduino execution speed seems odd indeed.
That said, performance measured in frames per second (FPS) can be relevant, see the picture in the arduino playground here: Arduino Playground - GLCDks0108
One of my favourite lines in the Simpson is when Homers is in the cartoon studio and asks "is this going out live", "no" is the reply, "we seldom do that due to the strain it puts on the animator's wrists".
Talking about frame rates in this context is rather the same, in that it depends on what is in the frame to know how quickly it will be finished. Even things like multiplying two numbers will take different amounts of time depending on what the numbers are.
In the days when these things were programmed in machine code this was simple, if rather tedious to calculate. Each instruction takes a certain number of machine cycles to execute, depending on the instruction and sometimes on the result it produced. You added up all the machine cycles in any loop. Then you multiplied by a constant factor determined by how many instruction cycles there were in a clock cycle, this was normally between one and four. Then you looked at the system clock to see how many clock cycles there were in a second. That way you could tell how long it took for any piece of code to execute.
Now things are a bit more removed as there is a compiler that turns the C code you write into machine code instructions. So any statement in C can be translated into one, or more likely many machine code instructions. Some compilers are more efficient that others so it becomes even harder to tell.
There is a further complication in that a special piece of code called an "interrupt subroutine" can kick in to perform background tasks like reading the serial port or updating a timer and steal some time from you, this can happen in regular or irregular chunks.
The standard arduino runs at 16MHz, that is the clock goes 16,000,000 times a second and some instructions can run in just one clock cycle, so that is the absolute fastest you can go.
Hope that helps.
As to MadLab, I just looked it up and it seems to be based in Edinburgh not Manchester, am I missing something.
there's a biweekly meetup called 'hacman' which is mostly physical computing based. check the events calendar.
elliot woods - I'd like to add my $0.02 worth ...
I suspect you already understand these observations, but it might help folks who feel your scenario is familiar to them and hence read this thread.
-
Try to avoid getting hung up on performance. It can get in the way of making something work. It is often called Premature Optimisation Program optimization - Wikipedia
-
If performance is very important, you can execute some 'Arduino Language' operations significantly faster (sometimes 10x or more) by using the hardware directly.
Further the 'Language', e.g. digitalWrite is normal code. It could be replaced (not recommended). More importantly, it has no special privileges. Anything it can do, your own code can do. So you can use the same techniques as it to manipulate the hardware directly.
I'd not recommend this, because the 'Arduino Language' (libraries) solves several problems, but there is no nasty 'magic' in the libraries (that I've read) to prevent this (one of the advantages of Open Source :))
(If you decide to do this, there is quite a lot of helpful stuff around, including the source code of the libraries, including the source of digitalWrite).
As a concrete example, I got much better than 10x faster digitalWrite (maybe at Arduino-0013) by using the hardware more directly. This did not require assembler. The Arduino hardware and software is lovely in this respect, you can usually stay in the normal language and access I/O pins, PWM, timers, etc.
Direct I/O might be helpful if you are driving things, e.g. like LED displays, where it must be driven continuously, but there are lots of other things to do in a 'frame' too. It may be helpful to set up the pattern for a whole column of a LED matrix in under 1 microsecond, rather than 8 uses of digitalWrite.
If folks do use 'straight to hardware' techniques, it might be helpful to learn about the macro facility (#define) so that you can seperate the specialised code, find its uses in your sketch, and change it more easily at a later date. A macro is not a function, it is just text replacement (like a find and replace) done by the compiler (during upload), so it has no speed overhead, but does make the program bigger with each replacement.
- It isn't necessary to use loop() as the 'frame' synchronisation point. I realise it is convenient, but it is not always helpful. Some of my code never leaves loop(), or more precisely only leaves when I want to 'start all over again'.
This saves the slight time cost of loop(), but that isn't really the point. Much more usefully, it enables me to organise the code to fit the way I want to handle the whole scenario. As a result, the code synchronises to the external event when it is fits the flow, and it doesn't try to re-loop() because it is a new 'frame'.
(As I wrote at the top, you probably understand all this, but it seemed to be complementary to the question and context of 'frame rate')
HTH
GB-)
it generally runs at 400,000fps until you try and do something
But that loop must include modifying something to indicate to some external measuring device that loop is ticking.
So, in fact, an empty loop would go even faster than 400000 Hz.
If a loop runs, and there's no-one there to measure it, does it still loop? ;D
But that loop must include modifying something to indicate to some external measuring device that loop is ticking.
-
if the 'tick' code is much shorter in duration than the loop() (say 20x, and it is consistent) then I would accept the error.
-
if you know how long the 'tick' code takes, you can subtract if from the measurement of loop() time. As the processor is very simple, this is quite doable by hand. The compiler is clever, but easily fooled so it wouldn't be too difficult to measure reasonably accurately directly either. (though I don't know if this was done in this case).
-
The system could be measured with embedded or external hardware, which might give very accurate timing (I'm not sure how clever Atmels debugging is but this is feasible with JTAG on some microcontrollers. My old iBook's CPU had hardware counters which had no run-time impact, and could gather timing information, so it was easy to have no run-time cost). (I don't know if this was done in this case).
-
There are hardware emulators and simulators which would give cycle accurate timing. Atmel will certainly have such software, and I thought there is one in something Amel sold. There was also some work on an Open Source emulator/simulator, but I think that stopped a while ago. (I don't know if this was done in this case).
So, you may well be correct in this case, but there is no reason that the assumption is generally true.
HTH
GB-)
So, in fact, an empty loop would go even faster than 400000 Hz.
Yes, an empty loop runs at a little under 2MHz with a 16MHz clock
You don't need to measure it to know how fast the loop is running, the machine code produced in a sketch with an empty loop uses 9 clock cycles, at 16MHz that takes 562.5 nanoseconds
If you do want to measure it, you can put SBI and CBI (direct port) instructions in loop to create a 125 nanoseconds pulse and measure the period. After subtracting the 125 nanoseconds, you can verify how long an empty loop takes to execute.
The optimizer in the Arduino compiler is very good, but empty loop code is running whether you can see it or not.