Connect Async vs write Async ( question more then Issue )

[EricB]

Hello Wchill, am very happy to stumble on your work with the winc1500.
This is not an issue but a question-feedback based on use-case of the winc1500.

I have built a CANbus-datalogger with the WIN1500 and I too found the winc1500 calls to be blocking.
HOWEVER, using a scope, I noticed that in the sequence ( Connect , write,write,write, read (loop) , client.close ) the CONNECT aspect is the one that causes the longest blocking.
If the server is present and OK, it will always answer within <10-100ms ( depending on ping time ) and then the client.write(s) and client.close() are always very fast.

if the server is down or extremly busy, then the client.connect() can reach the 20seconds timeouts.

I started reading down to the m2m_xyz(.c / .h ) and the nm_xyz(.c / .h ) and found your work on the ASYNC calls ...
Why did you focus on client.write() ? maybe there is something i have not seen yet ...

I'd like to check for a connectASYNC as well ... your feedback would be very much appreciated

Eric

[Eric Ahn]

Hi,

if you are using my fork of the Adafruit WINC1500 library, the beginAsync() function acts as an asynchronous version of begin() which is what starts the connection process.

I also made an asynchronous version of write() because for my particular use case, sometimes the internet connection is not stable and it causes the whole program to block. This is not good when the whole system must operate under real time - keep in mind that my system is designed to both log and pass through keyboard input from the user... it becomes very noticeable if keystrokes begin to "stutter"! In addition, if the write buffer on the WINC1500 fills up, the entire program will block until the write buffer is emptied, which may take a long time.

I didn't focus so much on read() and close() as read() makes use of a buffer that already gets filled asynchronously while close() should run extremely quickly anyway.

[EricB]

Hello,

Yes, I did see the beginAsync which is the connection to the "router".
But once connected to the router, the server might not be available which bring the 20 seconds timeout.

Is your HTTPserver always available once connected to WiFi? this may still be a blocking issue.

During my testing, I get my server to be unavailable for a few seconds ( realistic scenario ) and it suddenly blocks the main loop for 20seconds ...

My application sends and HTTP msg ( maybe I should go for UDP ... ) every minute.
Yes, I need to use your Wifi.beginAsync since it may block my main loop if wifi gets dropped.
and Yes, writeAsync would increase SPIbus availability

But my main concern is client.connect(server, port) blocking for a full 20 seconds.

What I am trying to solve:
I have multiple devices on the SPI port ( SDcard, WINC1500 and 2x Can controllers).
those standard librariries do not all use SPI.begintransaction to help with SPI multi-device sharing.

luckily I never have to write on my SD card AND use the Wifi at the same time BUT
when I process my CANbus ( mcp2515) interupts, if the WINC1500 suddenly decides to un-block, it starts to use the SPI port. (doh ! )

I tried noInterrupts() within my CANbus ISR routine to prevent WINc1500 to handle its interupt "right-away" and maintain a priority but for some reasons ... I did see it accessing the SPI bus while it was in my CAN_isr() function ...
I am getting to think that WINC1500 uses non-maskable interrupts as I have recorded.

can you confirm ?
I am trying to mask the WINC1500 interrupt for a few microseconds.
any suggestions ?

[Eric Ahn]

Ah, I forgot about the connect() call. My application uses raw TCP sockets (no HTTP server) and the backend server is more or less always available. When I was benchmarking the asynchronous calls, I didn't notice any performance issues from the standard connect().

If you go here https://github.com/wchill/Adafruit_WINC1500/blob/master/src/Adafruit_WINC1500Client.cpp#L155 and remove everything until line 167, it should work as an asynchronous version of connect(). I haven't tested this setup though.

[EricB]

Hello Eric,

I like your work on the async calls, i'll most likely use it and will let
you know if I find anything.

Have you found a way of resetting "locked" sockets ?
For large transfers, if the TCP/IP socket gets "broken" ( internet drop for
a few minutes) the server will close it's connection but the WINC1500 will
no longer assert the IRQ line to tell the CPU it now accepts more bytes to
send ...

I am trying to implement a timeout feature on writeAsynch for the current
connection.
If > timeout, close connection and re-try a new one ...

HOWEVER, even with a "client.stop", I can no longer call
client.connect(socket) ,
as it always return zero ( no connection ! ).

Q1: do you know how to flush the opened sockets in the WINC1500 ? i tried
all public methods with no success

I want to make sure that WINC1500 can ALWAYS recover from a bad network
link ...

What do you think ?

Eric

I checked into adding a "timeout" into client.write to mange such cases

On Tue, May 24, 2016 at 12:11 PM Eric Ahn [e-mail] wrote:

Ah, I forgot about the connect() call. My application uses raw TCP
sockets (no HTTP server) and the backend server is more or less always
available. When I was benchmarking the asynchronous calls, I didn't notice
any performance issues from the standard connect().

If you go here
https://github.com/wchill/Adafruit_WINC1500/blob/master/src/Adafruit_WINC1500Client.cpp#L155
and remove everything until line 167, it should work as an asynchronous
version of connect(). I haven't tested this setup though.

—
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub
#3 (comment)