Reading UART Rx count register on Mesa 5i25/6i25

1. Either way should work. I like the first better
2. TX frames (the sum of all frames) can be up to 2048 bytes max but depends on a compile time constant
in hostmot2.vhd currently this is 1024 bytes (256 x32 bit)
3. 1 clock low cycle so ~30 ns (much faster than a single PCI access cycle)
4. RCFIFO errors are only due to overflow and underflow of the receive count FIFO
But I have to check. I may need to push false start data to have this work properly
Also I will be adding a digital filers on the rx UART input so be advised that the
bit rate register will gain a 12 bit field for the input filter constant

Added man files: github.com/sirop/machinekit/commit/43c8c...6a48c503febf3e9a2036

Ok, machinekit PR is there: github.com/machinekit/machinekit/pull/901

@andypugh I'll try to do a LinuxCNC PR today or tomorrow.

@PCW
As soldering faults on self made RS232 converters are so discouraging,
I looked at your
store.mesanet.com/index.php?route=produc...74_78&product_id=263

But what is its max baud rate?

10 MBaud

PCW wrote:

10 MBaud

It means RS232 input can be also up to 10Mbaud?

our adapter is just for TTL ( typically from FPGA ) to RS-485
(sorry was looking at a different adapter not sure its on the store)

store.mesanet.com/index.php?route=produc...ct_id=192&search=485

is the one I was thinking about

sirop wrote:

Ok, machinekit PR is there: github.com/machinekit/machinekit/pull/901

@andypugh I'll try to do a LinuxCNC PR today or tomorrow.

github.com/machinekit/machinekit/pull/901 merged.

github.com/LinuxCNC/linuxcnc/pull/48 awaiting merge.

PCW wrote:

our adapter is just for TTL ( typically from FPGA ) to RS-485
(sorry was looking at a different adapter not sure its on the store)

store.mesanet.com/index.php?route=produc...ct_id=192&search=485

is the one I was thinking about

I did not see your edit in March and maybe my question was too vague.
I actually wanted to know if store.mesanet.com/index.php?route=produc...74_78&product_id=263
has the same functionality as sysbas.com/modules/catalogue/detail.php?...eld=&keyword=&page=1 ?

Apart from this I made further experiments with PktUART driver about provoking error conditions.
Do not know if I should formulate these as questions or just write them down for the record. Anyway.

Provoking a sticky RCFIFO Error.

1. Let your device be configured to be in streaming mode in the EXTRA_SETUP function of the component
2. Add yout receive/read functuion to a thread, butdo not start thread immediately, wait some time, for instance, 5 seconds
3. Only the start the thread

Result: sticky RCFIFO Error which cannot be reset with something like
I cannot tell if this RCFIFO Error is caused or accompanied by the RxOverrunError,
as RxOverrunError means " no stop bit", but I have to have a buffer overrun
and therefore Rx Counter overflow, because my waiting for 5 seconds before starting the thread
let 58*100*500 bytes arrive at the PktUART instance.


Simulating cable breach.

In the "field" a cable breach or unintentional unplugging can happen.
So we simulated this case by unplugging the DB25 connector from the daughter card.

If we had luck and unplugged between frames, then our component could resync
after re-plugging the DB25 connector.

If we had no luck, then a frame transmission was interrupted and an incomplete frame arrived in the buffer
of the PktUART instance. After re-plugging and resetting all registers the Rx Counter told us that we received, say, 50 bytes
which is the frame length to be expected. However the incomplete frame was still in the buffer,
so we could only read out Y bytes of the old incomplete frame + 50-Y bytes of the new complete frame.
This kind of "shifting" repeated itself in each thread cycle. Even this were not the worst case,
as this "shifting" has a constant index and can be dealt with by "re-shifting" of the data read out within our component.

However, we wanted to see if the data - although shifted - is not corrupt or invalid.
What we saw, was rather strange. It was a pattern like this:
Normally, there should be 6 bytes +2 bytes of Fletcher Sum beginnning with 0x06,
after that a new frame should begin with 0x75 0x65.
In this special case we see 10 bytes (not 8) beginning with and including 0x06
before the next frame starts with 0x75 0x65. Even more strange is that within this pattern
there is another pattern: 0x70 0xd0 is kind of "reflected" around 0xc7 0x85.
This sub-pattern repeats also each cycle - with other values.

I did not do any index manipulation, just printed out data as I can read them from the Rx Buffer...

If you re-connect in the middle of a frame, there is no guarantee that any async ( start-stop ) UART can resynchronize until there is a gap between transmissions.
This means all data after a connection in the middle of a frame is likely to be garbage, until the UART can resynchronize (this is data dependent of course but a minimum 1
character gap is needed to guarantee synchronization)

a RCFIFO error must be reset with a full UART reset (0x80010000 to mode register)

What gap do you have between frames?

To avoid overflowing at startup, i would not set RXenable until the thread is running

There probably is a way to do better synchronization to avoid partial and unsynced frames (maybe a hardware timer that waits for a specified idle period after RXEnable is set before it listens to RXData)

PCW wrote:

If you re-connect in the middle of a frame, there is no guarantee that any async ( start-stop ) UART can resynchronize until there is a gap between transmissions.
This means all data after a connection in the middle of a frame is likely to be garbage, until the UART can resynchronize (this is data dependent of course but a minimum 1
character gap is needed to guarantee synchronization)

a RCFIFO error must be reset with a full UART reset (0x80010000 to mode register)

You are right, my fault... as I just found a bug in my own PktUART driver:
github.com/machinekit/machinekit/blob/ma.../pktuart.c#L176-L192:the final if-bracket comes too late, it should be in line 180.

Just tested my component with explicitly:and could not reproduce none of the above test cases.

I'll test it a little bit more and prepare tomorrow a PR for LinuxCNC and Machinekit.

Thanks.