Re: [Machinekit] HAL driver dev: call a function when update a parameter

[schoone...@btinternet.com]

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. 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 can appreciate the desire to work within a model you are familiar with, I used to write a lot in Qt and used the signal/slot mechanisms for callbacks upon event a lot. The realtime polling does not add weight if programmed correctly. There could be problems with not checking for change at the same frequency that it can be set. Doing things in another thread with lower priorities may leave you dealing with changes that have since been superseded. It all depends exactly what you are doing and the frequency of any change and the required reaction time to it. 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. -- 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 machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.