Hi
I found this article on switching times on the Arduino http://www.billporter.info/?p=308 Does anyone have an oscilloscope and the time to do a test for comparison. It would be fun to know how the FEZ at 72Mhz stacks up to a 16Mhz Arduino.
Have a look at FAQ#14, FAQ – GHI Electronics
Toggling a pin as fast as possible isn’t what NetMF is designed to do. If you toggle a pin on an atmel using asm it’s going to be a hell of a lot faster than in C. Tests like this really don’t show you anything about a MCU or programming platform TBH. When was the last time you saw a commercial application for switching a pin on and off 4 million times a second?
I’d be interested in seeing how fast it can do it, but honestly i dont see any real use of this.
I totally agree with you on that there is no real use for it, but still it would be interesting to know if its slower than the Arduino digitalWrite command. I feel that if it can keep up with the Arduino C version, then all the other great stuff about FEZ sets it even more apart.
I’d be more interested in seeing how fast a user could write an advanced thing, like say joystick interaction on arduino/fez, or how fast an advanced operation can run - like i2c or something.
Unfortunately a lot of “benchmarking” is focused on trivial things like turning a led on and off. To me, the it’s much more important how quickly something can be developed/implemented - and how fast major operations work. For instance, you’d struggle to directly control a 4.3" LCD never mind 7" with WPF running.
Managed code will always be slower. Always.
Also, the Fez and other .Net devices have to run garbage collection occasionally. This also impacts speed.
So if you’re just looking for more raw “speed” and access to the hardware (like flipping a pin on and off) then the Arduino is more for you. Any .Net device won’t be able to compete there. It’s just not real-time code.
But for rapid prototyping and a much more “accessible” language you can’t currently beat it.
Arduino and ANY microcontroller running native code will toggle an LED much faster than FEZ or ANY micro running native code.
Now, log data to an SD card on Arduino (if possible!) and then do the same on FEZ and compare the speed 
Toggling LED is a VERY bad idea to compare native system to managed system. You can compare it between 2 native systems or 2 managed systems but don’t mix oranges with apples
Well if all I wanted to do is toggle an LED all it would take is two lines of C# code to set up a PWM. I suspect I could both blink the LED faster and still have the other 99% of the FEZ’s system resources available to to what ever else I wanted. No Contest… 8)
PWM is done in hardware and has nothing to do with execution speed. But if all you want is blink LED then use a $0.20 micro or 555 
That’s what I was trying to get at Gus, turning an output on/off really fast a test of a processors ability is silly. You can do it with PWM on the FEZ and still be able to execute all sorts of other programs with no loss of performance.
Never the less I managed to borrow an oscilloscope and these are the numbers for anyone interested;
Arduino: 7.9uS
FES Domino: 86uS
That said, Ill probably never go back to an Arduino based system. I absolutely love the FEZ Domino and speed vise its more then sufficient for my type of projects.
I just read the article and was wandering how FEZ would handle it. Now I have my answer.
Yes that is expected, not if you try to read from SD card, for example, the read speed on Arduino or similar systems is usually about 5KB/sec. Now, FEZ can do over 200KB/sec, that is 40 times faster This is better explained in the FAQ but if you only needed to see the numbers, you already got them
I know Gus. In an earlier project I had in VDIP1 from Vinculum hooked up to an Arduino for reading a USB memory stick. It was an absolute nightmare.
The funny thing is that GHI could release an update to the firmware with a built in function that could toggle a pin at 20Mhz tommorow, and still retain all the other features of the Fez. If there’s a demand for toggling a pin at that speed… you’ll get a solution
If you need to toggle a pin very fast, FEZ isn;t for you, as everyone has said. The FEZ is wonderful for high level stuff where you may not need ot have micro second timing, but you do need something fast. I have yet to see any timing issues in my RC car project.
Give it a rest guys.
My question wasnt how to make a led blink fast. It was how does these lines of Arduino code running at 16Mhz
void loop()
{
digitalWrite(ledPin, HIGH);
digitalWrite(ledPin, LOW);
}
Compare to the same program running on a FEZ at 72Mhz
while (true)
{
led.Write(true);
led.Write(false);
}
From a programming point of view, these programs are identical. And measuring the output would give some indication of the overhead on FEZ vs Arduino for this particular action.
Im fully aware of using PWM (and thats not unique to FEZ), but that is not what Im looking for.
Its good to see that Gus at least understood what I was talking about.
Next up, can we get a code sample and speed benchmark of the SD card performance that Gus is talking about? Perhaps also a code and speed sample for reading from a thumb drive?
There are hundreds of samples in the free ebook
I was thinking a sample of both arduino and FEZ side by side. So you can see both how much code and how fast it is.
Yes I know that FEZ is capable of doing all sorts of wonderful high level stuff. Things that probably is impossible to do on an Arduino. But Im not touching any of that high level stuff, only doing the most basic thing on an embedded system, -to change a pin for high to low.
What puzzles me is the fact that a system running 4.5 times as fast needs 10 times as long to switch the state of a pin.
Well, the Arduino isn’t running multithreaded applications and is doing far, far less. You’re basically comparing apples to oranges.
If native code was running on the LPC chip, yeah, it would fly a lot faster than the Arduino (from now on, I’m going to say ATmega328, because it’s not Arduino)
The FEZ run managed code, which takes a lot more effort than native. This is the reason for the slow down. It’s a gamble.