Yes, exactly. For example if you want to block for 1s: uint32_t cycles_per_tick = T_get_one_clock_tick_busy(void); uint32_t cycles_per_sec = rtems_clock_get_ticks_per_second() * cycles_per_tick; T_busy(cycles_per_sec);
It you take a look at the implementation of T_busy (https://git.rtems.org/rtems/tree/cpukit/libtest/t-test-busy.c) it is just a loop which wastes count cpu cycles. So the 1s is the time it blocks while being active on a CPU. Of course this only holds true if the cpu frequency is constant during execution. In most hardware cases this should be the case for RTEMS. I think by default energy saving is not used in BSPs. I am not sure how qemu will behave. Does someone else have more information on this one? Best regards Jan From: Richi Dubey <richidu...@gmail.com> Sent: Saturday, May 22, 2021 7:21 AM To: Joel Sherrill <j...@rtems.org> Cc: Sommer, Jan <jan.som...@dlr.de>; rtems-de...@rtems.org <devel@rtems.org> Subject: Re: Writing code that takes time to run Hi, About the code: T_busy(T_get_one_clock_tick_busy() * SOME_CONSTANT); does this support context switch? If task A executing on CPU 1 gets preempted while executing this (by task B) and then comes back on CPU 1 after some time (when task B finishes its execution), would task A finish its execution of this function - as nothing happened? So, if we ask Task A to run T_busy for 5000 ticks, and it gets preempted after 3000 ticks and maybe moves to another CPU, would it run for the remaining 2000 ticks on that CPU? On Fri, May 21, 2021 at 9:50 AM Richi Dubey <richidu...@gmail.com<mailto:richidu...@gmail.com>> wrote: Hi, Thanks for your quick responses! The suggestion certainly is helpful, we are going to try it out. I'll post the result here. On Thu, May 20, 2021 at 8:57 PM Joel Sherrill <j...@rtems.org<mailto:j...@rtems.org>> wrote: On Thu, May 20, 2021 at 10:05 AM <jan.som...@dlr.de<mailto:jan.som...@dlr.de>> wrote: Hi Richi, You can checkout the T_busy functions here: https://git.rtems.org/rtems/tree/cpukit/include/rtems/test.h#n2390 uint_fast32_t T_get_one_clock_tick_busy(void) gives you the busy count for one tick. You can then calculate the number of cycles you need to wait for you desired certain time and pass it to: void T_busy(uint_fast32_t) This should give you comparably accurate results over different platforms. That's certainly a better method than what I suggested. --joel Best regards, Jan From: devel <devel-boun...@rtems.org<mailto:devel-boun...@rtems.org>> On Behalf Of Richi Dubey Sent: Thursday, May 20, 2021 4:53 PM To: rtems-de...@rtems.org<mailto:rtems-de...@rtems.org> <devel@rtems.org<mailto:devel@rtems.org>> Subject: Writing code that takes time to run Hi, We are thinking of writing a piece of code that takes some time to run (it would be amazing if it takes around 2 secs to run on hardware, but we would be happy with something that takes a few milliseconds as well). We tried writing this: for(int i = 0; i<10000000; ++i){ fib2 = fib0 + fib1; fib0 = fib1; fib1 = fib2; } which takes few milliseconds when tested on qemu, but only takes few microseconds on a real board. Do you have any suggestions of what else we can do? We want to write a code that is context switch safe (so, we can't simply check the time before a loop, run an infinite loop that keeps checking current time and stops after a few seconds - because this logic would fail if there happens a context switch inside the loop and the task gets the control back after a few seconds). We also don't want to do a wake_after() since we want the task to be running on the cpu during the entire time (it is okay if the task gets preempted due to a higher priority process), and not voluntarily giving the control to some other task. Any suggestions? The aim is to see the affect of a task getting removed from the cpu due to task shifting by the newly arrived task (in strong apa vs non task shifting scheduler). Thank you. _______________________________________________ devel mailing list devel@rtems.org<mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
