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

All things pertaining to wireless and RF links

Moderator: phalanx

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

Postby Encryptic » Mon Nov 08, 2010 9:22 pm

Hello,

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.

I've updated my [very experimental] library here to include these changes: https://github.com/Encryptic/WiFly-Library

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
 
Posts: 37
Joined: Mon Sep 10, 2007 6:46 am
Location: Concord, NH

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

Postby follower » Wed Nov 10, 2010 7:51 am

Hi Encryptic,

Thanks for your post.

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;
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby Encryptic » Wed Nov 10, 2010 4:05 pm

follower wrote:Hi Encryptic,

Thanks for your post.

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.

Any ideas what you envision the interface being for this?
Encryptic
 
Posts: 37
Joined: Mon Sep 10, 2007 6:46 am
Location: Concord, NH

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

Postby soelen » Thu Nov 11, 2010 3:24 am

Hello,

how do I handle a post from a form field with the libary? I want to do something like

Code: Select all
<form method="post" action="">
<input type="text" name="testField" value="babyFace">
<input type="submit" value="gogopowerrangers">
</form>

And save the value in testField in a varialbe like
Code: Select all
String valuefromInputField = _POST['testField'];

regards, Soelen
User avatar
soelen
 
Posts: 9
Joined: Wed Nov 10, 2010 2:14 pm

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

Postby follower » Thu Nov 11, 2010 6:17 am

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.

--Philip;
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby follower » Thu Nov 11, 2010 6:27 am

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.

Any ideas what you envision the interface being for this?
Yeah, what you suggest sounds good. So, something like:

Code: Select all
WiFly.create(channel, "ssid", "passphrase")

Although at the moment passphrases aren't actually supported by the module, so that would be optional.

The fact that the module apparently needs to be rebooted to enter adhoc mode is a bit of a pain and may complicate things a little.

--Philip;
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby soelen » Thu Nov 11, 2010 6:40 am

hello follower thanks a lot for the post,

I know how to use post or get more or less heh... anyway suggesting sending the variable by get leads to the same problem which I have to face, sadly D:

for example, if my wifly is associated with the ip 192.168.22.21 and if I use the webserver example, I am getting following render result by requesting this ip:

Image

Next step I am going to edit the webserver example and insert a formfield with the GET method

Image
Code: Select all
<h1>TestServer</h1>
<form method="get" action="">
<input type="text" name="testField" value="babyFace">
<input type="submit" value="Submit">
</form>


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

Code: Select all
String urlString = WiFly.getURL();


regards, Soelen
Image
User avatar
soelen
 
Posts: 9
Joined: Wed Nov 10, 2010 2:14 pm

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

Postby follower » Thu Nov 11, 2010 9:15 pm

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.

--Philip;
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby soelen » Fri Nov 12, 2010 2:42 am

I do not understood clearly if you suggesting to use client.read() in combination with webduino or just looping client.read()~

in case of looping, I tried to do this into the loop function of arduino:

Code: Select all
String wholeReadIn;
void loop()
{
wholeReadIn = wholeReadIn + client.read();
}

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
Image
User avatar
soelen
 
Posts: 9
Joined: Wed Nov 10, 2010 2:14 pm

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

Postby soelen » Fri Nov 19, 2010 1:41 pm

After lots of testing I almost giving up. I finally get the HTTP header and see the get by serial.print it thank you your autoconnect terminal example. This is what I get
Code: Select all
WiFly Shield Terminal Routine
Associated!
192.168.178.21

exit

EXIT
END DATA
*OPEN*GET / HTTP/1.1
Host: 192.168.178.21
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0

END DATA
*CLOS*END DATA

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:
Code: Select all
#include "WiFly.h"
String myString;
byte myByte;
#include "Credentials.h"
String realData;
boolean dataReceiving = false;
int dataCounter = 0;

void setup() {

  Serial.begin(9600);
  Serial.println("\n\r\n\rWiFly Shield Terminal Routine");
 
  WiFly.begin();
 
  if (!WiFly.join("ssid", "password")) {
    Serial.println("Association failed.");
    while (1) {
      Serial.println("what!");
     
    }
  }
 
  Serial.println("Associated!");
   Serial.println(WiFly.ip());
}
void loop() {
   
   while(SpiSerial.available() > 0) {
      dataReceiving = true;
      myByte = SpiSerial.read();
      myString = myByte;
      Serial.print(myString);
      dataCounter = 0;
   }
   if (dataReceiving == true) {
      dataCounter = dataCounter + 1;
   }
   if (dataCounter >= 200) {
      
      Serial.println("END DATA");
      dataReceiving = false;
      dataCounter = 0;
   }
}


regards, soelen
Last edited by soelen on Sat Nov 20, 2010 3:06 pm, edited 1 time in total.
Image
User avatar
soelen
 
Posts: 9
Joined: Wed Nov 10, 2010 2:14 pm

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

Postby follower » Sat Nov 20, 2010 8:59 am

soelen wrote:
Code: Select all
GET / HTTP/1.1
This is the line you want to extract. (Except when you send the form it will look different.)

I try to save all what I get into a string and I want to regular express it, but it just doesnt work...

You don't have regular expressions on the Arduino but you might want to look at the TextFinder library which can be helpful.

--Philip;

P.S. You might want to delete your Wireless SSID and password from your post too. :)
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby StaticDet5 » Sun Nov 21, 2010 2:49 pm

I'm back!

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:

WiFly Shield Terminal Routine
Bridge initialized successfully!
¯—7hnñ1i±æ1Î^'.g.@îg—a®1Î`g‡×¶ ‡± ÈG7Þyg9`gNÎg7vng9f7Ïn7®0Áÿ

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.

Thanks
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

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

Postby follower » Sun Nov 21, 2010 11:12 pm

StaticDet5 wrote:I sent the board back to Sparkfun, where they evaluated it, and found it defective.
Was there any further detail given on the defect?

I'm now working with two computers, both running Arduino v.21.
Assuming it's configured correctly, using the Arduino IDE Serial Monitor should be enough for your tests.

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.
Does it make any difference if you use the external brick or not? It shouldn't be necessary.

Code: Select all
¯—7hnñ1i±æ1Î^'.g.@îg—a®1Î`g‡×¶ ‡± ÈG7Þyg9`gNÎg7vng9f7Ïn7®0Áÿ
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.

--Philip;
follower
 
Posts: 280
Joined: Sun Mar 14, 2010 11:58 pm

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

Postby soelen » Mon Nov 22, 2010 2:39 pm

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:

http://www.ladyada.net/make/mshield/use.html

with this shield, it is pretty easy to control the motors like that:

Code: Select all
 
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


Now I have the problem that delay is not working anymore after using

Code: Select all
WiFly.begin();

if I remove WifLy.begin();, the motors are working again (the wifly of course not anymore)

so this is what happened with the wifly on it:

Code: Select all
 
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....

regards, Soelen
Image
User avatar
soelen
 
Posts: 9
Joined: Wed Nov 10, 2010 2:14 pm

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

Postby StaticDet5 » Tue Nov 23, 2010 2:19 pm

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 tried modifying the code like you suggested, but the board kept hanging.

Just to be thorough, I tried taking the shield off the arduino, just to see what would happen.
Exactly as expected, the Serial Monitor shows that the bridge can't be initialized.

I haven't contact SFE tech support yet. I'm trying to exhaust the experts in the subject (You folks).

Are there any indicators on the actual WiFly board itself?

Honestly, have you folks have the experience that you plug the shield into the Arduino, and it just "works"?
Static
StaticDet5
 
Posts: 205
Joined: Tue Oct 12, 2010 8:08 am

PreviousNext

Return to Wireless/RF

Who is online

Users browsing this forum: No registered users and 2 guests