ESP8266 Community Forum

- Sun Apr 03, 2016 3:30 pm #44748 Hello,

I hope this is the correct sub-forum.

I interfaced my nodeMCU v2 with an HC-SR04 ultrasonic distance measure sensor (using a 1k resistor between the 5V echo pin and the nodeMCU's GPIO pin). As software I am using the well known node_hcsr04.lua script from Tamas Szabo (github link).

Here is the thing, though. When flashing a firmware from the MASTER branch (1.4.0) onto the ESP8266, everything works as expected and I can get the distance readings. As soon as I am flashing a firmware from the DEV branch (1.5.1) onto the nodeMCU, the node_hcrs04.lua script is unable to get any measurements from the sensor, i.e., measure the delay between trigger and echo signal ("-1" is returned which means, the echo signal hasn't been detected). Back on firmware 1.4.0, everything works again. Both firmwares were build via nodemcu-build.com with the same modules selected.

Is there a change between the MASTER an DEV branch in the GPIO module (or another one) which could render the node_hcrs04.lua script dis-functional? It basically only uses gpio.trig and gpio.write.

Thanks for any hints!

- Mon Apr 04, 2016 2:34 am #44769 I am the guy that implement this change. If you search the github issues list (use a GPIO in:title filter) then you can see all of the discussions.

The issue we had is that the old implementation didn't comply with the SDK guidelines and would often crash the WiFi stack. Getting GPiO to work was a bit of a black art. What we've tried to do is to make the system a lot more stable as well as conform to Espressif guidelines.

I will have a look at the source and see if I can give you some hints.

Edit: OK this works because it breaks all of the rules. Lua is not reentrant, and if you do this then you can crash the RTS. The old implemention did a 100 mSec delay and then used the fact that the trigger called the cb at ISR level to break into this delay. Both are really BAD.

You aren't supposed to spend more than 15 mSec in any task, otherwise the WiFi can crash. Replace the delay by an alarm callback so the the trigger can be delivered as a normal priority task and it should work. Also read the link below for the background. I'll leave you to post the github issue with the developer.

Also delete your duplicate post. This is bad forum etiquette.

Please see my Developer FAQ for Q&A on nodeMCU Lua before asking a question here that's already been answered. This and the other official documentation should be your first reference for developing Lua Apps

- Tue Apr 05, 2016 1:08 pm #44902 Thanks for your answer!

I will try to rework the code to use timers.

- Thu Apr 07, 2016 12:49 pm #45059 It's me again.

Today I got some time to put some thoughts into it. I started out with using tmr.alert() to reimplement the current tmr.delays. That's when it hit me that without that "busy waiting" I have no means of controlling when the measurement is done.

In my main routine (init.lua), I am starting the measurement upon receiving an HTTP request. Before serving the request, I do the measurement and report the value back.

Without the "busy waiting"/tmr.delay I do not know when the measurement is completed and have no means to wait before sending out the HTTP response. What I would need is either a blocking call to the measurement function or a way of firing an interrupt when the measurement is done (and then starting the HTTP response).

Is either way (or another alternative) possible within LUA?
(Sorry for asking this but I am just beginning with LUA and the nodeMCU)

Cheers,
lepido