View unanswered posts | View active topics It is currently Fri Mar 24, 2017 4:59 pm



Reply to topic  [ 5 posts ] 
COP Monitor Setup 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14498
Location: Home sweet home!
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!


Fri Jan 06, 2012 8:12 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14498
Location: Home sweet home!
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!


Sat Jan 07, 2012 5:12 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14498
Location: Home sweet home!
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!


Fri Jan 27, 2012 3:15 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14498
Location: Home sweet home!
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!


Thu May 16, 2013 8:26 pm
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14498
Location: Home sweet home!
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!


Thu May 16, 2013 8:59 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF. ColorizeIt.