I have about decided to do a single chip solution to
  the dwell ignition problem  because  potentially it is the
  cheapest way to do a stand alone ignition for use with a carb.
  The knowledge gained can then be used to do a variety of simple
  things including a trim table adjustment to the 555 fuel injection
  system using spread sheet data as suggested by Henry Nee.

  I will focus on assembly language as these are time critical jobs
  and with assembly language you always know how long
  it takes to do anything. If you keep the job  short and
  simple the software size will be manageable from many aspects.

  Further more I have considerable experience with assembly
  language much of which can be applied to the AVR instruction
  set.

  I realize that most of you will not be interested so you
  can delete the messages on the subject.

  Those that wish to follow along can make a folder and move
  the stuff over to that.

  Tom Walter, I think, was the first to mention the
  Arduino board as a good low cost and small AVR trainer that will
  do a variety of jobs. The advantage is it is wired
  for USB and there is programming software that runs
  on both Windows and Linux.

  There are a lot of people using this board around the world so there
  should eventually be a lot of asm code examples.

  The Arduino Mega 2560 is a small microcontroller board based on the
  ATmega2560.
  It has 54 digital input/output pins (of which 14 can be used as
  PWM outputs), 16 analog inputs, 4 UARTs (hardware serial ports), a 16
 MHz
  crystal oscillator, a USB connection, a power jack, an ICSP header, and
 a
  reset button. It contains everything needed to support the
  microcontroller;
  simply connect it to a computer with a USB cable.

  We will be using only a very few of these capabilities but the cost
  and size is so low it does not matter.

  AVRA is an assembler for Atmel AVR microcontrollers, and it is almost
  compatible with Atmel's own assembler AVRASM32.

  The initial version of AVRA was written by John Anders Haugum in 1999.
 He
  released all versions until v0.7. All later versions were released by
  Tobias
  Weber. And version 1.3.0 is released by Jerry Jacobs.


  Paul Lamar

  Runs on a Mac too.  This is the board we are using in the Mechatronics
  courses at the University of Utah.  Mostly for automated robots with
 lots
  of sensors.

  Chris Cosman

 Paul,

 The AT90USB Demo-Kit sells for 31.00 on Digikey and I think provides
 similar resources, plus has some external flash storage that might help
 for
 storing tables.  Check it out, as it could be a cheaper alternative.

 Thanks,
 Brannon

 That is a bargain. I had to call and confirm it was completely assembled.
 That beats the Arduino for our purposes. Thanks for finding that Brannon.
 I ordered one.

 Paul Lamar

 Paul,

 No problem, happy to help.  Let me know if you would like any help coding
 this up or if you'd like someone to review your code.  I've done several
 designs on these processors and one on this board in particular.

 One note, you might want to consider writing the majority in C, as you
 will
 be able to use the Atmel supplied libraries for USB communication, etc,
 and
 coding your time critical procedures in assembly.  Most compilers have
 statements that allow you to write in-line assembly.  Also, you can

 always
 generate the .lst file on compile and see what assembly is being
 generated
 for any code you do write in C.

 Thanks,
 Brannon

 Great Brannon!

 Good to hear it. Here is the problem.
 At 7500 RPM the engine makes one rev in 8 ms.

 The RX8 coil delays a fixed  2 ms after the crank sensor tells
 it to fire. This is called dwell.  In effect what this does is retard
 or reduce the advance near 90 degrees. That causes the spark to fire
 about 70 degrees AFTDC!!!!!! Of course losing power in the bargain and
 hurting the BSFC. (fuel burn).

 My suggestion is to measure the period of a give RPM and anticipate the

 advance
 required up to 2 ms at 7500 RPM for the next revolution. As you go
 through the
 rev range of course the adjustment changes. No adjustment at idle and a
 lot
 (2ms) at 7500 RPM.

 Any ideas? Do you have a scope you can test it with?

 CD's don't do this but they are a lot of bucks compared
 to the LS1 or RX8 coils with built in solid state switches.

 Paul Lamar


 What kind of help would you like on this project?  I think you ordered a
 different board, and it sounds like you are already coding things up.

 Let me know.

 Thanks,
 Brannon

 It had a lot of I/O on it in the form of input switches and ouput LED's
 and it was so cheap ($30) I could not resist. Just blink an LED when a
 switch
 is pushed and we will use that as a simple starting program.
 I'll explain it step by step for instruction and discussion.


 Paul Lamar


 Paul,

 Here's a simple routine that flashes an LED at Port B1.  If you send me
the
 output port that is going to the on-board LED, I can modify the code
 appropriately.  The LED flash frequency is also dependent on the micro
 clock frequency, and can be modified by adjusting the quantity
 LED_FLASHCOUNT found in LED.h.  I compiled it in AVR Studio 4 and had no
 issues.

 This is in C, and is well commented...let me know if this is the type of
 example you are looking for and I will expand it to flash the LED when a
 button is pushed.  Currently, it shows how to configure an output, and how
 to use an on-board timer to generate precise timing.  For the real app, I
 would probably use an interrupt, but as a first example that would
probably
 get a little complicated.

 Thanks,
 Brannon

 Can you do that in asm? Down the road when we get to time critical
 application we will need to do it in asm.

 Paul


Paul,

I agree that ASM will get you slightly faster code, dependent on the skill
of the coder, but I would not immediately discount C unless you can see on
a scope that it is too slow.  In most cases The generated ASM is plenty
fast.  For AVR processors, I have not had to use ASM except for controlling
digital communication timing when I have had to bit-bang a protocol.  Just
compile and check out the LST file to see what ASM is generated.

I understand from your posts that you are a strong advocate for coding in
ASM, but in my opinion it should only be used as necessary, as you gain
alot by using C in terms of readability, maintenance, being able to change
features, etc.

That's how we've done things with the med devices I've worked on for the
last ten years anyway.  Your call of course.

Thanks,
Brannon

C is great for a lot of things. IMHO it is not only about speed. When
controlling high speed mechanical
device it is essential to have precise timing accuracy. You don't get that
with C.
Print out the asm of your compile and send us that.

Paul Lamar

Sorry, but you can't draw a broad conclusion like that.  You have to look
at the speed and precision in which you want to operate, compare that to
the clock cycle of the microcontroller, and then determine where and when
ASM is appropriate.  Otherwise you are simply over-optimizing for a need
that may or may not even exist.

Both methods will provide deterministic code, which sounds like one of your
concerns.  The structure of the code is the major item that will determine
the timing accuracy.  As an example, the code that I sent will have a
timing variability based on where the main loop is in relation to timer 0
interrupt.  If this variability is unacceptable, pulling the flashing
routine out of the called function and placing it within the main loop
would reduce that variability (since calling a function takes about 20
lines of ASM, and those would be removed if the function call was removed).
Still don't need ASM.  Now, the actual setting of the bit will most likely
be done in two ASM instructions, whereas it could be done in one.  This is
a great place to do inline ASM, but only if it is really necessary, as one
ASM instruction, assuming two clock cycles for the execution, only takes
125ns.  Does your system require optimization in the 125ns ballpark?  If
so, what parts?

My point is that ASM is great, in the right situation.  Otherwise, it's
harder to write, more difficult to debug, and takes longer to develop.

Anyway, here's the LST file.

Thanks,
Brannon

All this to read a switch and turn on an LED in C?

Paul Lamar



It's built on an expandable, modular framework.  If you look at the C you
would see that.  Most of the assembly is backing up registers for function
calls and bit operations.  Also housekeeping stuff found at the beginning.
Most of this can be removed from the C code, but I would contend that it
should only be done if needed, as these are best practice methods.

If you are more comfortable with ASM then go ahead...that's certainly a
valid reason, it's one of the reasons I like C.  I'm simply disagreeing with
your blanket performance claims.

Brannon


We don't need an expandable, modular framework.
All we are doing is using a $30 single chip computer board to
do a job that should or could be done in analog chips if they
were available.

Paul Lamar