ESP8266 Community Forum

I don't know if this may be practical or not, but would it be worth considering the possibility of combining WAIT with TIMER, so that WAIT might be capable of optionally timing out to a [branch] if and when required?

It could be used to kprevent being trapped in wait and periodically allow checking other things before being returned back to wait again afterwards.

Not sure I am understanding the request here.

Wait is a dead-end trap that is not easy to escape from, but if it had an optional timeout to branch facility (like timer) then you could temporarily escape from a wait to do something, then return to it again after if needs be.

Ok, a problem scenario is for example when you have udp dhcp network nodes...

The problem is that for remote browser msgs to be displayed, the program must 'wait', and if it is waiting in order to display a remote msg such as 'Node nnn.nnn.nnn.nnn is rebooting', it can't actually be carrying out the local instruction.

If you just do the reboot without giving a confirmation msg, you are remotely sat in the dark unsure if the node has even received the remote command or not.

The same sort of problem happens at bootup - the node needs to locally flash out it's dhcp address, but if it does, it is unable to send a remote 'booting up' msg to the browser unless it 'waits', in which case it can't then locally flash the ip address.

UPDATE: In such scenarios, if wait had timed branch escape from the wait trap, eg: wait 1000, [blinkIP] you could send your confirmation msgs to the remote browser with the wait, but then timeout from the wait and branch to [flashIP] to carry out any local task, then goto a wait without an optional timeout declared, if that's what's then needed for catching interrupt responses etc.

GOTO:

Will jump to the branch label of your choice

goto {label}

GOSUB AND RETURN:

Will jump to the branch label of your choice and allow you to return to the location you call the gosub from and continue executing code after the return command is executed. The gosub command has a stack of 255 return points so it is possible to gosub from inside a gosub.

gosub {label}

return

delay:

Will wait for a number of milliseconds before continuing execution.

Useful for making leds blink

delay {Var or value}

Armed with these three things you should be able to arrive at a possible solution maybe.

At this point I suggest one thing to you because I think the interpretation of some of the things you are trying to share may be getting mixed up a bit.

Grab a camera with a microphone and record your project in action explaining the hardware setup and software setup and showing where it is you run into issues if you cannot get others to load your software I promise that they will watch your video and most likely it will be an epiphany for both parties in the discussion I would bet. It is amazing what a video can do to iron out the wrinkles in something and it is done quickly with maximum understanding at that point. You are correct in a lot of your assumptions in the driving lessons page the hardware itself can be slightly quirky at times but basic has done the best job thus far at elimination of these quirks in my opinion. Does this mean you should stop posting absolutely not this is just a suggestion to post and eliminate any confusion. I enjoy reading you posts if you cant tell seems I tend to like to participate in your discussions as well. Just a thought from one basic user to another don't take anything the wrong way here I know how interpretation can be mixed up by not only machines but by people as well :P