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> wrote: > > > 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
