hal: Update the hostmot2 drivers to getter/setter

[BsAtHome]

This is the last in the series to update the code base to the HAL getter/setter infrastructure.

The hostmot2 drivers are a very large interconnected set of drivers in several layers that are, unfortunately, difficult to migrate step by step. This PR needs to be reviewed and tested on real hardware before it can be merged.

All changes have been tested on a RPi5 with an 7i96s board+modbus. It is therefore known that at least the basic outline of the driver is functional and behaves as it has done before.

The main issue in porting the hostmot2 drivers (and also others) has been the (ab)use of parameters. Other drivers had similar problems, but they could be handled one-by-one. Parameters are now similar to pins, which means all use of parameters (as expensive local variables) had to be detected and adapted.

An important test is with attached smart serial board(s). The sserial driver is known to have some quirks and has code that needed special attention while porting. Note that the sserial/abs_encoder part has been internally changed slightly. The Fanuc style absolute encoder had an overlapping value, which now has been untangled. It should not change behaviour or appearance for the user, but it is nice if it can be tested, just like the other absolute encoders.

It is also necessary to test this with a variety of boards, both networked and local PCI bus boards (and others). Also, the more configurations that can be tested, the better we can guarantee that no hidden defects are present.

@pcw-mesa you probably have most hardware, somewhere. Have a go, please, with different setups if possible.
@rene-dev you have tested earlier with a smart serial board, please try again.

Anybody else, please test and report.

Edit to add:

• The step_type parameter in ...stepgen.NN.step_type is now capped at 16 to prevent read/write to unknown memory. There may be more failure modes when you set step_type to larger than 16, but that has not been considered.
• A bug in pwmgen that failed to consider all run-time config changes has been fixed (closing '}' misplaced). This should not alter operation or function.
• This does not fix Hostmot2 sserial state machine reassigns state unconditionally #4144 and its behaviour is not changed to prevent mixing old and new failure modes.
• This PR does fix Use, abuse or erroneous implementation of overlapping hal_float_t/hal_u32_t #4130 because the getter/setter update needed to untangle the access. The overlapped data access while also exporting that data as parameter does no longer function because parameters work similar as pins now.
• A bug in pwmgen when the firmware has no pwmgens was exposed with HAL's internal changes to add more checks. This has also been fixed. (see: hal: Update the hostmot2 drivers to getter/setter #4369 (comment) below)

[grandixximo]

Was wondering why it was so quiet here...
I see something was cooking...
Just a small patch hey...

Might be able to test on a 5i25 as well.

[BsAtHome]

For people who use stepgen and set the ...stepgen.NN.step_type parameter to anything larger than 16 will now have it capped to 16. You'd be reading/writing data to undefined memory and can crash.
So, any change in step behaviour should be reported only when you have verified that you did not set step_type larger than 16 in your config. Otherwise you first need to fix the config and re-test.

[pcw-mesa]

I can check some of this next week.

[grandixximo]

Built and tested on the 5i25
One bug found: zero-instance module descriptors (PWMGen x0 on some firmware) abort board registration via the new hal_malloc() size check.
Workaround for me was num_pwmgens=0 , but it should be fixed, default is -1 but it crashes, so limit to 0?

Also noticed a small detail while testing mode 20, we may want to fix here:

You requested is all in one word, the is a space missing...

Other than those minor things, it works well (on a bench test with only the 5i25 plugged in), tested a few firmware, stepgen pwmgen, encoder, all good.

I did what I could with sserial I don't actually have an sserial devices but the firmware loads ok, at least no regression there, Rene's symptoms from #4247 are untested without 7i76 or friends which I don't have.

[Sigma1912]

Testing with 7i95T with a 7i84 connected on smart serial looks fine to me.

Connected input and output signals work correctly.

Branch tested:

user@debian:~/git/bs_hostmot/src$ git status
On branch halgs_hostmot2
Your branch is up to date with 'origin/halgs_hostmot2'.

[BsAtHome]

Built and tested on the 5i25 One bug found: zero-instance module descriptors (PWMGen x0 on some firmware) abort board registration via the new hal_malloc() size check. Workaround for me was num_pwmgens=0 , but it should be fixed, default is -1 but it crashes, so limit to 0?

A genuine preexisting bug. Fixed. The first check only handled the config (when you set num_pwmgens=0). There is now a second check for zero pwmgens before the hal_malloc that checks the number actually present.

Also noticed a small detail while testing mode 20, we may want to fix here:

A preexisting text error, also fixed.

[grandixximo]

A genuine preexisting bug.

Yeah, a bug that was not biting till your changes though...🐞