9 replies to this topic

[H07R0D]

So I've been reading/coding reading/coding my little heart out. CanaKit dinged my credit card, so my NP is on it's way. I'm working on the code to handle all my inputs and outputs. Here's the pseudo: - Read SD "Plugins" folder for listing of assemblies - Pull them up and determine their purpose (currently just "Input" or "Output") - If it's "output" add the callback to a list of weak delegates for later processing - If it's "input", spin off a worker to generate data - When an "input" interval hits, pull data from wherever (Input plugins would be things like temp, ph, etc.) dump to shared memory space, and signal. - When the signal goes up, loop through the weak delegates and perform the output functions (write log entry to SD, upload channel data to Thingspeak) and clear the shared memory space What I'm trying to figure out right now is the process for the Input Plugins. Do I spin off a full thread for each Input or would Timers make better sense? In .Net-Full I would use the ThreadPools, but for .Net-Micro I'm not sure what the ideal option would be. Thoughts?

[Michel Trahan]

I read somewhere that the Times are not to be trusted ... not precise ... And a thread for each input ... isn't that an overkill ? Comments by a real newby ...

[Stefan]

If I understand you correctly you want to use a timer/thread to poll an inputport for data? You can also use a InterruptPort for that, which works event-based. See this tutorial for details: http://www.netduino....edbuttonapp.zip

[Michel Trahan]

See this tutorial for details

We have to work on a tutorial section ! Thanks for sharing this one !

[Chris Seto]

Pretty much nothing timing wise is precise in NETMF. As a general rule though, you want to have stuff powered by timers. You aren't really suppose to have infinite loops in NETMF and there are cases where that can really mess your software up, especially if you ever use WPF in NETMF.

[H07R0D]

Thanks for all the quick feedback.
@Stefan - I like that InterruptPort, it would make life a lot easier. All the input plugins so far are passive however. I'm planning on just reading a pin on a set interval to gather data. (i.e. Read temp once an hour) so can I still use the InterruptPort? I could add the interrupt and use that to trigger my output plugins, but I still need to poll the input plugins.

@Michel - You're right, I was thinking a thread per input was overkill, but some plugins will have different interval times (i.e. temp every hour, but pH may be every 6 hours or more)

@Chris - Eventually I'd like to put an LCD shield on for live conditions, so I'll have to look at the WPF stuff then.

Seeing as I'm leaning towards much longer time frames, would an additional clock (a la this one) be worth looking at?

[Stefan]

Thanks for all the quick feedback.
@Stefan - I like that InterruptPort, it would make life a lot easier. All the input plugins so far are passive however. I'm planning on just reading a pin on a set interval to gather data. (i.e. Read temp once an hour) so can I still use the InterruptPort? I could add the interrupt and use that to trigger my output plugins, but I still need to poll the input plugins.

The interruptport just triggers an event when the inputport changes value, nothing more, nothing less.
If you want to read a temperature once an hour it's perhaps not the best solution.

You could use a timer, see http://msdn.microsof...ercallback.aspx for more about that, but as stated earlier, timers aren't 100% precise I've read somewere else. If it's not life depended that it's a couple of seconds wrong, the timer classes can be useful.

[H07R0D]

The interruptport just triggers an event when the inputport changes value, nothing more, nothing less.
If you want to read a temperature once an hour it's perhaps not the best solution.

You could use a timer, see http://msdn.microsof...ercallback.aspx for more about that, but as stated earlier, timers aren't 100% precise I've read somewere else. If it's not life depended that it's a couple of seconds wrong, the timer classes can be useful.

That's what I was leaning towards. However, the example code is exactly the code I need.
Thanks again.

[Gauss]

I would follow Stefan's advice. Fair warning though, as someone who has dealt alot with Threading and Timers in .NET environments... You have to be INCREDIBLY careful, especially when debugging, what your reference timer is. Its not a big deal with software development, but when hardware starts entering the picture it can become important. Had a gigantic problem with serial comm traffic in .NET for a project I did last year, spent days trying to figure out what I was getting constant time-outs. After some digging I found out that the internal clock for all Timer related .NET objects/methods have a tolerance of 550 uS. I'll admit upfront that this is coming from a Netduino noob, I'm not as familiar with its environment and I would assume it has a much better Real-time functionality. Just some information for you regarding .NET.

[Chris Seto]

The proper way to do recurring events in NETMF is with timers. Unlike most embedded systems, NETMF doesn't play nice with infinite loops.