Teensy 4.1 + LinuxCNC

More
20 Aug 2020 09:45 #178812 by jakap
Teensy 4.1 + LinuxCNC was created by jakap
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

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

More
20 Aug 2020 12:22 #178820 by rmu
Replied by rmu on topic Teensy 4.1 + LinuxCNC
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).

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

More
22 Aug 2020 16:48 - 22 Sep 2020 19:42 #179013 by jakap
Replied by jakap on topic Teensy 4.1 + LinuxCNC
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?
Last edit: 22 Sep 2020 19:42 by jakap.

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

More
23 Aug 2020 13:44 #179099 by rmu
Replied by rmu on topic Teensy 4.1 + LinuxCNC
Not that I am aware of, but it should be relatively easy to copy relevant code from hm2_eth and implement a static protocol.

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

More
01 Sep 2020 17:34 #180343 by jakap
Replied by jakap on topic Teensy 4.1 + LinuxCNC
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:
halcmd> loadrt hostmot2
halcmd> loadrt hm2_eth board_ip="192.168.1.121"

which failed while retrieving the mac address:
hm2_eth: ERROR: 192.168.1.121: Could not retrieve mac address
hm2_eth: rtapi_app_main: Connection refused (-111)
<stdin>:2: waitpid failed /usr/bin/rtapi_app hm2_eth
<stdin>:2: /usr/bin/rtapi_app exited without becoming ready
<stdin>:2: insmod for hm2_eth failed, returned -1


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
sudo apr

Can somebody advise me how to set up and use hm2_eth with halrun?

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

More
01 Sep 2020 18:55 - 01 Sep 2020 18:56 #180346 by PCW
Replied by PCW on topic Teensy 4.1 + LinuxCNC
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...
Last edit: 01 Sep 2020 18:56 by PCW.

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

More
01 Sep 2020 18:59 #180347 by jakap
Replied by jakap on topic Teensy 4.1 + LinuxCNC
Could this be circumvented by modifying the hm2 driver? How difficult would that be?

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

More
01 Sep 2020 20:03 - 01 Sep 2020 20:03 #180351 by PCW
Replied by PCW on topic Teensy 4.1 + LinuxCNC
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.
Last edit: 01 Sep 2020 20:03 by PCW.
The following user(s) said Thank You: rmu, jakap

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

More
03 Sep 2020 13:47 #180546 by rmu
Replied by rmu on topic Teensy 4.1 + LinuxCNC

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.

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

More
03 Sep 2020 13:59 #180548 by rmu
Replied by rmu on topic Teensy 4.1 + LinuxCNC

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.

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

Time to create page: 0.092 seconds
Powered by Kunena Forum