> In fact, in your sample code, the unsigned int Word _can't_ be being
> used as a HAL pin, as it's a simple int, not a pointer.
The code I shared was a typedef. But yes, the pins are created with
hal_pin_new*() so it would seem OK
The hal types do seem to be a well kept secret. How about documenting
them in the hal component generator documentation?
https://linuxcnc.org/docs/devel/html/hal/comp.html#_definitions

> The EtherCAT drive doesn't interface directly to HAL, does it? The
> actual register size transmitted down the wires is defined in the
> ethercat driver.

Andy the ethercat driver was written a long time ago and it's no
longer actively maintained from what I have observed. Yet it's used by
many many users and use of ethercat has been growing among our user
base. I've made some minor changes to it so it can be shared  via a
repository. Whether or not it would break with the proposed changes
would remain to be seen. I certainly would not profess to have the
skills to modify it if that were required.  So who is going to
maintain it? How many other drivers could be affected by your proposed
changes?

Look, I am only a casual programmer that dabbles on the fringes. You
guys are going to do what you want to do. But the point I wanted to
make is there are likely many cases you have not considered that could
break and some of them won't have an active maintainer. I still don't
understand why you want to give up one of C's strengths when
interfacing with hardware and that is the rich variety of type
definitions available.

Rod Webster
1300 896 832
+61 435 765 611
Vehicle Modifications Network
www.vehiclemods.net.au

On Wed, 11 Oct 2023 at 23:45, andy pugh <bodge...@gmail.com> wrote:
>
> On Wed, 11 Oct 2023 at 14:09, Rod Webster <r...@vehiclemods.net.au> wrote:
>
> > If the hal_u32_t Word in this instance is changed to an S64, how can you
> > guarantee that the S64 is mapped back to the hal_u32_t when it's written
> > back to the Ethercat drive that has an externally defined register size?
>
> The EtherCAT drive doesn't interface directly to HAL, does it? The
> actual register size transmitted down the wires is defined in the
> ethercat driver.
>
> Inside the code the _only_ variables which would need to change type
> are those whose pointers are passed to the hal_pin_new*() functions.
> And in any code written correctly, that would happen automatically if
> the hal_*_t definitions are changed.
>
> In fact, in your sample code, the unsigned int Word _can't_ be being
> used as a HAL pin, as it's a simple int, not a pointer.
>
> --
> atp
> "A motorcycle is a bicycle with a pandemonium attachment and is
> designed for the especial use of mechanical geniuses, daredevils and
> lunatics."
> — George Fitch, Atlanta Constitution Newspaper, 1912
>
>
> _______________________________________________
> Emc-developers mailing list
> Emc-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-developers


_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to