View unanswered posts | View active topics It is currently Mon Dec 18, 2017 9:30 pm



Reply to topic  [ 9 posts ] 
FreeEMS summed up. 
Author Message
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14914
Location: Home sweet home!
newtyres1 wrote:
I feel a wideband controller is the last thing you would want on the board, as they are still evolving. Probably similar with knock detection. That would make MS3 a good example of built-in obsolescence. How about just doing ignition and fuel really well, KIS, and leaving some I/O (and RAM/flash) for things that are evolving. Thinking outside the square maybe a double row of header sockets for "evolving MS3 plug-ins" (e.g. EGT, knock sensor, etc) would be an idea but maybe not practical.

Ian.


I couldn't have said it better myself!

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 19, 2008 1:50 pm
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
Certainly! I'm a fan of "suggested builds", or "support cards", keep it modular.

Certainly an EGT/AFR/ETC card, and a version number, would be great.

Then people can use version 2.1, and if they make a change they propose version 2.5. Then your computer stays upgradable, while still being "standardized" to retain supportability and as a sanity check. Also it makes it easier for people to actually DO something - instead of seeing a schematic and trying to hack out their own custom near-copy.


Fri Feb 22, 2008 10:54 pm
Profile ICQ YIM
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
As i was saying back in January here...

ababkin wrote:
First off, i am the proponent of having all the extra (non time- and safety-critical) stuff to be on a separate CPU/MCU, to offload all the extra number crunching off the main CPU as well as remove the risk factor of the extra non-critical code somehow undermining the safety of the critical code. This is of course a luxury at this point (having 2 CPUs, PCB's etc), but should be considered for the final "bullet-proof" solution nevertheless.

_________________
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.


Sat Feb 23, 2008 4:55 pm
Profile
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14914
Location: Home sweet home!
That would be all well and great, but what do you do with the 60 I/O pins on the injection/ignition/rpm/engine position CPU that aren't needed for those three functions? Waste them? I would prefer to use them, and I see no good reason not to. All things that aren't time critical just get done when the CPU isn't doing something more important. Hooray for interrupts :-)

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 Feb 23, 2008 5:10 pm
Profile WWW
LQFP112 - Up with the play
User avatar

Joined: Tue Jan 15, 2008 5:14 pm
Posts: 215
Admin wrote:
That would be all well and great, but what do you do with the 60 I/O pins on the injection/ignition/rpm/engine position CPU that aren't needed for those three functions? Waste them? I would prefer to use them, and I see no good reason not to. All things that aren't time critical just get done when the CPU isn't doing something more important. Hooray for interrupts :-)

Fred.


I do know exactly where this IO hunger/greed comes from ;)
(and don't get me wrong, i also like to minimize waste)

Interrupts are all nice and good, but things done in main loop would also need to be snappy, which is inversly proportional to the IO handling count.
To handle many IOs while keeping time-critical non-interrupt things realtime (like the teeth counter/decoder for instance), we'd need to introduce concurrent loops with various priorities, etc. This increases complexity and introduces the risk of concurrency issues (like deadlocks, livelocks, racing, etc, and no you cannot test of even debug this easily) - the risk that i didn't want in the critical part of the EMS.

_________________
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.


Sat Feb 23, 2008 7:07 pm
Profile
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
If that's the concern, get a smaller, dedicated chip for running the motor, and keep the i/o laden one for running the periferals.

Things like wheel sensors, etc, might overwhelm the cpu with interupts if you have a 40 tooth crank, 4 tooth cam, 100 tooth x 4 wheels, 50 tooth driveshaft, etc... Figure that's (per minute) 8000 rpm x (40 + 2 + 100x4wheels/4rear-end + 50) = 1536000 interuprts per minute at top gear, full tilt, low geared car. Can you run 25600 sub routines per second? It's over 3 thousand cpu cycles per interupt at 80 mhz.

My feeling is you would still use most of it on the chip. If I were to offload some things, it would be stuff like a wheel speed sensor. Perhaps you can get away without an interupt and merely have a counter you poll. Certainly various interupts take priority over each other, which does mean some debugging.... And honestly many of the things I would want a high amount of i/o for is low rate stuff: updating guages, turning on lights, enabling cooling fans, air conditioning.

The best thing to do is write some sub routines which do some generic math, light a light or something, and bang the chip at 30 khz with interupts out on different pins (I guess you could have it interupt itself if you're short on ways to drive it. :-P


Sat Feb 23, 2008 7:52 pm
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14914
Location: Home sweet home!
One must be careful what exactly they assume ;-)

For example, assuming that the fuel, advance and dwell calculations will be done in a slow "main loop" might be a touch foolhardy :-)

The chip is only 40MHZ though, not 80, and I really like the idea of a secondary chip taking care of heavy interrupt loads like wheel speed and driveshaft speed sensors. I like it a lot.

Like Flacid says, most I/O stuff is low speed and takes little to no calculation. Bit banging the LED's at the moment for example is a very fast process indeed. The sleep loop does 3000 iterations between doing anything for 1ms each loop uses more than one CPU cycle.

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 Feb 23, 2008 11:39 pm
Profile WWW
Post Whore!
User avatar

Joined: Sat Feb 16, 2008 12:11 am
Posts: 629
Location: Sunny San Diego
There might be more overhead in actually realizing a situation like this (see, I'm trying to pace myself and not say everything at once) but what I really had in mind is a chip that would count and get polled, but if it saw more than x counts per second, or varied in rate by more than y amount (per second^2) it could interupt. Having to set that would suck, maybe. But, maybe not.

The more automatic it is, the more time is saves - and the more possibility for errors.


Mon Feb 25, 2008 9:28 am
Profile ICQ YIM
Moderator
User avatar

Joined: Tue Jan 15, 2008 2:31 pm
Posts: 14914
Location: Home sweet home!
Bump for everyone to read the first post!

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!


Wed Apr 02, 2008 1:46 pm
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 9 posts ] 

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.