• 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1
Request group membership
By: Tracy Allen, created: 2013-04-09 | updated: 2013-04-09


  • Can open up to 4 independent serial ports, using only one pasm cog for all 4.
  • Supports flow control and open and inverted baud modes
  • Individually configurable tx and rx buffers for all 4 ports, any size up to available memory, set in CONstants section at compile time
  • Part of the buffer fits within the object's hub footprint, but even so the object is restartable (inspired by Duane Degn's thread).
  • Buffers are DAT type variables, therefore a single instance of the object can be accessed throughout a complex project.
  • Includes companion object in zip, dataIO4port, to handle numeric output and also numeric and string input from any of the four ports.
  • Includes 2 demos. Demo1 simply shows how to set up a single serial port for debugging. Demo 2 implements three serial ports, the first to send data to the second at high baud rate using flow control, and a loop to send the data out at a lower baud rate to a terminal screen, showing the use of various methods from fullDuplexSerial4port and dataIO4port.
  • Modified from Tim Moore's pcFullDuplexSerial4fc. Changes and bug fixes include:
  • Flow control is now operational when called for, with correct polarity (bug correction)
  • Jitter is reduced, unused ports are properly skipped over (bug correction), operation speed is increased.
  • Stop bit on reception is now checked, and if there is a framing error, the byte is not put in the buffer.
  • Buffer sizes are flexible, set in CONstants, each port separate rx & tx up to available memory
  • Changes in pasm and in Spin methods to accommodate larger buffers, major reorganization of DAT section.
  • Added strn method for counted string, and rxHowFull method for buffer size.
  • Moved the numeric format methods such as DEC and HEX to companion object dataIO4port.spin. It is included in the .zip. Use that in order to maintain compatibility with methods in the original pcFullDuplexSerial4fc. Can be re-merged if desired. DataIO4port.spin also includes numeric and string input methods borrowed from PST (Parallax_Serial_Terminal.spin).


Original File Upload
Package icon fullDuplexSerial4port_1v01.zip29.75 KB


[originally posted by Anonymous on 2013-02-01 15:13:20] Works really great for me. Thank you very much! 

[originally posted by Anonymous on 2013-02-05 14:21:39] Thanks Tracy, it's handling my project's need where two others didn't.

Small bug fix to dataIO4port.spin.  In method StrInMax, need to change:

if (byte[stringptr++] := uarts.rx(0)) == NL

to use "port" instead:

if (byte[stringptr++] := uarts.rx(port)) == NL

Otherwise, it'll always read from port 0, which doesn't work if you want to use a different port number.

Thanks for the head-up about the bug in the dataIO4port.spin support routine for StrInMax.

I also found a bug in the main fullDuplexSerial4port code for port 0, which will only come into play if you try to use RTS flow control on that port without also enabling CTS flow control.   In th pasm code for port 0 initialization, find this sequence:


                       or      ctsmask,#0     wz     'cts pin? z not set if in use

        if_nz           or      dira,rtsmask          ' TTA rts needs to be an output   ' move this line down


The second line has to do with RTS flow control not CTS flow control, and should be moved down 7 code lines so that it appears after the test for rts flow control.


<code>                        or      rtsmask,#0     wz     'rts pin, z not set if in use

        if_nz           or      dira,rtsmask          ' TTA rts needs to be an output   'to here


This only affects port 0, and only when flow control is enabled.

Thanks for this great driver.

Is it able to be brought into SimpleIDE?

How is that done?


I have a couple of questions about this object:

  1. It would seem that every character transmitted is preceeded by a Mark bit that immediately preceeds the Space that is the Start Bit. This means that each transmitted character is 11 bit times rather than just the 10 that are necessary. Am I missing something about the transmit code sequence? Is this extra bit necessary to get correct operation of the receive code?
  2. The receive code syncs to the start bit and then offsets 1/4 of a bit time before beginning to sample the next 9 bits. Is there a reason that the offset is 1/4 bit time rather than something closer to 1/2 bit time?