[subexp-daq] NURDLIB: Init fast vs Init slow for modules
Hans Toshihide Törnqvist
hans.tornqvist at chalmers.se
Thu Feb 29 18:04:19 CET 2024
Dear Günter,
Here is a hopefully quick summary of the not so long nurdlib history
(tl;dr at the bottom):
The idea of two init functions came from the v1290, which has a
controller for many settings that is really slow to talk to. 'init_slow'
would do the slow configs which one does not want to sit through too
much, and 'init_fast' the faster ones.
The crate calls 'init_slow' for all modules, does some checks, calls
'init_fast' for all modules, and for certain modules also calls an
optional 'postinit'.
Later came the idea to do online configuration while a DAQ is running.
Rather than splitting the init functions (or my mind) even further,
'init_slow' was taken as the non-online part (e.g. mapping) and
'init_fast' the online part (e.g. writing thresholds). Some controller
drivers have been buggy and reducing re-maps has been important.
Obviously, it turned out that some, or most, slow writes on the v1290
were useful to do online, so lots of things in 'init_slow' moved over to
'init_fast'. Voila, the names don't really make sense any longer...
The online feature has higher priority than the re-initialisation
nowadays, since the latter should be rare in a properly working setup.
Eventually there should be a refactoring which is great since it changes
so much at once. I even have another one ready to go into 'master', but
I didn't dare to push that onto others yet.
Now for the useful tl;dr part :)
Put mapping and things that should not be changed online in init_slow,
and everything else in init_fast. Everything that comes from
'config_get_*' could be changed online, I think.
Cheers,
Hans
On 2024-02-29 17:00, Weber, Guenter Dr. wrote:
> Dear friends,
>
>
> is there a clear rule what should happen in the two init routines? In
> which cases INIT SLOW is executed and how is that different from INIT FAST?
>
>
>
> Thanks a lot!
>
>
>
> Best greetings
>
> Günter
>
>
>
>
More information about the subexp-daq
mailing list