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

[StaticDet5]

Minicom appears to be unix only. I have a linux system, but I’d be jumping another order of complexity if I bring a third machine into this mix.

I’m getting Serial Prints from the Arduino:

WiFly Shield Terminal Routine

and

WiFly Shield Terminal Routine

Bridge initialized successfully!

But I’m getting no other Serial Communication after that.

The arduino isn’t locked up. I’ve been able to create “noise” on the line by hooking pins up to the shield headers, which is giving me bizarre characters on the terminal. So it’s not that the arduino isn’t reporting information, it’s that no information is being sent to the arduino.

Thanks

[LMas]

Hi StaticDet5 sorry for my english

, but if i understand right you using arduino program to enter commands?

if yes it will not work get yourself UTF-8 TeraTerm Pro http://jaist.dl.sourceforge.jp/ttssh2/4 … m-4.67.exe <i think is this one see if it will help

P.S. use CONTROL>BROADCAST COMMAND for entering $$$ you might need to uncheck ENTER KEY selection then try to check it and use any other command from roming networks database i needed to do factoryRESET and save it before i could use a Transparent Terminal Sketch and then other ones. Hope it will help.

By the way i am using Windows 7 and xp .

[StaticDet5]

I’ve tried using:

TeraTerm

Multi Terminal (from Source Forge)

Arduino Serial Monitor

None of these are producing any results. On the off chance that the WiFly is getting my commands, I’ve tried the factory RESET command. Still no communication from the board.

Thanks

[LMas]

StaticDet5:
I’ve tried using:

TeraTerm

Multi Terminal (from Source Forge)

Arduino Serial Monitor

None of these are producing any results. On the off chance that the WiFly is getting my commands, I’ve tried the factory RESET command. Still no communication from the board.

Thanks

did you tryed pro tetraterm with ENTER KEY checked off?

Add me on SKype if you using it name lmasss

[follower]

StaticDet5:
On the off chance that the WiFly is getting my commands, I’ve tried the factory RESET command.

I seem to recall people who having issues with a non-responsive unit had the problem solved by doing that, so it's unfortunate that had no effect.

Given what you’ve tried, unless we’re missing something really obvious it sounds like it might be a hardware issue. My final two suggestions:

- If you feel up to it, you could try the hardware-based factory reset (instead of the software one you've already tried).

- Get back in touch with tech support and let them know you've still had no success.

–Philip;

[StaticDet5]

Spark Fun has been pretty helpful in keeping me sane. They’re a little slower than you folks to respond (which is probably good, all around), but they also been giving me ideas to try.

They’re going to take a look at the board as well, and see if it’s the board. I’ll let folks know what the issue was, once they get back in touch with me.

Thanks everyone!

[racine_20]

follower:

racine_20:
Could you implement most functions to use Wifly with UDP protocol for the next release please ?

Existant functions are for TCP protocol …

Did you have anything specific in mind? And do you know if the WiFly module is capable of it?

Another idea if you want, Try to use another method for getting IP and other parameters from Wifly , because, to use parsed *char is very very slow …

Can you please explain this request further?

Thanks for your feedback.

–Philip;

Hi Philip,

Thx for your support,

About UDP proto, yes wifly module is totally capable … In my mind, I propose to create functions for sending, receiving UDP packet just simply. This protocol haven’t need to create a directly connection with client, because it’s a connection less protocol.

About method, such as “Get IP”, your method is to fetch the result of wifly command “get wlan ip”, char by char. And this method is very very slow, try to measure the time taken by your method, You will see what I mean. Can you just call ip (or another data) directly in register of wifly module ?

Thx Philip,

– Ben

[follower]

Hi Ben…

racine_20:
About UDP proto, yes wifly module is totally capable

I discovered after reading your post that the user manual has been updated with the details about this–I must’ve missed that revision.

I propose to create functions for sending, receiving UDP packet just simply.

From looking at the documentation it seems like the data is just feed into/read from the UART so there might be some issues with being able to detect when packets end etc. I don’t anticipate getting the time to work on this functionality in the near future but feel free to work on it yourself.

About method, such as “Get IP”, your method is to fetch the result of wifly command “get wlan ip”, char by char. And this method is very very slow, try to measure the time taken by your method,

By my timing it takes about half a second. Is this what you mean by slow?

Can you just call ip (or another data) directly in register of wifly module ?

Unfortunately all the interaction with the WiFly module is via the serial interface–there’s no direct register communication. If you are running version 2.19 or later of the firmware you might be able to change the code to use the “get ip a” which sends less data. Increasing the serial speed might help too (not yet fully supported). But if half a second is too slow I don’t anticipate those approaches being that much faster.

–Philip;

[racine_20]

Plop,

I discovered after reading your post that the user manual has been updated with the details about this–I must’ve missed that revision.

It's no big deal ;)

it seems like the data is just feed into/read from the UART so there might be some issues with being able to detect when packets end etc.

Ok with this, but it hasn't solution to make easier the use of udp proto ? damn :)

I will try to enhanced my skill about UART R/W , I am beginner about this kind of plateform

By my timing it takes about half a second. Is this what you mean by slow?

Definitively, Yes !! :) Especially just for one "data". But the main cause come from the only serial interface, definitively !

I waiting your next release with impatience

Thx for your great contribution Philip !

– Ben

[leccmo]

Hi,

I am trying to load data from server to Arduino as client with Wifly and keep updating but it always crushes after some minutes. The length of time until crashing is really random. Does anyone know why it causes or any solution for it? I am stacking it for few weeks and couldn’t find a solution yet If anybody can help me out I really appreciate it.

Here is the code:

#include "WiFly.h"
#include "Credentials.h"

byte server[] = { 66, 249, 89, 104 }; // Google
Client client(server, 80);

void setup() {
  Serial.begin(9600);
  WiFly.begin();

  if (!WiFly.join(ssid, passphrase)) {
    Serial.println("Association failed.");
    while (1) {
      // Hang on failure.
    }
  }  

  Serial.println("connecting...");
  update();
}


int updateCounter=0;

void update(){
  
  client.flush();
  Serial.flush();
  Serial.println();
  Serial.println("updating...");
 
 //*****it will crushe here******//
  
  if (client.connect()){
    Serial.println();
    Serial.println("connected!");
    updateCounter++;
    Serial.print(updateCounter);
    Serial.println(" times");
    Serial.println();
    
    client.println("GET /notFound HTTP/1.0"); //getting Not Found page
    client.println();
  }
  else{
    Serial.println("connection failed");
  }
}


void loop() {
  if (client.available()) {
    char c = client.read();
    Serial.print(c);
    }
 
  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    client.stop();
    update();
  }
}

Thanks advance

[Encryptic]

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.

[follower]

Hi Encryptic,

Thanks for your post.

Encryptic:
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;

[Encryptic]

follower:
Hi Encryptic,

Thanks for your post.

Encryptic:
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?

[soelen]

Hello,

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

<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

String valuefromInputField = _POST['testField'];

regards, Soelen

[follower]

soelen:
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]

Encryptic:
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:

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;

[soelen]

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:

http://img600.imageshack.us/img600/3553/analog.jpg

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

http://img340.imageshack.us/img340/6831 … nnt1gb.png

<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

String urlString = WiFly.getURL();

regards, Soelen

[follower]

soelen:
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;](http://www.arduino.cc/playground/Code/TextFinder)](Google Code Archive - Long-term storage for Google Code Project Hosting.)

[soelen]

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:

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

[soelen]

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

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:

#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