Delay in sensing temperature locks up Photon

Firmware
1

Ok. Here’s the deal. I’m using OneWire and code from https://docs.particle.io/tutorials/projects/maker-kit/#wire-up-the-sensor for a Dallas DS18B20 temperature sensor.

And it all works fine, accurate and I’m able to move the data where I need.

But… the problem is that the code from docs.particle.io is using a delay of 1 second to wait for the read to actually come back from the sensor. So, therefore my photon is locked up for 1 second out of every 5. Thats 20% unresponsive time. Thats gonna kill me when I start getting feedback from clients saying that their machines aren’t responding 20% of the times when they initiate actions from their phones.

This is especially unnerving to me since I’ve done lots of coding in javascript where asynchronous non blocking execution is just the way things are and this would be a non issue.

So, is this just the name of the game with Arduino and Particle where, in order to read from a sensor like temperature, you gotta just wait for it? Or, are there tricks out there to not lock things up while waiting for a reading?

2

@risingtiger, I think you are actually referring to "blocking" rather than "locking up". There are lots of techniques to make your code non-blocking. The examples provided are designed to be very simple to illustrate a particular feature, and non-blocking code would make the example more complicated and not so easy to understand.

Among the techniques that could be used to make the code non-blocking is the use of interrupts (probably not the technique you would use in this particular case), software timers or using a finite state machine (FSM) to design the behaviour of your firmware. There are likely other techniques as well.

There are a couple of threads running right now where you can see someone else designing a FSM:

and

3

Depending on what kind of “unresponsiveness” you aree thinking of.
If you want your code to service Particle.function() or Particle.variable() requests this is the easiest substitute for delay(1000)

  for(uint32_t _ms_ = millis(); millis() - _ms_ < 1000; Particle.process);

this will spin in a tight loop for one second servicing the particle cloud tasks at maximum speed during that periode.

But in general non-blocking coding paradigms are the way to go.

4

Thanks ScruffR for the tip on setting up that loop to keep Paricle cloud communication going. I’ll probably end up using that for now. I totally get it that having non blocking code is the way to go though. Do you have any recommendations or references of how to do this specifically for sensing data, like temperature, where there is a wait time from the moment a read request is initiated to the time the data is retrieved?

The Dallas thermometer data sheet recommends a 750ms delay or, better yet, a one second. And all the tutorials I’ve found on this specific sensor have at least a 750ms delay in the code. Even the spark-dallas-temperature library has it.

5

Another approach would be to 1) look for a library that processes the return from the OneWire bus asynchronously, or 2) look to do that yourself (polling for a response).

Have a look at the robtillaart example here.

6

You know. This is the kind of stuff I’m looking for. Gives me a start at least. Thank you bulldoglowell.

1 Like