SparkFun Forums

[yngveha]

Adding hardware flow control i have managed to push the baudrate up to 921600 using Arduino UNO together with the wifly shield (v2.23 wifly).
Note that since you cannot get this kind of throughput out using the serial monitor(115200 is max), it may be important that you don't send too much to the PC, so that the arduino doesn't choke on data.

I found that using the hardware factory reset tool in the wiflyshield framework to be useful before finishing the code, since it provides safe startup, regardless of previous configurations. (This is quite essential if you mess up with baudrates and the wireless communication at the same time..)

Here is what i believe is the essentials:

-- in spiUart.cpp:
SpiUartDevice::configureUart(unsigned long baudrate){
setBaudRate(baudrate); //Unchanged
writeRegister(LCR, 0xBF); // access EFR register - essential, but unchanged

writeRegister(EFR, 0xD0); /// enable enhanced registers and flow control - changed * **

writeRegister(LCR, SPI_Uart_config.DataFormat); // 8 data bit, 1 stop bit, no parity- essential, but unchanged
writeRegister(FCR, 0x06); // reset TXFIFO, reset RXFIFO, non FIFO mode - unchanged
writeRegister(FCR, 0x01); // enable FIFO mode -unchanged
}

* This does work regardless of the flow control in the wifly device, so it can always be this way.
** I am not sure why the original statement for EFR doesn't work : writeRegister(EFR, SPI_Uart_config.Flow);
but to me it clearly did not, as communication at 115200 went with some errors before i changed this,
while i was able to go all the way up to 916200 with this combined with uart flow control in the wifly.

-- in the modified hardware factory reset module:

#include "WiFly.h" //this will also include the spiUart.cpp since wifly.h has includes-- etc.

// Setting up a serial connection over USB is strictly not needed, but since i use the readResponse ill add this to make the code complete
Serial.begin(115200);

SpiSerial.begin(); // Connect to the spiserial, using 9600 baud

...
hardware reset stuff getting the wifly back to factory settings
...
// reboot wilfy
hardwareReboot();
readResponse(1000); // give the wifly 1000ms to settle after boot


SpiSerial.print("$$$"); // enter command mode
readResponse(300); // 300 ms should be enough time to settle *

SpiSerial.println("set uart b 921600"); // set baudrate
readResponse(1000); // 1 sec is good for reading if you also write to the serial monitor using the USB to PC connection.

SpiSerial.println("set uart flow 1"); // set flow control**
readResponse(1000);

SpiSerial.println("save"); // always save after changing
readResponse(1000);

hardwareReboot(); //perhaps this can be done w/o reboot if baud rates was set instantly

SpiSerial.begin(921600); // setting up the correct baud rate for the spi serial is essensial if you want to read whatever is coming after booting
readResponse(1000);

-- Now the wifly should start up with a valid baudrate of 921600.

* if you want to skip using a predefined time, you need to be able to predict and read what is coming
to ensure that all is read before attempting to give the next command. For me, i'm not relying on top
speed during configuration, this i'd rather wait (and read whatever is coming in a timeframe) since it is safer.

** setting flow control in the wifly is OK at all times but useless if you didn't do it on the Spi-Uart, likewise
setting flow control in the Spi-Uart is OK at all times, but useless if you don't do it in the wifly device.

EDIT:
Note that if you struggle using (an "old") arduino pro- i found that the board i thought was a 3.3V Device running at 8 MHz actually was running at 16MHz (powered by USB only)- which means that settings like the baudrate in fact was doubled. Selecting the correct device when programming will correct this, as will using half the baudrates for the SpiUart and the Uart (over USB) setting. If you find yourself mysteriously using half the expected baudrate, try switch device from 3 to 5 V in the programming interface..

[Carpetfilter]

I hate to bring up an old thread, but I have the same issue - I can't get the WiFly Shield running any faster than 9600 baud. I'm trying to use it as a client only.

I have tried everything mentioned by all of the posters here. None of it has worked for me. I'm using the WiFly shield (14 Mhz) with an Arduino Uno R2. I'm supplying it power through USB, but have also tried a DC power supply thinking that it might have been a problem of inadequate power.

I have firmware version 2.31, and the newest WiFly library (from Git).

My most recent attempt was to follow yngveha's advice two posts up. This resulted in the device apparently hanging at the WiFly.configure(WIFLY_BAUD, 115200); statement in my modified example (otherwise identical to the provided client example). I figured this was where it was hanging, since there is a Serial.println just below, and this is never echoed to the serial monitor.

I'm connecting to an open network, and at 9600 this works fine, and I can retrieve the content of web pages with no issues. But I really want to get this working at, at least, 38400 baud.

The posts here suggest that it should be as easy as sending commands to the UART either by running the HardwareFactoryReset or SpiUartTerminal programs and issuing a SET uart baud xxxxx command, saving, and rebooting the device. Then altering the WiFly.configure(WIFLY_BAUD, xxxxx); command to agree with the chosen baud. I was able to successfully issue these commands and restart the unit, but this did not work.

Any ideas?

[Carpetfilter]

I solved my problem.

The high speed example in the newest code (as of June 28, 2012) doesn't work for me because it doesn't seem to set the baud rate for the SpiUart - it only sets the baud rate for the WiFly. To overcome this, I made the following change to SpiUart.h:

Code: Select all

#define BAUD_RATE_DEFAULT 115200 // WiFly default baudrate

This constant sets the SpiUart baud rate. There seems to be a way to set it on the fly by calling SpiSerial.begin(unsigned long baudrate), but I am unsure when is the most appropriate time to do this. So I changed the constant instead. This works for my purposes, but is suboptimal.

Once I did this, it worked nicely. I'm still confused why this was necessary, since I thought that issuing a "SET UART BAUD xxxxx" command took care of this. With this change working, it means I've had to set my chosen baud rate in three places. Not ideal, but if it works it works.