Page 4 of 7

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Nov 24, 2010 3:28 am
by soelen
@StaticDet5
Well no, but because I just started with arduino and I never tried c++ before. The functionality of my hardware were ok.

If you think your hardware / pins are for some reason broken, why dont you check continuity? Maybe you already did or it isnt such a helpful tipp after all... anyway here's an explanation how to check with a multimeter:

http://www.ladyada.net/learn/multimeter/continuity.html

Regards, Soelen

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Nov 24, 2010 5:26 pm
by follower
StaticDet5 wrote:Is the WiFly pin broken out on the shield? Looking at the schematics, I don't see where it is broken out. Heck, I can't even see the pins.
I don't understand what you mean by "is the WiFly pin broken out on the shield", could you please explain in more detail.
I haven't contact SFE tech support yet. I'm trying to exhaust the experts in the subject (You folks).
It's worth keeping them in the loop as they can do things we can't and may have additional information. :)
Are there any indicators on the actual WiFly board itself?
Indicators of what?
Honestly, have you folks have the experience that you plug the shield into the Arduino, and it just "works"?
Yes. :) I've got a number of WiFly boards I use for developing the WiFly library with and they all "just worked" (well, with the library written, at least :) ). (Although early on I did have one board which was the earliest revision stop working--seemingly something to do with SPI UART--but since then haven't had any problems with that.)

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Wed Nov 24, 2010 6:01 pm
by StaticDet5
My apologies for my horribly edited email.

Are there any indicators on the WiFly board itself (not the yellow, green, blue, and red on the shield)?

Is the WiFly board's reset pin broken out on the shield? It doesn't look like it on the schematic, and I can't see any way to get to it with the board mounted to the shield.

I'll compose a summary to SFE tech support after I perform continuity checks with my DMM. After the last board, I'm becoming an expert at that. :)

Thanks again, folks. Happy Thanksgiving to you all!

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Thu Nov 25, 2010 2:49 am
by soelen
You too staticdet5

But it seems like follower overlooked my post ^^;

viewtopic.php?p=114079#p114079

I'm not really good with c++ and of course I hope you know what I have to do!

regards, Soelen

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Mon Nov 29, 2010 3:21 pm
by pzgordon
Hi guys, I have a question about the WiFly shield, apologies if this is the wrong place to post, but this seemed like the most active WiFly related place.

I was wondering if it is possible to have the WiFly connect to a server through telnet or ssh?

What I would be hoping for it to do would be to connect to a laptop (macbook) and run a and launch an application.

Anyone able to shed any light on this?

Cheers,
Phil.

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Fri Dec 03, 2010 5:39 am
by follower
StaticDet5 wrote:Are there any indicators on the WiFly board itself (not the yellow, green, blue, and red on the shield)?
Ah, no, not as far as I know.
Is the WiFly board's reset pin broken out on the shield? It doesn't look like it on the schematic, and I can't see any way to get to it with the board mounted to the shield.
The most recent version breaks out the reset pin--there will be a date on the underside of the PCB if it's the latest version.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Fri Dec 03, 2010 5:41 am
by follower
pzgordon wrote:I was wondering if it is possible to have the WiFly connect to a server through telnet or ssh?
Through telnet, yes. Through SSH, probably not. (Unless you could port a SSH library to the AVR. :) )
What I would be hoping for it to do would be to connect to a laptop (macbook) and run a and launch an application.
You could also write a custom server that performed a similar task if you didn't want to use telnet.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Fri Dec 03, 2010 5:49 am
by follower
soelen wrote:if I remove WifLy.begin();, the motors are working again (the wifly of course not anymore)
...
Do you have any idea what the problem could be? I am all out of ideas again....
Looking at these, you might have a clash with the pins that are being used:

http://shieldlist.org/adafruit/motor

http://shieldlist.org/sparkfun/wifly

I haven't had any experience with the Motor Shield you have so I can't give you any specific advice. If you can't work it out you could try asking on the adafruit forums if it's possible to have both motor control and SPI operating at the same time.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Fri Dec 03, 2010 8:38 am
by StaticDet5
Quick update on my end.

I've performed continuity tests on the board, from the header pins to the chip pins. Those seem to be intact and correct.

I've sent a message to SFE tech support a couple of days ago. I'm hoping to hear from them today.

Still no joy getting any response from the WiFly itself.

I'll let you folks know what SFE says.

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Sat Dec 04, 2010 4:31 pm
by croyles
I have the same issues as the previous poster.

I have the WiFly Shield, plugged into the Arduino Uno.
I am using the default Arduino development environment.

I have tried to connect the WiFly using the Alpha Library WebClient, because the module does not support 64bit WEP, I am unable to associate to my O2 Access point, however, with an invalid combination of ssid and passkey, I get neither the "Association Failed" or "Connecting..." string, the code hangs when calling WiFly.join, which in turn locks up at line sendCommand("join ", true);
I am assuming this line is not returning, its waitForResponse("Listen on ") and never getting a response from the WiFly.

So I thought I would try the WiFly_Terminal, It loads fine, and the following is reported to the terminal.

WiFly Shield Terminal Routine
Bridge initialized successfully!

I can try typing anything, for example $$$, or CMD, with any combination of CR/LF, NL etc ... and I get no response from the WiFly. I cannot get it into command mode.

When I type something I get a very quick flash of the red led.
At all other times (other than reset or loading) the green led flashes constantly, and the yellow led flashes slightly slower.

Any advice on steps I can take to get this module into a command state?

I have the 14MHz clock, and have checked the code is configured for this.

Thanks

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Sat Dec 04, 2010 5:46 pm
by StaticDet5
Amigo!
It's so nice to know I'm not the only guy with this problem!

Please let me know if you get anywhere with this. I'll make a point of posting anything troubleshooting suggestions from SFE tech support

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Sat Dec 04, 2010 10:00 pm
by follower
croyles wrote:I have tried to connect the WiFly using the Alpha Library WebClient, because the module does not support 64bit WEP, I am unable to associate to my O2 Access point, however, with an invalid combination of ssid and passkey, I get neither the "Association Failed" or "Connecting..." string, the code hangs when calling WiFly.join, which in turn locks up at line sendCommand("join ", true);
I am assuming this line is not returning, its waitForResponse("Listen on ") and never getting a response from the WiFly.
The code to detect connection failure hasn't been written--the code is just hanging because it's not getting the expected response. If it gets as far as the join method call then I would think it is actually communicating with the module okay.

My suggestion is to remove the call to join entirely and just let the code fall through to the loop(). At that point you should be able to send commands directly from the serial console.

Also, to make things easier to track I suggest unpowering the Arduino and WiFly shield after uploading a sketch until you sort things out.

--Philip;

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Sun Dec 05, 2010 1:06 pm
by croyles
Wow, thanks for the fast response.

As a seperate check I used zterm (Mac) to access the Arduino, but that did not work either. $$$ resulted in nothing coming back. On a completely seperate topic, I found another WiFLy terminal test harness, but it uses stdio.h, which is not in my library list, or appears to be installed. Do I need to download this?
See http://www.youtube.com/watch?v=RhJK3Bd1oX4

@Static, if I make progress I will keep you posted.
@Philip, thanks for the quick response!
follower wrote: The code to detect connection failure hasn't been written--the code is just hanging because it's not getting the expected response. If it gets as far as the join method call then I would think it is actually communicating with the module okay.
Good point, if it does not receive the "Associated!" command its going to run until it get to EOM. Would that not return a false to :join() and fall through?
follower wrote: My suggestion is to remove the call to join entirely and just let the code fall through to the loop(). At that point you should be able to send commands directly from the serial console.
I will try this, its interesting you note this, as the module should be in 'command mode'. Does the module remain in command mode across reboots?
follower wrote: Also, to make things easier to track I suggest unpowering the Arduino and WiFly shield after uploading a sketch until you sort things out.
Sorry not sure what you mean by 'unpowered', it needs to be powered in order to send serial commands? Do you have suggestions on how to track this, I have been using simple Serial.print messages to debug, are there other approaches?

Thanks, Chris

Re: WiFly Shield code library alpha 1 release (also SPI UART)

Posted: Mon Dec 06, 2010 2:38 pm
by croyles
Update

I have successfully associated with a WiFi network (WPA) without modification to the library, it just worked. I have all examples pairing successfully.

All examples in the alpha library work as designed.

BUT

I am still unsuccessful in getting the WiFly into Command Mode outside of source code. The reason I want to get into command mode, is I want to extend the library so I can handle more 'get xxx' methods to understand more about the configuration. To do that I need to know what is returned 'verbose' from the WiFly so I can start coding the waitForResponse("<"); methods.

e.g. writing another WiFly::ip() method, that returns WiFly::everything(), if you see the logic.

Its not clear how the WiFly_Autoconnect_Terminal example functions?
Should this enable transparent serial comms to the WiFly in command mode?

I am looking for an example that puts the WiFly into Command mode, and then allows commands to be sent over Serial across to the WiFly, an the results to be printed into the Serial console. Preferably tested and working with the default Arduino SDK.

Thanks :)

Comments on Alpha 1 release

Posted: Wed Dec 08, 2010 8:14 am
by luwii
Just a couple of comments that might help others

I've also tried the Transparent Terminal sketch without much luck .. but the Alpha 1 driver set seems to work quite well! I used it with various Ethernet web server examples and it seem to work fine (in general).

I did however find various $$$ exit command repeated at the end of many web pages (I'm using it as a web server)

I manged to get rid of it by modifying void Client::stop() in Client.cpp

// _WiFly.switchToCommandMode(); // Commented this out and replaced it with the code below

delay(400);
_WiFly.uart.flush();
_WiFly.uart.print("$$$");
delay(400);

It came from the Roving Networks spec sheet where it indicates a 1 second delay before and after a $$$ is required to switch to command mode. For me 400ms worked fine. If you modify the subsections of of switchToCommandMode, more specifically WiFlyDevice::attemptSwitchToCommandMode() in WiFly.cpp then I don't seem to be able to connect to the WiFi network (Not too worried why)

Obviously this won't retry like the original code but you get the idea