> > snips...
> >
> > Well then as I understand it these GM LS1
> > one-coil-per-plug
> > units do not have a problem with charging time and
> > current
> > limiting. They fire when they are told with a
> five
> > volt
> > pulse and thats it. I could be wrong. These are
> the
> > units most
> > of us have and most of us are using now. GM part #
> > 12558948
> > If it takes some signal conditioning so be it.
> > If necessary I can set one up on the bench as I
> have
> > a
> > pulse generator and 12 volt power supply with
> > current
> > monitoring to verify.
> >
> > Lets keep this simple and deal with only one issue
> > at
> > a time. Too confusing otherwise. I am not
> > considering
> > the extra code at this time. Just the basic
> > MEGASQUIRT- 2001- V3.000 code to keep it simple.
>
> That's a good place to start, but you will not be
> able
> to control ignition with the V3.000 code. If you
> plan
> to work out another solution on that front, then
> this
> code will work for fuel only. The only other issue
> that comes to mind would be injector staging, which
> again is offered only in the -extra code.
>
> > For example: I assume the RX8 wheel will be
> > incorporated
> > in the extra code so that is of no interest right
> > now.
> > Is that a correct statement?
>
> Yes...certainly will not be ported back to V3.00.
>
> > We can make a cheap steel disk that will work with
> > 2nd gen,
> > third gen or RX8 keeping it simple.
> >
> > Some of us would also like to use MSD units. As I
> > understand
> > it these too can be fired with a simple five volt
> > pulse.
> >
> > Paul Lamar ...No rotor no motor.
>
> If you want to run LS1 coil packs from -extra code,
> then it's pretty straightforward. Like you say,
> these
> units have integral ignitors and take a logic-level
> signal, so driving them should be simple.
>
> In the msnsextra code settings for rotary, there is
> an
> option for FC or FD style ignition triggering. You
> want FD. Here's the difference:
>
> FC uses a single trigger pulse for leading. The
> trailing uses a trigger pulse at the same frequency
> as
> the leading, but some ecu-determined timing offset.
> As the two trailings need to fire separately, there
> is
> a third signal, the 'select' signal, which
> determines
> which of the two individual trailing coils to fire.
> So...three control signals to the coil packs -
> leading
> signal, trailing signal, and trailing select signal.
>
> FD uses a single trigger pulse for leading as well.
> For trailing, each coilpack has it's own dedicated
> timing signal, rather than the 'select' method used
> in
> FC.
>
> The rotary code is set up to use the three led
> circuits as ignition outputs. Pullup resistors need
> to be added as shown in the pic part way down this
> page:
>
http://megasquirt.sourceforge.net/extra/setup-gmdis.html
<http://megasquirt.sourceforge.net/extra/setup-gmdis.html>
>
> The two leading coil packs would be fired together
> via
> one led driver circuit, and the remaining two led's
> would fire the two trailing coils.
>
> I realize the MS world is hard to follow. Such is
> the
> nature of a highly active open source community.
> Development happens at lightning speed, so newer
> codes
> are feature rich, but often documentation-poor!
>
> Roger.
>
> You are back to talking extra code here. I am not
> going
> to run the extra code. If necessary I can modify the
> basic
> V3 code. There is a lot of stuff in the extra code
> we don't need for an aircraft application.
> I don't really care about new developments anyway.
> They mostly seem to deal with car issues.
> Extra code is four or five times larger. Harder
> to maintain, harder to debug and harder to modify.
> Keep it small and tight. KISS
Paul,
Why bother modifying the V3 code, when the work is
already done? The majority of the code bloat that
occurs in -extra results in increased program size,
but not proportional increase in cpu overhead. Big
blocks of code are jumped over each cycle if that
particular option is not enabled. If you want to hack
a code base, go to -extra, and pull out the code
blocks you don't need. You could drop in size
dramatically, but as there's no issue with flash
storage space, trying to reduce program size would
have little tangible benefit.
The extra code as it sits will fire the LS1 coils with
only the addition of pull-up resistors to the board.
The extra code will also decode a variety of different
wheel configurations, so that side is also addressed.
Seems like a logical choice to me, unless you are
looking for another project.
Roger.
I'll take a look at that idea Roger. Thanks.
Paul Lamar ...No rotor no motor.
What's the statistic on how many lines of code there are between bugs??
More lines IS more bugs... (I know, these are lines that don't ever get
executed.)
My only issue with 'big' programs is that they take a long time to
load.. In this case, the flash time will be increased (though I have to
admit that I don't know how 'big' we are talking about here). When
doing dev/debug work, anything that slows that iteration process is
annoying.
Anybody looking at running CVS (concurrent version software) for a
project like this? That can be slick because you might be working on a
chunk of code that you don't want to throw away (or reintegrate), but at
the same time you might be interested in trying out something that was
developed in a new version of software. CVS allows this by keeping
track of differences/changes in files. Very slick. And a huge
time/effort saver on a project with multiple developers..
Regards,
Matt-
Matt, some really good points you have there. The flash memory
we are talking about here is 64K max and the serial port works
at 9600 baud I think. In the old days we burned and erased
our 16K EEPROMS over and over hundreds of times.
The MS basic original binary code is 13K and and the "Extra" code
is 53K.
Paul Lamar ...No rotor no motor.
The Rotary Engine NewsLetter. Powered by Linux.
ACRE NL web site.
http://www.rotaryeng.net
Copyright 1998-2006 All world wide rights reserved.