Digital programmable CDI ignition for 2-stroke engines

[bob weir]

feb 22
more images of the feb 21 post of exp 3 . in color and with the cursors.

on reading the BX-AX numbers we learn the scope facts.
they show that the trip point is closer to 131u than 128u .
i'm looking at the code lines 48 to 54 . and asking what
is going on here. more than meets the eye , for sure.

the internal RC OSC is not as accurate as a 4.0M xtal would be.
i think this result is showing how a RC OSC counts out 1:1 units
of time that are not exactly 1uS each. thus the TMR0 register
holds a number that is off by a few uS

one idea is to repeat the exp 3 with A5 input pulses of known width.

what do you think ?

 

[bob weir]

feb 22
.................. wait ............ there's more.
regards the feb 21 exp 3 post ...
the scope reveals the 32u A0/A1 pulses arent exactly 32u either. more like 39u

this is more of a s/w matter than one due to using the internal RC OSC.

that dly32u subroutine is , by its very code, is less accurate at low loop numbers than larger ones.
while writing it the MPLAB Stopwatch was used for loop counts of 100 not 1.
it was based on the Gooligum delay10m code algorithm from one of the baseline lessons.
where for a step of 10mS a few uS arent going to matter any.

i've known this for a long time. that delays in the low uS region need special
coding attention to make then come out exact.

the bugaboo is the goto's that differ in count by the number of loops the sub' has to take.
and each time a goto executes it adds 2uS to the delay tally

the ideal code is an exact multiple of a 'delay' for all loop numbers 1 to 255.

at this point in my coding evolution i expect to have to do a custom job
for every exact delay needed. and when being 'close' will do then continue
with what is already working. it just all depends on the degree of accuracy
needed

in the meantime this timing accuracy will be kept in mind as an open-ended matter

 

[bob weir]

mar 3 update
a change is being made to the 16F506 signals circuit. the old one uses 8 of its pins for leds.
the leds show the hex value of the TMR0 register. this then is the spacing between the -70
and -10 flywheel pulses in units of 32us.

for long it has bothered me that these leds use current that has to flow thru the 506 chip.
this can cause surges in the +5V bus of the bd.bd. when all 8 are lit the i is > 100ma
often odd test results appear on the scope screen. ...missing pulses, stunted in size pulses.
and its a headache trying to identify where the errors are coming from. so this change
is a step in the direction to eliminating one possible source of them.

... if i were rich and had a crew of elves working for me then 2-sided circuit boards
would be made for every test circuit.
with their sizable ground and +5V bus's i-surge glitches would be a
thing of the past.

the change is to offload the leds on/off i to a 74164 circuit board. and let all the current surges
take place there. where they wont be 'felt' by the 506 uC 5V and gnd busses , meager as they
be on a common bread board.

given that each 74164 uses 2 or 3 signal pins we have 8 506 pins available. its now just
a matter of editing the existing 74164 code to match the selected 506 pins.

in case you've forgot , the big value of using a 506 uC is that is has an ADC module.
thus with a 10-turn pot we can turn the 5V supply voltage into a number in the 1-255 range.
just by turning the pot and watching the 8-leds hex number chg. and pick the one we want.
and use this number to space the 70 and 10 pulses. doing this simulates a change in RPM.
..... without this easy number we'd have to code the 506 or a 508/509 for every RPM
we wanted to test. which is do-able, it justs adds a bunch of extra time and swapping
of chips from the ckt test bd. to the programmer board.

 

[bob weir]

mar 5 update

while working the next exp , no. 4 , something came up.
a lack of knowledge. thus uncertainty with how to proceed.

lets go back to the code for exp 3. on p.1 line 41 bit 3 = 1
... this is done in order to setup TMR0 to count in single-uS steps.

and on looking at line 13 we read : _WDT_OFF

the question that arose is : what is the dependency , if any , between
the CONFIGURATION WDT setting and the bit 3 WDT setting in OPTION ?

exp 3 appeared to work as expected with the coding cited.
or was this just dumb luck. or a mis-interpretation.
and disaster awaits the unwary code writer ?

you'll find the OPTION register settings on p. 24 of the 509 data.
and the CONFIGURATION bit settings on p. 42

comments anyone ?

 

[32Vwasbetteronboats]

Maybe a switch-box from a mercury outboard for part of this, it only needs a few volts to trigger it.

My suggestion really is to look at what the outboard motor racing guys are up to for ideas.

 

[bob weir]

mar 7 update
the sketch is a 'picture' of what exp. no. 4 is attempting to do.

one uC , 508-1 , acts as a signal generator. and the 2'd uC , 508-2 , takes these 2 pulses
as inputs and measures the time between their LE's. and saves this 'time'
in some variable , call it delta_t

then 508-2 does its best to issue a pulse of its own , with a width equal
to delta_t

there are 2 distinct uC goals here. and each has its own code requirement.
thus there will be 2 postings of code. both for 12F508 uCs.

the lack of a good OSCCAL value mentioned earlier this winter is no more.
new 508s are being used. and they have factory-installed CAL' values.

note too the sketch shows a 74164 optional circuit addition. two scope
screen images will show how well the times agree. and the leds can do the
same thing. and be a less costly version of a 'scope'

note too that A0, A1 et al labels are shorthand for GPIO,0 & GPIO,1

lastly , by using a 508 uC instead of a 509 uC we can save ourselves
the bother of using the directives PAGESEL & BANKSEL. the result is
code that is 'tight' , i.e. as small as can be

 

[bob weir]

mar 7
you will soon see how the code for both the 508's contains a move not seen before.
oh, those of you who are plowing thru the Gooligum baseline lessons will have.
in lesson 5 ex. 1 . where , in a loop , TMR0 is being continually
compared to the number 250.
this lesson 5 ex. 1 tests your ability to react fast enough after a led lites to
push a button-switch and do so in under 200ms. ... do that and you've won.

our exp. 4 508 code 'move' amounts to reading the timer TMR0 while it is counting. ( actually for baseline
uC's the timer is always counting. it cant be shut off ).

we can both read and change the TMR0 on-the-fly. by 'change' i mean to make it
any number 0-255 that we want to. in fact , as you'll see , both 508's code does that . with
the line 'clrf TMR0' ... this changes whatever the count happens to be to a '0'.
another way would be : movlw .0
....................................... movwf TMR0

then we read it and next we take the TMR0 count at that instant when its read
and then compare it to some number. in out case we want the number to be 100.
so that when TMR0 is 100 our code detects this and we end the pulse.
our pulses is a 0-1-0 type with the '1' being 100u long.

and , as you can expect , due to instruction execution overhead the width wont be
exactly 100u, but a tad over.

be thinking how we could correct for that .

 

[bob weir]

mar 8 .............. more ideas about exp. no. 4

it occurred to me that as soon as the A0 LE was detected by 508-2 it could issue a LE for its A0 pin
and start a copy-pulse. then , next , when the 508-1 A1 LE is detected the 508-2 would issue a TE
on its A0 pin. and i think the 508-2 copy-pulse width would be an exact match to the time between the
LE's of the 2 incoming A0 and A1 508-1 pulses.
and this method would not involve using the 508-2's TMR0. and likely means too that no
variable of a saved TMR0 value would happen either. and this variable would be what the
74164 leds would show us.
that's all i have to say now about this idea.

oh , another idea was to recognize how we are accumulating a list of 'unit operations' in terms of
assembly code. that is , we are doing specific things along the way. for instance : detecting
a LE, and a TE , creating a pulse of known width, measuring the time between 0-1 or 1-0
events on input pins .... and with this exp. no. 4 reading the timer module over and over until
its value matches some arbitrary number.
...... so in a way we are building a tool-box of code. and when we are later on faced with a similar & specific task
such as output some variable out of 2 uC pins to a 74164 we already have the code/tool to do it.

david m. of Gooligum led the way with this idea. he created a library of useful 'macros'
and called it : filename .... stdmacros-base.inc
the last i checked this library held a subroutine for a 10ms delay, and code to debounce
a switch

 

[bob weir]

Mar 9 exp no 4 update
first off is the code for the signals 508-1 uC

in it line 47 has the w-register loaded with a number. this number is meant to
be the time between the LE's in u-sec (us)

as a test of the code w-reg was filled , in order , with 50 , 100 and 200.

next are posted screen shots off the scope. the BX-AX cursor values
are there for you to read. and learn how close we came to our target times.

 

[bob weir]

mar 9 exp no 4

in all 3 cases the width exceeds the w-reg value. and by the same amount.
isnt that interesting. it has me wanting to do a instruction-cycle timing study
and learn how this 9uS happens in each case. feel free to jump in with your
own timing analysis.

so , naturally, some of you are eager to have me edit the code on line 47 and
subtract 9 from each of 50, 100 and 200 and see if we dont get an exact time.

another thing to notice , in the code on line 48 where you find a subwf instruction.
the format is "subwf f,d" . and when coded the 1'st time the 'd' was left off. and
a BX-AX was something like 49. so after reading the data on this instruction i knew
that 'd' needed to be '0'. this way the result of the actual subtraction step is placed
in the w-reg. were it d=1 the result would be put in the TMR0. and as we are
reading the timer over and over in the loop lines 47 to 51 its value would not be
the natural count. but would get totally messed up.

this is yet another example of how making a mistake leads to fresh knowledge

my next task is to write the code for the 'signals processor' 508-2.
and see how well we can take the incoming LE-to-LE 'delta_t' and turn it into
an output pulse with that same width.

and 2 methods are going to be coded for the 508-2 uC.
first is the one referred to in the idea posted yesterday . mar 8.
and the 2'd will be one using TMR0 to count time between
the incoming LE's and save this value to the variable 'delta_t'

... at this point, looking ahead , i expect an exact width with method 1 and an
oversize width via method 2.

 

[bob weir]

update Mar 14
the 16F506 uC has been re-coded so that the 74164 displays a hex no. on its 8 leds.
the 506's ADC and the external pot make signal spacing adjustment between
the -70 and -10 output pulses just too easy to not have.
the alternative is having to re-code a 508 or 509 every time a different RPM signal
is applied to the uC with the ignition-code in it.

posted first is the code , 4 pages of it , and in color. then a few bench-top fotos,.
and then a few scope screen shots.
and later in a day or two will be the circuit diagram.

the lines 121 - 144 show the serial-out code that takes the ADRES value and sends it to
the 74164 to display on its 8 leds. see lines 74 and 75 too.
this code was originally done for a 16F84A .
so the big task here was to figure out what signals were which and re-assign the code
to pins on this different uC, the 506.

note too lines 136 - 144 to clear the '164 are optional. skipping CLR will also
save you one pin of the uC

 

[bob weir]

update mar 14
the blue pot is dialed in to an ADRES value of 0x50 ( 80 decimal ). which you can
make out with the 8 leds , 2 of which are lit. ... b'01010000'
power is via that 9V battery and the small bd.bd on the left with a 5V-regulator.
it supplies juice to both the 6"x3" bd-bd with the 74164/leds ckt on top. and below it
is the bd-bd with the 506 uC. see too the scope probes connect to wires running
to pins 13 and 12 ( B0 & B1 ), where the -70 and -10 pulses emerge

the scope and its cursors are measuring the time between the -70 LE and
the -10 LE to verify the code spacing on lines 86 - 90 . note in line 87 how
the ADRES/tmp0 has 6 subtracted from it then stored back in variable tmp0.
this is done to compensate for the -70 pulse being 6 * 32us wide.

 

[bob weir]

update Mar 14

the 2 scope screen shots showing the measurements between pulse edges.
note how the 1'st one measures from LE to LE. this is critical. as the ignition
code polls its pins for the LE of each of these -70 and-10 input pulses

the 2'd image shows the measure from the -10 TE to the next -70 LE.
give some thought why this TE - to - LE measure is ok

some of you may wonder the need for the 2'd -70 pulse.
that S/D 84A code faces the same problem . ...
( remember that the 506 is supplying us with signals to test the other uC
that has the ignition-code in it. )
.............. namely that we need the
first -70 and -10 pulse to establish RPM and timing advance.
then this timing advance delay is applied to the next -70 pulse.
the code delays some amount of time referenced to the -70 LE
then fires somewhere in the -30 to -10 range according to RPM
and the timing-advance table

this can be difficult to follow. due to 2 things happening at the same time.
between -70 and -10 the TMR0 module in the uC is counting time.
the timer is zeroed at -70 LE and is read and saved at the -10 LE.
and simultaneous with that there is a coded s/w delay going on
during this same flywheel rotation from -70 to -10.

we get away with other code running while TMR0 counts in the
background. with the warning that our other delay and fire code has to be
done before the flywheel gets to the -10 deg. mark. or else we miss
the magnet/sensor coil -10 pulse LE

the troublesome area is at the low RPMs end of the engine running range.
one work-around will be to send both the engine-generated -10 signal
and the ignition-code uC lo-RPM fire pulse to a 2-input OR-gate.
so that one or the other will get to the CDI circuit and cause a spark.

the engine-generated -10 deg fire pulse is good to about 2k RPM.
any faster and more timing advance is needed.

we will test the ignition code uC with -70 / -10 input pulses at a known spacing.
and thus a known RPM. and via the timing advance graph we know
when the fire pulse should happen. this will appear on the scope
as a certain delay after the -70 pulse LE to the LE of the fire pulse.

it is this delay value that will be the sign our ignition code is good.
and that it is good all across the 2k to 6k RPM range

 

[bob weir]

mar 15
here's the ckt diagram for the post yesterday.
it shows the 16F506 uC , the 74164 and 8 leds

a switch is shown on pin 4 , the /Mclr .
for every push the 70,10,70 set of pulses emerge.

note too the 74164:9 pin is active low. thus a
1-0-1 pulse is needed to clear the led display.

lines 136 - 144 show the 506 code that does this

 

[bob weir]

mar 15
the 1'st color scope screen shot that has BX-AX = 2620 is redone here at a different H-scale.
and code line no's added. they show you what code executes for pulse creation and spacing.

and added is some math to help clarify the adjustment for the width of the -70 pulse

the adjustment results from the 506 having to finish making the 70 pulse before
the delay-to-10 pulse code can run. if we dont correct the delay = ADRES * 32u is
referenced to the 70 pulse TE. thus the code in the ignition uC will sense the time
between the 70 LE and 10 LE and this time will be (ADRES + 6 ) * 32u.
and this is too large by a factor of the 70 pulse width ( 6 * 32u ) .

the consequence of a erroneous spacing is the RPMs will appear to be slower.
and thus less of a timing advance delay will be selected by the code.
say, for example , -15 deg of advance instead of -20 deg

 

[bob weir]

mar 16
the 4 pages of code posted on mar 14 are for the 16F506 uC. i've been favoring its ADC module and its
12 i/o pins. however using these features comes at a cost.
briefly , besides the ADC are comparator functions .
both of these modules use analog voltage level signals. and by default the uC enables those pin-functions
at power-up. analog pins are enabled in favor over digital ones. so to make the 12 i/o pins be digital
they have to be setup for digital operation. lines 41+ of the code show how this is done. its a bit of
work to read about and understand. and i went ahead and made them all digital. and on reading the
data now think this is not so smart. that enabling the fewest digital necessary would be better

those of you who have read ahead in the Gooligum baseline lessons 8, 9, 10 ,11 will have already
come across this uC as it is used in all 4 of those lessons. and learned some of its capabilities and coding
requirements. i find the moving average coding in lesson 11 particularly interesting for how the
author lays out why 3 types of variable definitions are called for.

the other feature to mention is it can run faster than the 4MHZ we've gotten used to with 508/9's.
line 13 of the code shows the configuration ( p. 57 of the data ) to set it up for a 4MHZ int'l osc.
p. 1 of the data shows that an external 20MHZ xtal is the fastest speed choice .

the 'cost' then is an imposition on you to have to learn how to setup this
new uC. to make the i/o pins digital , how to set the clock operating speed,
and to thoughtfully use both pagesel and banksel as this 506 uC has 2 pages
and 4 banks .

if you want to set the select bits w/ code then see fig. 4-2 , p. 20 , for the bit 5 of the
Status reg' for Pagesel & fig 4-6 p. 26 for bits 5 and 6 of the FSR register for Banksel.
this is how it was done in the old days, like when the 16F84A was popular in the 90's

lastly , about the code , did any of you notice there are no banksel directives used at all.
how did i get away with that ? given there are 4 banks of GPR's . see p. 16 of the data.
no errors or warnings arose during the BUILD step. so my thinking is that the 8 UDATA user
variables on p. 1 of the code were all put into Bank 0. ( it has space for 16 variables )
and this bank is selected by default. see table 4-2 p. 18
but i'm not really sure here. had there been an error msg then banksel would have been used
in the usual way.

... next i'm going back and finish up with exp. no. 4
the 2'd uC that receives the pulses from the 1'st uC needs its code finished so that it outputs a pulse of its own.
with the 506 circuit working it can now be used to supply the -70/-10 input pulses to it .

after that i'm taking leave of the experiments and going to focus on the final CDI ignition
code for the uC that will be on the motorcycle. and its likely to be 1'st a 508, or 2'd a 509

 

[bob weir]

mar 18
this post is to show you some (?) mis-behavior of my 1054 rigol scope. 3 of its 4 probes are connected to
a 506 output pulse pins ( -70 and -10 ) (Ch 2 & 3) and to a 508 that accepts these pulses and outputs a 'fire' pulse for the CDI circuit. ( Ch 4)

what i want to convey is how the scope shows erratic signals on its display at power up and for the
first one or two times you press the 'send' button on the 506 for the 70 & 10 pulses
to be on their way.

................ this screen is immediate on connect the 5V battery.
the scope is in 'single' mode and catches whatever 0-1 rising edge occurs on Ch 2
................ Ch 2 is the -70 line and Ch 3 the -10 pulse line

 

[bob weir]

mar 18
next are 4 screens of the scope showing a crazy group of pulses on the 1'st push of the 'send' button after the battery is connected and the screen cleared for the next 'single' event

[/ATTACH]

... this 'send' button is one added to the 506 PORTC pin no. 3 . it was added so as to
not depend on startup or reset to make the 70/10 pulses be emitted. but to have
then sent via manual control. like what i've been doing with my pulse generator
when i want a single pulse out. the 'send' button in it is called 'MAN TRIG '




this last one is particular. because it is tantalizying close to a good result .
and if you dont know better will have you looking at the code
to try and figure out why the 3'd Ch 4 pulse doesnt end . it came up often and the
remedy is simply to reset the scope screen and hit the 'send' button again

 

[bob weir]

mar 18
finally , after clearing the scope screen and pushing 'send' a 2'd or 3'd time i finally get what i expect.
yes , it looks right , but is it ?
verification comes of using the scope's cursor to measure all pulse widths and the spacing
between them. they're not exact but i've learned not to expect that

so , what is causing this ? my guess is its a mix of scope s/w and the nature of solderless
bread-board circuits and connecting them all with long thin copper wires.

at any rate these sort of responses put us all on notice that the scope/test-boards
are not infallible. and may give us results that are not true. and to keep trying.
and when the screen that looks right keeps coming up on successive 'send's
and the screen cursor measurements check out then you've got it, the results of
whatever ver. of code is running in your uC's

... in spite of these sort of crazy screen results i still hold this scope in high regard.
and think for a first storage scope its been a good one . its a lot of horsepower for $400.
its really opened my eyes to what the chinese are capable of.
and after over a year there is still more than half of its abilities yet to learn.

 

[bob weir]

Mar 18
besides finally getting a good scope result something else arose worth mentioning.

it amounts to the timing accuracy of one uC vs. the other. when the case is ours of
having one uC send pulses to a 2'd uC

it dawned on me that the 506 test code is using a 32u s/w subroutine to space its
output pulses. and the 508 ignition-code uC is using the TMR0 to measure the
time between the LE of these incoming 70 & 10 pulses.

... and recently we have looked at the variable nature of the 32u subroutine
based pulses ... how accuracy depends on the number of loops . and how at
low loop counts its the worst. close to 40u instead of 32u

... this will require further thought to understand . i want the test results to
be as accurate as can be. only now i realize how to do this is an ongoing
process