I am trying to generate PWM signals in RLP and I encountered a value Fpclk, which I guess GHI has set up before. So, if thats the case, what is the value then? Also what does GHI define CCLK to?
Thanks.
System clock is 72Mhz and usually we set the peripheral divider to 4.
Thanks Gus! Didnt expect to be replied that quick!
The reply came from automated system 
… the automated system set up to try to pip Architect before he can reply 
I can’t beat the Gus_Bot! ;D
What!! The Panda has been replaced by a robot!
Well the robot can’t create fritzing parts…
Cheers Ian
Here is a quote from the netduino board, that got me thinking about latency and and interrupt handling something I had tacked for granted since the dos3 days.
So are these limitations the same across all .netmf boards or are some boards better/quicker?
As far as core yes but GHI adds a lot of features to cover about every need, like RLP for example.
What are you trying to do?
Take sensor readings at Regular intervals 100-200ms, doing fast interrupt handling, any sort of two way communication requiring a event handler so your code can spend time doing what it’s designed to do instead of stopping dead waiting on an IO.
I’ve noticed several oddities as have other people. I’m just trying to find out if the fez boards are going to be better than the netduino boards for those purposes. The netduino boards are fine boards I have a couple and they work great for what I purchased them for. I have several fez panda II boards and I love all the built in features, so I’m not slamming them either.
Specifically I I’m going to build a small network of sensors and collect the data at one central board over wireless and have the central board log and possibly web serve them. Both the sensor boards and the central board are going to spend most of their time in other code while waiting to send or receive. One of the people on the netduino boards has a similar idea( I think most of us have) and is having trouble with high interrupt latentcy, and the standard poor time keeping of .net in general.
I know you’ve put a lot of effort in to your projects and it shows, I just wondered if there was any difference in terms of interrupt speed and time granularity with your boards.
Thanks.
P.S. Nothing here should be taken as being negative about any product, its simply a question.
Why are you worried about interrupt speed? Interrupts are time stamped so you have a pretty good idea when they happened.
The core NETMF system is the same on any NETMF device, that is designed by Microsoft. It is design to be user friendly and to be very productive but ti is not real time.
But what about those who need real-time but still want to use NETMF? What about other existing limitations limitations too, like in field update? This is why GHI spent years developing value-added to NETMF. With the added benefit from GHI, you can now design about any system with NETMF.
Not only added features, GHI did spend a lot of time optimizing every details so you get the fastest performance with most feature and still use the least memory. Count in the features GHI add int eh firmware and look at how much free memory is till available for your application.
What you mentioned should work fine. Also, our boards are 72Mhz so you should get better performance regardless of other optimizations we have
Interrupts should be accurate like Jeff said.
If anything need to be optimized, you can simply include that in RLP. You can even make interrupt handling in RLP or use the native tasks. The interrupt latency will be few micro seconds in this case. So nothing to worry about.
yeah in your specific use-case, i can’t see anything that is close to timing critical as you seem to be concerned about. If you don’t get your sensor data inputs read in the first 250msec, does something drastic happen like the house burn down?
Just data loss, data corruption and whole reason for the project.
which are all transport level issues you need to explicitly handle, no matter what… so therefore they’re non issues and they sure don’t make things overly timing critical
Were that it were so.
There are a number of applications in which sensor nodes need very exact timing and need to process the sensor inputs quickly. In fact I know I can name a dozen while continuing to type and a hundred if I stopped to think about it. Some of us are here for different reasons, and some of us have propritory data and project information to protect.
I can tell you what I am not, I’m not a competitor of GHI, nor of any other .netMF based company, nor the Arduino project, nor PIc/PicAXE nor XMOS etc.
I am currently looking at various boards. Some are .netMF and so far I would prefer those based on the VS 2010 GUI and relative ease of programming. My next choice would be Arduino, but it’s rapidly becoming vastly out horse powered by newer MCU’s. Xmos looks promising but hardly has the level of market and developer support I’d like to see, and still has a lot of limitations. And I have MCUs I haven’t even set up yet like some sample TI 32bit TMS320F280200DAT, CC2511f32RSPR chips which look promising along with some other samples.
I need information In order to base decisions on more than gut instinct or marketing vapors. If the typical interrupt latency is too long it may make a board not worth pursuing. GUS don’t get ahead of yourself and think I’m some major tycoon or this means a big project. I’m just an engineer doing basic product research, for projects that may never get implemented or may use completely different technology. I already purchased three of your Panda II’s for my personal use and I’m quite impressed overall.
Brett,
I’ll give you a simple hypothetical project. Totally Hypothetical.
You have to build a Star Trek like piece of equipment for the army. It's a probe with airborne and ground sensors,(a BLIDS with the BL) to be planted when securing a location. It needs to be cheap($250) and expendable because it will have a self-destruct triggered by battery depletion or incorrect operation. Also the Army has a talent for dropping/losing/destroying your equipment when they have more important things to worry about, like finding who just ambushed their patrol, and they don't like to go back and pick them up again.The probe needs to detect sound, vibration and if possible IR, figure out if it’s something to worry about, vote with other probes planted in the ground, and alarm the troops, if possible it needs to present the information to them, possibly by sending a signal with vectors to different sound/vibration sources. It needs to be completely off the shelf because the Army needs it five years ago. The components have to be of minimal help(read computing power) to the enemy if captured and not completed destroyed.
Build it for real and you can could sell millions to the Army, save lives, and be rich. Seriously.
Your boss loves all things Microsoft, and especially the .NetMF thing he read about in CIO monthly and thinks the Netduino Mini is “Cute” and you should be using it. Your first problem is going to be having a single probe wit as few as possible transducers produce a usable vector from sound travelling at 5000 to 13000M/S. Assume the transducers that are about six inches apart.and there are three of them. How quickly will you need an interrupt to fire in order to get the information you need? How quickly will it need to fire to prevent a second vibration from obscuring the vector of the firstt?
All grossly oversimplified but a real world problem, including the part about a pointy haired boss picking the most important part of the design before the project starts. Yes it really happens.
<\HYPOTHETICAL>
Don’t take any of this too seriously.
[quote]Brett
FEZ Master
8,020 exp
which are all transport level issues you need to explicitly handle, no matter what… so therefore they’re non issues and they sure don’t make things overly timing critical
[/quote]
I LOVE this answer ;D, and I wish I could sell it, until then it all bites ME in the arse when it doesn’t work :’( Especially the projects for my live at home boss. :wall:
Most of the stuff built for the military is vapor-ware anyhow. Sounds like a real Dilbert company.
You might want to consider off-loading some of the work to smaller CPUs and just using GHI’s boards to do the decision-making. It would still be easily within the budget (military considers budget?) and reduce the requirements.
In any case, I think you will need a more exact definition of the timing required before you pick a board - otherwise it will end up as a typical military project.
.NETMF may be a wise choice, though. Probably not yet that many competitors in the military field who know what that is.
So i think the key is that the way you pitched your original use-case didn’t imply things like hypersonic sound detection criticality and other military uses. That is certainly something that I would recommend you stayed away from something that is not a real-time platform, and a FAST one at that. You could always use a netmf as the core controller and offload the processing of the time critical stuff to something more specific, like Lurch suggests.
I guess as a proof-of-concept you could use netmf to handle everything but purely to highlight the beenfits of netmf in dev time.
It’s horses for courses. If you have a temp sensor that you need to read occasionally and publish to the interwebs, or occasionally update a LCD display, then netmf is a great choice. There are lots of things you can do from simple to complex with netmf boards, but there are always going to be things that you would have to take a big compromise on if you tried to shoehorn it into netmf.