How know that dhcp client is running, so can use netcon words? about punyforth HOT 7 CLOSED

Maybe you could check if an ip address is associated (using wifi-ip, softap-ip) to the esp or not. But keep in mind that these words create and return a newly allocated string each time. So it's not a good idea to use them in a loop unless doing some extra memory housekeeping.

In the esp-open-rtos there is a function called sdk_wifi_station_get_connect_status().

https://github.com/SuperHouse/esp-open-rtos/blob/7c702d7f09f4f810144a17ae3d0ebd110ee77599/tests/cases/04_wifi_basic.c#L124

But currently this is not exposed as a forth word.

from punyforth.

Thanks for info, zeroflag. I wondered if I had just not seen something. I think just doing a loop around the netcon-connect until it works is good enough for my purpose.

A related issue I am chasing right now is that netcon reads do not seem to time out. I can see a value being set in netcon-new, as follows:
: netcon-new ( type -- netcon | throws:ENETCON ) override netcon-new dup 0= if ENETCON throw then RECV_TIMEOUT_MSEC over netcon-set-recvtimeout ;
but I've had netcon-readln wait for hours - at least I think so. I am still struggling with keeping track of multiple tasks on 2 ESP8266s attempting to co-operate. My brain gets very full sometimes (most times?). Well, the co-operation part was not too hard, but handling comms failures is doing my head in. Sometimes just figuring out which end of the comms screwed up is hard and I spend hours poking around the wrong code before I get a clue. I keep learning, but sometimes there's a few steps back before I get to go forward again.
Many thanks again for your help.

from punyforth.

A related issue I am chasing right now is that netcon reads do not seem to time out.

This is quite possible and looks like a bug (or a missing feature). The purpose of RECV_TIMEOUT_MSEC is not to block the running tasks (threads) by the one that waits for the data. The word read-ungreedy executes a pause (which yields control to an other task) when timeout occurs then retries forever. So RECV_TIMEOUT_MSEC is an internal timeout, but there should be an other timeout to be able to exit this loop. This is missing right now, thanks for letting me know.

I'm going to try to fix this in the weekends.

from punyforth.

I added option to specify global read timeots on netcon sockets.

10 read_timeout_sec ! \ set read timeout to 10 seconds

or

-1 read_timeout_sec ! \ -1 indicates no timeout

The netcon-read and netcon-readln throws ERTIMEOUT exception when a timeout occurs.

from punyforth.

Many thanks for timeout. I'd missed reading the internal timeout in read-ungreedy. Time for me to have another go.

from punyforth.

Probably it would be better to be able to set the read timeout on individual connections instead of globally. So this may change in the future.

from punyforth.

Please note that I replaced the global timeout with an individual timeout per netcon.

\ words for setting and getting the socket level timeout

netcon-read-timeout! ( read-timeout-in-seconds netconn -- )
netcon-read-timeout@ ( netconn -- read-timeout-in-seconds )

\ example

variable: socket
PORT HOST TCP netcon-connect socket !
60 socket @ netcon-read-timeout! ( set the timeout of this socket to 60 seconds )
socket @ netcon-read-timeout@ . cr ( print out the timeout )

from punyforth.