FullDuplexSerial2.spin for use with FastSpin/PropTool and the P2

msrobots

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.

attached now
v1.4 - 01/05/2023

Enjoy!

Mike

evanh

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.

msrobots

@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

evanh

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.

msrobots

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

AJL

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.

msrobots

yes;

"however this doesn't prevent incorrect elimination of non-echoed byte"

is what scares me so I will not implement that.

Mike

msrobots

just added v1.3 - 07/22/2019 to the first post. on strin one can now switch echo on or off.

Enjoy!

Mike

RossH

Hello msrobots

There is an error in this driver - line 927 should not be there. The line is:

shr rx2_i_char, #32-8 'shift char to lsb justify

This line stops the second serial port from receiving characters correctly. The line is a duplicate of line 922. Removing line 927 fixes the problem.

rossh

pilot0315

@msrobots
I have been away from the Prop2 etc for over a year. I was using your FDS2 in FlexGUI.
Have not tried it in Pnut or Prop tool 2.6.2. Would there be any issues?
Thanks.
Martin

FullDuplexSerial2

msrobots

should not, i wrote it with proptool. But rossh found a bug, see his post above

Mike

pilot0315

@msrobots

Thanks. I will install it and let you know.
Martin

pilot0315

@msrobots
I saved it to the library for prop tool 2.6.2
I can open it. But when I tried to obj it I get this error. Is there something I am missing when adding it??
Thanks.

whicker

You have an extra space character after the 2

evanh

The important details

pilot0315

I will check that!!!!!!!!!!

msrobots

Finally I had some Propeller time and updated FullDuplexSerial2.spin2.

FullDuplexSerial2 is a 2 port serial pasm driver with rx and tx buffer in the lut. It basically needs 4 longs in HUB as mailbox and can be used nicely from PASM and SPIN.

I put the bugfix of @RossH in, changed method names to match FlexSpin's Driver and added some Documentation of the Source using the nice Spin-Documenter @"Phil Pilgrim (PhiPi)" offers at http://www.phipi.com/cgi-bin/spin2html_cgi.pl, works for P1 and P2 Spin, but you need to rename .spin2 to .spin to use it, maybe Phil can add the .spin2 extension to the accepted file extensions.

This now compiles with FlexSpin AND PropTool.

Enjoy!

Mike