You could use some hideous delaying loop - a ‘busy-wait’, but that’s not very good. Instead you have delay x.xx or sleep.
There’s a lot going on when you delay; granularity afterwards, interrupts being disabled, and other processes running and your process in the waiting queue. So really delay means ‘delay at least this amount’.
To do periodic activity, you shouldn’t just delay x.xx because of how long your activity might take. So for example instead, you do something like:
Next_Time := Clock + 7.0;
loop
-- do stuff;
delay until Next_Time;
Next_Time := Next_Time + Interval;
end loop
This way, it will run on average every 7 seconds, with only local drift making a difference. If the ‘do stuff’ section takes 8 seconds, the delay statement will just have no effect.
In most embedded systems the timing requirements are very simple, the difficult bit is meeting these requirements in the implementation.
Verification is done in terms of temporal scopes; blocks of code. You have various different ‘things’ that you want as a requirement:
Temporal scopes tend to be repetitive, therefore you measure the temporal scope in terms of a single repetition. This may just be a ‘periodic’ scope which runs after every x delay. It may also be ‘aperiodic’ e.g. waiting for an interrupt then running, in which case the TS is the ‘running’ bit (not waiting for the interrupt, obviously).
Deadlines can be Hard, Soft, Firm, or Interactive. I lost track of the differences and stuff…
Comments
blog comments powered by Disqus