16 megahertz / 2^X = Hz of resets. 1/Hz of resets = COP timeout period.
X=14 ~= 1024hz = 1.024ms this definitely won't be OK, main loop takes longer for calcs.
X=16 ~= 256hz = 4.096ms this likely won't be OK due to long serial requests.
X=18 ~= 64hz = 16.384ms this likely won't be OK due to long serial requests.
X=20 ~= 16hz = 65.536ms this likely won't be OK due to long serial requests.
X=22 ~= 4hz - 262.144ms will definitely be OK, I think.
X=23 ~= 2hz = 524.288ms this has to be OK.
X=24 ~= 1hz = 1s this is just silly.
Worst serial request is about 250ms max, but that's for sending, so real timing is much less, need to measure. I think it's reasonable for 3/4 of CPU time to go to interrupts at high revs. This is an arbitrary guess, though. So we need to take worst case and multiple by 4. OR, we need to assume that MTX interrogation will only occur at low RPM, which isn't unreasonable. I'll do some experimentation on the bench before I commit this, and also make it part of the config such that it can be fine tuned by a user.
EDIT: Issue link: http://issues.freeems.org/view.php?id=69
- where Open Source means Open Source, and Free means FreedomFreeEMS.org
- the open source engine management systemFreeEMS dev diary
and its comments thread
and my turbo truck!n00bs
, do NOT
PM or email tech questions! Use the forum!The ever growing list of FreeEMS success stories!