An archive of community.esquilo.io as of Saturday January 26, 2019.

Esquilo for timing sensitive inputs

rick

I'm working on a project to build a controller for a deep well pump. I'm considering the Esquilo, but I'm concerned about the lack of interrupt support. One of the inputs will be connected to a hall effect sensor to monitor the rate of water flow. On the Arduino, we'd use interrupts to catch the pulses generated by the sensor, but without interrupt support, how would we do this on the Esquilo without losing pulses?

Thank you,

Rick

Scott_Shumate

It depends on how fast your hall effect sensor changes. If it's in the few kHz or less range, then you'd probably be fine with the GPIO class onchange() method which is in effect an interrupt. If you need very precise measurement between pulses, then you can use the Capture class in a loop. That will give you microsecond resolution.

rick

Scott,

Thanks for your quick response.

The liquid flow sensor uses a rotary hall effect sensor, so the frequency and pulse width will vary depending on rotation speed. I don't expect the frequency to be greater than 330 Hz, but I'm not sure about the pulse width. Based on your comment, either approach should be fine, but onchange() and Capture functions run asynchronously, correct? Since they don't use interrupts, will onchange() and Capture tie up the processor, or is there a risk that pulses will be dropped if another task is tying up the processor?

Thank you,

Rick

Scott_Shumate

The onchange() method runs asynchronously while the Capture class is blocking. What onchange() does internally is turn on a low-level GPIO change interrupt. Every time the interrupt fires, it sends a RTOS message to the Squirrel task to run your function asynchronously. Several of these may be queued up so you won't miss them unless you overflow the message queue.

At 330Hz, you've got a huge margin for error so I don't see a problem. By default, the Squirrel task runs at PRIO_NORMAL, where only the WiFi driver and TCP stack will take the processor away. If you wanted the lowest possible jitter, then you could use priority(PRIO_HIGH) or even priority(PRIO_HIGHEST) to assure the callback is run without delay or interruption.

rick

Thanks! It looks like onchange() will do the trick. The nice thing about onchange() is that I can run a counter in the background to calculate not only flow rate but also volume. If I understand correctly, the Capture class will only allow me to take a short samples, effectively polling the sensor.

Rick

Scott_Shumate

Correct, you would need to poll with capture. You would have time to do other processing in your loop but you would have to adjust the time returned from the capture to account for that.