Digital programmable CDI ignition for 2-stroke engines

[bob weir]

on the nov 29 post some of you have noticed the above rigol screen image has only one fire pulse , blue , not two. there is suppose to be a blue
fire pulse after every -71 deg input pulse.

oh , every other pulse , as shown ,could work. some of the time. in a 4-cycle engine

this post is to bring you up to date. the code was edited. there are new lines ... 39 - 55 and 66. a new user variable is d3 ,line 12.
what is going on is as soon as we have the TMR0 value it goes both to nmbr then to d3. and the plan is to delay an amount in d3
after the line 33 lead edge of a -71 deg pulse is detected. with the idea being the fire delay will be identical at least for 2 -71 pulses.

now the code looked good when i stopped the editing. the next step was to wire the uC into a breadboard and apply an input pulse.
and monitor this pulse and the fire pulse too. and see if there is now a fire pulse after every -71 pulse and if the delay between them
is the same for 2 pairs of these two pulses.

good news there is a fire pulse for every 71 pulse.
bad news , the delay between them is unequal . this you can see on the rigol screen image

here is the screen image and scans of the 3 pages of assembly code

 

[bob weir]

and here is the code.

before writing this post one idea to fix this mess was to use the MPLAB simulator and step thru some of the code and watch what
is going on with some of the registers.

and in writing today's post above with the screen image another idea came to me.
where there is an error with my code-thinking.

to not interfere with your own learning process nothing more will be said now.

i'll play with these 2 ideas and let you all know what comes of that in the next post.

 

[bob weir]

another idea , for perspective , is that with a ( mid-range ) uC that has 2 timers in it , not just one like these 'baseline' uC's have , each timer could
begin counting alternately after every -71 input pulse. our code , again ,will fire with the same time delay at least two times in a row.
for a 2-timer uC this time delay could keep up more closely when the rpms are changing.
and be a unique delay for each 71 pulse

given that one of these two-in -a-row identical time-delay fire pulses is 'wasted' anyway in a 4-cycle engine this all may not matter that much.
its something to keep in mind

remember the original plan for this project was to see how well a baseline uC could work in a ignition timing application.

although we've bumped into some unexpected problems and i'm still confident we'll
get this code done with the baseline 12F508 and get the motorcycle running again

 

[bob weir]

lets look at the 2 screen time delays and try to understand how they were created. the basis for this idea
is the time delays are both code - driven. so with the delays lets work back wards and get the multiples
of the line 40 dly25 and line 160 dly25u code . and play with them

for a first try we expect one of these two delays to be in accord with the frequency of
the -71 test pulse signal
and the other delay is via new code that delays by a 'nmbr' of times ( based of rpm and psa=128uS )

the one rigol screen shot shows a BX-AX of 3540 uS and the other is 2470 uS

and in the lower left corner of the dec 6 post , in blue , read 55 Hz

some math ... 55 hz has a period of 1/55 or 18182 uS .. divide by the psa = 128 uS = 142
142 becomes the variable nmbr value. and is what the range test code crunches.

first multiply 142 x 25u and get 3550 uS ... close to one of the measured delays.
this delay is the line 66 step of movwf d3. so that when line 40 runs this delay code repeats d3 times.
..... thus the 142 times to repeat times the 25uS delay per loop for a total of 3550 uS

now we should verify the range test result is the other time delay we measured.
for nmbr = 142 the range test result will be rt5 or rt6. leading to rpm 3024 with a literal of 104
or rpm 3324 and a literal of 92. lets see if either of these are close to 2470.

remember that these 'literal' numbers are based on the timing advance curve.

92 x 25u = 2300 uS 104 x 25u = 2600 uS

these two values bracket the 2470 uS that was measured.

this is close enough to the result expected for a 55 hz input to affirm we have
accounted for these scope readings.

also we have some idea what is wrong with the code. by 'wrong' is meant the two
delay values are not the same. and they should be. the first -71 delay is coded
by the value of nmbr. when what we need is the value of the literal in the rpm code
section. as this is what the 2'd -71 delay is based on.

the question now is how to set d3 to this literal ??? could it be done in each of the
12 rtN code or the 12 rpmXXXX code ? of just once at the start of the sub dly25u ?

more experimenting is called for. once both delays match then refining the code
may happen.

given we have lots of unused program memory space in the 508 uC its whatever works and
suits our style of coding
...................................................

 

[bob weir]

in the upcoming edited ignition code the command "movwf " is used 2 times in a row
with different destination registers.

this command is moving the contents of the w-register to some file.

left unsaid in the instructions section of the 12F508 manual is what happens to the
contents of the w-reg after this move.

something about this has bugged me for a long time. namely the matter of what is w-reg
after this move. recently i came across this topic. and the writer said the move is also a copy.
which answers the question.


example ...
movlw .250 ; this puts a decimal 250 in the w-reg
movwf d3 ; now 250 is copied from w-reg to the d3 variable
movwf d2 ; 250 is copied again from the w-reg to the d2 variable

the belief here now is that all of w-reg , d3 and d2 now contain the same value of 250

and just to be absolutely sure the simulation tool of MPLAB will be used to verify this

 

[bob weir]

this rigol screen image shows the fire pulse after each -71 pulse with equal delays.
this is the goal of the ignition assembly code program.

via previous posts you recall the code was firstly delivering a fire pulse after every other -71 pulse.
and in later code , delivering a fire pulse after every -71 input pulse.
only in this latter case the time delays were not equal. one varied with a delay according to rpms .
as it is suppose to.
while the next one was the same delay no matter what. ( the errant fire pulse )

that was the problem to solve. figure out why and do some code editing.

one path taken was a review of the rules for using the assembler directives Pagesel
and Banksel. doing so led to the conclusion neither one is necessary for this chip.
read about these in gooligum baseline lesson 3.

the 508 has only one bank of registers. and at 512 memory locations ( one page) a goto
command with its 9-bits for the address can reach anywhere in memory it needs to go to.

the principal clue worked with was that the errant fire pulse was happening 200 uS after
the 'first' -71 pulse. since this delay has to be coming with the code the effort was to see
what was making such a delay. the cause was identified. the dly25u subroutine had as
a 1'st line movwf t1. and the sub' was getting called by the fire subroutine. it was determined
that t1 would have to be loaded with the literal for the number of times the dly25u sub' runs
in some other place. this was accomplished by adding the line movwf t1 to each of the 12
rpmXXXX sections of code.

if you would like the newly edited code e-mail me at [email protected]
the previous ver. , with its coding errors, is available too. just say which you want

the MPLAB s/w lets you save the project in an .asm and .mcw zip-file. they are easily
un-zipped then MPLAB can open them for editing, printing etc.
ver. 8.70 was used to generate these files. this will save you the work of using the
project wizard to create and build a program. plus the hassel of having to deal with
the .jpg scan of the code pages posted here.

right now i'm looking at a few things to do and post that will add to an understanding
of what all is going on with the code. one will be a revised flow diagram. it comes to mind
again that some readers are very new to all of this. and for their sake i want to make this
posting of an ignition project be a 'cdi ignition code 101' level. the idea here is to provide
a working example of ignition code . so that one can then use it as-is or make changes
to suit your own engine.

a note here to clarify calling a pulse the 'first' pulse. the yellow pulse of CH 1 is off
the flywheel. and occurs at about -71 deg btdc. every revolution.
these are the pulses being called 'first' and 'second' .
the code needs two of these -71 pulses. a 'first' one and a 'second' one.
to calculate rpms / period to then be able to know what the proper delay-to-fire is
according to the mfg's given timing diagram. this delay-to-fire is some integer multiple of
the dly25u subroutine. the integer is saved in the variable t1 to be used for fire-timing
after the next pulse ( the 'first') of the two-pulse pair. ( a 'first' and a 'second')
thus the time-delay-to-fire after the first -71 pulse
is a repeat of the last calculated delay. then a new delay is calculated. and this delay shows
up after the 'second' pulse fire-pulse delay. this cycle of calculated-delay , repeat -delay goes
on for as long as the engine is running.

this may be better done with a sketch. let me think about that ...

 

[bob weir]

; note - jan 6, 2016 this is the ver. of code that led to the rigol screen shot posted yesterday
; it was copied from the .mcp project screen with the .asm listing shown. the copy-paste
; process from MPLAB IDE 8.70 s/w to this sites editor caused the layout to become messy.

; when you go to Build this code as-is on the screen here a million error msg's will show up
; because of all the command lines beginning in the L-most column where only
; line labels are suppose to be
;
; a reminder about using the zip file for this project. its a snap to extract, then just dbl-clik
; the .mcp project file and the windows-7 will automatically find MPLAB 8.70 on your PC
; and have it open the .mcp file, find the .asm file too and show you the screen of these
; two entities . from there you can just close it, or edit and build it . either way you will
; have the hex file your PK-2 or PK-3 programmer needs to burn a 12F508 with.
;
; or if you set for 'line numbers' and to print them in the Edit menu , Properties , " 'ASM' file
; types" you can print out a nice copy of the assembly code listing. w/ line no's
; but , as you can see
; the PC-7 op-sys 'copy' - 'paste' commands do not catch the line numbers when you
; want to get them from your .mcp screen to this forum



list p=12F508
#include <p12F508.inc>
__CONFIG _MCLRE_OFF & _CP_OFF & _WDT_OFF & _IntRC_OSC

UDATA ; variable definitions
nmbr res 1 ; this is the number of psa = 128uS per rev of crankshaft
d1 res 1 ; for dly25u sub
d2 res 1
k1 res 1 ; for the dly25 sub
k2 res 1
t1 res 1 ; t1 holds the rpmXXXX loop count number

RCCAL CODE 0x1FF ; rc calib location of OSCCAL number at 0x1FF
res 1
RESET CODE 0x000 ;; RESET_VECTOR CODE 0x1FF
movwf OSCCAL
; OPTION bit 2-0 = 110 prescale 128 ; bit 3 = 0 p/s to tmr0
; bit 4 = x ; bit 5 = 0 use int; clock enable a2 ; bit 6,7 = x
movlw b'11010110' ; chg 111 110 nov 14 for 128u psa
option
movlw b'001000' ; 0,1,2,4,5 are outputs a0->CDI , a3 is pulse in
tris GPIO ; the 12F508 PORTB pins are also called GPIO

movlw .250 ; pre-load d3 with a slow rpm value and a long delay
movwf t1 ; t1 is the number for delay code 'dly25' to loop after 'first' -71

start clrf GPIO ; clear pin A2 for later fire pulse out on it
nop
one btfsc GPIO,3 ; loop until a3 pin is a zero
goto one

p_up1 btfss GPIO,3 ; loop here until 1'st pulse 0-1 edge occurs on pin A3
goto p_up1 ; note that code detects '1' levels not 0-->1 transitions
clrf TMR0 ; zero the TMR0 file ... and start counting in 128uS units

dly25 movf t1,0 ; store t1 into w
movwf k2 ; put w into k2 , the loop count
c2 movlw .7
movwf k1 ; k1 and k2 are user variables
c1 decfsz k1
goto c1
decfsz k2
goto c2

fire1 bsf GPIO,2 ; make A2 high to begin the fire pulse , 'A2' = GPIO 2
movlw .8 ; 8 x 25u = 200u
call dly25u ; jan 3 here is where t1 ends up being 8 via line 173 movwf t1 i.e. w is saved to t1
nop
bcf GPIO,2 ; bring A2 low to end the fire pulse

two btfsc GPIO,3 ; loop until a3 pin is a zero again , added dec 30
goto two


p_up2 btfss GPIO,3 ; monitor A3 for rising edge 1-0 of 2'd incoming pulse
; ; when A3 is a '1' then jump to "movf TMR0,0" to save its value in nmbr
goto p_up2 ; note that code detects '0' levels and not 1-->0 transitions
movf TMR0,0 ; store TMRO in w
movwf nmbr ; copy w to nmbr ... for range tests , w still = tmro

; the 12 range tests span 1900-5100 rpm ; rtn .. the rt is range-test

rt0 movlw .234 ; nmbr in range 234-255
subwf nmbr,0 ; 1900-2000 rpm
btfsc STATUS,C
goto rpm1900
rt1 movlw .213 ; nmbr in range 213 - 233
subwf nmbr,0
btfsc STATUS,C
goto rpm2011
rt2 movlw .195 ; nmbr in range 195-212
subwf nmbr,0
btfsc STATUS,C
goto rpm2211
rt3 movlw .173 ; nmbr in range 173-194
subwf nmbr,0
btfsc STATUS,C
goto rpm2416
rt4 movlw .156 ;nmbr in range 156-172
subwf nmbr,0
btfsc STATUS,C
goto rpm2725
rt5 movlw .142 ;nmbr in range 142-155
subwf nmbr,0
btfsc STATUS,C
goto rpm3024
rt6 movlw .130 ; nmbr in range 130-141
subwf nmbr,0
btfsc STATUS,C
goto rpm3324
rt7 movlw .120 ; nmbr in range 120-129
subwf nmbr,0
btfsc STATUS,C
goto rpm3633
rt8 movlw .111 ; nmbr in range 111-119
subwf nmbr,0
btfsc STATUS,C
goto rpm3939
rt9 movlw .104 ; nmbr in range 104-110
subwf nmbr,0
btfsc STATUS,C
goto rpm4261
rt10 movlw .97 ; nmbr in range 97-103
subwf nmbr,0
btfsc STATUS,C
goto rpm4550
rt11 movlw .91 ; nmbr in range 91-96
subwf nmbr,0 ; 4882-5100 rpm
btfsc STATUS,C
goto rpm4882
; goto start ; for the case when nmbr is < 91

rpm1900 movlw .208 ; these literals, .208 et al, are all calculated based on rpm's
movwf t1 ; copy w-reg value to variable t1 for the correct fire-delay for 'first' -71 pulse
call dly25u
goto fire2
rpm2011 movlw .180
movwf t1
call dly25u
goto fire2
rpm2211 movlw .160
movwf t1
call dly25u
goto fire2
rpm2416 movlw .140
movwf t1
call dly25u
goto fire2
rpm2725 movlw .120
movwf t1 ; note that w=120 after being copied to t1
call dly25u
goto fire2
rpm3024 movlw .104
movwf t1
call dly25u
goto fire2
rpm3324 movlw .92
movwf t1
call dly25u
goto fire2
rpm3633 movlw .80
movwf t1
call dly25u
goto fire2
rpm3939 movlw .72
movwf t1
call dly25u
goto fire2
rpm4261 movlw .64
movwf t1
call dly25u
goto fire2
rpm4550 movlw .56
movwf t1
call dly25u
goto fire2
rpm4882 movlw .52
movwf t1
call dly25u
goto fire2

dly25u nop ; do not copy literal to t1 in this sub
movwf d2 ; copy literal value to the d2 reg. for loop count control
p2 movlw .7
movwf d1
p1 decfsz d1
goto p1
decfsz d2
goto p2
retlw 0

fire2 bsf GPIO,2 ; make A2 high to begin the fire pulse 'A2" = GPIO 2
movlw .8 ; 8 x 25u = 200u
call dly25u
nop
bcf GPIO,2 ; bring A2 low to end fire pulse
nop
goto start ; repeat code for next spark

END

 

[bob weir]

this set of data shows both the delta-t delay for in-range RPMs and out-of-range RPMs too.

a reminder and by the table of data above you know the RPM range this code as is written
now for is 32 - 81 Hz or 1920-4860 RPM . the lower end is limited by the prescalar choice
of 128. and we can easily add code to extend the upper RPM range , with the 128 as is.

the first check is that the in-range data is good.

and for the sake of more thorough code understanding
i thought it'd be good to know how the code produces the out-of-range delays as well

when the code measures the time between 2 71-pulses it is counting on the TMR0
counter to not overflow i.e. stay at 255 or less. thus we are limited to whatever period
255 x 128uS is equivalent to in RPMs. my calculator says this is 1838.24 , 30.64 Hz

by 'limited' i mean this is the slowest RPM that can be measured with the code range-tests.

so why doesnt this , 30.64 Hz , agree with the 32 Hz / 1920 RPM above ?

a note about the data ... there is some measurement error in this table of data.
due to not fully knowing how to operate this scope.
it has 'tracking' and 'automatic' cursor placement for this sort of measurement.
only they dont behave as i expect them too. thus 'manual' is used. and the errors are
due to the width of the screen cursors themselves.

note - a look is also being taken at the fact that each RPM range has but one delta-t.
and that this could mean some rpm's are fired 'early' and others 'late'.

 

[bob weir]

by the jan 13 posting table of data you can read that the code produces 'fire' pulses for input signals that are
out of range in terms of the RPMs.

ideally the engine spark plug fires only when the rev's are in the RPM range the code was written for.

the code is based on the manufacturer's given timing diagram.

you have read that the code can be easily edited to include RPMs beyond the present 4860 limit.

there is a problem with the code dealing with an RPM below the 1920 limit.

here's an example. let the RPM be 1800
calc. the period ... 1800/60 = 30 HZ
then the period is 1/30 = .033 sec

calc. what nmbr should will be
.033 / 128uS = 260

in one rev of the flywheel at 1800 RPM the TMR0 overflows ( ... 254 , 255 , 0 , 1 ,2 ,3 ,4 ... )
and the returned count is 4 , not 260 . 260 is too large to fit in 8 bits
4 for nmbr is a very high RPM

the math ... 4 x 128uS = 512uS for a period in HZ this is 1/512uS = 1953 HZ
and 1953 x 60 = 117K RPM way beyond what this engine can run at

for the code to run as-is there will occur fire pulses not according to the given timing diagram.

for the upper end some simple math can tell us what the actual code-able upper RPM limit is.

the lower end comes with a favorable circumstance. the magnet on the flywheel produces
a -9 deg BTDC signal every rev. and we can use this signal to fire with up until the engine
RPMs meet the lower code limit.

we'll need a way to direct both of these signals to the same destination
a 2-input OR gate could do the job.
or possibly with a wired-OR circuit like is already in use on the CDI circuit board.

we can view this -9 deg signal as mechanical in origin and useable from the lowest RPM the
engine will idle at up to near 2000 RPMs. which is to say the engine will run at these low
end speeds without needing any help from a microcontroller

this problem is due to the long times one rev takes at low RPM in terms of how high
the 8-bit TMR0 can count before overflowing. as is coded we are using the same 128
prescalar for the entire RPM range, low to high

the value for the prescalar of 128 is selected with bits 0, 1, 2 of the OPTION register.
it may be possible to change this value to better optimize the nmbr count depending
on where in the RPM range the engine is now turning. i mean to change it on-the-fly with code.
have it be 256 for the low end , and 128 mid-range, and 64 for hi-end RPM

this last idea is just food for thought. to be able to do that is intriguing

my next efforts will be to edit the code and eliminate any fire pulses out-of-range.
and see about utilizing the -9 deg signal for the lo-end RPMs

 

[bob weir]

for the sake of the person new to this CDI ignition code forum and a reminder to everyone else here is a summary of the path we have taken thus far :

version 1 of the code produced one fire pulse a calculated delay after the 2'd one of a pair of -71 deg signals off the flywheel

version 2 produced a fire pulse after each -71 deg signal. only two fire pulses in a row were not of the same delay

version 3 fire pulses were of the same delay and the delay was of the timing diagram posted on p. 3 aug 11 2015

note : all 3 versions were error prone for flywheel signals of RPMs out-of-range ...less than 1900
and beyond 4900.
the coded in-range RPMs were from about 1900 to 4900.
there were 12 tests in this range, thus each test was for a RPM span of about 300

this span of 300 was arbitrary. and chosen when it was not known if the final code size would fit into a 12F508 uC chip

ver 3 code fills about 1/3 the memory space of the 12F508. and it appears there is plenty
of room both for the planned ver 4 changes. and to decrease the RPM span to 200 or so
if we ever decide to do that

version 4 is being worked at present. it is intended to fire only for flywheel signals that pass the in-range test.

there will be no code for RPMs less than 1900. by the timing diagram you can see that the -9 deg
signal off the flywheel (see magnet foto p.2 6-12-15 , and scope flywheel -71 , -9 signals ) can be used from idle to 1900 RPM.

also the ver. 4 code will have 3 or 4 range-tests added to extend the upper range out to 6000 RPM

and to repeat something that is shown by the timing diagram ... no microcontroller is needed
for the low-end RPMs. the -9 deg flywheel signal does the engine timing nicely out to 1900 RPM

the purpose of this project is to write code that provides the proper
timed fire signals for the RPMs from 1900 on out to 6000.

but not produce any fire signals for RPMs outside of this 1900-6000 range

the engine will not speed up any beyond 1900 RPM without electronically aided timing advance.

you'll still be able to ride your dirtbike. slowly though , and without power to climb anything
using only the -9 deg fire signal

 

[bob weir]

 

[bob weir]

no way was found to make the ver 3 code work to my satisfaction. the problem was out-of-range low RPM values . they had the same appearance as did
the in-range values. the code had no way to tell if the TMR0 value was an overflow value or not. if this baseline uC had a flag to tell you when TMR0 overflowed we'd a had a chance.

an idea for you all who want to make this rev. 3 code work for you ...
recall that the -9 signal could be used to send a fire signal for idle up to 2000 RPM. we could simply wait until the engine is good and warmed up then switch on the uC. by rigging a switch
to the throttle cable to on-off the uC.


ver 3 used TMR0 to measure the rotation period of 360 degrees. on doing this we get big numbers from slow RPM's using psa = 128.
what is being explored is using the 2 signals -71 and -9 to time the rotation. this amounts to timing 62 of 360 deg. a time for 62 deg still
correlates to a period. that is we dont have to measure a full revolution to know how fast the flywheel is turning.

we will measure the delta-t between every pair of the 2 pulses -71 and-9 then fire some delay after the next -71 arrives.
the TMR0 will be used to measure the delta-t between -71 and -9. and the delay-to-fire will be done with software.
we have to do it this way. there is only the one timer , TMR0. and we are required to be doing two timing operations simultaneously.

we just gotta watch it and not have the code run longer than the worst case of 1111uS.
if that should happen the -9 pulse edge would pass by the sensor and not be detected and the code would loop
until the next revolution. this creates an overflow out-of-range value for TMR0

by data in the table above you can see that all numbers returned from TMR0 are in the
8-bit 0-255 range. so long as the idle is set to 660 or more there will never be
any overflow in TMR0. 660 rpm for an idle value is lots more reasonable than 2000

in case you were wondering where the -31 deg comes from it is off the timing diagram posted long ago.
the most ignition timing advance the engine gets at high RPM is -31 deg

 

[bob weir]

humble apologies for the error in the posting yesterday.

its on the sketch-with-notes--table page. the note along the right side ... "the code has from -71 to -31... "

the code ( for the RPM range-tests ) cant run at -71 as that is when the delay-to-fire code has to run.
the range test code runs after the -9 pulse '1' is detected. as once we have this '1' level we read the
TMR0 and learn how many 64uS steps it took for flywheel to spin from -71 to -9 degrees.
this number gets saved at once. and is what the range-test code needs

at present i'm working on a number of sketches to better illustrate what the code is
doing and when.


looking ahead some means is needed to supply the uC with pulses to simulate
what the flywheel provides. 2 separate and distinct signal pulses
this morning i stumbled across the idea that for testing a digital signal generator will be able
to drive both the -71 and -9 uC pins simultaneously. it can do this because these
2 pins are read at different times. for the previous ver 1 to ver 3 code only one uC pin ,
the -71 pin , was needed to detect a test signal. now we need 2 of them .
we need 2 pins on the uC to detect each of these 2 pulses : -71 and -9 .
and the spacing between these 2 pulses will represent RPMs.

as of now only 3 of the 6 uC i/o pins are planned for use. 2 pins for the -71 , -9
input signals and one pin for the fire output signal to the cdi circuit board

an early test version of the -71/-9 code is planned to use 3 leds on the 3 spare
uC i/o pins. they will each light when the input pulses spacing matches the rpm range
for that led.

doing this will show you how the uC gets configured so all its pins are for digital i/o .
you'll have run into this matter via doing the Gooligum baseline lessons

 

[bob weir]

pseudo code for ver 1 of -71/-9 cdi code ............................. feb 8 2016

variables : c1 , c2 ; both used by subroutine dly25u
................... e1 , e2 ; both used by sub' dly25
..................... t_dly ; a value calculated so that the spark plug fires at the right time
..................... arc_62 ; the number of 64uS steps of TMR0 when read at -9 deg

pins used : GP5 -71 signal in ................ GP3 -9 signal in .................... GP2 fire pulse out to the CDI circuit

subroutines : dly25 and dly25u ; both provide a time delay of 25uS per loop

0. start
........................... ( the uC has already been setup for OPTION, TRIS, RCCAL , _CONFIG , TRIS , OSCCAL )
1. loop at the GP5 pin until a '1' is detected ( this is also called 'polling' a pin ) ... a '1 'means -71 is here
2. clear the timer TMR0 so it starts counting at zero in steps of 64 uSec
3. run dly25u the number of times in the variable t_dly
4. run the fire code with dly25 so that a 200 uS pulse is sent out to make the spark plug fire
5. now monitor pin GP3 until a '1' comes along ... a '1' means the -9 signal is here
6. read TMR0 and save the value in the variable arc_62
7. run the range-test section of code using the value in arc_62 for each subtraction test
8. the arc_62 value will be true for one of the 10 range-tests . once true the code jumps to one of the ten rpmxxxx pieces of code.
.................. there a unique value will be stored into the variable t_dly
9. end of code
..................... that's it. this is all the code needs to do. now it simply jumps back to the top ( 0. start )
................................ and repeats.


note : it will take further thought and testing to be sure this code outline is good. one concern i have now is that at slow RPMs the delay-to-fire takes so long the -9 signal is missed. it may be smart
to a) include the -9 signal in the CDI 'fire' path or b) set the idle speed to 800 or more

 

[bob weir]

guys - a sketch is being worked on. and should be ready to post in a day or two.

it will show the code action in terms of the 360 degrees of flywheel rotation timeline.

it is meant to aid understanding the big picture of what the program does. and where

a note of warning ... since the timing is in reference to degrees in advance of the 0 mark the labels for degrees are negative.

another note and one not highlighted on the sketch is how the -9 uC pin polling code has little time to run depending
............... on how long the time-delay-to-fire code runs. for a slow-rpm long delay to the -11 or -10 region the -9 uC
............... pin will have just a sliver of time to catch that signal.
also squeezing the time the -9 pin will
..................... have is the fire code that outputs a 200 uS pulse. and takes 200 uS to do so.
both the delay and fire pulse have to be done before the -9 pin code can begin polling.
and if the delay times are too long the -9 signal gets missed.


................. you will also see how for most of the rotation, from just under -360 then to -270 , -180 on to -90 and finally
when the flywheel gets to the -71 position does the code polling the -71 pin get a 'hit' . what i'm getting at is that for
over 3/4 of every rotation the code loops 1000's and 1000's of times as it polls for a signal that isnt there yet.
and if we were using a mid-range uC with
interrupt ability then we could include code during this 3/4 rev that does something useful. like send a signal to an
external RPM meter or something. and then read the TMR0 register etc. as part of the -9 uC pin
interrupt service routine


learning how well a 'baseline' uC can do this ignition timing job is one of the project's goals.
i'm still optimistic of getting a 508 or 509 do the job. only now with one new hurdle after another this
optimism is being tested. and my thoughts too are that one of you will come up with an
even better way to deal with the problems you've been reading about here

once i get the uC to run the engine so the bike can be ridden my efforts will move on to
a mid-range chip.

 

[bob weir]

the dashed or slanted lines in the horiz. rectangles mean the exact time is a variable

B and G are identical except for G showing the TMR0 is running all the time.

and only during the B time frame do we care what the TMR0 is doing

if you set bit 5 of OPTION to '1' the TMR0 wont count if an ext'l clk source is absent

about the most important thing to see in the sketch is that the t_dly obtained when the
E code runs is the 'coded delay' mentioned in the C frame.

the range tests and the proper time-delay-to-fire are at the heart of this ignition timing code

 

[bob weir]

this is the first draft for ver. 1 of the new cdi code that uses the -71 and -9 signals. and a psa
of 64 uS , not 128 uS as with the earlier 3 versions of code

a reminder for those of you who are new to this code ... this -71 / -9 version is using TMR0 to
measure the time of rotation of an arc of 62 degrees. the previous 3 efforts all measured
the full flywheel rotation of 360 deg. only there were problems with overflow in TMR0 at the low RPM end .
the 12F508 is a 'baseline' uC. and lacks a flag to let you know when the timer rolled over.

this new code here today does build so it is syntax good.
but it will not yet give you the ignition timing results that fit the BTDC timing-RPM curve

the literals used in the range tests and rpmxxxx code are what was used in the previous -71 / -71 code.

and they will all need to be re-calculated. then tested with a pulse generator and scope.

i'm hopeful that some of you will jump in and work out what you think these literals
should be. and any other changes that you think are needed

what is puzzling me is how , for the arc time from -71 to -9 degrees , the OPTION psa of 64uS
gets us TMR0 counts in the 0-255 range. and that -71 is the starting point for a s/w delay - to - fire
in 25uS steps. my take is that an 8-bit number wont provide enough loops for the dly25u
subroutine for all the delay-to-fire time that a slow rpm will need

 

[bob weir]

feb 25 2016
while working the calculations for the literals in the code some new ideas came to mind.
the images show where they derive from

the scope image is of the flywheel timing signals in their raw sine form.
these 2 signals come from the sensor coil that gets swept by the magnet on the flywheel
they are , first, the -71 deg sine and followed closely by the -9 deg sine one.
for every spin of the flywheel these 2 signals occur.
and our code will use them both

the 2'd image is the factory timing advance curve for this engine.
the key thing to notice is that the engine timing is a constant -9 deg of advance
from 0 to 2000 RPM .

beyond 2000 more advance is needed. and that is what our program provides

this -9 deg signal is available for firing the spark plug circuit with a little analog-to-digital conversion.
the cdi circuitry is digital in design and needs a digital -9 deg pulse edge to trigger a fire action
thus a person has the option to use it out to 2000 RPM instead of having the code calculate a fire pulse.

the benefit of doing this is dealing with higher , faster , RPMs so that their TMR0 count fits in the 8-bit space nicely.
by 'nicely' is meant we arent having to worry about any overflow in the TMR0 count from long , slow revolutions.
in fact at this point it looks like we can reduce the OPTION psa bits to select 32uS not 64uS . and still not have any overflow

not yet mentioned is how using a smaller psa step leads to less timing error with the code.
one way you can see it is in the timing diagram , below . for any RPM in the 2000 - 5000 range
draw a vertical line . and see how the BTDC value for that particular RPM is itself a range. of
3 to 5 degrees or so. this range sets the limits on how much error our code can have.
you can say too that the idle RPMs have a range , of about -8 to -10 deg.
give some thought to a source of coded timing errors. there are a number of them.
more about this later.

a table of calculations is being prepared to post that will show the updated range test RPM sizes and the delay-to-fire values.
in effect the table will show all of the literals that need to be included with the assembly instruction movlw .
the 'l' in movlw is 'literal'. a generic label that MPASM uses for decimal integers 0-255 .

using the arc_62 value provided by the TMR0 the code has to determine the RPM range
this arc_62 value is in then select the correct delay-to-fire time .
only now it will focus on RPMs starting with 2000 out to the 5000 / 6000 range. and not start with
600 or 800 RPMs like was the plan earlier this month

 

[bob weir]

the size of coded RPM ranges are shown in red rectangles. and a horizontal line to the left shows
what the BTDC timing angle is for that range of RPMs.

for a first try only 9 ranges are coded : no. 0 to no. 8

ex. for range-test no. 3 , 2600 to 3000 RPM ... the timing is -16 deg

next to post will be a table of the RPM ranges and their expected arc_62 value for
a TMR0 psa of 32 uS .

once we have the RPM range the timing angle is fixed.
by the diagram posted today. and is what the code will use.
pending test results this all could change.

all that's left for the code writer to do is calculate the time it takes
for the flywheel to spin from when the -71 deg pulse edge is detected to the fire
angle in degrees. and delay that amount with a s/w delay loop.
this delay amount will be represented by a literal value in the program that is the number
of times the delay code loops .

 

[bob weir]

here is the data table for the upcoming -71/-9 ver. of CDI code

note that the 2 columns 'no. 32u' & 'no. of 25u' are the literal values that will
appear in the code as-is

the '32u' no's are = arc_62 value that is saved then run thru the range-test section of code
in order to figure out what RPM the engine is spinning at

and the 'no. of 25u' values are the number of times the 25u s/w loop repeats to
get the correct delay time before the spark fires for that particular RPM


the next post will be a revised ( feb 8 ) pseudo code list.

and then will be posted the newest ver. of code that contains these table literal values