On 05/07/2013 02:36 PM, Sebastian Pavez wrote: > Hi Gilles, > > Sorry for the mess :-) I hope this is more clear: > >> Hi Gilles, >> >> Thanks for your answer. About the execution time issue I'll explain better: >> - How I see the code works: >> - I set the period of each thread 'control' and 'pert1' >> - After the initialization of variables and DAQ card the code >> inside 'while(1)' is executed periodically >> - I determined the time take it by this 'while(1)' via direct >> measure (activating a signal before the code and disbling it after, and >> measuring the width of the 'pulse') >> - I get something like 18us for the control thread. So In the pert1 >> thread I use a 'for' loop inside the while(1), when I increment the >> interations number I get a higher execution time >> - What I'm trying to test: >> - For the same period for both tasks and the higher priority for >> the pert1 thread I incremente the number of iterations inside the for loop >> - I expect, with a execution time of pert1 over 35us, to see a >> malfunctioning in the DC motor following the reference (via some signals >> I get in the oscillo) because the control will not have >> enough time to be executed properly before the next period in >> wich the pert1 thread will resume his execution ... (is this correct?) >> - All this is done to confirm the results obtained in simulation >> >> Now, what I'm doing (the structure of my code) is in order with the >> results I would like to test? or I'm misinterpreting something. I would >> like to clarify this in order to know if the problems are about the >> theory or the implementation ... or, sadly, both. >>> I do not see all this in the code you sent to the list, what I see is >>> two threads which sleep on pthread_wait_np and do nothing else. So, >>> execution time virtually 0. You can use rt_timer_spin to simulate some >>> load. Some point you may have missed too, is that Xenomai timer runs in >>> one-shot mode by default, which means the thread periods will not elapse >>> at the same time, except if you synchronize them by using the first >>> argument of pthread_make_periodic_np. >> > Sorry for that, I now attached the code ... It's quite raw at the moment > but it does what is suppose to, control the DC motor.
That is fine, but if you want us to be able to test your code, you should send code which runs anywhere, using rt_timer_spin to simulate load. > Regarding the first argument of pthread_make_periodic_np, I use > pthread_self() to assign to the calling thread, wht do you precisely > mean with "using the first > argument of pthread_make_periodic_np"? I mean the second argument, the start time, sorry. > >>> In general, however, a Xenomai system where a real-time task consumes a >>> lot of cpu does tend to crash, it is recommended to let linux run (by >>> having all your real-time tasks suspended at some point) from time to >>> time. A safe solution is to let it run at least for its timer tick, so >>> every millisecond, 4 milliseconds, or 10 milliseconds depending on >>> CONFIG_HZ value. >>> >>> How could I do this? >> Arrange for every thread to not run more than the time of the period >> corresponding to CONFIG_HZ. >> > > This mean, don't set a period more than 4ms for each thread? (I have a > configuration of 250hz) I am not talking about the period, I am talking about the cpu time consumed by the thread, a thread should never run for more than 4ms without suspending. > I tried to start in text mode by changing "quite splash" to "quite > splash text" in the grub ... I only get a black screen at the start. If you are using a graphic login such as xdm, gdm, kdm, simply disable it. On a debian system, you would do this with update-rc.d, for another distribution, I do not know. Anyway, as I told you, before trying to run in text mode, you should try to run a more recent patch, the one for linux 3.4 or the one for linux 3.5 which you will find in xenomai 2.6.2.1. > > One more question, the results I get with 'cat /proc/xenomai/stat' and > 'cat /proc/xenomai/sched' prove that the threads are being executed in a > rel-time mode? > or there's something "weird" about them? or That's not enough info? I am not sure I understand your question, if you do not show me what problem you seem to see. "real-time mode" is ambiguous. A thread is present in /proc/xenomai/stat and /proc/xenomai/sched if it has a real-time shadow, it is then able to run either in "primary mode", under control of Xenomai scheduler, or in "secondary mode", under control of the Linux scheduler. The mode it is currently running on is shown by the "STAT" field. A thread running in secondary mode will have an "X" in its status bits in /proc/xenomai/sched. See: http://www.xenomai.org/index.php//proc/xenomai/stat http://www.xenomai.org/index.php/Proc/xenomai/sched -- Gilles. _______________________________________________ Xenomai mailing list [email protected] http://www.xenomai.org/mailman/listinfo/xenomai
