gsxrex - I have no doubt this software will develop into very usable stable code and am interested to see how you make things easier for end-users.
In the mean time I figured out the plumbing between the top-level sketch
loop() function and the WiShield's
handle_connection() function. By adding a
char outBoundBuffer[100] to the
appstate struct (in socketapp.h) and modifying the WiShield::run() method to copy data from
loop() to
handle_connection() each time
run() gets ticked, the one-way datapath is achieved. You could just as easily use larger buffers (for, say, 10 sensor numbers) and also go the other way as well for bi-directional client-server communications from
main().
- Code: Select all
void WiShield::run(int loopCnt)
{
// retrieve the socket_app_state and place data from main() into the outBoundBuffer[] before calling stack_process()
struct socket_app_state *s = &(uip_conn->appstate);
memcpy(s->outBoundBuffer,&loopCnt,sizeof(int));
stack_process();
zg_drv_process();
}
Having figured this out raises another question though. It seems the
run() method needs to be ticked a number of times for it to sequence its way through the tcp/ip stack state and do the communications. After putting a 1 second delay in the loop() it slowed things down enough to figure out that
run() needs to be ticked multiple times for a single data transfer. This is slightly different than the posix
send() function. This is perfectly understandable on a microcontroller that cannot spawn a separate process in the background.
Here is the output of a modified example client-side application that connects to the WiShield:
./main.tcp.client.arduino.exe
connected to WiShield
loopCnt=[11], Hello. What is you name?
abc
Hello abc
./main.tcp.client.arduino.exe
connected to WiShield
loopCnt=[31], Hello. What is you name?
def
Hello def
./main.tcp.client.arduino.exe
connected to WiShield
loopCnt=[98], Hello. What is you name?
ghi
Hello ghi
Notice the
loopCnt is 11, 31, and 98. This corresponds to about 11 seconds of runtime, then 31 seconds, then about 98 seconds. This tells me that
run() needs to be ticked as fast as possible to complete the wireless communications as fast as possible. The rest of the code in
loop() needs to be written with this understanding. For example, something like this may be warranted:
- Code: Select all
loop() {
// do some other stuff
doSomeOtherStuff();
// send/receive over tcp/ip
while (!tcpComplete()) {
WiFi.run( loopCnt );
}
}
Also I have only medium confidence this is the 'right' way to move data from main() to the sending and receiving portion of the tcp/ip stack. It is
one way for sure but I am interested seeing what you guys come up with as a more well-thought-out approach.
Make sense...? ...
benquark?
Marc
