"Parallax Serial Terminal.spin" vs "FullDuplexSerialPlus.spin" vs "FullDuplexSerial.spin"
DavidZemon
Posts: 2,973
in Propeller 1
The documentation at the top of PST says:
But doesn't go into explaining what the differences are. Does anyone know, or will I need to look them over myself?
This object is heavily based on FullDuplexSerialPlus (by Andy Lindsay), which is itself heavily based on FullDuplexSerial (by Chip Gracey).
But doesn't go into explaining what the differences are. Does anyone know, or will I need to look them over myself?
Comments
If I only need one serial port, I use FDS or FDS Plus. Otherwise, I use a four port version.
I always find PST much easier to use, so I guess there must be other advantages to FDS for displays/terminal which I am not aware of.
Although this observation is non-critical (both FDS and PST work very well) I would be interested to hear any expert thoughts on it.
So quite literally the only reason to use FDS over FDS Plus is if you are using a Spin compiler without unused method removal?
You mention PST is "easier" than FDS but that you prefer FDS. What is it that FDS does better? Faster? More flexible?
I was confronted with this question when I started working on the Spin Standard Library, and ended up creating com.serial and com.serial.terminal, which is what I use for new projects now; com.serial is the base serial driver and com.serial.terminal adds formatting methods.
Maybe TC has a comment on this, he seems to prefer FDS over PST.
@Duane, after a week of school, kids are not so easy to get involved with math.
I'm using propeller-load within CLion, and CLion is buffering my input (so propeller-load receives an entire line of input at once, therefore transmitting the minimum number of stop bits). I don't know how to configure propeller-load to increase the stop bits.
As far as I know, PST goes only to the screen. I used Fds to talk to a lcd. And then I stole just enough to do dec and wrote my own bit-banger so as to save a cog.
There was a golden version of FullDuplexSerial but it did not have my mods.
Found it: http://obex.parallax.com/object/249
I extensively tested FDS several years ago. I could receive reliably over 230400, but only after commenting out the ping-pong multi tasking for transmit.
For my project I had plenty of free pins so I used the FT245. I re-wrote FullDuplexSerial to work with the FT245 and have been *VERY* happy with the results.
http://obex.parallax.com/object/247
By "commenting out the ping-pong multi tasking for transmit" you mean you changed FDS to be half-duplex, receive only? And then you were able to hit 230k?
I'm not familiar with the FT245 so I took a quick gander at http://www.ftdichip.com/Products/ICs/FT245R.htm. So is this basically just a buffer for your UART bus, so that the Propeller doesn't have to be always-listening? Sounds like a really good idea! I may want to provide an object for that in PropWare. But, as for this thread, it only exists to help me decide which buffered UART driver PropWare should use, so the FT245 doesn't help me too much on that quest.
There's fullDuplexSerial4port.spin that does 4 full duplex UARTs in a single cog. One cog can be transmitting 4 different bytes on different pins at different bauds and receiving 4 different bytes on different pins at different bauds all at the same time. It can do flow control too, but I've never needed it. I always use this object or one of its many variants when I need more than one serial port.
Why don't you add fullDuplexSerial4port.spin or a variant of it to PropWare, but remove the transmit channels so the receive channels can do faster bauds and use your PropWare transmit code instead? Then, you can do up to four (or eight if you replace the transmit channels with more receive channels instead of just removing them) asynchronous receives, with flow control if desired, with no external hardware.
Correct. As I recall there is a set of jump returns that check to see if TX the buffer ring was updated. I commented the jmpret in the receive section, if I remember correctly.
Instead of it being a serial FIFO, it is a parallel FIFO. It transfers data in parallel, so there is no bit banging. Theoretically it should be at least 8 times faster than serial. It requires 12 propeller pins for operation, so that is the down side.
Using the FT245, I send data to the prop at 3,000,000 bps without issue. Keep in mind this is a USB device, so it is only good for talking between a PC and the prop.
Regards,
Terry
Well, yes. But the Propeller isn't so hot at doing async receive comms. Aka: receiving UART or being a slave on an SPI bus. Probably others too but those are the only two I've had to deal with. So, putting that FT245 inbetween the Prop and something else allows the Propeller to become the master, and therefore increase comm speed significantly. I think the FT245 was also a parallel interface, so that would make it even faster.
I can definitely add the 4-port object, and probably will someday. But first, I want to start with a single-port, reasonably fast (230,400 doesn't seem too unreasonable to me), 8N1 object. If it can be configured to do more than that, great, but not required. I think these three requirements probably fill the single largest need. I know there are a lot of other needs for UART around here, but I'll bet that fills a lot of them. I thought FDS would fit this bill right out of the box, but apparently not. Do you know off the top of your head if the 4-port object would work with those requirements?
And PropWare provides great integration with spin2cpp, which is part of the reason I'm not all too concerned with porting every object in the obex over to PropWare right away