On 27/02/2017 15:25, [email protected] wrote:
On 27/02/17 11:15, Matteo Facchinetti wrote:
OK, now I understand (I hope...).
V1 components parameter are referenced by a pointer that could be
used to direct access the value and
this is the reason that force to pool the parameter to get the last
value.
So the best place to do that is where use it, in this case, in the
realtime main loop of my driver component
checking old/new value and then update my control word.
Is this right?
v1 pins are effectively pointers to a memory area holding their values
You should be aware that params are deprecated and now not used in
instantiable components at all, just maintained for legacy .comp
components.
params originally came into being, because pins could not be
initialised upon creation to defaults.
Now they can, so you should use an IO pin of the relevant type instead.
OK, clear.
This is the missing information.
So, now a new components should never use params; only pins for all
things (physical pin, counters and params flags or control word)
I try to find V2 components but I don't understand where are used.
Where can I find information or example about V2 comp?
All the instantiable components have counterparts written as v2 (with
v2 added before the extension)
https://github.com/machinekit/machinekit/blob/master/src/hal/i_components/
At their simplest implementation, they just use pin_ptr s instead of
pins and use atomic accessor functions instead of pointer dereferencing.
The atomic operations are ones which are indivisible and guaranteed to
complete in one hit, which prevents a lot of problems with race
conditions when several
functions are trying to update or read the same value at the same time.
More complicated conditions where values are required to be updated or
read across different threads or even different cores can be dealt
with by ring_buffers or triple buffers,
depending upon the exact need.
There are some extremely complex examples in the components, such as
https://github.com/machinekit/machinekit/blob/master/src/hal/components/encoderv2.c
where Michael Haberler converted it to use atomic functions to pass
data between a fast and a slower functions within the component.
I am looking at cobbling some documentation together at present, but
it is work in progress right now.
In git this components are very recents... for this reason I'm not found
nothing.... aaarghh... I have cloned last month and never pull it again.
So, at the moment, to writing a new driver for an I/O module and make
sure to not use legacy or deprecated code, could be right say:
- write the driver in v2 format --> so add an extension v2 at the end of
the filename
- use only pins in V2 forms
I suppose, this driver is not an instantiable components because need
only one instance (is not possible to use more than one module a time),
so I put the code in hal/driver subdirectory?
Or, I should do like an instantiable components with only one instance
and put in hal/i_components? or hal/components?
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups "Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
