- From: David MacMahon <davidm_at_astro.berkeley.edu>
- Date: Wed, 12 Jul 2006 23:52:09 -0700
Frank Mori Hess wrote: > On Wednesday 12 July 2006 02:51 am, you wrote: >>I may not be understanding your idea fully/correctly, but it sounds like >>you're suggesting using GPTC resources to divide the external clock > > No, that's not what I'm saying. I'm saying I don't want different drivers > coming up with different configuration instructions to perform the same > function. Thanks for the clarification. I think it's a worthy goal of keeping a unified, abstract interface that doesn't diverge from driver to driver or board to board. That said, however, there will always be cases where one driver or board needs or provides some functionality that is not so ubiquitous or universal. For example, RTSI configuration is (AFAICT) unique to the NI drivers (and boards?), yet comedi.h defines an INSN_CONFIG_SET_RTSI_CLOCK_MODE configuration_id. Perhaps that functionality should ideally be addressed by a new (or existing?) configuration_id that is more generic and abstract. Another worthy goal (IMHO), is making it easy for the application programmer (the user of the driver) to create flexible and versatile applications. For example, if a program wants to be able to use either the internal clock or an external clock (e.g. based on a command line option or environment variable), it should be able to simply check the option, make the appropriate clock selection configuration, and then continue on with code that is independent of whether the internal or an external clock is being used. Using TRIG_OTHER for external clocks but TRIG_TIMER for internal clocks makes that programmer's job much harder. For the internal clock, TRIG_TIMER is very convenient since the _arg field specifies the number of nanoseconds and the driver computes the divider appropriately. On the other hand (pun partially intended), using TRIG_OTHER is very inconvenient (IMHO) because the programmer must both compute and configure (via INSN_CONFIG_TIMER_1) the divisors "manually". This is the ugliness that TRIG_TIMER so beautifully hides from the application programmer. From an application programmers point of view, I would much prefer always to use TRIG_TIMER (for timer based events) with its nanoseconds argument rather than have to worry about computing divisors and configuring them manually if I use an external clock. For the NI boards, an external clock selected via the INSN_CONFIG_SET_RTSI_CLOCK_MODE configuration_id becomes the primary timebase frequency of the entire DAQ-STC module (AFAICT). The TRIG_OTHER approach for external clocks requires that the programmer use TRIG_OTHER and INSN_CONFIG_TIMER_1 for everything that would have used a TRIG_TIMER with an internal clock. Of course, if the external clock has the same nominal frequency as the internal clock, then this discussion is moot (just configure to use the external clock and keep on using TRIG_TIMER); this discussion is only relevant if the external clock differs in frequency from the internal clock. Anyway, I've said more than enough on this topic. My patch works for me and I'm happy. If you still don't want to commit it (or suggest another alternative) I can respect that even if I don't agree with it. Thanks for the drivers! Viva la open-source! Dave
Received on 2006-07-13Z05:52:09