For the RTOS to be accurate in the Unity environment, tasks will need to take an appropriate amount of Unity frames to mimic the real world. Unfortunately this would require a complex parallel processing system for it to be completely realistic.
A workaround is thus:
Have the RTOS execute a student task, and measure the time it took to complete the task
The RTOS will calculate how many Unity frames this is equivalent to
The RTOS will wait that many Unity frames before taking the task action
In order to avoid giving an unfair advantage to students with fast computers, a scaling factor will be applied to the time as such:
At the start of the simulation, run a quick benchmark (i.e. run a for-loop 100 times, 10 times in a row, and average the run times)
Take the ratio of the desired runtime divided by the measured benchmark time
Multiply this ratio by the task time which is measured by the RTOS
Thus, if a typical computer executes the benchmark in 10 ns, and a slow computer takes 20 ns, then all RTOS task times will be cut in half. Likewise, if the benchmark is 10 ns and a fast computer takes 5 ns, then all RTOS task times will be made twice as long.
For the RTOS to be accurate in the Unity environment, tasks will need to take an appropriate amount of Unity frames to mimic the real world. Unfortunately this would require a complex parallel processing system for it to be completely realistic.
A workaround is thus:
In order to avoid giving an unfair advantage to students with fast computers, a scaling factor will be applied to the time as such:
Thus, if a typical computer executes the benchmark in 10 ns, and a slow computer takes 20 ns, then all RTOS task times will be cut in half. Likewise, if the benchmark is 10 ns and a fast computer takes 5 ns, then all RTOS task times will be made twice as long.