On Thu, May 20, 2021 at 10:05 AM <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> *On Behalf Of *Richi Dubey
> *Sent:* Thursday, May 20, 2021 4:53 PM
> *To:* rtems-de...@rtems.org <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
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
