Mesa programming and relationship with HAL

I watched the series of HAL videos by Feral Engineer, and learned enough to implement my first logic gate in HAL... baby steps.

My understanding is that most and perhaps all? of the logic running in the FPGA on the Mesa board is pre-programmed and the HAL file just defines the links between the various pre-programmed blocks within the FPGA and LinuxCNC?

Now if I come along and add say 10 AND gates to the servo thread using HAL, do those 10 AND gates get implemented in the FPGA or are those 10 AND gates implemented as code that gets executed sequentially by Linux as part of the servo thread that I assume gets called by LinuxCNC probably via an IRQ based on the servo thread interrupt rate.

If implemented as logic in the FPGA I would expect adding a lot of logic would have very little impact on the CPU running LinuxCNC, however if implemented as code to be executed by the LinuxCNC CPU it could start to add up and effect latency.

Can anyone shed any light on the subject?

 

The only thing in hal that affects how the FPGA runs is the hm2_eth (assuming you are using an ethernet based mesa card) component.

Here is the snippet from a HAL file of mine:

loadrt hm2_eth board_ip="10.10.10.10" config="num_encoders=1 num_pwmgens=1 num_stepgens=5 sserial_port_1=11xxxxxx"
setp [HMOT](CARD0).pwmgen.pwm_frequency 20000
setp [HMOT](CARD0).pwmgen.pdm_frequency 6000000
setp [HMOT](CARD0).watchdog.timeout_ns 5000000

In my case, I have 1 encoder, 1 pwmgen, 5 stepgens and a couple serial connections that are all running on the Mesa card. Everything else is all stuff that runs on the PC. Provided you aren't doing anything crazy, I wouldn't worry about performance. All the I/O connections in your HAL file are updated at the speed of your servo thread.

Your intuition is spot on. The FPGA has hard-coded modules like stepgens and pwmgens that can be configured/used (or not), but any custom logic you add to HAL runs on the main CPU. So yes, you do have to think about the code you throw there. A couple AND gates will make no big difference, but it does add serialized computation exactly as you suspected, i.e., it does not get "moved" into the FPGA.

I'd add that for any kind of modern / beefy computer, a few HAL entries for AND gates will make no noticeable difference in performance.  That is because the CPU is much faster than the servo thread interval, so there is plenty of free-time "left over" each cycle to calculate things like AND gates.

Where this starts to become a problem is on older, slower, smaller computers, such as a "spare" 20-year-old computer or a tiny single-board-computer like the Raspberry Pi 4.  These will have little time "left over" between servo thread intervals, so adding AND gates can start to cut into the servo thread timing and lead to issues.  (The RPi5 is considerably faster, however will not work with some cards currently.)

If unsure, make a copy of your config folder, comment-out the logic functions in one of them, then load each config into LinuxCNC and start the chips.ngc toolpath (or whatever gcode you have to torture-test your machine.)  Crank the speeds & feeds - if the AND-gates-config causes a fail, it's too much.  Could also open the latency tester during each run and see numerically how the timing jitter is affected.

rdtsc wrote:

I'd add that for any kind of modern / beefy computer, a few HAL entries for AND gates will make no noticeable difference in performance.  That is because the CPU is much faster than the servo thread interval, so there is plenty of free-time "left over" each cycle to calculate things like AND gates.
 

To follow up on this, at one stage I traced the kernel and was able to identify the real time servo thread (1 ms = 1000 usec). On a 4 core PC (celeron or i5, can't remember), we observed the thread was active for about 200 usec then slept for 900 usec. That meant the servo thread was only using 25% of the servo thread time slice so there was plenty of capacity for HAL.