Shop OBEX P1 Docs P2 Docs Learn Events
Has anyone a project in SPin or ASM for adjustable common RS232 RX Baud rates upto 250K — Parallax Forums

Has anyone a project in SPin or ASM for adjustable common RS232 RX Baud rates upto 250K

Has anyone a project in SPin or ASM for adjustable common RS232 RX Baud rates upto 250K

Some example common baud rates used.

300
9600
14400
19200
28800
31250
38400
56000
57600
115200
250000

And any others.


Thanks in advance,

AndyProp




Comments

  • It's not at all clear what you're asking. There are quite a few serial I/O drivers in the Propeller Object Exchange as well as the Full Duplex Serial driver included with the Propeller Tool. All of them are configurable with the Baud rate expressed as an integer. The 4-port Full Duplex Serial driver can handle up to 750KB if only one port is used or up to 230KB each if two ports are used (with the usual 5MHz crystal and 80MHz system clock).
  • Are you talking about AutoBaud?

    (calculating baud rate from the transmission its self)? (because the transmission baud may change?)


    http://forums.parallax.com/discussion/136720/autobaud-on-the-propeller-not-using-special-characters-but-total-packet-length
  • jmgjmg Posts: 15,173
    AndyProp wrote: »
    Has anyone a project in SPin or ASM for adjustable common RS232 RX Baud rates upto 250K

    If you want to tolerate the widest Baud settings, that's usually AutoBAUD based.
    Most commonly something like 0x55 is sent, and timed, and then that used for BIT times.
    Because you capture over 8 bits and divide, usually there is spare capture precision (but take care with the rounding details)
    A purist might use that extra precision, in the bit-timing, with fractional baud design.

    Range and Granularity are the next things to consider :

    A P2 at 80MHz will have a SysCLK count of 320 per bit at 250k, and 266667 at 300 Baud, for single-sample designs.
    Those are fine enough to give low AutoBAUD errors, without needing fractional baud extras.

    Full Duplex can get a little more coarse, as that can use multiple samples per bit, & run both Tx and Rx state engines at the same time.
  • Sorry if my question was a bit confusing.

    I am wondering if it exists a object or code to set receive data Baud rates with all of those ranges 300 to 250K.

    Not all the same time, just optionally set with something like RXbaud equals 300

    300
    9600
    14400
    19200
    28800
    31250
    38400
    56000
    57600
    115200
    250000







  • Mike GreenMike Green Posts: 23,101
    edited 2016-05-08 21:29
    Look at FullDuplexSerial here. The initialization call requires the I/O pin numbers for receive and transmit, a mode value for normal/inverted, and the Baud specified as an integer (like 300, 1200, etc.)

    As I mentioned, there are other drivers there that all use pretty much the same sort of initialization call.

    I tend to use fullDuplexSerial4Port because I sometimes need more than one serial port and this only uses one cog for up to 4 serial ports. It also supports hardware handshaking and the timing has been improved since FullDuplexSerial.
  • jmgjmg Posts: 15,173
    AndyProp wrote: »
    I am wondering if it exists a object or code to set receive data Baud rates with all of those ranges 300 to 250K, just optionally set with something like RXbaud equals 300

    Yes, see the comment above that says

    All of them are configurable with the Baud rate expressed as an integer.

    You need to define the SysCLK, and then usually a single equation sets the Divider(s) from that.

    With 32b native support, I would expect all to work as low as 300, and at the very top end, I would suggest you just check the final integer value used, for the timing core.

    Values below 100 infer > 1% granularity and values below 50 infer 2% granularity, which is pushing UARTs.

  • That is what I was looking for

    Thank you Mike Green, it is the "fullDuplexSerial4Port" done by "Tracy Allen" ?

    obex.parallax.com/object/248

    4 ports are very useful indeed

    Thank you all and especially jmg for the technical explanation.





Sign In or Register to comment.