Teensy 4.1 + LinuxCNC

Could this be circumvented by modifying the hm2 driver? How difficult would that be?

I think only spaces 0,2,and 4 are used but none are actually necessary for
a simple interface except space 0.

On the other hand implementing all the hm2 discovery logic doesn't really make sense
if you have a simple relatively hardwired remote device. So while hm2_eth might be
used as a guide for the basic Ethernet communications, It would probably be best to
start a much simpler driver from scratch.

PCW wrote: The issue is a missing LBP16 Ethernet EEPROM memory space ( the hm2 driver uses this
space to read the MAC address ) I actually think this is a mistake and the MAC address of
the remote device should be retrieved in a more generic manner, but that is why you are
getting this error...

The linux kernel knows the MAC address of the remote device via ARP protocol, else it couldn't communicate with it. But I don't know off the top of my head how to find out about a mac address from a c program, but probably some ioctl(2) on a socket will be involved. Also, the driver shouldn't need it if it is talking UDP.

JakaP wrote: Could this be circumvented by modifying the hm2 driver? How difficult would that be?

Hostmot2 lbp protocol is very generic and includes stuff like process data and parameter discovery. Modifying the hm2_ driver to avoid a simple query at startup time doesn't really make sense, most of the stuff thats needed for that will have to be implemented anyways. IMHO.

A sensible first approach would be to implement a linuxcnc hal component that exports a "read" and "write" function. Read would request current data via UDP, vs. write would send current process data to the teensy. Type and number of "process data" and peripherals in the teensy like digital/analog I/Os, stepgenerator(s) etc. would be hardcoded, so no discovery would be needed.

Thank you rmu and PCW for your inputs. Over the last few days, I wrote simple C++ routines to communicate with teensy using custom message packets and a system call interface (sys/socket.h). Currently, I am testing it with 12 byte messages sent from PC ((three 32bit integers) and 8 bytes return messages (two 32 bit encoder values) sent from Teensy. Running 10000 such communication packets is completed within 1250ms, meaning that on average, sending one command and receiving the answer takes 125 us.
So far I am pretty satisfied with the result. Next, I am looking forward to modify the code into a hal component, integrate it with linuxcnc and test it on the machine.

Edit:I added a third encoder, so now the 12 byte messages are sent in both ways. After I stripped the code on the microcontroller side and removed all serial communication between the udp transmit/receive cycles, one send/receive cycle is <80us only!

Liking the project and will keep watching. Good work and a tip o the hat to you.