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

More
21 Feb 2016 21:57 - 21 Feb 2016 21:57 #70459 by PCW
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
Last edit: 21 Feb 2016 21:57 by PCW.
The following user(s) said Thank You: sirop

Please Log in or Create an account to join the conversation.

More
29 Feb 2016 13:10 - 29 Feb 2016 21:13 #70806 by sirop
Last edit: 29 Feb 2016 21:13 by sirop. Reason: commit typo

Please Log in or Create an account to join the conversation.

More
24 Mar 2016 05:33 #72081 by sirop
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?

Please Log in or Create an account to join the conversation.

More
24 Mar 2016 14:00 #72091 by PCW
The following user(s) said Thank You: sirop

Please Log in or Create an account to join the conversation.

More
24 Mar 2016 14:08 #72092 by sirop

10 MBaud


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

Please Log in or Create an account to join the conversation.

More
24 Mar 2016 14:15 - 24 Mar 2016 14:29 #72093 by PCW
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
Last edit: 24 Mar 2016 14:29 by PCW.
The following user(s) said Thank You: sirop

Please Log in or Create an account to join the conversation.

More
26 Mar 2016 16:30 #72186 by sirop

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.

Please Log in or Create an account to join the conversation.

More
09 May 2016 15:17 #74411 by sirop

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
hm2_pktuart_setup(PktUARTInstanceName, BAUDRATE , 0x0ff20,  0x007f08,1,1);

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:
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 42 0x06
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 43 0x0e
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 44 0x00
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 45 0x0b
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 46 0x70
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 47 0xd0
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 48 0xc7
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 49 0x85
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 50 0x70
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 51 0xd0
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 52 0x75
May  9 07:03:19 debian-slave msgd:0: hal_lib:5386:rt Reply frame 1, byte 53 0x65

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...

Please Log in or Create an account to join the conversation.

More
09 May 2016 16:03 #74415 by PCW
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)
The following user(s) said Thank You: sirop

Please Log in or Create an account to join the conversation.

More
09 May 2016 17:04 #74416 by sirop

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:
if (buff != inst->bitrate){
        inst->bitrate = buff;
        r += hm2->llio->write(hm2->llio, inst->rx_bitrate_addr, &buff, sizeof(u32));
        r += hm2->llio->write(hm2->llio, inst->tx_bitrate_addr, &buff, sizeof(u32));

        /* http://freeby.mesanet.com/regmap
        The PktUARTx/PktUARTr mode register has a special data command that clears the PktUARTx/PktUARTr
        Clearing aborts any sends/receives in process, clears the data FIFO and 
        clears the send count FIFO. To issue a clear command, you write 0x80010000
        to the PktUARTx/PktUARTr mode register.
        */
        buff = 0x80010000;
        if (txclear==1)
            r += hm2->llio->write(hm2->llio, inst->tx_mode_addr, &buff, sizeof(u32)); // clear sends, data FIFO and count register
        if (rxclear==1)
            r += hm2->llio->write(hm2->llio, inst->rx_mode_addr, &buff, sizeof(u32)); // clear receives, data FIFO and count register
    }
the final if-bracket comes too late, it should be in line 180.

Just tested my component with explicitly:
 u32 buff = 0x80010000;
 hm2->llio->write(hm2->llio, inst->rx_mode_addr, &buff, sizeof(u32));
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.

Please Log in or Create an account to join the conversation.

Time to create page: 0.334 seconds
Powered by Kunena Forum