Chat freely about anything...

User avatar
By Hairyloon
btidey wrote:It is not waiting for the event, but when an event occurs the handler will effectively perform its task and on a single core processor like the esp8266 this will inevitably pause activity in the loop.

Ordinarily I might argue that that is a semantic distinction, but semantics are very important in programming, so I thank you instead. :)
User avatar
By Inq720
#93845 The ESP8266 chip has a lot of things it has to do down in the lower levels when not under your control while in either the setup() or loop() methods. If you keep it too long, those other things can't get done. That's why they have the watch dog... you abuse the lower level, it gives you the finger and reboots on you. So anything longer than single digit milliseconds really ought to be asnyc. Happy dogs don't bite.

So for you to get work done you can...
case 1... A BMP280 pressure sensor wants you to initialize it and it returns a time that indicates when the answer will be ready to pull from the sensor. I want to say it was in the 5-10 ms range. For a lazy weather station project, where a reading once a minute is overkill, you can easily do synchronous - call init(), delay(10), read() all in the loop method and call it good.

case 2 - Another project where I needed pressure readings on two sensors at a 100 Hz while doing a lot of other things including running a webserver and multiple websockets. In that case. I called init() returned from the loop... letting the lower level work. When it came back in the loop I did something else and returned. After thousands of these (do something) loops (10 milliseconds had passed) and I could then do the read() on the first sensor.

That is very painful coding... the better way is setting up events.

With anything client/server related you might as well assume you must use async. Even in the same room a good turn around for a message may be a couple of milliseconds, but I've also seen 400ms in the same room. If the client is half way around the world, it will be far more than the watch dog will tolerate. Besides if you are holding the loop method, the lower levels can't send or receive any traffic. You have the CPU.

You asked specifically about an async web server and does it interrupt the loop. Not like a true software interrupt. Not... really... it's just expecting you to return from the loop to let it do its work. It says... I have a new message that came in and I'll fire the even that finally bubbles up to you. So yes, it comes to you between loop calls, but never while you have control in your loop method.

I don't know if that is clear.
User avatar
By Inq720
Hairyloon wrote:Say for example I have an asynchronous web server with a button on it.
The button should trigger a routine on the ESP.

Maybe a code example would be easier to read than my last post. :D

The server-side Sketch creates the server. The lower level code makes the decision to call (1) its own WiFi code (2) any callbacks or (3) your loop() method... in that order of priority. So... technically, it's not really interrupting anything... it's just prioritizing.
Code: Select all#include <InqPortal.h>

InqPortal svr;

void setup()
  svr.publishRW("ClkMe", NULL, NULL, NULL, clickedMe);
  svr.begin("SoftSSID", NULL, "<your SSID>", "<your Password>", "HostName");

void loop()
  // put your main code here, to run repeatedly:

void clickedMe(u8 val)
  svr.LOG(1, "A person clicked the client's button (%u)\n", val);

Once you browse to the Admin, you can upload this to its "disk", then you can browse the "client" page and click the button.
Code: Select all<!DOCTYPE html>
  <title>InqPortal Sample Press Button Event</title>
  <meta name='viewport' content='width=device-width, initial-scale=1'> 
  <script src='InqPortal.js'></script>
  <link rel='stylesheet' type='text/css' href='InqStyle.css'>
<body class='space'>
  <h1 class='space'>
    <button onclick='set({ClkMe: 42});' class='btn'>Click Me</button>
Here it is working... about 2 minutes to code up.