From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <487201E0.9080700@domain.hid> Date: Mon, 07 Jul 2008 13:45:36 +0200 From: Philippe Gerum MIME-Version: 1.0 References: <4871CA89.8060703@domain.hid> <5883386fa4d9312cda538cb80f032180@domain.hid> In-Reply-To: <5883386fa4d9312cda538cb80f032180@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] xenomai scheduler's ticks period Reply-To: rpm@xenomai.org List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: matthieu.connaulte_xenomai@domain.hid Cc: xenomai-help Matthieu wrote: > Hi > > Well I'm going to try to be clear : > > I work on a project that aims at migrating VxWorks tasks from PPC boards on > VME crate to X86 Computer ruuning with Linux. The cost of using Xenomai API > instead of vxworks skin seems very costly. The idea is to keep the maximum > of mechanisms. > > As there is no implementation of vxworks periodic task instruction, the > idea was to use watchdogs. In fact, as watchdogs are counting from ticks, > it's easy to make tasks periodic if the period of the task is a multiple of > the tick period. So each task starts it's watchdog, executes some routine, > and suspends itself. The watchdog, when the specified delay ticks elapsed, > resumes the task. And so on... You may want to use a semaphore to synchronize your wd handler with the task instead of suspend/resume calls. > > The use of multiple PPC boards, with periodic tasks that need to be > synchronized, has required the use of an hardware interrupt, spread to all > CPUs, and which handler tickAnnouce() vxworks. I know that this mechanism > isn't still necessary as there is only one vxworks tick on Xenomai, even if > I work with many CPUs. Wrong, Xenomai ticks on each CPU because internal timers are per-cpu resources; only the boot CPU tracks jiffies, but that's a different issue. But in the new configuration, I have a PCI card that > will send this interrupt. So I need to stop the automatic vxworks tick with > tick_arg=0 and to handle this interrupt to tickAnnouce() manually. As I > will don't have this card all the day, I need to simulate this mecanism, > and I need to create something that will tickAnnouce() at a periodic time. > > I created a module that, in on case, will handle the interrupt, and on an > other case, will create a xenomai rt_task that tickAnnouce. And this > doesn't work. I want the ioctl method send the period to the module in > order to modify the period of the tick. > > I still have created this driver has you see but it doesn't work. What your code did is switching the VxWorks timer to aperiodic mode which stops periodic timing; in that mode, the time unit is nanosecond, so every timeout data is interpreted as a count of nanoseconds. This is likely not what you want. I'm going > to test your modifications. Thank you for that. > Forget about this example; actually, those changes do not fix the logic, but only provide some hints about xntbase_switch(), and fix return code issues. > I will also need to get a precise time, and Gilles suggest me to use > xntbase, but xntbase_get_time(&nktbase); isn't recognized. What Gilles told you is that solely switching the VxWorks clock to aperiodic mode (by passing period == 0) would wreck the underlying timing logic of a VxWorks app, which does not pass/expect nanoseconds but jiffies/ticks. In short, doing so is not enough. Normally, solving your issue would require to make the master timebase paced by your PCI card, which would in turn provide the correct timing for the VxWorks timebase (as the timebase doc states, periodic timebases are cascaded from the master aperiodic one). However, doing so would also require to adapt the Xenomai HAL code accordingly, and a PCI hw that is oneshot programmable as well. If you want to hack the Xenomai timer sub-system in order to only affect the VxWorks timebase, what you actually need is to control the coupling between the master timebase (paced by decrementer) and the slave VxWorks one, so that decrementer ticks may be prevented from kicking the VxWorks timebase. This way, you would be able to call tickAnnounce() freely to announce any incoming VxWorks tick (i.e. from your PCI handler). In short, when paced by the PCI interrupt, you will need to: - call xntslave_stop(base2slave(wind_tbase)) - call tickAnnounce() from your PCI IRQ handler When paced normally (simulation, "somebody stole by PCI card" mode), just leave the burden to the system timer (i.e. ppc decrementer) as usual, by coupling the VxWorks slave timebase to the master one anew: - call xntslave_start(base2slave(wind_tbase), xnarch_get_cpu_time() + period, period); /* period is given in nanoseconds, depends on the master timebase */ In any case, you don't need to change the VxWorks tick period. Starting/stopping the VxWorks timebase should do the trick. NOTE: this is a hack exposing Xenomai internals -- we should probably encapsulate this into new xntbase_bind/unbind calls if this does eventually works for you. -- Philippe.