On 10/11/23 06:15, andy pugh wrote:
On Wed, 11 Oct 2023 at 10:58, Nicklas SB Karlsson <n...@nksb.eu> wrote:
Have programmed for many years and some programming languages have quite
hard check if data types fit together and think this in general is a
good feature.
And I have programmed _HAL_ for over 10 years, and so think that in
this case there will probably not be many problems.
One example of a useful simplification is that the pin
motion.motion-type has an output type of S32. The most common
components that you might want to connect this to are are "enum" and
"bitslice", both of which require an unsigned input.
There is also the probe input disabler, enables the probe blocking if
motion.motion-type is /=5. I use a select8 module for that.
S64 has more than enough bits to cover both situations.
How much trouble for the compiler when the target is armhf or arm64?
My lathe, running on an rpi4b seems to be ok running on Rod Websters
bookworm build for arm64, the latency-test results are poorer than my
original 4.19 preempt-rt armhf self built kernel, but still good enough
that I've not noted any stutter in its movements. Latency went from 12
microseconds to around the 75 area.
Much of that diff I suspect is due to the wider stack frame, but I've no
actual timing evidence to back that up. Perhaps Rod could comment?
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
