Fastest Stable Baudrate w/ 50MHz?

Steel

In the help file for the SX in "Serin" (under Quick Facts),· when the Frequency is at 50MHz, it says·· > 230400 for baudrate.

Is there a more determinate value that has been proven to be a successful candidate?

I am pushing a LOT of data to my SX (128 bytes every 2mS) and I am wondering what the fastest baudrate that I can put my SX up against.

Has anybody done 256k?· Has anybody done 500k?· I don't have the ability to test right now, and I figured that this is something that somebody else has tested.

Any input?

Thanks
Shaun

JonnyMac

I've done 250K SERIN for DMX-512 and am working on a DMX fader that uses an ISR for the UART and triac control.

Bean

I think 500KBaud would be no problem at 50MHz. But I've never tried it....

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"Educate your children to self-control, to the habit of holding passion and prejudice and evil tendencies subject to an upright and reasoning will, and you have done much to abolish misery from their future and crimes from society"

Benjamin Franklin
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
www.hittconsulting.com
·

Phil Pilgrim (PhiPi)

This is two questions, really:

1. "What is the fastest input baudrate you can achieve when you're camped in the input line waiting for data?"
2. "What is the fastest input baudrate achievable when it's being handled in the background by an interrupt routine?"

I agree with Bean's answer, so long as it's the answer to question one. Answering question two is more difficult, though, since it involves deciding how many CPU cycles to leave for the foreground routine and how the background asynchronous receiver is coded. The most common way to do the latter is to use the timer interrupt at a 3X baud or higher rate. But a faster method might take advantage of the Port B pin-change interrupts, whereby the interrupt routine just reads the free-running timer to see how many bits went by since the last interrupt and kicks out a byte when enough have transpired. For this to work well, two conditions would have to be met:

1. The input datastream has to be noise-free (i.e. no stray edges), and
2. A ninth, zero-parity, bit might have to be added to ensure that the stop bit starts with a low-to-high-edge. Otherwise you could be waiting for the next start bit to finish the previous data byte.

I've never coded a receiver using this method, but it's something I've been wanting to try.

-Phil

pjv

Hi All;

The results I'd put forward is that under Phil's #1 scenario the maximum practical would be about 1 Mbits/sec, and that is with some constraints.

In scenario #2 it would be about 500Kbits/sec.

That said, in a synchronous scenario where the receiver takes only one sample in the middle of the bit, I have been running 10 Mbits/sec absolutely without error for years now, albeit in a "bursty" mode.

So as said by others, "fastest" depends on what else is going on......

Post Edit:· Actually, it appears Shaun is already doing 640 Kbits/sec. How did I miss that earlier?

Cheers,

Peter (pjv)

Post Edited (pjv) : 4/24/2007 4:41:34 AM GMT

Dave Hein

Shaun,

With optimized code you could transfer data at a rate of 5 to 10 cycles per bit. It depends on whether you use loops or straight-line code. At 10 cycles/bit your data transfer rate would be 5 M-bits/s at 50 MHz. Since you only need to handle 640 Kbps your processor clock could be as low as 6.4 MHz. I assume you want to do something with the data, so you would need a higher clock rate to handle the extra cycles for processing.

If you run asynchronously the sender and the receiver transfer rates must be within a percent or so of each other. If your willing to use an extra line for a clock you could run synchronous at very high rates as Peter mentioned. In that case you wouldn't have to worry about the accuracy of the transmitter and receiver clocks.

Dave

Steel

All-

Thank you so much for your input.· As soon as I get my hardware back from other tests, I will see how quickly, and cleanly I can get the data transferred.

Thanks!