I'm not looking at military uses and the project is only an example, although a fairly typical example of the way projects start and often go bad. I'd actually use something like a cheap DSP combined with FPGA and possibly a third piece like a Zigbee chip with built in MCU to handle wireless traffic, encryption, and other tasks. My tour in the military ended in November 1988, and I was a submariner, not a ground pounder.
I'm not the pointy haired boss, I'm the Dilbert and I'm just doing basic research on several platforms so I have the base knowledge to make valid decisions on future uses. Usually I get what I want to do the projects I'm assigned, fortunately allt the pointy haired bosses have been promoted to upper management where they can do the least harm.
I've looked at arduino and written some librarys, even fixed a few librarys that had problems with them. It's a nice platform, but it's slow, the GUI is virtually non-existant, and many of the librarys are flawed, and debugging is a fail.
I'm looking at .Netmf, the GUI is nice and the upload and debugging process is pretty painless. I've experienced some oddities related to interrupt handling and while investigating, I came across something that concerned me. Having a 20ms delay because someone based interrupt handling on a slow clock and a high latency environment is a completely contrary to the whole concept of an interrupt.
Most of the things I would use an MCU for would be near real time applications. If .netMF is going to be taken seriously as a platform it has to be able to deliver real time or near real time data aqusition. it doesn't matter how many digital IO pins you have to interface with sensors if you can't get the data expeditiously.
Fortunately I have some side projects the .NetMF platform is perfect for, and I’m even considering a Cobra or even the chipworxs system soon. The extra memory and speed would be a godsend. one projectI’m working on requires interfacing to about a dozen different sensors and about the size of a paperback novel, but the data will be delivered to a human at human speed via a smart video screen( http://www.4dsystems.com.au).
.NETMF isn’t an RTOS. Multitasking with threads costs time - you won’t be able to guarantee the time, so it would be best to look at another platform. .NETMF can do a lot, but it doesn’t seem to be what you need.
You still haven’t put a number on the speed you need, so we’re just guessing.
Your point about interrupts is somewhat valid - the idea of an interrupt is to get notified of an “event” and find out when it happened, then take some action. In NetMF, the point at which you can take some action is potentially further awayfrom the point the event happened than you would expect, but the timekeeping aspect of when the event occurred is still pretty accurate.
In “complex” systems, you often find you use specific-purpose chips. So interfacing a specific sensor might need a specific support chip and have that tied to a “master”, SPI or I2C type connection back to the master. That way the support chip can handle the timing critical things and you put the effort into the logic at a level that is simpler to write at and simpler to debug.
Of course one other great GHI feature is that you can create RLP code which can be used to handle some of those timing sensitive controls. So you have it good here; you obviously have a wealth of experience which will stand you in good stead for whatever you want to do with your Fezzez, and Netduino (and Atmel and FPGA and… ).
I’ve been doing this a long time back to days when we hand wire-wrapped patches on PDP-11 backplanes, and I’ve been programming even longer. I can appreciate your points, I even largely agree.
My surprise was the slow speed of the clock used for time slicing and interrupt handling on the other board I looked at, and .netmf interrupts not really being what I typically think of as an interrupt. Combined it creates a large amount of interrupt latency, which we both agree is a problem in anything real time. Typically when you associate a piece of hardware with an interrupt vector you see a very quick response from the OS.
I wondering how dependent the interrupt latency is on the hardware .NetMF runs on, if I understand correctly it’s dependent on the speed of the clock being used for time slicing/interrupt handling in .NetMF, which appears to be realitively slow. I am intruiged by the RLPs, am I correct in thinking RLP is for the Chipworx and EMX boards?
For my personal uses the issue is purely academic, I like the GUI ;D and my .Net programming experience makes the learning curve a lot lower ;D. I like the GHI hardware ;D a lot of bang for the buck. For other uses the interrupt timing is something to be aware of when making a decision. I don’t want anyone to think I’m running down .Netmf or GHI, i’m just looking at the pros and cons of choices.
Time-slicing has nothing to do with processor or vendor. This is a “by design” and works very well for the purposes NETMF is intended for. Since some developers love the productivity of NETMF and need real-time then GHI added RLP. This features is available on all NETMF devices coming from GHI. It complements NETMF great features with speedy and real time extensions.
Note that in some cases it is just simpler to use 2 micros, one to do sampling and and real time and other to do high level stuff, like user interface (NETMF). A 32bit 50Mhz cortex-m0 is $1.50!
