SparkFun Forums 

Where electronics enthusiasts find answers.

All things pertaining to wireless and RF links
By Robert Mann
#99852
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?
By follower
#99890
Robert Mann wrote: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:
Code: Select all
>>> hex((12288000/1)/(9600*16))
'0x50'
struct SPI_UART_cfg SPI_Uart_config = {
0x20,0x00,0x03,0x10};

To get 38400 and even that is unreliable.
I got the following divisor value for 38400:
Code: Select all
hex((12288000/1)/(38400*16))
'0x14'
How did you reach your value?
Am I missing something or does anyone have any suggestions?
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;
By Robert Mann
#100865
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 wrote:
Robert Mann wrote: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:
Code: Select all
>>> hex((12288000/1)/(9600*16))
'0x50'
struct SPI_UART_cfg SPI_Uart_config = {
0x20,0x00,0x03,0x10};

To get 38400 and even that is unreliable.
I got the following divisor value for 38400:
Code: Select all
hex((12288000/1)/(38400*16))
'0x14'
How did you reach your value?
Am I missing something or does anyone have any suggestions?
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;
By follower
#101583
Robert Mann wrote: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.
When you say "minor errors" do you mean corrupted characters or do you mean missing characters?

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;
By follower
#102541
follower wrote:I have made contact with the engineer who designed the board and will update you when I find out more.
(Whoops, I should have added "assuming I don't completely forget to post a followup", sorry!)

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;
By bswift5528
#107020
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. :(
By follower
#107105
bswift5528 wrote:Has this changed in the last few months?
Yes, this has changed recently with a different crystal (~14MHz) now used.
Any chance it will ever be able to do somewhere in the ballpark of 0.25 Mbaud?
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.

--Philip;
By Kybo_Ren
#107223
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:
Code: Select all
<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 :)
By RonanM
#128015
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
By n0ym
#131182
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:
1) initialize the 750, and leave the baud rate of the 750 UART at 9600 (I assume this is default)
2) initialize the WiFly, and set the baud rate of the WiFly UART to the desired higher rate
3) 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.
Last edited by n0ym on Tue Aug 02, 2011 8:13 am, edited 2 times in total.
By n0ym
#131186
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.
User avatar
By viskr
#131189
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)
By n0ym
#131191
viskr wrote: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)
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.
User avatar
By viskr
#131193
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.
By yngveha
#136654
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.