I've been seeing some conflicts with some other libraries which include the Arduino Pin Definitions (pins_arduino.h). After some backtracking the issues I found out that you actually define MOSI, MISO, SCK again which causes conflicts with other libraries.

I have changed _Spi.h to remove the defines and instead include pins_arduino.h and that has improved compatibility. Edit: The other thing that must be done is to use CS instead of SS in _Spi.cpp.

Also, this change should support for the Arduino Mega 2560, however, I don't own one to test on.

Another thing I was thinking about was a way to define the crystal frequency usage so that users of the library do not have to modify the library, the reason I don't like this is every time I pull the latest library my code no longer works because I have the older version of the shield. Anyone have any thoughts of how we could clean this up? It could be switched to a variable and add an overload to the WiFly.begin method which will allow us to change the crystal frequency, then when we update the library it will no longer silently fail.

Encryptic wrote:I've been seeing some conflicts with some other libraries which include the Arduino Pin Definitions (pins_arduino.h). After some backtracking the issues I found out that you actually define MOSI, MISO, SCK again which causes conflicts with other libraries.

I have changed _Spi.h to remove the defines and instead include pins_arduino.h and that has improved compatibility. Edit: The other thing that must be done is to use CS instead of SS in _Spi.cpp.

Great, thanks heaps for tracking that issue down. The moving of SPI defines to pins_arduino.h is a relatively recent change so that's probably how the issue cropped up. I've made a note of your changes and will work on incorporating them.

Another thing I was thinking about was a way to define the crystal frequency usage so that users of the library do not have to modify the library, the reason I don't like this is every time I pull the latest library my code no longer works because I have the older version of the shield. Anyone have any thoughts of how we could clean this up?

Backward compatibility is always going to be a bit of a pain. My current philosophy is to always have the latest release support the latest board revision "out of the box" so that people who buy a board today will have it work straight away. The hope is that people with the older boards will notice a new revision stops working and will read the README to work out what they need to change.

It could be switched to a variable and add an overload to the WiFly.begin method which will allow us to change the crystal frequency, then when we update the library it will no longer silently fail.

I was actually thinking about this the other day. There's a few issues that come into play:

a) I want to keep 'begin' as compatible with the Ethernet version as possible and don't want to expose implementation details in the initialisation stage. As an alternative we could have a separate method or property that enabled configuration. But...

b) Moving it into a sketch level change means it has to be set for every sketch and modification of the sketch is required when the board changes. I think this is undesirable. For most people (except those developing the library) keeping the configuration as a define will require the least changes.

c) In theory there might be some possibility for writing an "auto-detect" routine but I'm reluctant to code this up because it also seems like one more thing to go wrong in the name of backward compatibility.

I'm open to suggestions of a solution that will strike the right balance.

Encryptic wrote:I've been seeing some conflicts with some other libraries which include the Arduino Pin Definitions (pins_arduino.h). After some backtracking the issues I found out that you actually define MOSI, MISO, SCK again which causes conflicts with other libraries.

I have changed _Spi.h to remove the defines and instead include pins_arduino.h and that has improved compatibility. Edit: The other thing that must be done is to use CS instead of SS in _Spi.cpp.

Great, thanks heaps for tracking that issue down. The moving of SPI defines to pins_arduino.h is a relatively recent change so that's probably how the issue cropped up. I've made a note of your changes and will work on incorporating them.

Another thing I was thinking about was a way to define the crystal frequency usage so that users of the library do not have to modify the library, the reason I don't like this is every time I pull the latest library my code no longer works because I have the older version of the shield. Anyone have any thoughts of how we could clean this up?

Backward compatibility is always going to be a bit of a pain. My current philosophy is to always have the latest release support the latest board revision "out of the box" so that people who buy a board today will have it work straight away. The hope is that people with the older boards will notice a new revision stops working and will read the README to work out what they need to change.

It could be switched to a variable and add an overload to the WiFly.begin method which will allow us to change the crystal frequency, then when we update the library it will no longer silently fail.

I was actually thinking about this the other day. There's a few issues that come into play:

a) I want to keep 'begin' as compatible with the Ethernet version as possible and don't want to expose implementation details in the initialisation stage. As an alternative we could have a separate method or property that enabled configuration. But...

b) Moving it into a sketch level change means it has to be set for every sketch and modification of the sketch is required when the board changes. I think this is undesirable. For most people (except those developing the library) keeping the configuration as a define will require the least changes.

c) In theory there might be some possibility for writing an "auto-detect" routine but I'm reluctant to code this up because it also seems like one more thing to go wrong in the name of backward compatibility.

I'm open to suggestions of a solution that will strike the right balance.

Thanks again for your contribution toward the library.

--Philip;

What are your thoughts on the interface for adding support for the Ad-hoc mode to the library? Right now I've hacked it into my library but I use the begin method. Right now I've used an overload, so if you grabbed the library and an existing sketch, it will just act using the default logic. If you say WiFly.begin(true); it will use ad-hoc mode.

The more I think about this, I've been thinking it might be nice to instead move around support so that instead you would have a "create" method which would automatically use ad-hoc mode and join always be implied to join an existing network.

soelen wrote:how do I handle a post from a form field with the libary?

You'll need to learn how to send POST requests via the HTTP protocol. It's the same in any language. If you can change from a POST request to a GET request it is less complicated as you can just modify the URL to send the data.

Encryptic wrote:The more I think about this, I've been thinking it might be nice to instead move around support so that instead you would have a "create" method which would automatically use ad-hoc mode and join always be implied to join an existing network.

soelen wrote:The next question for me will be how to get the get variables? or at least the url string? I am imagine a WiFly libary method which gives me the url string somehow... something in this direction

Ah, I actually misunderstood your original question slightly. The WiFly library isn't intended to deal with the HTTP-level of things, only the network side of things.

You might want to look at something like webduino which I think is intended to make handling HTTP-level things easier. It's designed to work with the Ethernet library but "should" either work out of the box or with small modifications with the WiFly library.

Essentially, you'll want to read data using the client.read() method and parse it. You might find something like TextFinder handy. If you start by printing to the serial port the data that is transferred you'll see what you have to extract.

I only got some repeatly exit and $$$ commands from wifly for some reason, maybe I did something. Anyway I only can try that again this night so I am going to post in a half day again, showing success or... oh well~

Edit: Personally, it looks more like I have to rewrite the wiFly code library a lot to use webduino somehow, this is the moment which I show what a fool I am if we talk about programming haha

I try to save all what I get into a string and I want to regular express it, but it just doesnt work... not a matter what I try. Please give me the right direction how to analyze the get data. Here is the code:

I sent the board back to Sparkfun, where they evaluated it, and found it defective. In the interim, I purchased an Arduino Uno to continue this project. The new WiFly board came in the other day, but this is the first chance I've had to sit down and work with it.

I'm now working with two computers, both running Arduino v.21. My primary computer is running Windows 7, my secondary computer is running Windows XP. Both computers are using TeraTerm and Multi Terminal (available from Sourceforge.net). I'm trying the troubleshooting techniques with both systems.

The Arduino UNO board is being powered by an external power brick, to make sure that the board and shield are supplied with enough power.

The WiFly shield is plugged directly into the Arduino Uno.

I am now still trying to get the WiFly board into command mode. This time, whenever I hit any key, while in the TeraTerm (or Multi Terminal) terminal mode, the red activity light on the WiFly shield illuminates for a split second. However, I do not appear to be getting any characters back from the WiFly module other than the initial string:
WiFly Shield Terminal Routine
Bridge initialized successfully!

Attempting to enter the
$$$
command does not yield anything, unless I wait approximately 3-5 minutes. Then I get the following:

These characters seem to come whether I attempt to enter commands, or let the board just sit idle after boot up (I do not have to enter "$$$" to make the characters come up).
The characters seem to be consistent to the computer (The Windows 7 computer seems to output the same characters each time, and the Windows XP computer seems to output the same characters each time, but different characters than the Windows 7 computer). The characters look like the board is trying to send me a message, but at a different baud rate. However, the baud rate is correct for the initialization message.

The board activity lights: The yellow light is blinking at a rate of about two per second. It seems to mostly blink 15 times, and then stop. Occasionally it blinks 7 times and then stops. The Green light is blinking asynchronously with the yellow, at a slower rate. At the end of the yellow light cycle (the 15 or 7 times), the green light stays illuminated for a period, while the yellow light stays dark for a similar period.

I have trouble believing that I have two defective boards. I could almost believe that my last Arduino was damaged or old, or something. But I have a brand new Uno board.

Any thoughts? Any other information that I can provide to help figure things out, just mention it.

This certainly has the appearance of a baudrate issue with the module.

The characters look like the board is trying to send me a message, but at a different baud rate. However, the baud rate is correct for the initialization message.

The WiFly module itself does not sent the initialization message. The fact that the initialization message appears suggests that the connection to the SPI UART chip on the board is okay but there's some problem between it and the WiFly module.

Have you got back in touch with SparkFun technical support?

You could always try the hardware reset procedure for the WiFly module if you felt up to it. Or you could start by changing the baud rate specified in the SpiUart.h file of the library in case the WiFly module has just been configured at the incorrect rate.

Hey follower, thanks for the tip first, speaking of the ssid and possword ^^;

Indeed the textfinder was very helpful! First their were some error messages on textfinder but after your second suggestion using it I gave it anohter try and... it worked! I was able to read and to analyize the GET variables. Thanks a lot for your help, I am pretty sure I wouldnt come that far if you wouldnt helped me at all ^^ I really do appreciate that and I do not know how to thank back for now hehe...

Unfortunately I have now another problem

First you have to know that I am building a robot, i want to give commands wie GET how to move it. This is why I am using another shield for controlling the motors:

motor.run(FORWARD); // turn it on going forward
delay(1000); // wait one second
Serial.print("tock");
motor.run(BACKWARD); // the other way
delay(1000); // wait one second
Serial.print("tack");
motor.run(RELEASE); // stopped
delay(1000); // wait one second, repeat because it is in loop

motor.run(FORWARD); // nothing happened
delay(1000); //wait one second
Serial.println("something is written heere after a second");
Serial.print("tock");
motor.run(BACKWARD); // nothing happened
delay(1000); // wait one second
Serial.println("something is written heere after a second");
Serial.print("tack");
motor.run(RELEASE); // nothing happened
delay(1000); // wait one second
Serial.println("something is written heere after a second");
motor.run(FORWARD); // it moves forward, forever

Do you have any idea what the problem could be? I am all out of ideas again....