AsyncLabs Forums

[GregEigsti]

In reference to fdarvas' question in the following thread
http://asynclabs.com/forums/viewtopic.php?f=15&t=18&start=20

fdarvas would like to create a WiShield app that that opens a socket that essentially streams sensor data via that socket to a remote client. In looking at the sample apps I am seeing that they are "hit and run" - meaning that the server apps will listen on a port and either send one chunk of data and close the socket or only send data in response to received data. After reviewing the uIP documents my understanding is that data can only be transmitted in response to the stack calling your UIP_APPCALL function - and the recommended way to accomplish this is via paying attention to uip_poll() (or its variants). My experimentation shows this to be true (I cannot send using uip_send() from my application loop() but can uip_send() in response to a poll event in UIP_APPCALL).

From the uIP doc

1.6.1.8 Polling
...
The polling event has two purposes.
...
The other purpose is to let the application send new data that has been produced. The application can only send data when
invoked by uIP, and therefore the poll event is the only way to send data on an otherwise idle connection.

Am I understanding correctly that an app that wants to stream data over a socket must queue up its data and send it in response to a poll (or other) UIP_APPCALL event?

Also, how does breemen's distribution of his Client/Server code (from above thread) differ from the official WiShield distribution? It appears to be a superset with some added functionality?

Thanks!
Greg

[GregEigsti]

After thinking about it and re-reading some uIP stuff I think my above thinking is correct re: having to send from UIP_APPCALL.

One other question - is UIP_APPCALL called down the stack from WiFi.run() (and not due to an ISR)? Was thinking that I would have to protect any shared data but if the UIP_APPCALL is called due to the call to WiFi.run() this would not be an issue (at least for my code that would update the shared data via a call from loop()).

Thanks!
Greg

[GregEigsti]

So I have been playing with this and have an implementation that sends a buffer full o' bytes every UIP_APPCALL/uip_poll(). I have also found that the max amount of bytes that I can send is ~330, I can only send once per UIP_APPCALL/uip_poll() and UIP_APPCALL/uip_poll() is called about every 500ms. So this means that the max number of bytes that I am able to stream is 330 per 500ms period or 660 per second.

What am I missing to get more data (magnitudes) streamed via the WiShield?

[Edit]
It looks like I can squeeze more out by sending additional bytes in response to uip_acked(). Yuck, means more complicated send buffer handling...
Any better ideas?

Thanks!
Greg

[fdarvas]

Where (in relation to loop()) are these functions called?

In the example, everything is in socketapp.c, but can this moved to the main program? Or how do I pass data, e.g. from a buffer, to these uip functions???

[Tamalpias]

I just ran into the same issue while venturing on my own implementation. Have you ever been able to get more continuous data sent over a live socket stream? Thanks!

[GregEigsti]

Umm, I don't remember, maybe PM me with your email addr and I'll send you what I was playing with.

Greg

[rryan]

Greg:

After reading the zg2100 driver, it looks like the send buffer size is bounded by UIP_BUFSIZE. Did you try increasing UIP_CONF_BUFSIZE to see if that helps in sending packets > ~330 bytes?

[GregEigsti]

I have brought a lot of the uIP stack settings from various files into apps-conf.h in the user contrib distribution of the WiShield libs to provide a better "one stop shopping" experience - doing the same for UIP_BUFSIZE/UIP_CONF_BUFSIZE would certainly be beneficial (until people start blowing their stacks...). I think I have mucked with the buff size setting in the past but have never launched into a streaming type app personally (its a 16mhz Arduino after all). My comments in this thread were merely trying to help others out - not my project

Greg

[spidermonkey04]

I regularly use an 800 byte buffer, gone up over 1000 at times...

---Jared