I'm having some difficulty figuring out the best way to use the WiflyInterface and underlying Wifly object.

The WiflyInterface provides very little functionality on its own, but the underlying Wifly object capable of doing some real work doesn't seem to have any documentation or explanation.

It looks like the Wifly object has a handy "SendCommand" method that looks like it can be used to generically send a "command" to some remote system and then get back either an acknowledgement string, or an actual data response of some kind. Ok, cool, but then what's the right way to "listen" for an incoming message from the remote connection and then respond to it? Do I poll wifly.readable() and then try to empty the read queue? So far that hasn't worked out real well for me... but that may be my fault.

There also appears to be a naming conflict where by the .connect() method defined on WiflyInterface is hiding the connect() method defined on Wifly and they do two totally different things. I've had to rename the one on WiflyInterface to "connectwifi()" (which is really just a join() operation) so that I can use the one defined on Wifly (which is actually a socket connection operation).

My ultimate goal is a processing routine along the following lines:

Define Interrupts for Two Digital Input Pins

• Interrupt callback simply records the event in a list

Execute Main Loop

• Check event list for events
  • If more than 0, send oldest to remote TCP endpoint
• Check console input for key char
  • If found, append to current console input command
  • If command complete (char = LF), process current input command
• Check Wifly for any incoming data
  • If found, append to remote input data
  • Check input data for a complete message
  • If found, remove message data from input data and process message
• Repeat

That is the basic gist of my application.

Currently I'm using a TCPSocketConnection for communication, and while it works pretty well once I get connected, it doesn't always connect reliably. Occasionally I do wind up with incomplete data as well, so I know my implementation is not perfect.

I tried switching to a UDP socket, but that didn't work correctly at all with the Wifly when I tried to use non-blocking mode. I had to use a timeout of at least 1 full second, and when I used a timeout that large, my processing loop stopped doing its other work (such as capturing console keys and building a command). The only process that would execute was reading the UDP socket when it was finally sent data. (open Question in questions section of this website)

So now I was trying to see if I could get better results out of the Wifly instance itself instead of the socket.

If anyone could help me understand how best to utilize the Wifly object or one of the sockets to achieve my goal I would be ever so grateful.

Hi Reed,

I'm far from a "native" C++ speaker, but the WiflyInterface is derived from the Wifly, so it [WiflyInterface] has access to all of the methods of Wifly. The Wifly also supports the underlying needs of the various socket APIs (Socket.h, TCPSocketConnection, TCPSocketServer, and so on). This is where you'll find the traceability to the Wifly::connect( ).

Have you worked with the various examples in the WiflyInterface cookbook page?

With respect to your renaming the method, you should not have to do that, so I would encourage that you undo it. The basic interfaces try to remain compatible between the WiflyInterface (and underlying socket interfaces) and the EthernetInterface.

SendCommand( ) is intended to send a command to the Wifly module itself, not to the remote end. With this it configures everything from security to baud rates.

Now, even after suggesting you not modify the WiflyInterface and Wifly code, I've done so. I had some challenges with blocking/non-blocking and performance. I have not extensively tested my code changes for backward compatibility, but you're welcome to take a look. I still faces some startup problems, but once "online" it seems pretty robust. From Smart-WiFly-WebServer you can drill in to the WiflyInterface and the Wifly class.