Another place to buy if you out of stock here: ;D
http://dangerousprototypes.com/2011/03/22/fez-mini-net-arm-development-board/
Sorry about that Architect We must have both posted about the RLP at the same time.
Cheers Ian
At least they will get the point!!
I saw some haters out there. So was compelled to write.
“There are many things other then pure speed to consider. Ease of use, IDE quality, Thread support, library quality and depth, and time to solution. VS and c# excel at all the above and that can not be after thought. How about breaking and seeing all threads in a list and jumping between them. How about Linq support? The quality of the end-to-end experience is top notch. For most robots and sensor devices, I have not run into a speed issue. If your doing alot of UI or a 160mph jet PID loop, then your probably looking at a dedicated co-processor/pic anyway. Moreover, many of APIs needed to run (i.e. outputcompare) at sub ms levels, run in native code anyway.”
There are situations where .Net may not fit. Same with C. People just try put label .net as slow and don’t even bother to see if it will work (by factors) for there project. Guess they are missing out.
Excellent point(s)! ;D
Thanks guys, you all are great support to FEZ and GHI. We couldn’t have gotten this far without you 
So, just because I’m that sort of person, I followed the spidery tendrils of the performance discussion mentioned on that post to the bitter end, and I decided to whip up an additional test, using GHI’s OutputCompare to do the bitbanging. This is the code I used (I called my test 5, and 3 and 4 aren’t relevant, since they use Netduino stuff):
public class Test5 : Test
{
public Test5() : base("OutputCompare", 1024) { }
protected override void DoTheTest(OutputPort port, int numIterations)
{
var pin = port.Id;
var times = new uint[1024];
for( var i = 0; i < times.Length; i++ )
times[i] = 5;
port.Dispose();
using( var oc = new GHIElectronics.NETMF.Hardware.OutputCompare(pin, false, 1024) )
{
for( var i = 0; i < numIterations; i++ )
oc.SetBlocking(true, times, 0, times.Length, 0, false);
}
}
}
The results I got are as follows:
[quote]*** I will do repeatedly larger runs until a given test takes 10 seconds or more
*** I will do repeatedly larger runs until a given test takes 10 seconds or more
*** I will do repeatedly larger runs until a given test takes 10 seconds or more
*** RUNNING TEST C# v1 (1 on/offs per loop iteration)
Total time for 131072 on/offs is 00:00:14.4730010. usec per on/off=110.42023468017578, which is 9056.3111271808793 Hertz
*** RUNNING TEST C# v2 (10 on/offs per loop iteration)
Total time for 163840 on/offs is 00:00:13.5595285. usec per on/off=82.760794067382818, which is 12083.01601342554 Hertz
*** RUNNING TEST OutputCompare (1024 on/offs per loop iteration)
Total time for 2097152 on/offs is 00:00:16.0323934. usec per on/off=7.6448409080505373, which is 130807.16943984172 Hertz[/quote]
OutputCompare, it’s fast
By the way, the image is from old stock. New minis have headers soldered on it instead of holes, making it even easier to use.
Changed to 4096 on/offs per iteration, and a 1us delay between on/off, and now I’m seeing this:
All this, and not a drop of native code. I imagine something could be set up with RLP for even higher performance.
Someone ought to work up an RLP solution for the “BitBanger” driver mentioned over at the netduino forum. Something like OutputCompare, but able to drive both a clock pin and a data pin… “soft SPI” I guess. Something I could use to write bits to my shift register very very quickly.
They are talking about this display. I use SPI. Feel free to mess with it if you want to try RLP approach:
and on “Fezzer”
http://code.tinyclr.com/project/229/monochrome-128x64-oled-graphic-display-driver/
That Frank on the seeed page holds to the past tight, doesn’t he.
Everyone has a personal opinion and you can’t make every single user happy…but we surly keep trying to make everyone happy
The good news is that he has FEZ and netduino plus also trying native programming. So he has all options, commercial support, open source and DIY…I think/hope he will come to a point and will realize how much work is being put into FEZ and why using FEZ makes development just so much easier. You know, everyone in this community have used something before, arduino, netduino, basic stamp, PIC, AVR or even ARM but once they use FEZ they quickly fall in love, right?
so lets focus in for a second; does this action [url]http://www.tinyclr.com/forum/17/2734/[/url] then allow JTAG use in the scenario Frank was talking about over on Dangerous Prototypes? Is there anything that this doesn’t give that he might have been thinking about?? I know it doesn’t give a fallback position, but otherwise does it meet what he thinks he needs?
I think one of his complains was that once it is erased you can’t put GHI firmware back by yourself.