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

[schoone...@btinternet.com]

On 28/02/17 09:53, Matteo Facchinetti wrote: 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? Changes do not invalidate old style components. You can write a .comp component and specify that it is singleton, or the C equivilent. This still pertains for the thc and thcud components for instance.  I reverted them back to .comp, because the author only sought to support a single instance and specified it to be 'singleton', so having it as an instcomp made no sense (plus you now cannot specify singleton with an instcomp) Unless writing an instantiated component for 64 bit architecture, there is no need to use v2, because atomic ops are 64 bit. Just use i/o pins instead of params, because params will be deprecated in comp too eventually. If it is a board or device driver, then hal/drivers is probably the place for it, but don't worry too much about that, you will be advised if whoever reviews it feels it will fit better elsewhere. -- 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.