Teensy 4.1 + LinuxCNC

Hello everyone,

As many of you might know, recently, a Teensy 4.1 with native 100 Mbit ethernet came out. It offers 600MHz clock, 12bit ADC, 4 hardware encoders and plenty of other periphery such as FPU for 64-bit doubles and 32-bit floats, meaning all trigonometry calculations are supported by FPU Hardware. See more:
www.pjrc.com/store/teensy41.html

I am aware of similair projects in the past but those were running userspace components and are therefore not really suitable for RT applications: forum.linuxcnc.org/24-hal-components/287...rduino-over-ethernet

I wonder, what would be the easiest way to implement the RT HAL ethernet driver on the linuxcnc side? Is RTnet still a way to go in 2020?
forum.linuxcnc.org/27-driver-boards/2429...for-linuxcnc?start=0


Regards,
Jaka

Don't bother with RTnet. Just use preempt-rt kernel and a udp based protocol. It should be possible to reach 4kHz update rates (according to some tests with mesa hardware).

Thank you for pointing me in the right direction.
When using hm2_eth as is, I guess one would have to emulate the LBP16 register access protocol on the microcontroller. This looks quite complicated, but maybe not all adress-spaces are needed (or are they?).
Is there any HAL component for simple UDP communication besides hm2_eth component?

Not that I am aware of, but it should be relatively easy to copy relevant code from hm2_eth and implement a static protocol.

A small update: on the microcontroller side I have implemented a simple UDP communication. For now, whatever is sent over UDP, it is transmitted back to PC over serial communication, so I can verify that the connection is working. I tested the connection in both ways and was able to read the encoder values in terminal using netcat. Next step would be to replace netcat with hm2_eth.

For this, I adjusted the IP of the device to 192.168.1.121 and tried the following:

which failed while retrieving the mac address:


I have never worked with hostmot2 before. In the manual I read that the interface name should be set to "eth1", while mine is "enp5s0". Could this be a problem? I can otherwise retrieve the mac address without a problem with
Can somebody advise me how to set up and use hm2_eth with halrun?

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

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.