I am trying to configure the SPI - UART baud rate to something above 9600.
struct SPI_UART_cfg SPI_Uart_config = {
0x50,0x00,0x03,0x10};
Doing the math with the crystal that is being used I cant come up with much. I tried using
struct SPI_UART_cfg SPI_Uart_config = {
0x20,0x00,0x03,0x10};
To get 38400 and even that is unreliable.
Am I missing something or does anyone have any suggestions?
Robert Mann:
I am trying to configure the SPI - UART baud rate to something above 9600.struct SPI_UART_cfg SPI_Uart_config = {
0x50,0x00,0x03,0x10};
Doing the math with the crystal that is being used I cant come up with much.
I used Python to save using my brain based on the formula on page 17 of the SPI UART data sheet.
To calculate the original value (for 9600) I got this:
>>> hex((12288000/1)/(9600*16))
'0x50'
I got the following divisor value for 38400:struct SPI_UART_cfg SPI_Uart_config = {
0x20,0x00,0x03,0x10};
To get 38400 and even that is unreliable.
hex((12288000/1)/(38400*16))
'0x14'
How did you reach your value?
Assuming the value is correct I assume (but haven't confirmed) that you also need to change the WiFly's baud rate--and I assume you have to do this before changing the SPI-UART baud rate.Am I missing something or does anyone have any suggestions?
–Philip;
Doing the math you are correct. I have tried it that way and still no luck. I get stable results at 9600 baud only. It works at 38400 with some minor errors but there should be no errors.
Doing the math I can not find any other solid numbers using that crystal combination other than 9600 and 38400. Am I doing something wrong here? Am I missing a chance to preload something?
Anyone been able to get the WiFly shield to operate above 9600 communicating with the SPI to UART bridge?
If so can you share your numbers or a part of your code that sets up the configuration?
follower:
Robert Mann:
I am trying to configure the SPI - UART baud rate to something above 9600.struct SPI_UART_cfg SPI_Uart_config = {
0x50,0x00,0x03,0x10};
Doing the math with the crystal that is being used I cant come up with much.
I used Python to save using my brain based on the formula on page 17 of the SPI UART data sheet.
To calculate the original value (for 9600) I got this:
>>> hex((12288000/1)/(9600*16))
‘0x50’
<QUOTE> > struct SPI_UART_cfg SPI_Uart_config = { > > 0x20,0x00,0x03,0x10}; > > > > To get 38400 and even that is unreliable. </QUOTE> I got the following divisor value for 38400:hex((12288000/1)/(38400*16))
‘0x14’How did you reach your value? <QUOTE> > Am I missing something or does anyone have any suggestions? </QUOTE> Assuming the value is correct I assume (but haven't confirmed) that you also need to change the WiFly's baud rate--and I assume you have to do this before changing the SPI-UART baud rate. --Philip;
When you say "minor errors" do you mean corrupted characters or do you mean missing characters?Robert Mann:
Doing the math you are correct. I have tried it that way and still no luck. I get stable results at 9600 baud only. It works at 38400 with some minor errors but there should be no errors.
If the problem is missing characters then the issue at 38400 baud may be related to the need for hardware flow control. The alpha 0 release of the WiFly library implements hardware flow control but the tutorial example doesn’t.
I have been working on adding baud rate support to the SPI UART library that is part of the WiFly library and have encountered the same issue (corrupted characters) you did at speeds other than 9600 and 38400.
I have made contact with the engineer who designed the board and will update you when I find out more.
Thanks for your report–I was grateful that I didn’t spend some confused hours discovering it myself! (Which I realise is little consolation. 
)
–Philip;
(Whoops, I should have added "assuming I don't completely forget to post a followup", sorry!)follower:
I have made contact with the engineer who designed the board and will update you when I find out more.
So, I have talked to the engineer and we can confirm that the current revision of the WiFly and SPI-UART breakout can only communicate reliably at 9600 and 38400 due to the crystal used.
–Philip;
Wait, really? Has this changed in the last few months? I kind of need to push much higher than that for what I have in mind. Any chance it will ever be able to do somewhere in the ballpark of 0.25 Mbaud? I really hope that’s possible. 
Yes, this has changed recently with a different crystal (~14MHz) now used.bswift5528:
Has this changed in the last few months?
I think in theory the SPI-UART connection should now be able to support ~900 kilo-bits per second but I've not tested actual throughput. I'm also not sure what overhead the library adds at the moment. I'm also not sure what other factors will limit the throughput.Any chance it will ever be able to do somewhere in the ballpark of 0.25 Mbaud?
–Philip;
This is just an “FYI” post, sort-of (not really) related to this thread.
I recently had trouble with my WiFly where it would not join a wireless network (from DD-WRT on a WRT54-GL set as WPA2, AES+TKIP) very near by. The strange part was that I had successfully joined this exact network a number of times before, but it no longer would connect.
After I told it to “join open” (the name of my WPA2 protected network is, ironically, “open”), it would say something like:
<2.19> join open
Auto-Assoc open chan=3 mode=MIXED SCAN OK
Joining open now..
<2.19> Associated!
DHCP: Start
[NULL]WiFly Ver 2.19, 04-12-2010
MAC Addr=00:06:66:xx:xx:xx
*READY*
In other words, as soon as it would start DHCP, the unit would reboot. I first thought it was a power supply issue and tried giving a better supply (rather than running off the power from an FPGA dev board), but to no avail.
Eventually I figured out the problem was only occurring when the rate was set to 0 (1Mb/s). When I reset the rate to 12 (24Mb/s), which is the default, the unit had no problem joining and would no longer reboot on DHCP Start. I have no idea why rate “0” doesn’t work and I don’t know if it’s an issue with my router, the router firmware, or the WiFly itself, but maybe I’m not the only one with this problem. Hopefully Google helps someone with the same problem find this post
Returning to the main topic of this thread: Baud Issues with with the WiFly Shield.
I have not any success in getting the SPI-UART baud rate above 9600. I’ve modified the “SpiUartTerminal” example to function as a simple test program but every time I use another baud rate above 9600 - failure. My WiFly board is a recent one so it is using the 14Mhz crystal.
Can anyone verify success in getting the SPI-UART baud rate above 9600 and what is the highest reliable speed?
Thanks, Ronan
I’ve been digging through the code of the WiFly_Terminal program, as well as the WiFly library. I think Follower makes a good point above that might have been missed.
It seems to be to function at higher than default rates, the higher baud rate needs to be set both at the SC16IS750 SPI-to-UART bridge AND in the WiFly module itself.
If a different baud rate needs to be set both in the SC16IS750 and the WiFly, it would need to be set first in the WiFly, communicating with the 750 at the 9600 default, using the “set uart baud” or “set uart instant” command. If you set a higher rate first in the 750, you probably couldn’t even access the WiFly at that point, or the data would come out scrambled.
(Of course, the SPI interface clock from the Arduino needs to be set at a faster rate, too, to take advantage of it. In fact, it should be set higher than the desired baudrate to the WiFly to account for the overhead of sending both data and register addressing in the 750.)
So, what you’d need to do is:
initialize the 750, and leave the baud rate of the 750 UART at 9600 (I assume this is default)
initialize the WiFly, and set the baud rate of the WiFly UART to the desired higher rate
change the baud rate in the 750 UART to match the higher rate of the WiFly UART.
Most of the various terminal routines seem to default to 9600, and if the baud rate is set it seems to be set in the 750 only (still reviewing the WiFly library code).
I’d like to know more about the crystal issues, and whether they’ve been solved – the frequency used, with the divider in the 750 UART, should produce the right baud rate values.
EDIT: nevermind, I see from the posts above the crystal problem should be resolved.
You might also have an issue if you set the WiFly baud rate to a higher rate, and you save that in the WiFly config file (“set uart baud” instead of “set uart instant”). The next time you power things up, you’ll need to re-set the baud rate for the 750 to the higher rate. I assume the WiFly will reboot and use the saved rate.
We’ve been running much higher baud rates, and have got 460Kb working reliably. Our end is an LPC1756
use “set uart baud 460800” (must come first)
then “set comm size 1420” (for max packet size)
then “set comm time 80” (so it doesn’t bang on the WiFly interrupts so hard, default is 10)
viskr:
We’ve been running much higher baud rates, and have got 460Kb working reliably. Our end is an LPC1756use “set uart baud 460800” (must come first)
then “set comm size 1420” (for max packet size)
then “set comm time 80” (so it doesn’t bang on the WiFly interrupts so hard, default is 10)
I assume you’re using a WiFly module directly connected to the 1756?
I’m going to experiment with the maximum standard speed the WiFly’s datasheet says it can handle (921,600) as soon as I modify the terminal code to also set the 750’s UART to work at that speed.
Yes its directly connected to a UART on the LPC1756.
We’re using UDP packets (much much less overhead than TCP)
And we found we got 460Kb throughput for long periods from our sensor connected to the LPC1756, and receiving data on a PC connected to a wireless router.
We weren’t able to push it reliably any faster end to end.
I can confirm that i got this working with the 14MHz clocked wifly shield, and Arduino UNO.
The first test that worked i tried
configuring the Wifly RN131C:
$$$
set uart baud 115200
set comm size 1420
set comm time 80
save <— do not forget to save(!), or it will start up using 9600 baud after reboot!
reboot
in SpiUart.cpp:
#define MCR_DIVIDE_BY_FOUR_PRESCALER 1 << 7 //Yngve
#define LCR_ENABLE_DIVISOR_LATCH 1 << 7
writeRegister(DLL, 2); // for 115200
writeRegister(DLM, 0); //
writeRegister(EFR, EFR_ENABLE_ENHANCED_FUNCTIONS); // Using the divide by four
writeRegister(MCR, MCR_DIVIDE_BY_FOUR_PRESCALER); //
This could of course be solved by dividing by eight in the DLL and not using the MCR divide by four.
The main thing is
1: Do configure the uart on the wifly
2: Remember to save!
3: Reboot the Wifly unit
4: Program the Arduino to set up the Spi-Uart Bridge.
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
}
** 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.
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…
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?
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:
#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.