FullDuplexSerial2.spin for use with FastSpin and the P2

FullDuplexSerial2 is a spin-off of my cogserialpasm driver.

FullDuplexSerial2 is a LUT-buffered Serial driver providing not just one but optional two serial fullduplex connections.

I integrated the way FastSpin uses common serial routines (adapted for 2 ports), so it will fit well next to the two other drivers fastspin provides, using the same syntax.

So you have all the common output functions plus a string input function. The driver also provides additional async functions to start a read or write of blocks of HUB memory while doing something else and just poll for completion.

In opposite to the both existing 2 drivers included in fastspin, this driver does support the mode parameter, currently just the first two bits, inverting RX and/or TX.

Adding open drain is easy possible, I just haven't figured out what setting I want/need to use. On echo suppression I am completely at lost how to implement that with a buffered driver at all.

Enjoy!

Mike
I am just another Code Monkey.
A determined coder can write COBOL programs in any language. -- Author unknown.
Press any key to continue, any other key to quit

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.

Comments

  • Echo suppression can be viewed practically as a blanking time. You have a window in which to transmit and a specified turnaround gap after. So the handler doesn't really have to know anything about the transimitted data other than when it was completed. All echoed/received data during this period can be generically binned in null. Or diverted for diagnostics if you like.

    Regarding the timing of turnaround. nothing can delay the TX bit shifter from completing so time required for the hardware to finished shifting last bits is a fixed interval. Add a little more to the timer and then toggle DIR to allow real incoming data arriving after the turnaround gap has elapsed.

    It's important that you provide (specify) at least a small turnaround gap so that the receiver hardware can correctly sync to the start bit of a different data source. Your TX hardware has to release the line and this may result in a state change, or at least a glitch. This glitch needs time to be ignored so it doesn't get treated as a valid start bit of the reply.

    Which means your blanking time is a little longer than even your TX drive time.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • @evanh,

    I appreciate your posts, sadly they go over my head, often. So I try to explain what happens in order of execution and you might be able to give my a more detailed hint.

    1. the COG using/calling FullDuplexSerial2 wants to send a byte.

    2. the main process in the cog of FullDuplexSerial2 takes the byte and writes it into its LUT buffer. Transaction finished.

    3. int3 fires every 100 sys clocks, looks if there is something to send, if yes it looks if the SmartPin Hardware is able to accept a new byte into the output buffer of the Pin, if yes puts it into the Pin Buffer. Transaction finished.

    4. at some time after (depending on baudrate) the SmartPin sends the byte serial and the receiver sends a echo back (at what time?)

    5. the byte gets received by the HW of the RX SmartPin and after fully received the SP generates a interrupt that a byte is ready and the interrupt routine writes the byte into the receive buffer in the LUT.

    But between 1. and 5. can be a large gap since when the buffer is say half full 512 bytes have to get transferred out before the particular byte is send.

    On the other hand it is full duplex, so the other side can send its own stream while receiving, and is now mixing its own data with the echoed data.

    Since the other side can also be a buffered driver the delay time between sending a byte and receiving a echo seems not to be calculatable for me.

    My current guess is that echo suppression can just work half duplex and without buffering.

    Right? Wrong?

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • Ah, those last few sentences sounds like we are not using certain terms for same reasons:

    Echo is not a reply from another device. Echo is your outgoing tx data being received on your rx pins because the two are tied together.

    It's impossibly for multi-drops like RS485 or CANbus to use simultaneous two way comms that full-duplex offers. Any attempt by another sender at the same time will garbage the data stream. These systems are half-duplex, no if's or but's.
    "There's no huge amount of massive material
    hidden in the rings that we can't see,
    the rings are almost pure ice."
  • Now your short gap makes sense to me, a echo is just there on half-duplex over one line!

    RX is reading its own TX. OK. I am still not sure how to handle this with my SmasrtPin usage, but maybe I figure out something.

    Lucky as I am @Peter Jakacki gave me the values I may need for open drain/source, and I can at least support now 3 of 4 bits of the original mode parameter.

    Getting somewhere,

    Mike
    I am just another Code Monkey.
    A determined coder can write COBOL programs in any language. -- Author unknown.
    Press any key to continue, any other key to quit

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this post are to be interpreted as described in RFC 2119.
  • msrobots wrote: »
    @evanh,

    I appreciate your posts, sadly they go over my head, often. So I try to explain what happens in order of execution and you might be able to give my a more detailed hint.

    1. the COG using/calling FullDuplexSerial2 wants to send a byte.

    2. the main process in the cog of FullDuplexSerial2 takes the byte and writes it into its LUT buffer. Transaction finished.

    3. int3 fires every 100 sys clocks, looks if there is something to send, if yes it looks if the SmartPin Hardware is able to accept a new byte into the output buffer of the Pin, if yes puts it into the Pin Buffer. Transaction finished.

    4. at some time after (depending on baudrate) the SmartPin sends the byte serial and the receiver sends a echo back (at what time?)
    The receiver echoing data (resending the data received from the other party) is not an automatic function of a duplex (ANSI terminology: full-duplex) channel as the Tx data and Rx data exist on separate wires (or pairs), and when used both devices need to manage it properly or the channel will quickly saturate with copies of sent bytes. What you are looking to suppress is called remote echo.
    msrobots wrote: »
    5. the byte gets received by the HW of the RX SmartPin and after fully received the SP generates a interrupt that a byte is ready and the interrupt routine writes the byte into the receive buffer in the LUT.

    But between 1. and 5. can be a large gap since when the buffer is say half full 512 bytes have to get transferred out before the particular byte is send.

    On the other hand it is full duplex, so the other side can send its own stream while receiving, and is now mixing its own data with the echoed data.

    Since the other side can also be a buffered driver the delay time between sending a byte and receiving a echo seems not to be calculatable for me.

    My current guess is that echo suppression can just work half duplex and without buffering.

    Right? Wrong?

    Mike

    The advice evanh is giving is for local receive suppression (technically this isn't echo from a serial comms perspective) which is only needed for simplex (ANSI terminology: half-duplex) links.

    In reading the source for Full-Duplex Serial Driver 1.2 from the OBEX (and the derivatives thereof) the rxtxmode bit only appears to be tested in the spin code, and if set calls the Rx method directly before returning to the calling program. This seems to work by immediately intercepting the next received byte, assuming that it will be the echo; this is a fair assumption if you tie the Tx and Rx pins together, but may not be so if you are using remote echo with another system.

    One option for what you are trying to do, is to maintain a circular Tx buffer and compare the received bytes against those previously sent to eliminate the echoed bytes; however this doesn't prevent incorrect elimination of non-echoed bytes that happen to match previous transmissions.
    If you control the code for both ends of the interface and the hardware supports it, an alternative could be to (ab)use even/odd parity to identify the origin system for the eight bit bytes. A parity test on the received frame can then determine whether it should be put in the receive buffer or not.
Sign In or Register to comment.