Hi Bob, Great job. :-D Do you have plan to port SPI to RTDM? Last time when I checked the rs232 driver in RTDM for omap3 still also had problem. I don't mind to work on that. But I am driver-challenged person.
Have a nice weekend. Everett On Sat, Aug 7, 2010 at 10:22 AM, Bob Feretich <[email protected]> wrote: > I completed porting my PWM timer driver to Xenomai. > I limited the heavy use of the dm_timer routines to the module_init and > module_exit routines. Other parts of the driver only used the dm_timer > routines that read and wrote timer registers. > > You guys did a great job defining and implementing Xenomai and RTDM. > Porting the Linux driver to RTDM was easy (2 days). It worked the first > time I got a clean compile! > > I have 4 pulse width modulated signals being output by the OMAP3 chip, 3 > are completely generated by hardware, the other is done by software > being activated by RT interrupts. When I examined the signals with a > scope, I couldn't tell which one was software generated. In the pure > Linux environment I was seeing 100-200 microseconds of jitter on the > software generated signal on a lightly loaded system. Under the same > conditions in Xenomai, there was no noticeable jitter. > > Thanks for your help. > Regards, > Bob Feretich > > On 8/5/2010 12:07 AM, Gilles Chanteperdrix wrote: >> Bob Feretich wrote: >>> I want to verify that my understanding of the RTDM driver structure is >>> correct. >>> >>> My driver is created as a module that is loaded by Linux insmod. Given >>> that... >>> >>> My module_init routine (and module_exit)... >>> * is executed in the Linux driver context. >>> * should use Linux spin locks and events instead of rt_locks and events. >>> * can call rtdm_irq_request (rtrm_irq_free) to register my interrupt >>> handlers >>> for rt interrupts. >>> * can call rtdm_device_register (rt_dm_device_unregister) to register >>> my rt device. >>> * can call Linux omap dm_timer routines to reserve general purpose timers, >>> so that Linux will not give my timers to others. (these routines >>> call Linux locks) >>> >>> My driver's open_nrt close_nrt entry points... (open_rt& close_rt are >>> deprecated) >>> * are executed in the caller's Linux user context, if the caller is a >>> standard Linux >>> user process. >>> * are executed in the caller's Xenomai user context (secondary mode), >>> if the caller >>> is a rt user process. >>> * can use Linux spin locks and events instead of rt_locks and events, >>> if I know >>> that protection is not needed from rt tasks and interrupt handlers. >>> * should use rt locks and events, if protection is needed from rt tasks >>> and >>> interrupt handlers. >>> >>> My driver's ioctl_rt, read_rt, and write_rt entry points... >>> * are executed in the caller's Xenomai user context (primary mode), if >>> the caller >>> is a rt user process running in primary mode. >>> * are executed in the caller's Xenomai user context (secondary mode), >>> if the caller >>> is a rt user process running in secondary mode. >>> * must use rt locks and events. >>> >>> My driver's ioctl_nrt, read_nrt, and write_nrt entry points... >>> * are executed in the caller's Linux user context, if the caller is a >>> standard >>> Linux user process. >>> * I should use rt locks and events, for protection from rt tasks and >>> interrupt handlers. >>> >>> My driver's rt interrupt handler entry points... >>> * are executed in the Xenomai interrupt context. >>> * must use rt locks and events. >>> >>> Is the above correct? >> Hi, >> >> Yes, this is correct. Note however, that if you need to lock something >> in the init_module or an nrt callback, and you use a linux lock, you >> will not be able to use this lock from rt context, so, the only way to >> solve this will be to use an rtdm lock. >> >>> The OMAP3 chip has a collection of hardware timers that must be shared >>> between the Linux and Xenomai environments. I want to allocate/reserve 5 >>> timers for my use in the real time environment for the creation of pulse >>> width modulation output signals, but the rest of the timers should be >>> available for general Linux use. Being able to call omap dm_timer >>> routines in the module_init and module_exit routines make this much easier. >> Another remark: Xenomai uses, as, a system timer, a timer in one-shot >> mode (same as Linux so-called "high resolution timers"), so, if you >> program several periodic software timers, Xenomai timer subsystem will >> arrange for your timer callbacks to be called at the right time, so it >> looks like you will not gain much by using several hardware timers. If >> you fear that Xenomai timing subsystem will not scale well with many >> timers, you can enable the heap-based or wheel-based timer management. >> >> Regards. >> > > _______________________________________________ > Xenomai-help mailing list > [email protected] > https://mail.gna.org/listinfo/xenomai-help > _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
