View unanswered posts | View active topics It is currently Mon Dec 18, 2017 2:06 am



Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
distributed computing? 
Author Message
LQFP112 - Up with the play

Joined: Thu May 01, 2008 6:30 pm
Posts: 135
Location: Ann Arbor, MI
I was thinking about the processing speed requirements and i thought why not free the core processor from doing "menial" things. Like having a dedicated (and small) processor to receive and interpret the crank sensor and put the RPM value on either CAN bus or I2C bus... Another processor to deal with cam sensors - another one to take care of IAC valve - another one to take care of injectors/spark - maybe one more processor to deal with all the other sensors (and calculations) like CTS, IAT, MAP, MAF, TPS, O2 etc etc. The core processor will then be available to do all the FP calculations and basically supervises all other subordinate processors and tells them what to do (back in the days this method was called SCADA).
e.g. - the core might tell the injector processor - make AFR 14.0 - the inj processor can request the air flow from the bus and makes the necessary PWM calculations and talks to the injectors.

The more i think about it the more it seems kinda "out there" - But it may bring costs down and increase the overall "power" even though it adds hardware complexity.... What do you guys think? Pie in the sky? When pigs fly?


Fri Jun 13, 2008 3:52 am
Profile WWW
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
Price and board real estate

I'm toying with the same idea but using a Propeller chip with all of the parallel processing on the same IC to reduce additional cost and real estate.

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Fri Jun 13, 2008 4:25 am
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
shameem wrote:
even though it adds hardware complexity.... What do you guys think? Pie in the sky? When pigs fly?

I think it adds software complexity and overhead too. You have to communicate between cores to do this, and you have to do it pretty well. The latencies bother me TBH. I'm very keen for our fueling calcs to be done as close as possible to injector close time as it will mean the controller is much closer to reality during transient situations. MS is far from reality during transients, with the exception of Ken's EAE lag compensation which is a step in the right direction they drop the ball on that.

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 Jun 13, 2008 7:37 am
Profile WWW
LQFP112 - Up with the play

Joined: Thu May 01, 2008 6:30 pm
Posts: 135
Location: Ann Arbor, MI
For communication - could it be made simpler if the cores dump "data" on to a bus (as they are coming in) and other cores which see relevant data just grab them and store them for "later" use..... In theory atleast relevant data will be available to relevant cores almost as instantly as the data comes in......

For fuel and spark calculations - the core responsible for that should "know" the position of each piston (or atleast the ones about to be injected and sparked) so that it can pre-calculate values..... (it should know the amount of air that went into the cylinder in the previous cycle already right?)

In a propeller all cogs share the i/o pins and it dont come with ADCs either - Also is a 32K RAM and 32K ROM enough? How much real estate would it actually save (considering external ADC and memory chips which are probably on a parallel bus configuration) - wouldnt a lot of cycles be wasted on shunting data between the internal and "external" bus?


Fri Jun 13, 2008 7:52 am
Profile WWW
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
My basic argument is that for the fuel/spark calcs, and event firing, you must use one core. All other tasks are not time intensive, so you can collect ADC data (easy/fast), run your pwm idle valve (easy/fast), etc. The one core that needs to do those core things must be high enough in performance that auxiliary non ISR tasks can be performed in the spare time without impacting important things. Thus, the other cores seem superfluous to me as the one that you must have has more than enough grunt to do the menial tasks and the important ones.

As for rom, currently we are at about 8k of flash with a skeleton in place. I would expect to fill out 32k by the time all the calculations are in place and the decoding, port managment and serial are working properly, possibly more. Certainly there will be a need for further flash past 32k to do anything interesting like accessory control. This is all assuming nice readable C code though. If you optimised it in ASM, it could be smaller and faster, but that is not conducive to a modern system that is accessible to all for mods.

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 Jun 13, 2008 8:13 am
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
Interesting discussion

Fred promotes the KISS approach, and rightfully so - reduce costs, complexity, delays and potentially higher failure risk that's present in distributed systems compared to that of centralized.

But, as i mentioned in one of the recent threads, modularizing the 'tach wheel decoder'/'ign/inj event scheduler' into a separate standalone module, looks very appealing to me, especially if one uses something like a simple multi-core MCU (like propeller chip mentioned earlier) or even better - a CPLD/FPGA
I will try to outline the potential pros/cons of this vs. a single MCU KISS approach in a formal document soon if i find time

Keep it coming guys

_________________
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.


Fri Jun 13, 2008 3:07 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
ababkin wrote:
modularizing the 'tach wheel decoder'/'ign/inj event scheduler' into a separate standalone module, looks very appealing to me

Thing is, as soon as you have this, you have spare cycles and nothing critical to do with them, you may as well use them to open relays and turn on pumps etc. PWM is hardware on our chip for example, and because of that it keeps PWMing all the time, you just update the duty as you need to. I really can't see the point in breaking it off. Whatever you use to do the critical stuff almost certainly has time to do the non critical stuff 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!


Fri Jun 13, 2008 3:31 pm
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
ok, let's try to analyze and discuss those two in depth

some questions that would determine the criteria for this comparison:
- what is the XDP's hw reaction time to external interrupts (crank/cam teeth) and is it significant (i.e can it affect event scheduling to a point of degraded operation of the engine) ?
- is this time constant or varies randomly (based on the immediate state of the pipeline for instance) ?
- is there an inherent delay due to the software ISR interrupt handlers ?
- does decoding/scheduling still works when eeprom/flash is being written ?
- (add yours here)

keep in mind that, AFAIK, such module, using say a CPLD, will give perfect answers to the above questions, which is why i said earlier that programmable logic looks like a better match for the decoder/scheduler problem that the module will solve.

But, to keep my argument balanced, i also realize that it also highly dependent on the MCU's architecture, and again: characteristics of reaction to the external interrupts.
I've been reading about the ARM architecture for example, and from what i gathered, due to extra caching and pipelining in it, the reaction to hw interrupts suffers by not only being delayed, but more-so because those delays are random (depending on cache/pipeline state). But, an advantage of ARM arch is that the complex calcs run much faster and are cached much better to reduce the fetching delays. So , maybe you're right that using a CPLD wouldn't be justified with the XDP's arch, but it may with MCU's like ARM - in which case the split between the math intensive module (MCU) and time-critical module (CPLD) would be highly necessary. (and modules are available like this one: http://www.knjn.com/board_Xylo.html , albeit not in automotive temp range)

EDIT: I'd like to add more comparison points
- pluses and minuses of the physical and logical decoupling
- no software (CPLD), e.g no long sequential algorithms (if designed right), which is one of the inherent causes of bugs in the traditional software design. Ability to efficiently implement a pure data/signal-driven design (as opposed to algorithmic/sequential design, which is IMO inferior and promotes sloppyness and confusion if algorithm is reasonably complex).
- harnessing the power of true parallelism (the VHDL program for CPLD can be highly parallelized for this particular task, therefore both total delays and delay deviation will be minimized). It is much harder to parallelize stuff on an ordinary MCU (i am keeping the XGATE in mind though)

DOUBLE-EDIT:
- no need to optimise ISRs in assembly for speed = much cleaner code

_________________
Legal disclaimer for all my posts: I'm not responsible for anything, you are responsible for everything. This is an open and free world with no strings attached.


Fri Jun 13, 2008 4:17 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14913
Location: Home sweet home!
ababkin wrote:
- no need to optimise ISRs in assembly for speed = much cleaner code

There should be no need to do this anyway!

There is zero delay in recording events on the external wires (Input Capture) a slight but trivial delay (less than 10us at present) till it is finished being handled. On the output side, same deal, the pin fires EXACTLY when you want it to (Output Compare) and you deal with the consequences of that in very short order.

IE, with the ECT module, the HCS12 is perfect for that job :-) You can't improve upon perfect even if you want to :-p

As for code complexity and bugs etc etc, that is what a good dev process is for. Create good code, test it well, iron out issues, and eventually know that it is solid. No software exists without such a process. It's just a shame we can't do any unit testing on the code :-(

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 Jun 13, 2008 6:27 pm
Profile WWW
LQFP112 - Up with the play

Joined: Thu Apr 10, 2008 5:51 pm
Posts: 205
As far as distributed computing goes, I am in the camp that is in favour of a signalling bus rather than a data bus for engine position synchronization between processors.

I would suggest a processor programmed to read the specific sensor setup on a particular engine, and using an accurate crank position predictor, generate a standardized signal that is easy/practical to decode.

I have run through many ideas for a standard signal. It's tough, because a good standard should use as few I/O lines as possible, have a short synch time, have good resolution for angle-based events, and also have phase info for COP and sequential injection. It also needs to have capability to be generated/interpreted as either wasted spark or COP for fast startup and flexibility.

Some ideas I came up with were:

(a) 5-bit Gray Code cylinder ID/cylinder TDC bus (up to 32 transitions per cycle (16 cyl engine), doubled the transitions up so it can be used properly with odd numbers of cylinders)

(b) composite tach/phase/highres bus similar to Nissan CAS/GM Optispark

I like the Gray Code idea because it can contain both ID and timing info in a single signal. The main drawback I can see is it wont fail over to wasted spark easily. And the fact that I don't know if there are pure Gray code sets to deal with all of the cylinder combos yet. Odd fire might be a bit tricky too, unless two buses are used.

As far as an opti-style signal, to cover all of the cylinder combos up to 16 one would need a minimum 720 transitions per revolution to have TDC for any given cylinder to always fall on a transition. From my Propeller Chip perspective this isn't a problem as one core can be dedicated to high-speed triggering while the other cores do the calcs.

/blab

_________________
Keith MacDonald
Control Engineering (Systems) Technologist


Wed Jun 25, 2008 4:46 pm
Profile
Display posts from previous:  Sort by  
Reply to topic   [ 11 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: No registered users and 1 guest


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.