Can you post the code?
- Netduino Forums
- → brianmakabro's Content
brianmakabro's Content
There have been 12 items by brianmakabro (Search limited from 26-April 23)
#62262 InterruptEdgeLevelHigh
Posted by brianmakabro on 27 April 2015 - 02:02 PM in Netduino Plus 2 (and Netduino Plus 1)
#62196 InterruptEdgeLevelHigh
Posted by brianmakabro on 20 April 2015 - 03:08 AM in Netduino Plus 2 (and Netduino Plus 1)
If you want to interrupt on EdgeLevelHigh - is it possible you should maybe use an external pull-down resistor on that line?
Brian
#62177 Multithreading
Posted by brianmakabro on 17 April 2015 - 09:46 PM in Netduino Plus 2 (and Netduino Plus 1)
No, not really. Of course, it takes memory to start threads, but the garbage collector will (hopefully) reclaim that as the threads are done and no longer "in scope". I'm sure there is a limit to the number of simultaneous active threads the Netduino can handle - but I don't know what that is. It's also dependent on what each thread is doing, how many variables, etc. are being instantiated, and such. I don't think 3 or 4 threads are going to break the bank unless you're really doing something processor-intensive in them. Maybe Chris could answer that?
Welcome
Brian
#62150 Input as event
Posted by brianmakabro on 16 April 2015 - 07:25 PM in Netduino Plus 2 (and Netduino Plus 1)
How about something like:
#62121 Multithreading
Posted by brianmakabro on 15 April 2015 - 02:59 PM in Netduino Plus 2 (and Netduino Plus 1)
I'll edit my above statement that "you can re-use Thread, but you can't re-use ThreadStart" - it's a misstatement. The actual Thread(s) are always "new Thread" - AND "new ThreadStart" - but I think the example shows what I mean. Sorry if I'm confusing the situation.
#62120 Multithreading
Posted by brianmakabro on 15 April 2015 - 02:50 PM in Netduino Plus 2 (and Netduino Plus 1)
You can re-use threads... but you can't re-use ThreadStart... very simple example below. I personally don't think doing stuff in a "while loop" is bad - it all depends on what you are trying to do, and without seeing an example of your code it's all just a guess... anyway, I beg forgiveness for this cheesy example but maybe it will illustrate what I mean:
#62104 BLUETOOTH Module and Apps
Posted by brianmakabro on 14 April 2015 - 12:23 PM in Project Showcase
I've used both HC5 and HC6, without problems. The default pairing code is (on mine anyway) 1234. Once paired, should automatically connect when in range. Scanning for it on your target phone or tablet should pick up the mac address of the HC. Very simple to connect, VDD, GND, HC TX goes to Serial RX on Netduino, HC RX goes to Serial TX on Netduino. I've run mine on both 3.3v and 5v.
#61993 Interrupt Port and Debouncing
Posted by brianmakabro on 31 March 2015 - 12:12 AM in Netduino Plus 2 (and Netduino Plus 1)
Sorry - I just realized upon re-reading that you are not using Level interrupts. My bad.
Brian M.
#61992 Interrupt Port and Debouncing
Posted by brianmakabro on 30 March 2015 - 10:26 PM in Netduino Plus 2 (and Netduino Plus 1)
From
https://msdn.microso...y/cc532335.aspx
"When configuring an interrupt port, note the differences between level and nonlevel interrupts. Level interrupts, which are either InterruptEdgeLevelHigh or InterruptEdgeLevelLow interrupts, are dispatched when the value on a pin matches the specified high value or low value, respectively. The system dispatches only the first occurrence of a level interrupt until it is cleared by means of the ClearInterrupt method. With nonlevel interrupts, every specified edge is dispatched, and the ClearInterrupt method throws anInvalidOperationException.
In practice, it is best to use level interrupts when the interrupt condition needs to be checked only periodically."
Based on the above explanation, your interrupt will ONLY fire when the edge is high, so checking for both high and low states in the interrupt event is not necessary. I would also think that heartbeatInput.ClearInterrupt() should be called unconditionally from the interrupt event handler itself, before it exits the handler, (since your "handleHeartBeat()" will only be called from time to time.)
On first look of your code, the ClearInterrupt will not always be fired - it will only be called if ts.Ticks > 1500000.
Also - you might try using the GlitchFilter to de-bounce.... I believe that's one of the things it is supposed to be used for.
Brian M.
#61930 Controlling Multiple I2C devices
Posted by brianmakabro on 22 March 2015 - 11:45 PM in Netduino Plus 2 (and Netduino Plus 1)
I think it may have been done that way because of the "Netduino as master-only." It's very similar to the way MS did their Point-Of-Sale architecture. It's really not very intuitive, at first. (IMHO, of course.) But then since ND can only be the master, it IS the I2CDevice - and the slaves are all just so many connections.
#61925 Controlling Multiple I2C devices
Posted by brianmakabro on 22 March 2015 - 01:56 AM in Netduino Plus 2 (and Netduino Plus 1)
Absolutely can be done, instantiate multiple Configurations and just set device.Config = configX.
#61835 Inconsistent Server Response
Posted by brianmakabro on 10 March 2015 - 06:25 PM in Netduino Plus 2 (and Netduino Plus 1)
Maybe some latency in the network is causing your int bytesReceived = clientSocket.Available; statement to continue looping, whereas putting a breakpoint there gives the client socket enough time to have processed the request...
Maybe something like:
while (clientSocket.Available == 0) { // waiting for request to be processed };
would allow the request to get fully queued up before the code continues?
- Netduino Forums
- → brianmakabro's Content
- Privacy Policy