Main Site Documentation

.NET C# Fast? Inline Functions List?


Guys, I’m totally new to Fez and .NET C#. From what I read in the description, C#/.NET is interpreted, and that there are a set of internal functions that are faster to process things. But where can I get a list of those “faster” functions?

Overall, compared to an Arduino 8-bit 16Mhz, how does a FEZ Panda works?

The project I’m thinking is simple:

  • LCD 16x2
  • 16 buttons (push)
  • 16 leds
  • Rotary Encoder
  • 2 axis Thumb Joystick with Click

Its a Midi Sequencer with 16 Tracks. So Memory is an issue.

Also, do I need extra hardware to add an SD connector? (the Arduino doesn’t need, just the SD connection case)

Also, how easy is to work with MIDI? I already have SparkFun MIDI Breakout box on my list.

Thanks for any help so far.

Best Regards, WilliamK


Pretty much all the libs that come with .NETMF are written in the native layer, so naturally its faster.


As fare as I understand .NET Micro Framework it’s not an interpreted code and will compile to a runnable code, not like the high level .NET JIT compiler.
When it comes to speed your project probably will run better on a FEZ base board then any Arduino. I believe that with this many interrupt based inputs: 16 buttons, rotary encoders, joy stick the only way to do this is by an event driven device.


You will need additional SD Card hardware for the Panda.

There is a MicroSD addon made for it by the FEZ guys or you could wire up the sparkfun SD Card breakout for a full-size card. While you need to pay a little extra for the socket it does come with a few advantages like high speed 4-bit data transfers, not the slower SPI interface and a full FAT16/FAT32 native layer driver in the .netmf so you don’t need to roll your own filesystem driver.


On a PC .NET languages are compiled to IRL (intermediate runtime language) which is compiled to native code at run time (JIT compilation). On NETMF things are done differently, the C# source code is compiled to a form that is downloaded to the NETMF device and interpreted at runtime by the NETMF runtime on the FEZ (or other NETMF devices.) In other words the C# you write for your NETMF device is never compiled to native code at any point along the way.


By the way, I remember we asked Microsoft’s NETMF team long time ago on why not JIT? Since native is faster than managed, right? I remember their answer was the benefit was very little performance enhancement vs losing a lot of RAM. As you know RAM is precious on these little systems.

Why is it little benefit? Because most of the processing is done natively anyways. Let us say you are making a GPS data logger. Where is most the work being done? It is in the FAT file system, SD drivers and serial drivers to read the GPS. Your interpreter code is only reading GPS messages and passing them on to the file system. In short, if comparing code size, you are about 1% or less managed and 99% or more native code.

That was just an example. I am sure there are application that uses manged more that 1%. For example, if you want to calculate CRC or do encryption in C# then things will run too slow. That is why we even have libraries for CRC and cryptography.


Thanks guys, that clears up a few things.

When you say interrupt based device, could you give me an example?

Does Panda have any interrupt I/O? The one I need most is for the Rotatory Encoder, the rest would help, but not mandatory. (I guess)

I’m a C++/Assembly programmer, so I guess C# won’t be a problem, right?



I’m also taking a look at the Arduino Mega, which has 6 interrupt inputs. That way I could add the most important stuff directly without problems.

Now, could I use a FEZ Panda for other things and have the 2 boards talking to each other?



Panda has not much interrupt pins : around 37 only :smiley:

I’m joking, of course : I don’t think you will ever be limited.

Edit: I’m not joking on the number :wink:


Ah, good to know, I read so many PDF files from TONS of MC sites that I didn’t even read about this over FEZ Panda.

So, 37 interrupt pins? Really?

That’s much better than the Arduino Mega! :-o

I’m starting to move to the FEZ direction.

Another alternative I’m looking at is the XMOS kit, but is much expensive, but its also 400Mhz!!! But the community is shy right now, not like here, which I’m starting to love.

I got much faster responses here, and I will need some help to get my open-source midi-sequencer done. :wink:



Another thing, 60K of memory is not bad, but I don’t know how much ram I will need for the midi sequence, keeping in mind that its a 16 track/pattern sequencer.

So, what’s faster, SD reading, EEPROM or some other solution? I need to mostly read, but at times, write too. (during Recording)

Of course, I’m nuts, so I’m pretty sure I will keep adding stuff until the board can’t cope with the data, but I worry about that later on. :wink: :whistle:



And just to confirm, its easy to add the midi breakout from sparkfun to this board, right?

I also got some 8-bit shifters, but since this board has so many I/Os, I guess I could just plug things directly? But again, what’s faster?




Look at the bottom of this page
Click on example code! :slight_smile:

I doubt you will ever will the FEZ memory for your MIDI project. I actually challenge you to do so :smiley:

Did you know about the challenge of using FEZ Panda IOs? I challenged anyone to use all IOs on FEZ Panda for a prize…it has been a while so I do not remember what was the prize! Of course, uses them withing a reason fro something beneficial, not connect LEDs to all pins!

Forget the shift registers you pointed out and get busy using all IOs on FEZ Panda :wink:


Thanks Gus! That’s perfect!

I just placed my FEZ Panda order via SparkFun. I’m in Brazil, so it may take 2 or 3 weeks to arrive. But lets hope not! :wink:

In the meanwhile, I will read the ebook and install everything up.

I also need to wait for some other parts from China, which can take more than a month to arrive. :frowning: