Shop OBEX P1 Docs P2 Docs Learn Events
Full Duplex Serial (128byte buffer) - comm parameter settings — Parallax Forums

Full Duplex Serial (128byte buffer) - comm parameter settings

wplumwplum Posts: 6
edited 2014-10-19 20:57 in Propeller 1
Looking for tested OBJ for Full Duplex Serial (128byte buffer) with parameters for word length, parity, stop bits. Thanks.

Comments

  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-09 18:31
    wplum wrote: »
    Looking for tested OBJ for Full Duplex Serial (128byte buffer) with parameters for word length, parity, stop bits. Thanks.

    PropWare contains an unbuffered implementation in C++ that fits your other criteria.

    Sorry... I know you were probably hoping for Spin :(
  • Cluso99Cluso99 Posts: 18,069
    edited 2014-10-09 18:57
    All I have seen are 8N1.
    I posted a version FullDuplexSerial_rr004 in obex that has variable buffer length to 256 (in powers of 2) so you can easily change to 128.
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-09 19:00
    If buffered comms are an absolute must, and no one else provides a solution that works for you, let me know. Adding a buffered implementation of PropWare::UART is on my TODO list and I could bump up the priority if theres a real need for it.
  • AribaAriba Posts: 2,690
    edited 2014-10-10 06:45
    I have made a configurable FD-Serial object with optional parity on transmit. It also allows for bigger rx-buffers.
    You can find it for example in this post.

    Andy
  • mklrobomklrobo Posts: 420
    edited 2014-10-10 09:54
    What protocol will be used? If Xmodem, fill me in on that code!
  • wplumwplum Posts: 6
    edited 2014-10-14 09:58
    Thanks all. I am trying to communicate with a serial device (2400, 8E1). The device can be set to send blocks (56 bytes) of data every second or in a polled mode. Currently available spin OBJ's apparently are all 8N1. (except Andy's Tx)

    Andy - Thanks for your posting. This should get the polled method of getting data working... if only somehow the parity (E) can be ignored on the prop receiving data.

    Any other lights going on for resolution of this problem.
    Hardware UART? is there an SPI, I2C chip available?
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2014-10-14 11:18
    The MAX3100 is an SPI hardware UART with interesting capabilities. I've used it with the BASIC Stamp to endow it with an input fifo. I see there is now an SPI+I2C MAX3107 available. It does seem like vast overkill though with the Prop at 2400N1E. Is it okay just to ignore incoming parity errors?
  • wplumwplum Posts: 6
    edited 2014-10-14 12:16
    Thanks Tracy: In the absence of Spin OBJ FDserial configurable Parity bit for Tx and Rx then MAX3100 SPI UART looks like the way to go. This will give a robust universal tool for serial comm. Now I just need to procure the chip (14DIP) and go at it!

    WPlum
  • AribaAriba Posts: 2,690
    edited 2014-10-14 13:15
    wplum wrote: »
    Thanks all. I am trying to communicate with a serial device (2400, 8E1). The device can be set to send blocks (56 bytes) of data every second or in a polled mode. Currently available spin OBJ's apparently are all 8N1. (except Andy's Tx)

    Andy - Thanks for your posting. This should get the polled method of getting data working... if only somehow the parity (E) can be ignored on the prop receiving data.

    Any other lights going on for resolution of this problem.
    Hardware UART? is there an SPI, I2C chip available?

    Sorry my previous post was a bit missleading. If you set my object to 9 bits, with Even parity and 2400 Baud then you should be able to communicate with your serial device.
    On transmitted bytes (from the Propeller side) the E-parity is inserted automatically so the Serial device is happy. On received bytes the Assembly driver receives 9 bits, but does not check the parity and also does not pass it to the Spin Rx methodes. In fact the parity is just ignored, but the Serial device does not know this and should not have any problems with that.
    The reason to not pass the received parity to Spin is that it would need a 9 data bit wide buffer. But we only could make 16 bit wide buffers with 7 bits wasted. Because the receive buffer can be made very big, I dont have implemented wider buffers. And what can Spin do if the parity was wrong? To handle it right the Serial device needs to be informed and it has to resend the byte, but that is only possible withcomplicated protocols. So for a simple object it's the best to not test the parity on received bytes.

    Andy
  • Bobb FwedBobb Fwed Posts: 1,119
    edited 2014-10-15 14:34
    Cluso99 wrote: »
    All I have seen are 8N1.
    I posted a version FullDuplexSerial_rr004 in obex that has variable buffer length to 256 (in powers of 2) so you can easily change to 128.

    I came on the forum today just to look for a large buffer FDS object, and you're already helping someone with it. Thanks! It's going into my project!
  • wplumwplum Posts: 6
    edited 2014-10-16 09:29
    ANDY: Thanks for clarification. Having problem locating FD_SERIAL_CONF.SPIN (Configurable for Parity) Could you please re-post or provide link. Thanks. WPlum.
  • AribaAriba Posts: 2,690
    edited 2014-10-16 09:40
    Here you are...
    spin
    spin
    FD_Serial_Conf.spin
    9K
    zip
    zip
    FD_Conf.zip
    3K
  • wplumwplum Posts: 6
    edited 2014-10-16 18:34
    The link to FD_Serial.Conf.spin you provided is to "attachment.BHP" <http://forums.parallax.com/attachment.php?attachmentid=111468&d=1413477609> which I can't do anything with.Still floundering !!X!! I am new to forum methods. Is there a trick I should know?

    I guess if this was easy someone else would be doing it.
  • AribaAriba Posts: 2,690
    edited 2014-10-16 19:16
    Not sure what happens on your side. I see a .spin file and when I click on it it gets downloaded.
    What Browser / Platform do you use?

    I have attached now also a ZIP - hope this works.

    Andy
  • DavidZemonDavidZemon Posts: 2,973
    edited 2014-10-16 19:40
    Here ya go. I've uploaded it to my site for you.
    http://david.zemon.name/downloads/FD_Serial_Conf.spin
    My only guess is that you have something disabled in your browser that keeps for the forum software from resolving the link correctly.
  • msrobotsmsrobots Posts: 3,709
    edited 2014-10-17 21:30
    wplum,

    this is a issue with the forum. I complained about this a couple of month ago.

    all download links appear with the filename attachment.php on IE as browser.

    Since nobody at parallax appears to use Windows and IE it just gets ignored.

    Solution is to type in the correct filename and extension while saving the file. Then the download works fine.

    Enjoy!

    Mike
  • wplumwplum Posts: 6
    edited 2014-10-19 20:57
    Mike/Andy:
    Changed from IE11 to Firefox and problem not... FD_Serial_Conf.spin‎ downloaded as one would expect. Problem is with Parallax forum & IE11. Just the kind of issues we need eh?
    Onward we charge!

    Thanks to all (Moderator taking notes?)
Sign In or Register to comment.