Using pktuart with 7i80hd

The header pktuart because this is how I started testing. When the problems came I switched to mesa_uart because I generated the pktuart bitfile. The uart bitfile was made by Peter, sure good

Of course I fixed the mesa_uart name pointer problem. Linuxcnc is from github. I'm attaching the mesa_uart.comp file, please take a look.

I'm interested in this. Does using pkt_uart still require a bitfile to expose the UART? If so, a freeby for the 7i96 UART based on Peter's *pl.bit file would be something I'd like to play with.

I see PhillC has an Arduino based simulator of a Hypertherm plasma cutter so it would be cool if we could access a plasma cutter using the UART.

I checked on another machine (Asrock motherboard + i5 cpu) the mentioned two errors are the same.

Eureka! There is a reason for the error.
Unexpected data on rx was caused by the unconnected free rx input. The random parsing error is caused by the MSI + AMD motherboard. (poor latency)
Sorry for the needless fright.
Now the task can come

This component has an RS232 serial interface. Uses Mesa's hm2_uart services to establish a connection and
transfer data. It's not quite ready yet, but it's good for us to discuss.
Comments and documentation are very poor yet.

Attention! For testing and review purposes only.

The package includes:
- rs232_uart.comp: The new component
- trs232.comp: rt mode test component
- pyrs.py: user mode test component
- rsrttest.hal: testing in rt environment
- rspytest.hal: testing in a usr environment
- 7i80hd_25_svstua4_12_4d.bit: bitfile

Use:
1) Extract to any directory
2) halcompile --install rs232_uart.comp
3) halcompile --install trs232.comp
4) halcompile --install pyrs.py
5) Download the bit file to the card
6) halrun -I rsrttest.hal or halrun -I rspytest.hal

I use a 7i80hd25 card with 1 uart configured in the test. The P3 port 1-3 pins need to be connected for operation.

Between the master and the uart component, tx-req and rx-req handshake signals controls the transmission of data.
The data is not stored as usual in hal-type arrays, but in char-type arrays. These arrays operate in circular
buffer mode. The attributes of the arrays are a read and write pointer and an overflow counter.

Originally I wanted to solve this with a byte stream, but not much information about HAL_PORT. I would like to ask the
experts what is the reason for this? Unsupported model or unstable operation?

I don't consider this solution the only one, it's good to get to know the basics. However, this can be useful in
simpler cases. According to my plans, the following would work on a pktuart basis.

Note: After a long time now I'm getting to know the deeper level of Linuxcnc, I welcome any criticism

I was able to work a bit with the uart handler. It already works with pktuart. The attached package contains the files.

Rs232_shm_pktuart works with send and read functions.
The client and the uart component communicate via shared memory. The client sends the data in packets (message). The first short int word of the message contains the length of the message. The send function breaks the message into max. 64-byte frames and sends it to fpga.
The read function builds the message from the received frames and sends it to the client in shared memory.

I encountered two problems (there are several but they can be solved):
1) It would be nice to have a tx_full indication.
2) If there is more than one frame in the message, the receiver holds the last frame. Not lost, enforced by the first frame of the next message.

For the first one, until I find a better one, I will use a handshake. Until the client responds, it will not send the next message. I need a dummy message to kick off the last frame. Alternatively, we can adjust the delay between two messages.
The second may be in the algorithm, but I can't find it:). It may be caused by the fpga bug.

Pult_shm.comp is a simple client simulator. After startup, sends num-msgs messages to the uart.
Repeat with halcmd:In case of a jam we can try to tune in with:
I use 7i80hd-25. The hardware loop requires p3-1 and p3-9 pins to be connected.

If anyone has an idea for mentioned two problems, it would help a lot.

Note: this is still under construction.

1. There's room in the mode register (10 bits) for a count of free doublewords in
the TX buffer, that might be a decent way to check TX status
2. I tested sending multiple frames and letting them stack up in the receiver
and didn't see an issue extracting the frames, but I can do this again or dig up the test code

Thanks for the quick response.

I created two logs that show the process of the frames

SEND is a TX lines
Pult and rest is RX lines

The first:
=== we sends 4 messages with value 0,1,2,3
SEND -- tx_msglen: 136, num_frames: 3
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 0
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 1
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 2
=== the last frame of the fourth message does not come, the message is not complete.

halcmd: setp pult.restart 1
=== another 4 messages.
=== First comes the missing frame from the previous package with value = 3,
=== then comes the new package
halcmd: SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 3
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 0
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 1
SEND -- tx_msglen: 136, num_frames: 3
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 2

This log shows the frames in the packages:

SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 1
>>>>B -> body = 64 bytes
SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 1
>>>>B -> body = 64 bytes
SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 1
>>>>A -> last = 8 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 0
>>>>Sum frames in pocket: 1
>>>>B -> body = 64 bytes
SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 2
>>>>B -> body = 64 bytes
>>>>A -> last = 8 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 1
>>>>Sum frames in pocket: 2
>>>>B -> body = 64 bytes
>>>>B -> body = 64 bytes
>>>>Sum frames in pocket: 3
>>>>A -> last = 8 bytes
>>>>B -> body = 64 bytes
>>>>B -> body = 64 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 2

halcmd: setp pult.restart 1

SEND -- tx_msglen: 136, num_frames: 3
=== This frame was missing from the previous message
=== The message is complete and goes to Pult
>>>>Sum frames in pocket: 1
>>>>A -> last = 8 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 3

SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 2
>>>>B -> body = 64 bytes
>>>>B -> body = 64 bytes
SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 1
>>>>A -> last = 8 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 0
>>>>Sum frames in pocket: 1
>>>>B -> body = 64 bytes
SEND -- tx_msglen: 136, num_frames: 3
>>>>Sum frames in pocket: 2
>>>>B -> body = 64 bytes
>>>>A -> last = 8 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 1
>>>>Sum frames in pocket: 2
>>>>B -> body = 64 bytes
>>>>B -> body = 64 bytes
>>>>Sum frames in pocket: 2
>>>>A -> last = 8 bytes
>>>>B -> body = 64 bytes
Pult -- RX: POTMETER -- len: 136 type: 2 op: 21 -- val: 2
>>>>Sum frames in pocket: 1
>>>>B -> body = 64 bytes

Maybe showing things....

I've seen similar behaviour when the receive FIFO/Frame count FIFO get out of sync
I'll test a bit here and show what I find