0

I have a ds18b20 sensor connected on pin D3 and an hall sensor on pin D1. I use tmr.trig on pin D1 to count falling edge events. When I call ds18b20:read_temp(callback, pin, ds18b20.C) everything works as expected.

The odd thing starts to happen when interrupts from the hall sensor start arriving. Just an interrupt per second is sufficient. read_temp hangs and doesn't call the callback and I get no readings. After a while a lot of calls to read_temp pile up and the esp8266 resets.

I traced the problem down to line 205 of ds18b20.lua:

if lcb then node_task_post(node_task_LOW_PRIORITY, lcb) end

If I replace node_task_LOW_PRIORITY with node.task.HIGH_PRIORITY the issue is fixed. This looks like the scheduler is starving that low priority task.

I'm wondering if I'm doing something wrong? Or is this a bug? Do interrupts interfere with node.task?

Elinvention
  • 1
  • 1

1 Answers1

0

I answer my own question. I found out what was interfering with the task. It wasn't the interrupt in itself, rather a call to gpio.serout inside the callback function. As stated in the documentation:

HW timer FRC1_SOURCE mode is used to change the states. As there is only a single hardware timer, there are restrictions on which modules can be used at the same time. An error will be raised if the timer is already in use.

Indeed I did receive an error, but couldn't read it because it printed as gibberish in the serial terminal.

Elinvention
  • 1
  • 1
  • The gibberish is likely coming at 74880 baud like the messages from the boot loader. http://cholla.mmto.org/esp8266/weird_baud/ has some insights. – Marcel Stör Apr 29 '20 at 05:29