General chat at the Stuttgart meetup drifted onto the subject of HAL
pin types, and a suggestion that all pins could be of type "double"
and it would still work. This may actually what the STMBL does.)
A double can exactly represent signed integers up to 43 bits, so this
would actually be an impro
How would that work when you need to match a pin type with an external data
structure?
eg. An ethercat 16 bit long pin or a gpio structure
Sometimes pins are manipulated as bit maps.
You really need to consult widely on that
Rod Webster
*1300 896 832*
+61 435 765 611
Vehicle Modifications Netwo
On 11.10.23 11:21, Rod Webster wrote:
How would that work when you need to match a pin type with an external data
structure?
eg. An ethercat 16 bit long pin or a gpio structure
Sometimes pins are manipulated as bit maps.
You really need to consult widely on that
I dont see how that doesnt fi
On Wed, 11 Oct 2023 at 10:24, Rod Webster wrote:
>
> How would that work when you need to match a pin type with an external data
> structure?
In most cases it will just work. Possibly with unused higher-order bits.
Unless anything is _relying_ on overflow, there shouldn't be any
difficult fixes.
Agree, you really have consult widely on that.
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. Some programming languages allow defining sub types for
example restrict range and even def
Den 2023-10-11 kl. 11:54, skrev andy pugh:
On Wed, 11 Oct 2023 at 10:24, Rod Webster wrote:
How would that work when you need to match a pin type with an external data
structure?
In most cases it will just work. Possibly with unused higher-order bits.
Unless anything is _relying_ on overflow,
On Wed, 11 Oct 2023 at 10:58, Nicklas SB Karlsson 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
On Wed, 11 Oct 2023 at 11:11, Nicklas SB Karlsson wrote:
> Encoders are commonly used in Linuxcnc and do overflow. However not sure
> if this i a big problem since it fit inside a double.
That's one of the things I want to fix.
> Then there is for example a double output a unsigned or signed 16
Den 2023-10-11 kl. 12:13, skrev andy pugh:
On Wed, 11 Oct 2023 at 10:58, Nicklas SB Karlsson 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
Here is another example where a 16 bit word is decoded into individual pins
but the word is also used as a pin
typedef union
{
struct
{
unsigned char SwitchOn: 1; // 00
unsigned char EnableVoltage : 1; // 01
unsigned char QuickStop : 1; // 02
unsigned char En
Seems like there could be a significant performance hit for 32 bit
architectures. We don’t directly use LinuxCNC, but EMCApplication is a shallow
fork of LinuxCNC that will occasionally pull from upstream. We use
EMCApplication on the BeagleBone Black, which is a 32 bit architecture and is
alre
On Wed, 11 Oct 2023 at 12:01, Rod Webster wrote:
>
> Here is another example where a 16 bit word is decoded into individual pins
> but the word is also used as a pin
Well, it shouldn't be
The size of "unsigned int" is platform dependent, all HAL components
should be using the HAL types for th
On Wed, 11 Oct 2023 at 12:08, John Allwine wrote:
>
> Seems like there could be a significant performance hit for 32 bit
> architectures. We don’t directly use LinuxCNC, but EMCApplication is a
> shallow fork of LinuxCNC that will occasionally pull from upstream. We use
> EMCApplication on the
>And if hal_u32_t was mapped into an S64 (as I am proposing) then
>nothing at all would need to change in this code.
I am fully aware data types can change with platforms but in this case,
this part time programmer knows what platform he is compiling for.
If the hal_u32_t Word in this instance is
On Wed, 11 Oct 2023 at 14:09, Rod Webster 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 doe
On 10/11/23 06:15, andy pugh wrote:
On Wed, 11 Oct 2023 at 10:58, Nicklas SB Karlsson 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 yea
That’s correct. We are using MachineKit-HAL for its instantiable components and
better HAL Python bindings. Hopefully that functionality could make its way
back into LinuxCNC at some point.
> On Oct 11, 2023, at 5:53 AM, andy pugh wrote:
>
> On Wed, 11 Oct 2023 at 12:08, John Allwine wrote:
> 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 documenti
On Wed, 11 Oct 2023 at 20:33, Rod Webster wrote:
> 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 hav
Den 2023-10-11 kl. 21:31, skrev Rod Webster:
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
number of HAL pin types.
On Wed, 11 Oct 2023 at 20:33, Rod Webster wrote:
> 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 coul
On Thu, 12 Oct 2023 at 04:05, Chris Morley wrote:
.
> I assume you would use a feature branch to start anyways, so we could see
> what problems crop up and assess.
Yes, this is definitely not something to drop straight into master. (or 2.9)
--
atp
"A motorcycle is a bicycle with a pandemonium
. (GMT-08:00)
To: EMC developers
Subject: Re: [Emc-developers] RFC: Reduce number of HAL pin types.
On Thu, 12 Oct 2023 at 04:05, Chris Morley wrote:
.
> I assume you would use a feature branch to start anyways, so we could see
> what problems crop up and assess.
Yes, this is definite
pugh
Date: 2023-10-12 1:57 a.m. (GMT-08:00)
To: EMC developers
Subject: Re: [Emc-developers] RFC: Reduce number of HAL pin types.
On Thu, 12 Oct 2023 at 04:05, Chris Morley wrote:
.
I assume you would use a feature branch to start anyways, so we could see what
problems crop up and assess.
Yes
24 matches
Mail list logo
