As a component author, one thing you can do with a parameter that you
can't do with an IN pin is "correct" an out-of-bounds value to the
closest permissible value.
For instance, take the 'pwmgen' component. The 'pwm-freq' parameter has
an upper limit related to its period (up to the frequency def
Subject: Re: [Emc-developers] parameter pins in components
>
> On Mon, Oct 03, 2011 at 06:31:33PM +, Chris Morley wrote:
>>
>> Am I missing something?
I recompiled the PID comp to make its Gains be Pins not Params as it was
very handy to connect them to VCP scale controls for tuning.
As yo
On Mon, Oct 03, 2011 at 06:31:33PM +, Chris Morley wrote:
>
> Am I missing something?
Not in my opinion. I think your guess about the original reasons,
your observation of the occasional annoyance, and the possible
solution of not using params at all is exactly in line with what
others have
I was wondering is there a reason for having param pins instead of just using
regular pins?
And related is there a good reason not to allow signals to connect to param
pins?
I could see the original idea that params should not change once set but in
practice
it is sometimes annoying that one c
IEEE 754 floats have a fully specified format, so they have no endian-ness
issues. The only degree of freedom is the resolution.
- Reply message -
From: "andy pugh"
Date: Mon, Oct 3, 2011 01:38
Subject: [Emc-developers] Single-precision datatype
To: "EMC developers"
On 3 October 2011
On 3 October 2011 03:33, Peter C. Wallace wrote:
> a "float" type is 99.9% IEEE 754 single precision (32 bit) these days since
> almost all hardware is now IEEE 754 (those running EMC on VAXes feel free to
> object :-)
Reading around a bit, it seems that "float" is very likely to be 4
bytes wid
