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


 Gotcha...

 Brannon

Paul,

Okay, I removed all the fancy stuff.  Here is a program that will turn on
an output LED on PB1 when a button is pushed on PB0.  I've included some
inline assembly to show how that is done.  The .lss file is significantly
smaller, though as you can see you could ASM the input check as well, as
the C compiler translates the check generically and does not take advantage
of the ASM instructions that are tailored to the I/O ports.

Thanks,
Brannon

ROLF the whole program could be hiding in the includes :)
We don't need no stinking includes :)

Paul Lamar


Hi Paul, I've been reading a few hours a day, learning, getting an over
view of what these things do. At the moment, while downloading avr studio5,
I read down and linked to all of the Xplained mcu boards. There are ad on
boards for the xmega-a1, and their other eval products; that do sensors.
Sensors include gyro, accelerometers, compass, and pressure. Looks like
there is a lot of interest in these functions.

www.atmel.com/products/AVR/sensors_xplained.asp

Hopefully, in a few days, I can plug mine in and begin to try it out. It
really does appear that there is a lot of in house software support to get
me going.

Ed Carver

I wish I had more time to work on this asm stuff but I am focused on getting the RV4
flying. Asm is a very creative medium and a lot of fun.

I am almost there with the RV4. I have the camera mounted one the tail wheel
spring and the screen mounted on the instrument panel.

I was delayed a few days with a problem getting new PC boards made.
The last thing is getting the new PCM mounted in the instrument panel
and getting your wide band mixture monitor  installed so I can run it up to
full power on a tie down.

Paul Lamar