From mboxrd@z Thu Jan 1 00:00:00 1970 From: Philippe Gerum In-Reply-To: <4B9AD0DE.4020103@domain.hid> References: <4B97BA0C.9000702@domain.hid> <4B9AD0DE.4020103@domain.hid> Content-Type: text/plain; charset="UTF-8" Date: Sat, 13 Mar 2010 10:28:43 +0100 Message-ID: <1268472523.27899.135.camel@domain.hid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Analogy cmd_write example explanation List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexis Berlemont Cc: xenomai@xenomai.org On Sat, 2010-03-13 at 00:40 +0100, Alexis Berlemont wrote: > Hi, > > Sorry for answering so late. I took a few days off far from any internet > connection. > > It seems you sent many mails related with Analogy. Many thanks for your > interest. I have not read all of them yet. However, I am beginning by > this one (which seems unanswered). The answer is quick and easy :) > > Daniele Nicolodi wrote: > > Hello. I'm looking into the analogy cmd_write example. > > > > I'm not sure I understand the reason for the rt_task_set_mode() function > > call into the data acquisition loop (lines 413 or 464 in the code > > shipped with xenomai 2.5.1). > > > > I do not understand why we have to set the primary mode at every > > iteration, when we set it before for the task (line 380). > > > > Is it because the dump_function() uses system calls that can make the > > task to switch to secondary mode, or there is a deeper reason I'm missing? > > > You are right. The dumping routine triggers a switch to secondary mode. > That is why, the program switches back to primary mode after. This is wrong. The Xenomai core will switch your real-time thread to primary mode automatically when running a4l_insn* calls that end up invoking rt_dev_ioctl(), since you did declare a real-time entry point for this one. Let's summarize the whole point of forcing primary mode through rt_task_set_mode(): it's bad, it's wrong, it's counter-productive CPU-wise, it usually reveals a design issue in the calling code in most cases. The only application-level use case where switching to primary mode eagerly this way might make sense, is when the code first switches to secondary, then runs an awful lot of CPU-intensive code without issuing any syscall, one might want to keep un-preempted from Linux IRQs. In such a case, the question which arises immediately is: why the hell does one ever tolerate switching to secondary mode initially, if strict timely behavior is wanted later on? That crap is a freaking mistake of mine, when I exported such anti-feature via the native API mindlessly, to provide a work-around for rare situations some internal Xenomai code might benefit from. I should have provided an internal syscall instead, to hide this monster deep into the abyssal zone it should never have left. In short: DO NOT USE THIS. > > Almost all the Analogy programs (cmd_read, cmd_write, insn_read, > insn_write, insn_bits) are just demonstration examples. That is why the > code is so linear, lengthy and repetitive. Furthermore, the code was not > meant to be efficient. I just wanted to test the RT and NRT entries. > > By the way, I started to improve them. One change (which is still > missing) is the use of rtdk. > > > Thanks. Cheers, > > Alexis. > > _______________________________________________ > Xenomai-help mailing list > Xenomai-help@domain.hid > https://mail.gna.org/listinfo/xenomai-help -- Philippe.