Author Topic: Concurrency?  (Read 2344 times)

jherrild

  • Newbie
  • *
  • Posts: 1
Concurrency?
« on: July 08, 2016, 03:26:28 pm »
Sorry in advance if there is an obvious answer to my question that I'm missing.

So I realize true concurrency might be impossible to achieve on the Oak, but what is the best way to emulate it? I'm relatively new to Arduino/Oak programming, and I can't find a way to ensure that my Oak registers a momentary button press if it happens to be reading a sensor right at that moment. Is there a library I'm unaware of that handles this for me?

Thanks,
J

PeterF

  • Hero Member
  • *****
  • Posts: 881
Re: Concurrency?
« Reply #1 on: July 08, 2016, 06:15:14 pm »
True concurrency is impossible as these are single core / one thing at a time processor units. The nearest you'd be able to get to that is by using interrupts (attachInterrupt) and triggering a flag to be set when you press the momentary button, which your main code loop would then look for to see if it needs to respond to the button press. This *should* allow it to not miss button presses but still keep collecting the sensor data. You need to make sure the interrupt function is very compact - ie. just sets a flag/variable, is it is essentially stopping the sensor read, responding to the button press, and then picking up where it left off with the sensor read.

There may be some libraries that will help with this, but most of the button helper libraries I can think of ATM work in the main loop (meaning they won't respond or register a button press if the sensor read is blocking) and don't use interrupts.

DrJFM

  • Newbie
  • *
  • Posts: 31
Re: Concurrency?
« Reply #2 on: July 08, 2016, 09:38:05 pm »
The Oak passes info via the Particle cloud (or some other WiFi/internet connected site).  If you send data at more than a few transfers/sec, the cloud software will throw you off for hogging too many resources.  The Oak can respond to hardware events, as PeterF said, via interrupts ect. At 80 MHz processor, it is fast for an Arduino compatible system, but slow compared to a desktop.

If you want to "see" data with a time resolution of a few milliseconds, you will not be able to with this type low frequency cloud transmission.  Even a USB connection to a Arduino or such is most often trading data at say 115,200 baud -- and this can be slow for some events.

The Oak can read and/or react to a fairly high frequency event stream -- possibly storing data or acting on it as generated.  You can get a "dump" via a micro SD card, for example, or be informed when a value meets some criterion.  Just not if the value you are wanting to react to changes more rapidly than a few Hz. 

Affordable sensors such as the common DHT22 humidity sensor typically take 1 to 3 seconds to make and transmit a set of readings to the Arduino/Oak.  More money buys speed and takes more money for faster communication and faster computers. 

You can do a lot w these MCU's  -- if you can be more specific about what timeframes you need to resolve, you can get some more specific input.  When I use my phone, via the cloud to tell my Oak to mute my stereo in the basement, I can notice a lag -- just a not very objectionable one. 

Cheers.

PeterF

  • Hero Member
  • *****
  • Posts: 881
Re: Concurrency?
« Reply #3 on: July 09, 2016, 12:34:01 am »
Indeed they are fast for a Arduino compatible system! :D Thanks for point that out James.

I'd just add to my previous post that it is usually possible to craft code that isn't blocking (ie. can give the impression of doing multiple things at once) with a bit of elbow grease :) i.e. if you need to wait for something (ie a sensor to give you a temperature reading), send the request for the data, and instead of using a delay, use the millis() function to keep track of elapsed time, and let the main code loop keep running until the sensor responds with the data. Hence your code could be checking for user input, grabbing sensor data, checking cloud input/output and updating a display and SD card seemingly at the same time, as it can switch between tasks rapidly.

So given the right circumstances, you are certainly able to make it behave seemingly concurrent, since we can't even perceive the few milliseconds it takes to switch tasks and respond appropriately.

emardee

  • Full Member
  • ***
  • Posts: 135
Re: Concurrency?
« Reply #4 on: July 09, 2016, 10:39:11 pm »
You can do a lot w these MCU's  -- if you can be more specific about what timeframes you need to resolve, you can get some more specific input.  When I use my phone, via the cloud to tell my Oak to mute my stereo in the basement, I can notice a lag -- just a not very objectionable one. 

I would be keen to hear more about your stereo control project, (...and I'm sure I'm not the only one!). You've mentioned it a couple of times, and it sounds intriguing. Perhaps you'd consider doing a write up in the Oak Projects section of these forums?

Mike