Yes, it appears it was down. That was the first fail since I started experimenting with it.
It's down again. Looks like I can crash it on demand. Sorry about that.
"!*" is a packet or SPI write. I send what I calculate as 7 packets using client.write(),
It's an SPI write. A packet is something else. The distinction is important.
Any way you look at the math, delay(100) is a 100ms delay.
Yes, I get what delay(100) does. What you don't appear to be getting is the bus write is decoupled from the network write. What role is that gert big AT32UC1512 playing in all this?
However, the internet computers that surprised me downloaded the files fast, noticeably faster than mine.
You do not know whether those computers downloaded anything at all.
It is not difficult to tell the difference when talking about 20+ seconds difference.
So try to explain the variation to me. What mechanism could cause the throughput to go from an average <20Kbps to over 500Kbps? The most likely answer is, it doesn't.
If I start a download with one computer, then try to download with another computer, I get a "connecting" message until the current download is finished, then I get a "connected" message and the download starts.
Yes. The TCP session handling appears to be borked.
According to them, the ethernet shield does use all 4 sockets, and the wifi shield uses only one.
Server_Drv.h contains the prototypes for ServerDrv::getClientStatus(socketIndex) and ServerDrv::getServerStatus(socketIndex), which return values enumerated to TCP Socket states.
0 = CLOSED, 1 = LISTENING, 4 = ESTABLISHED.
The state transition looks like this
status: Client, Server
0 0 //Closed
0 1 //Listen
4 1 //borked!
A TCP Socket can not be ESTABLISHED and LISTENing at the same time.
Calling ServerDrv::startServer on a Socket which is already LISTENing causes new connection attempts to be rejected. But I can not for the life of me get another socket to start listening. As far as I can tell, the problem is on the other side of the SPI bus - Beyond my ability to debug or do anything about it.
You seem to be the only other person here besides PaulS and myself that really cares anything about this.
LOL. I guess I care that you don't post sarcastic comments alluding to my having made stuff up!
I also care not to encourage people to waste money on a device, which is unlikely to meet their expectations. The WiFi shield is a candidate for the draw of shame
- You know, that draw full of stuff that is never used. The shield is not entirely useless but reliably serving interactive web pages onto the internet, is currently beyond it.
Apart from that, call it a professional interest. Poking around with the WiFi shield has been reminding me of what I take for granted. Sockets being no more than data structures in software, for instance.
Nobody else has responded, so it is difficult to tell how it is actually working on the client end. Check with your wireshark and let me know what you see.
I write my own clients. The compiler I am using is paid for but there are plenty of free tools, including Processing. You can download Wireshark for free too.