How to speed up serial baudrate ?

tripp

I am trying to speed up serial baudrate.
Using·"Multiple serial port driver" from Propeller Object Exchange.
http://obex.parallax.com/objects/340/

looking at the comments in the start it says:
''*··· 1 port up to 750kbps

The fastest i get is to 225kbps above that i start to miss bytes!

Have someone really got it working at 750?

Is there another faster serial driver?

my settings:

CON································································
· _clkmode····· = xtal1 + pll16x···································
· _xinfreq····· = 5_000_000··

Thanks in advance.

Timmoore

I have had it running that fast, though it was with an earlier version of the driver. It was with itself, i.e. prop to prop. One of the things I noticed with it and with the normal FullDepluxSerial driver was tx took longer to get the next byte to send than receive did to store it but with other serial port implementations you could overrun the receiver storing the byte. If thats the problem and you can delay slightly between bytes on the sender it will work otherwise oyu need to slow the baudrate so the receiver has enough time to store the byte before the next byte starts arriving.

Peter Jakacki

I have written a variety of serial routines and I have also used the four-port object at 115.2K. But I found that many of these objects may work but the timing is imprecise and causes problems at higher baud rates. At one point I tuned an object (DSO + diagnostic signals) to give me precise timing both on transmit and receive but it is essentially half-duplex at this stage until I get around to seeing if I can do a bit more with it. The half-duplex wasn't a problem for me as it was being used on RS-485 networks anyway or RS-232 "ping-pong" connections. I have tested the routines for accurate operation to 1Mbaud.

*Peter*

grahamreitz

is it 750 kilobits/s or kilobytes/s?

I was just about to ask what is the theoretic max for serial on the prop.

Toby Seckshund

Baud rates only state the bit rate. The house keeping that has to be done may lower the byte rate you could stuff through,·but the baud rate wouldn't change. One solitary byte sent at 750K, every 2 hours, still is 750K.

Timmoore

Right, the driver can do a baud rate of 750K but it can't run that continously. For 750Kbps the max bytes/s is 75KBps (1 start/1stop/8bits). But the driver needs time when it received the stop bit to store the byte for receive and on tx is needs time to get the byte before transmitting. This slows the max KBps down from the theorical. The driver has a longer time to load for tx than to store for receive so for prop to prop you can't overrun it before you get to max Kbps. For other devices which have hardware tx Fifos they can back to back the bytes on the wire and the prop driver will lose the 2nd byte.
The other problem you can see is the baud rates on the tx/rx not matching, the baudrate has a tolerence, I have seen cases where I ended up setting the prop baudrate different from the nominal baudrate - e.g. I have a CMU camera that should be 115200 but I find I set the baudrate for the prop driver to 116500 for it to work correctly. This is within the tolerences of the serial port on the CMU camera.

Toby Seckshund

On most UARTs the sampling of each bit is arranged to be at the centre of that bit. So with 1,8,1 format the sampling cannot drift so much that edges or wrong bits are sampled. Sample is at 50% and ther are 10 bits therefore max error allowed would be 5% before you drift off to one edge. This would be pushing a perfect theory to the hilt, 4% would be the most you could hope for

2% should be ok. That is the reason for some of those "strange frequency" crystals ie 11.059MHz they divide down perfectly, for hardware UARTs. Bitbanging requires good resolution counters.

Timmoore

The prop driver waits for the start bit, then waits 1.5bits for the middle of the 1st bit. However, if the device sent 2 bytes back-to-back while the driver is storing the 1st byte, the start bit is arriving for the 2nd byte. Then you start timing from somewhere in the start bit and you can end up at the end of the 1st bit rather than the middle. If the baudrate tolerence is close you are still ok by the 10bit, if its really a bit faster, then you sample the 10bit after the 10bit is finished sending. You will see this problem with 3rd party hardware serial ports that are faster than actual baudrate. The 4 port serial actually times 1.25 bits from start bit to give a bit more room for error here.

Hanno

ViewPort transfers data full duplex at 2mbps, 1mbps, and 115kbps- all with autodetection. The code to send a bit every 40 cycles is straightforward. What's extremely difficult is understanding the various Windows and USB drivers to make sure your bytes don't get lost. ViewPort already supports most things people seem to want from a serial connection:
- streaming lots of variables from the Propeller to be displayed/shared on the PC
- sampling data very quickly (up to 80msps) and updating the PC display
- grabbing a frame of ntsc data from a camera in real time and streaming the video to the PC
If you have a new use case let me know- I'm sure we can figure out a solution.
ViewPort is also completely extensible- everything you see was created from the ViewPort Developer's Kit that's included in the Ultimate package.
Hanno

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Download a free trial of ViewPort- the premier visual debugger for the Propeller
Includes full debugger, simulated instruments, fuzzy logic, and OpenCV for computer vision. Now a Parallax Product!