SparkFun Forums

[mattyjon70]

Hi Forum,
ive got the Alpha 1 release of the Wifly Shield Library.
Ive also got the Wifly with the 14MHZ xtal and Wifly model RN-131G.
The changelog going back to August sais....

.............................................................................................................
* Added ability to set baud rate at runtime in SpiUart class.
(Note: This ability to change the baudrate has not yet been propagated
to the WiFly class.)
..............................................................................................................


I am trying to get the baudrate up from 9600.
Ive changed ....
#define BAUD_RATE_DEFAULT 9600 // WiFly default baudrate

to

#define BAUD_RATE_DEFAULT 38400 // WiFly default baudrate

but i cant get past Wifly.begin();
I guess its held up because i think im stuck in initUart.

Ive tried setting the baudrate after initUart but still no success.

If anyone has been able to up the baudrate any pointers would be great

thanks
Matt

[follower]

Hi...

ive got the Alpha 1 release of the Wifly Shield Library.

Note that the latest release version is now Alpha 2.

If anyone has been able to up the baudrate any pointers would be great

If you feel like using the version of the code that is in the WiFly source repository the functionality for changing the baud rate has been committed there but not yet released.

Note that AFAICT at the moment only 19200 results in a useful improvement. You'll need to edit any example you use to include this line after the network has been joined:

Code: Select all

WiFly.configure(WIFLY_BAUD, 19200);

Don't forget to also change your serial console speed.

--Philip;

P.S. It's best practice to mention the product in the subject of your post--I almost missed this because I couldn't tell from the subject that it was WiFly related.

[mattyjon70]

Thanks Phillip, i grabbed the latest code but can can only get to 57600.
Basically i'm getting data in via a USB Shield and wanting to shovel that out
via the Wifly. At the moment im getting about 130K of data at a rate of about 1HZ
and i'd would like to send that out over the Wifly at the same rate. Its taking about 30 secs
which is to long for me.

I read somewhere that BUlk Transfers are not being used yet. I wonder how far away that is
and if it will help my situation.

Why do i have to change my serial console speed ?
Currently its 115200.

thanks

[mattyjon70]

Hi Phillip,
can you please tell me why i have to adjust my serial console speed ?

Ive always had it at 115,200. Any ive still been able to use the Wifly at
anything up to 57600 without a problem. Cant get Wifly working at 115,200 though.
FYI i'm using the USB Shield and the Wifly on Top of an Arduino Uno.
Ive changed the CS pin for the Wifly shield to pin 6.(const static uint8_t SS = 6;)
in "pins_arduino.h"
All works well.

I would really like to have the Bulk Transfer working for the Wifly Shield.
Ive tried playing with that section of code and i can get it to work
by checking that the output buffer is empty before i send any data
but i know this is slow from comments in your code.
Obviously some more dynamic way of seeing whats free in the output
buffer and then filling only that would be better.
When i enable Bulk Transfers i do get a noticeable speed increase even with .....

Code: Select all

void SpiUartDevice::write(const uint8_t *buffer, size_t size) {
   while (readRegister(TXLVL) < 64) {
   // Wait for empty TX buffer (slow)
    //(But apparently still not slow enough to ensure delivery.)
};
select();
transfer(THR); // TODO: Change this when we modify register addresses? (Even though it's 0x00.) 
while(size > 64)
  {
    transfer_bulk(buffer, 64);
    size -= 64;
    buffer += 64;
  }
transfer_bulk(buffer, size);
deselect();
}

Without the Bulk Transfer and at 57600 with the Wifly it takes about 30 secs to send a 130K jpg file.
With Bulk Transfer and the code above at 57600 it takes only 10 seconds.

Any advice how how to get the speed up or get the bulk transfer working better would be good.

A little more info on my application...
Canon500d Camera to USB Host Shield.
Arduino Uno serving up webpage to control the camera and show live view stream to anything on Wifi with a browser via Ad-hoc connection.(thanks to your client server code).
I'm using an iPad or my iPhone with Safari.


--Matt

[follower]

Thanks Phillip, i grabbed the latest code but can can only get to 57600.

Try the latest code from the GitHub repository, I've increased the clock speed used for SPI communication so that should improve things.

Basically i'm getting data in via a USB Shield and wanting to shovel that outvia the Wifly.

Ah, okay, my previous feedback assumed you were using the WiFly to download data not upload it. Also, it wasn't clear until your later post that you meant the USB Host Shield.

At the moment im getting about 130K of data at a rate of about 1HZ and i'd would like to send that out over the Wifly at the same rate. Its taking about 30 secs which is to long for me.

Try out the new code to see if that improves things for you. It allowed me to double the download speed I was getting but I don't know how it will affect upload.

Why do i have to change my serial console speed ? Currently its 115200.

That suggestion was if you were using it for downloading.

I would really like to have the Bulk Transfer working for the Wifly Shield.
Ive tried playing with that section of code and i can get it to work
by checking that the output buffer is empty before i send any data
but i know this is slow from comments in your code. Obviously some more dynamic way of seeing whats free in the output
buffer and then filling only that would be better.

The current code is slow because it waits until the buffer is completely empty, you could modify the bulk transfer code so that it checks to see how much is available and then sending that amount.

Without the Bulk Transfer and at 57600 with the Wifly it takes about 30 secs to send a 130K jpg file.
With Bulk Transfer and the code above at 57600 it takes only 10 seconds.

The risk with not implementing bulk transfer correctly is that you may drop data.

Try out the new code with the higher clock speed and see if that works well enough without requiring bulk transfer.

--Philip;

[mattyjon70]

Hi Phillip,
thanks for the response.
With that new code i can go up to 115200.
Speed is improved in sending from the wifly by about 10% only.
A problem introduced now is that anytime i use a browser to request from the Wifly im having to request twice. Its not picking up the first request. Every single time i request i can see the RXTX light on the wifly light up but the "server.available();" doesn't seem to be seeing it.
my loop is ....

Code: Select all

void loop()
{
  Client client = server.available();
  if (client)
  {
    ...... blah blah etc

There weren't any noticeable problems with the USB Shield now you
have increased the SPI speed.
As you may remember im using Arduino pin 6 for the Wifly CS and Arduino Pin 10 for the USB CS. MOSI, MISO and SCK pins are shared.

Ive also played around with the the Wifly's comm size and comm time
to see if that makes a difference.

Code: Select all

sendCommand("set comm size 512");
sendCommand("set comm time 1000"); 

Whilst it changes the way packets are sent it doesnt seem to have any affect on how fast the data is received totally from the Wifly at the browser. As expected if the comm size is small the TXRX light
looks to be on continuously. If i increase the size to 512 as above
i can see the light flash slower and thats because the packets are larger.

As for not using Bulk Transfers i could not get it to run at all without bulk transfers at 115200.

Any thoughts before i go back to the slower speed and have a crack
at better Bulk Transfer code to monitor the buffer ?

thanks again
--Matt

[mattyjon70]

Hi Phillip,
a little more investigation.
So i modified your bulk transfer method...

Code: Select all

void SpiUartDevice::write(const uint8_t *buffer, size_t size)
{
	//How many spaces free in the buffer ?
	uint8_t bytesFree = readRegister(TXLVL);
 	bool b = true;
	while(b)
	{
		select();
		transfer(THR); // TODO: Change this when we modify register addresses? (Even though it's 0x00.) 
	
		if(size <= bytesFree)
		{	//Data will fit into buffer space so just send and return
			transfer_bulk(buffer, size);
			deselect();
			break;
		}
		else
		{	//More Data than buffer spaces
			if(bytesFree >=1)
			{	//Send up to free spaces
				transfer_bulk(buffer, bytesFree);
				buffer += bytesFree;
				size -= bytesFree;
				if(size == 0)
				{	//No more data to send so return
					deselect();
					break;
				}
			}
		
		}
		deselect();	
		bytesFree = readRegister(TXLVL);
	}
 }

And i'm another 10-15% faster.
I'm not sure if the codes the best but at least i see a performance increase.

I'm still miffed as to why i have to make my http requests to the Wifly from my browser twice.
The first request after power-up seems to work on the first go.
But anymore requests after that i have to send them twice from the browser.

I wonder if it's something in Server::available() ?
I also wonder if this issue is related to the fact i cant go above 115200.
The Wifly module configures correctly at higher baud rates than that and responds so i can only assume
the Server class and specifically Server::available() maybe adding another problem.
Does the wifly capture requests and hold them for Server::available to pickup when called ?
I'm only calling Server::available() every 400mS or so when i'm not responding to a request and sending a jpg etc.



thanks again

--Matt

[follower]

Hi Matt..

A problem introduced now is that anytime i use a browser to request from the Wifly im having to request twice. Its not picking up the first request. Every single time i request i can see the RXTX light on the wifly light up but the "server.available();" doesn't seem to be seeing it.

Hmm, odd. You could try enabling the debugging code which logs some of the functions used to see where it's missing the request. Has this issue only occurred since you updated to the repository version of the code?

Be aware that the debugging code alters the timing of the code which can change its behaviour.

Ive also played around with the the Wifly's comm size and comm time
to see if that makes a difference.

FWIW, from what I've read in the user guide the module should automatically modify those values when you change the baud rate.

I'm not sure if the codes the best but at least i see a performance increase.

Other than a couple of stylistic issues that seems like a reasonable approach.

Does the wifly capture requests and hold them for Server::available to pickup when called ?

Underneath it's all just a stream of serial data from the WiFly module--in theory the hardware flow control should prevent data loss.

I'm only calling Server::available() every 400mS or so when i'm not responding to a request and sending a jpg etc.

I wouldn't have thought that would be an issue.

My suggestion is to enable the debug code and see if you can see where the failure occurs. I would guess either the request data isn't getting received or it's not getting parsed correctly.

--Philip;

[mattyjon70]

Hi Phillip,
iv'e spent quite a bit of time trying to nail this down.
Before i post what i believe will help, have you noticed that querying the baud rate after an instant baud rate
change does not report the new baudrate ? This is not just immediately after but any time after.
ie: "get uart" is returning 9600 even though i'm sure i'm at 115200 or even higher.
Initially i thought that i wasn't actually changing the baudrate successfully but i must be because if i don't re-initialize
my SPI baudrate after the "instant" change i just get garbled chars.

--Matt

[follower]

Before i post what i believe will help, have you noticed that querying the baud rate after an instant baud rate
change does not report the new baudrate ? This is not just immediately after but any time after.
ie: "get uart" is returning 9600 even though i'm sure i'm at 115200 or even higher.

Yeah, I think I've noticed this in the past. I assume it's because the value returned from the "get uart" query is the value which is stored, not the current "instant" value. AFAICT there's no way to determine what the current "instant" baudrate value is.

--Philip;