Serial port Speed
Kye
Posts: 2,200
I'm working on a serial port driver in C and I'm stuck on making a trade off.
I can either do:
A two port serial driver in one cog that does 115200 BPS. The two ports will have both RX and TX FIFOs which allows the LMM cog to not have to block on sending data.
A two port serial driver in one cog that does 230400 BPS. The two ports will have only RX FIFOs which means the LMM cog will have to block on sending data by bit banging itself.
Which is better? Should I go for the higher speed? Or, should I take the lower speed option which blocks the LMM cog less.
Thank you for suggestions.
I can either do:
A two port serial driver in one cog that does 115200 BPS. The two ports will have both RX and TX FIFOs which allows the LMM cog to not have to block on sending data.
A two port serial driver in one cog that does 230400 BPS. The two ports will have only RX FIFOs which means the LMM cog will have to block on sending data by bit banging itself.
Which is better? Should I go for the higher speed? Or, should I take the lower speed option which blocks the LMM cog less.
Thank you for suggestions.
Comments
While extreme serial port speeds are possible on the Propeller, the 32K RAM limit is a rather small buffer. So the real question is what size are the actual data transfers going to be that require huge bursts of speed?
Most of what I do with a Propeller is to send and recieve 20 or so bytes as a string. If some one really needs huge speed, they can dedicate a cog to another serial object that will do it in PASM.
The issue is that for the lower speed version the LMM processor doesn't have to block on sending data while in the higher speed one it does.
This becomes an issue when you run the really high speed port at a low speed. The non-blocking one seemingly becomes faster because the LMM core does not have to send the data at a slow baud rate itself.
If you run at much higher speeds like 3M baud or more you can forget about transmit buffering and simply bit-bang directly from the LMM cog and then have the other cog dedicated to receive which it can do really well. This is the approach I use in Tachyon. There is no reason to favour traditional baud rates of 115200 etc just because this is the highest speed some serial programs can run at as there are plenty of programs that don't have this limit such as Minicom.
To go slightly off topic, after configuring a number of propeller projects that use serial devices, what would be most helpful to me would be a driver where receives and transmits could be configured independently.
Most of the projects I've worked on have had several serial devices where some devices only received, like from a GPS sensor, and some only sent, like to an LCD display, but as often as not, they use different baud rates, forcing me to either customize an existing driver to allow different baud rates on send and receive, or to use multiple instances of a driver, where half of each driver goes to waste.
Back on topic, I've ever only needed a FIFO on receive, but going further, I've had to increase the size of a receive FIFO before, so a configurable receive buffer size would be helpful to me. (Changing the buffer size of a library serial driver turned out to be pretty easy if the buffer size is kept as a power of 2.)
The issue is blocking. If you transmit a huge message at 300 baud then everything else that the main core was doing is blocked on that message.
I believe I'll go with the TX and RX FIFO options given this.
Thank you,
david b, fullduplexserial_rr004 allows simple changes to the buffer sizes by changing a constant, butinpowers of 2. its in obex.
also take a look at the 4port serial driver - cannot recall its precise name - its in obex.