Prop Baudrates

tom90

Hey All,

Im using FullDuplex for data output and the highest baudrate I could manage was 460_800. Is there anyway I can get a higher baud rate out of FullDuplex, and if not is there any other object I can use that will accomplish a higher baud rate?

Thanks
Tom

Microcontrolled

No. The propeller timing does not allow for that kind of thing.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Toys are microcontroled.
Robots are microcontroled.
I am microcontroled.


If it's not Parallax then don't even bother. :-)
·

Mini-Din/PS2 connectors are for sale! 5 for $1! PM me if you wish to make an order.
Cheap·shipping unless specified!··········150 left!!··

JonnyMac

If your application can tolerate a fixed baud mode (e.g., true only) and separate cogs for TX and RX you can get significantly higher baud rates.

[noparse][[/noparse]Edit] Added wait(b) and waitstr(pntr) to jm_rxserial; increased size of buffers.

Post Edited (JonnyMac) : 7/16/2009 9:35:44 PM GMT

Mike Green

There's a 4 port serial driver (that takes only one cog) that supports up to 750 kBps if only a single port is defined.

obex.parallax.com/objects/340/

Bobb Fwed

It can definitely go faster, I recently wrote a synchronous (usually slower than asynchronous) serial driver for an ADC that did over 3.9mbps (I think I'm doing that math right...seems high). And there are techniques that would allow me to go even faster, but I was already past the limit of the ADC I was using so I didn't push it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
April, 2008: when I discovered the answers to all my micro-computational-botherations!

Peter Jakacki

@Bob - asynch requires constant sampling of the input stream which is asynchronous to the internal sample clock. On hardware uarts the sample clock is typically 16 times the baud rate. It's the receive routine timing that is difficult as the transmit timing is synch'd to the "uart" clock. So anything synch'd to the sample clock such as interfacing to SPI chips etc can achieve very high data rates.

Tom, there are routines that have been optimized for higher baud rates as mentioned but they do suffer from imprecise timing at the higher speeds. This may not be a problem in some instances especially a simple point-to-point connection but using this to talk to another prop may cause problems.

Dedicating a cog to rx will achieve much higher data rates as I spec my drivers to 1Mbaud but I believe Hanno has some that run around 3M.

If your communication is essentially half-duplex you can use the one cog but have a modified serial routine that doesn't try to multitask but either receives or transmits. But in all this I must ask you, what hardware driver are you testing this speed with. I hope it's not RS-232 because you have probably max'd what the chip itself can do.

*Peter*

Lawson

JonnyMac said...
If your application can tolerate a fixed baud mode (e.g., true only) and separate cogs for TX and RX you can get significantly higher baud rates.

Cool code! Doesn't look like it'd be easy to convert into a one-cog half-duplex driver. I've been wanting a rs232 driver that can drive the 1Mbaud plus speeds that the FTDI usb-serial chips support. This looks like a good option.

Lawson

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?

Peter Jakacki

Tom, this code uses the one cog and definitely works at 1M. You can weed out the support routines as you like.

*Peter*

Peter Jakacki

Whoops, I just checked that code I attached and it looks like it was a WIP (work in progress) as I was doing some enhancements to the original FASTSERIAL. So I have attached the previous version and once I have checked out the new version I will post it here.

FASTSERIAL FEATURES:
Timing accurate to 1Mbit (main feature)
Compiler time setting for data bits and stop bits.
Parity
Auto half-duplex (once it's transmitting or receiving it won't try to do both which suits most actual communications)
Binary variable receive buffer size (any binary multiple as is practical)
ANSI commands (draw lines, boxes etc)

FINAL VERSION GOALS:
run time selection of databits, stopbits, parity, baud.
break detection and generation
receive gap reporting
auto checksum
Full parity control
RS-485 on two pins (RXD/TXD + TE/RE) (previously removed)

*Peter*

Kye

Use buffer sizes of 256 bytes, then you can have auto wrap arround using a byte to hold the head pointer and tail pointer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nyamekye,

Peter Jakacki

That's the most basic and easy way of course. With high speed coms it is necessary to have large receive buffers and and a very small transmit buffer, if at all. This step is covered in my code where a mask is calculated and applied to wrap it all, that way the buffer size can be 512 bytes or 1,024 bytes etc.

The next step after this is to have any arbitrary size passed in the start parameter list.

*Peter*

tom90

Thanks for everyones response.

I have been busy lately but will soon test out all of your suggestions.
-Tom

Stephen Moraco

Tom,

I've been running High Speed drivers 2Mb (1cogTx,1cogRx) since early last year. I found
articles that showed how to setup Windows to use the 2Mb and 3Mb settings of the FTDI chip.
Then I found that when setting these baud rates (any baud rates) for the windows driver
actually causes the FTDI chip to then change it's Rx/Tx rates to the propeller. This caused
me to first load a cog with an autobaud routine (simple one) then once it determines the rate
the cog is reloaded with the Rx routine which is then followed by another cog being loaded
with the Tx routine. I'm running with 80MHz clock and was not able to code a working 3Mb in
both directions (Tx works, Rx doesn't). However, now that we are
clocking > 80MHz (100MHz with new 6.25MHz crystals), we can likely get to full 3Mbit in
both directions.

I had a need to watch a communications bus and get all of the traffic logged to the PC without
doing much buffering in the propeller RAM. This took me to these speeds. They work very well.

There's more write-up here: new-serial-driver-testing-results

I thought I'd posted the routines but off-hand, I'm not finding the posts in my quick search.
[noparse][[/noparse]edit] Found the post! http://forums.parallax.com/showthread.php?p=720623

Let me know if this encourages, or you need more info, etc.

Regards,
Stephen, KZ0Q
--

Post Edited (Stephen Moraco) : 7/21/2009 7:56:07 AM GMT

Lawson

I bet some of your problem with 3Mbaud at 80Mhz was because 80/3 is not an integer. I'd bet you'd have much better luck with a 6Mhz crystal, (96/3 = 32) or by keeping track of time in sub-clock increments and adding a "leap clock" as needed to keep timing errors in check. (i.e. for 80/3 = 26+2/3 the bit waits would be cycle between 27, 27, and 26 clocks)

Lawson

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?

Post Edited (Lawson) : 7/21/2009 5:48:23 PM GMT

Lawson

I've been doing some testing of the 1Mbaud or more RS232 objects I can find. I haven't tested "FASTSERIAL-080927.spin" from above because I need full duplex for my current application and have extra cogs to throw at serial.

@Stephen Moraco
I've been able to break your serial RX code. The attached serial terminal is something I found on the 'net to let me send and receive binary bytes over rs232 without having to resort to programming. When I set it to a custom baud rate of 2_000_000 baud, type something into the transmit text box and hit send, garbage sometimes comes back. This terminal program won't do this when I tell it to "send file". My best guess is that whatever text is in the send box is dumped into the TX buffer of the FTDI chip in one block so the FTDI outputs RS232 bytes with no gaps. (setting 2 stop bits helps but won't fix this)

@JonnyMac
I can get your "jm_rxserial" to receive garbage too at 2_000_000 baud and 2 stop bits. With some small tweeks though I've been able to get the code working at 1_500_000 baud and 2 stop bits. (commented out a waitcnt after the ASM byte receive loop, and boosted the RX buffer)

My prop is clocked at 80Mhz.

Lawson

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?

Stephen Moraco

@Lawson
Thanks for the testing and feedback. Good work!
I'd like to recreate your break and find out what needs "tuning" [noparse]:)[/noparse]
Are you using the autobaud routine? If so, are you sending the CR(s)
up-front that it needs?

In short, tell me how to recreate the failure and I'll hang a logic analyzer off of my
test platform to see what's happening... Then I should be able to fix it.

Again, thanks for the problem report!

Stephen, KZ0Q

Lawson

Ah, sorry. I didn't bother to setup the above linked terminal program to send a lone "CR", but a capitol 'M' seems to work well enough. I.e. I can send "Marty Lawson" and the auto-baud prompt will pop up with the correct speed. But if I keep rapidly clicking the send button (blue arrow of the attached picture) on the transmit text box (red arrow) I'll start to get garbage characters mixed in with what I sent. I can't get this to happen with PST. Hyper Terminal won't do this either, even when I ask Hyper Terminal to send a text file. (sending a text file with the attached program won't get garbage either, it can be slow in odd ways) Also, changing from 1 to 1.5 to 2 stop bits effects how many garbage characters are seen and how fast the baud rate can be set before garbage starts to show up.

Lawson

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Lunch cures all problems! have you had lunch?