08M at 16Mhz?

Coyoteboy

Senior Member
Is it possible?

I'm trying to write a wheel decoder and the 450 microsecond execution time for each command at 4mhz will be significant at higher wheel speeds. Can i push the 08M to 16 or is 8 my limit?
 

hippy

Technical Support
Staff member
No, you're stuck with 8MHz. It's not even possible to be adventurous and rewrite the PICmicro CONFIG fuses to use an external crystal.

If you have very high-speed pulses coming in then you'll probably have to use a hardware divider or some other trickery.



 

Coyoteboy

Senior Member
Figured as much, cheers. The problem is i have a wheel with up to 12 pulses per rotation and up to 8000rpm speeds, and i need to log every tooth, determine the time between teeth and look for a missing tooth, then fire a pulse on an output. Unfortunately the turnaround time on the pulsin>if not timed out>output>pulsin loop would take a significant portion of the inter-tooth time at high revs :(

Ah well,I guess Im asking a bit much of a £2 IC!
 

manuka

Senior Member
8000 rpm = 8000/60 x12= 1600 inspections per second. Checking "missing teeth" at these speeds sounds like a dentist's dream cash cow. Tell us more -just what IS the application?
 

hippy

Technical Support
Staff member
That's potentially one tooth every 600uS, so there's not a lot of time to do anything. There are just some tasks a PICAXE cannot do, and I doubt 16MHz would even help you here.

You could use hardware to count revolutions and count individual teeth then check the two results match to detect missing teeth, but I suspect you'd be better off using an alternative microcontroller.
 

Coyoteboy

Senior Member
Yeah, i think it'd just be plain easier to get a faster micropro.

The application:
I run a Megasquirt I DIY ECU for my car engine, a large part of the processor flash and and time is used counting teeth and determining when the engine is at top dead centre. I was going to relieve the main processor of this job byt creating a wheel-decoder board. Ideally the board would be able to handle a 60 tooth crank wheel at up to 8000 rpm, but i was going to settle with a 12 tooth wheel.

Ahh well, I'll have to look elsewhere, i was going to be very pleased to run an 'axe but i think i may have asked too much!
 

hippy

Technical Support
Staff member
Counting teeth seems rather error prone and potentialy catastrophic should it ever glitch and miss one or two, and how do you know where TDC is to start with ?

Rather than counting teeth, wouldn't it be a lot easier to use once-per-revolution crank position detection and then sync from that ?

I'm sure that's how my car does it, and it should make the timing issues more manageable.
 

demonicpicaxeguy

Senior Member
my father in law is doing somthing similar with a mini engine we've had good success with a simple air/fuel ratio stored in an i2c eprom and an interupt that gets triggered by a reed switch it seems to work very very well we are using a 28x and a 24lc256 at 16mhz it does have it problems like it'll miss a tigger every now and again

so far it uses a simple flap inside a section of rhs tubing with a 10k pot to measure how fast the air is going in we have the oxygen sensor in the exhaust the tdc sensor(reed switch) and another 10k pot for the throttle position sensor

it's been the simplest project i've ever had anything to do with

the one thing we did that made allowed it to work well was that we used 4 tdc triggers
1 for each cylinder
 

RexLan

Senior Member
That signal may already be present if it is an early Ford product with the EDIS system. If not perhaps you can "adapt" a Ford EDIS module to the application.

The Mega-Squirt system uses the PIP line from the module for position information which it sounds like you are trying to do?

Perry Edwards has helped me allot with this circuit and he offers an excellent technical discussion of the EDIS here http://www.dainst.com/info/edis/edis.html if you’re interested.
 

MartinM57

Moderator
Ah the army of Megasquirt/EDIS/PIP/SAW DIY'ers who don't want to give much away surfaces again!!

I've done a missing pulse detector with a 60 tooth wheel - works fine at well over 10000 rpm. But I didn't use a PICAXE!
 

hippy

Technical Support
Staff member
demonicpicaxeguy: <i>we've had good success with ... an interupt that gets triggered by a reed switch ... does have it problems like it'll miss a tigger every now and again </i>

You've answered two questions I'd been formulating, so thanks. The first was, this topic had come up before but I hadn't seen any follow-up and was wondering if it worked at all, and secondly, how well.

I was wondering how much of a problem jitter in detecting TDC was. A standard

DO WHILE pin0 = 0 : LOOP

wait for trigger could be delayed by up to something like 300uS @ 8MHz ( I'm guesstimating actual times ).

DO : LOOP WHILE pin0 = 0

Is actually faster than the previous, with a delay of something like 150uS @ 8MHz.

At 6000 RPM there's one TDC pulse every 10mS, 150uS jitter could mess the TDC firing up by -0%/+1.5%

A tight &quot;DO:LOOP&quot; or &quot;GOTO self&quot; with interrupts would reduce that, but the best I could think of was using a PULSIN, which should finish executing quite quickly - and more importantly with consistent delay - once it's seen the trigger pulse.

I was worried that jitter would outweigh any benefits gained and could have an adverse effect on the engine. Your experience seems to suggest otherwise.
 

demonicpicaxeguy

Senior Member
ok i'll explain in more detail

basically when an interupt is triggerd by the tdc sensor (reed switch) it simply updates pwm and then continues normal execution which conisits of continuously takeing an adc reading of the air going in and the oxygen sensor and the throttle position sensor

based on the adc readings from the air intake , exhaust sensor and throttle position a value is read from the 24lc256
after a bit of maths
(16bit value) and a varible is updated with the new pwm value
pwm gets updated every interupt

now pwm is used here to charge 4 capacitors whos decay time is used to hold the injectors open before getting cut off by a transistor
the injectors are triggered by the tdc triggers i mentioned earlier that consists of an optical disk

as far as updating the ecu map goes that is done by removing the 24lc256 and using another picaxe to write to it it's not yet updatable while the engine is running but it'll get there

so far it's rather crude and simple
not really that much better than the old su carbie,(personally though i don't think the interupt is nessessary but he wanted to do it that way, i wanted to stick the pwm update at the end of the loop)

when we get the new cd player for the mini i'll take it out from behind the dash /pull it apart and and take some photos we mounted it in a diecast aluminium box

i'm going to do one for my own mini after i have finished my cnc machine which shouldn't be too long

*forgot to mention that the 4 tdc optical triggers are taken from the distrubutor
the distributor is another very long story but in short it's a modified dizzy that uses an optical disk to trigger the electronic ignition system

Edited by - demonicpicaxeguy on 12/04/2007 12:46:07
 

premelec

Senior Member
I notice www.austriamicrosystems.com is advertising a high temp [150C] angle sense unit for engine use - AS5140H magnetic drive .35 deg resolution... you might want to look at the data sheet for this unit...
 

Coyoteboy

Senior Member
I could use a once-per-180 degree (two firings per revolution) setup no problem, in fact the MS can do this on its own already and is a much simpler method than decoding the wheel, however I wanted to get this working with near-stock hardware, which is a 24 tooth wheel on the crank, ground to give essentially 2 12 tooth wheels with one tooth missing (12-1). You determine TDC-90 by the position of the missing tooth, set the trigger tooth to tooth 1 (60BTDC) and then the MS figures out the time for the spark after tooth 1.

MS performs well with 36-1 and 60-2 crank wheels but 12-1 seems to upset it. I am seriously considering shaving all but 4 teeth off and running it in distributor mode, but I'd hoped the 'axe could handle decoding.

The MS1 doesnt utilise the intermediate teeth for anything other than synchronisation so there really is no point (other than less labour involved) in NOT shaving the extra teeth off, but I like to get things running properly, not mask the issues I have. I'd love sub-degree crank encoding but nothing but the latest processor power could use it, so I'll stick with 180 degree encoding :)
 

hippy

Technical Support
Staff member
Thanks for the explanation; I hadn't twigged the &quot;missing tooth&quot; really was physically missing, and thought you were trying to compensate for errors and whatnot :)

The way I'd approach it is as a once per revolution TDC signal pulse, then use a separate 08M to do the missing tooth detection which feeds the main PICAXE. The main PICAXE can then work either direct from a 'traditional TDC sensor' or from the 'tooth fairy'.

It also splits the project into two distinct parts, each of which can be fine-tuned individually. Modularisation has many benefits and PICAXE's are cheap enough to do that.

Using a PULSIN to detect the gap between teeth, a PICAXE should be able to toggle an output line when detected with fairly consistent and accurate timing ( fixed latency ) ...<code><pre><font size=2 face='Courier'> SetFreq M8
Main:
PulsIn pin,w0
If w0 &lt; whatever Then Main
Toggle output
Goto Main </font></pre></code> If a PICAXE isn't up to speed, it should be a very short PICmicro program.

Toggling an output is perhaps better than pulsing it; the receiver has a full cycle in which to see the change so any processing time creep shouldn't miss a signal, and an interrupt can be used to catch rising edge the first time, falling edge the next. Then again you could generate a substantial length pulse knowing that you won't have missed a tooth during that time.

I was somewhat sceptical to start with, but now think it should be possible. Thanks for the enlightenmnet.
 
Top