COP Monitor Setup

Official FreeEMS vanilla firmware development, the heart and soul of the system!
Post Reply
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

COP Monitor Setup

Post by Fred »

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

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS 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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: COP Monitor Setup

Post by Fred »

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.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS 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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: COP Monitor Setup

Post by Fred »

The COP should be cleared from the main loop at a fairly fast rate of equal to or greater than:

mainLoopExecutionTime * (1 / (1 - allowedProportionOfInterruptTimeAtHeaviestLoad))

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.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS 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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: COP Monitor Setup

Post by Fred »

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.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS 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!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: COP Monitor Setup

Post by Fred »

The above is false. In the firmware we erase a sector at a time, not a page, so that's about 20ms per sector.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS 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!
Post Reply