Variable continuity

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:

Variable continuity

Post by Fred »

As some of you may know, I have a scheme in the code which has banks of data such that the interrupts don't cause a short to be made up of two halves of two unrelated shorts.

This is achieved by writing input ADC readings etc into one mem location and then when its time to use them, blocking interrupts, switching the variables and using the latest such that the interrupts can continue to store ADC data into the other bank over top of the old copies.

The same occurs on the output stuff, pulsewidths dwell etc. the interrupts use the old ones until the new ones are swapped in once calced.

There are lots of good reasons to do this and a few to not do it.

What I noticed today is that all the vars that aren't inputs and aren't outputs actually only need one copy. I thought i needed to swap those too, but I can't think why now. Can anyone confirm that there is no need to swap those middle ones?

In the future there may be a need as datalogging could be generated on the xgate. In this situation we would want contiguous sets of data, not randomly changing ones. However we aren't there yet so it shouldnt be coded for now anyway.

Thoughts? Can I safely swap back to a single copy of the middle vars? The only things accessing those are accessory functions which can't run at the same time anyway due to being in the main loop too.

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
jbelanger
LQFP144 - On Top Of The Game
Posts: 387
Joined: Sat Feb 23, 2008 8:58 pm
Contact:

Re: Variable continuity

Post by jbelanger »

The only reason I can think of is for datalogging purposes so that you have a consistent set of data from input to output and everything in between in one datalog frame. If it is not logged then I don't see the point.

But I don't see why you mention datalogging by the xgate. No matter where it's done, you still need a buffer with consistent data that only gets changed once the frame is completely transmitted (actually you can start updating the buffer while transmission is happening but you still want to preserve consistency).

Jean
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Variable continuity

Post by Fred »

The reason I mention xgate is that if not done by xgate then only the math XOR the logging can execute and therefore it will always be consistent. If done by xgate it could execute at the same time and cause issues.

I'll knock out the double copy thing for those intermediate values, thanks for confirming, I wonder why I didn't realise this earlier...

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: Variable continuity

Post by Fred »

Done! :-)

Documentation in the header looks a lot like this :

Code: Select all

/* The banked running variable system and structure
 *
 * The program running variables are divided into three broad groups: inputs, working
 * and outputs. For both the input and output groups there are two copies of each set
 * of variables, whereas there is only one copy of each set in the working group. This
 * is required to allow both the inputs and outputs to be safely written and read at
 * the same time. To facilitate this all sets of variables within the input and output
 * groups are referenced with two pointers each. For the input group, the copy pointed
 * to is swapped when fresh data is both available to and required by the mathematics
 * function. For the output group the copy pointed to is swapped when the mathematics
 * function has produced new output data. The input data is supplied by the engine
 * position interrupt service routines as ADC readings and RPM values. The output data
 * consists of pulse widths, timing angles, dwell periods and scheduling information.
 *
 * Accessory functions (Idle, Boost, etc)
 *
 * In order to achieve minimal latency and maximum frequency of execution of the
 * main mathematics code the accessory functions must run asynchronously. Although
 * we can guarantee that these functions will base their calculations on a matched
 * set of data, we can not guarantee that it will be the same set of data presented
 * along side the accessory data in the data log. Thus, where it is required to see
 * the inputs that an accessory functions calculations were based on, those values
 * should be cached for logging on a per function basis.
 *
 * Although it seems like a lot of trouble to go to, it is critical to transient
 * performance that the environmental conditions the engine is operating under are
 * tracked and reacted to as quickly as possible. Having the less important stuff
 * run asynchronously will result in an order of magnitude improvement of parameter
 * tracking and is well worth the extra memory expense and complication.
 */
Corrections and comments welcome.

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: Variable continuity

Post by Fred »

Jean, just reread your post. The issue is that at some point you have to grab a copy of the running vars from wherever they are and put them into that buffer to be sent. If that happens from interrupt or from another CPU then you need two banks of the internals too. If not you don't. It's easy to put back in though, so I'm happy with how it is now (ie one copy of intermediates).

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!
Post Reply