Just to clarify.
setp does not create an event, it merely directly alters the memory
area allocated to the param value.
*setp param_name**value*
comes out as *
rtapi_mutex_get(&(hal_data_mutex));
*(param_name)**= value*
*rtapi_mutex_give(**&(hal_data_mutex)*);
(with a lot of code missed out)
Unlike higher level abstractions, where a GUI for instance hooks into
the underlying sub-system of the window manager
and receives a callback to a nominated function upon an event it is
interested in,
the components are based upon kernel modules, which are expected to
be stand alone entities, requiring the minimum of external resources.
It is precisely because of this direct 'bit fiddling' in memory
referenced from an offset, which is all based upon the x86 memory
map, that the multicore
work arose.
The v2 components use accessors to pin_ptrs, instead of direct access
to pin values.
Edit:
They operate ***without*** a lock which ensures that only one access
can be made
at a time and the value returned is ensured to be the latest one for
the pin, via a triple buffer mechanism.
mixing v1 and v2 in my head :)
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?
So,
Direct memory access provide to a parameter the way to be used in the
realtime context unless problems.
I think that's great if I need a parameter like a counter that need to
be updated in a realtime context.
In my case, I'd like to handle this parameters unless put check controls
and shifts in the main loop realtime task because for this parameters
don't have sense to reflect their value changing with realtime performance.
I think something like an other kind of parameter... i.e hal_user_param_t:
- not direct memory access
- not possible to use in realtime context
- change value only passing throught hal_userparam_set(),
hal_user_param_get()
- report the update event to the component driver, calling a callback
function.
Is this helpful for the entire project?
If others components have parameters like these
could be used to simplify and reduce the weight of the task in realtime
context.
I try to find V2 components but I don't understand where are used.
Where can I find information or example about V2 comp?
The update of values, still does not trigger an event however.
There are always many ways to do things, but since the component is
attached to a thread and polled every thread cycle, it can do its own
checking and then
act as appropriate within its own code, upon detecting a relevant change.
The easiest is probably just to store the 'old' value and at every
poll, check this against the current
value.
If they are different execute the code you want to.
Just need to make sure you initialise the param value properly when
the component starts.
Or is there an other way to make that?
Thanks in advance,
Matteo
--
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]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
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]
<mailto:[email protected]>.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
--
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.
