|Anonymous | Login | Signup for a new account||2017-11-20 11:30 UTC|
|Main | My View | View Issues | Roadmap | Repositories|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000127||Firmware||Scheduler (Inj/Ign)||public||2011-06-15 12:54||2014-02-18 23:06|
|Target Version||0.2.1||Fixed in Version|
|Summary||0000127: Split the code run time stuff into different parts|
|Description||Split code run time into decoder, loop iteration max and number of iterations to do. Make decoder only loop through required number of entries. And therefore keep scheduling as tight as possible.|
|Tags||No tags attached.|
|Risk of Breakage||high|
I just realised that this is actually slightly more complicated than I was modelling it. The worst case from input edge to output being triggered is this:
=WORSTOF(All other ISR runtimes and ATOMIC operations) + WORSTOF(primary decoder logic, secondary decoder logic) + (number of iterations * iteration runtime)
In other words, to do this right, we not only need to profile each and every decoder, and the scheduling code, we ALSO need to profile all other ISRs and ATOMIC blocks!
Make sure this is done correctly!
|Copyright © 2000 - 2011 MantisBT Group|