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.

Hmm, if I flag entry/exit to/from the comms handler then I could clear the COP stuff from the RTI while comms is occurring and not otherwise. This would enable a much shorter and safer timeout to be used without false activation.

The consequence of a COP activation is the loss of live tune data, and thus should be avoided. However the tuner should really detect the reset and handle that, MTX currently doesn't. There are some things in the works which would make it easier for MTX to know what has happened, however there is enough info as is.

If comms didn't affect the COP timeout activation then the timeout could be pretty short with low (no?) risk of false tripping.

IE, if main loop takes 3ms with no interrupt load and we allow interrupts to take 75% of available CPU time, then main loop will take 12ms to run, max.

3 * (1 / (1 - 0.75)) = 3 * (1 / 0.25) = 3 * 4 = 12

Thus if the main loop takes 3ms and we allow 75% ISR load, then the COP trigger should be set to 12ms or greater.

This will fail everytime a long comms task is called, though, so needs to be more complex, as mentioned above.

I just thought of another idea for this to make it even more safe, and it's to keep a secondary manual COP timer in the RTI such that if a comms routine takes too long, it gets nuked too. That way if something goes wrong while inside the comms routine, even if unrelated to the comms routine, then we're safe.

In addition to the long serial calls, or perhaps to be considered part of them, flash erase takes quite a few ms too, 330ms is the number I have, per page. This means that the smallest we can go is 0.5 seconds until the flash stuff is changed.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum