PULSOUT stops execution ?

Simple - and probably silly - question: during a PULSOUT, the picaxe stops execution until the pulse "runs out" ?

Hi,

Not so simple; it depends what you mean by "stops execution" (and to some extent which PICaxe chip).

Generally, the software core is "counting" the width of the Pulse, so it isn't doing anything else (thus it won't start to execute the next command until the pulse finishes). But I think it does also disable the internal (hardware) interrupts, so the "multitasking" and the "time" variable increments stop, in M2s.

However, the pure internal hardware functions such as PWM (and Servo? ) should continue to work and might offer a solution to generating medium-width pulses (around 10 ms) whilst doing something else.

Cheers, Alan.

Thanks Alan. What i meant was if the picaxe would start the next instruction before the pulse was over, so this answers my question.
What i want is a pulse of a certain length - a few milliseconds - that wouldn't stop the flow to the next instruction. A single pulse, so PWM probably won't do. So far, without resorting to interrupts i cant see any other way.
Any ideas ?

It depends a lot on how many is a few and how accurate it needs to be.
To ask a micro to do a short timing event and still execute commands during that event is a BIG ask.
At 4Mhz each command takes around 250uS. (a significant proportion of "a few mS").
Even if it did not "stop execution" during the pulse, what do hope to gain, one or two extra commands during that period?

Would a HIGH followed by a few commands and then a LOW be accurate enough for you?

Perhaps you should explain in more detail what you really want to do. There might be alternatives to your current approach.
The only option I can see to get what I perceive as your requirement is to use extra hardware. I do not see how interrupts would help either as they too need to be processed by the same processor that currently doing the timing of the pulse.

You might be able to set the pulse, execute some instructions and then turn the pulse off. It should be possible to adjust that for consistent timing but would depend on the complexity of the code.

You could use some on-chip hardware, possibly requiring some POKESFR control, to generate a pulse via HSPI or HSEROUT.

Some more info...

Project is an engine ECU (yes, I know, i'm stretching the envelope...), powered by a 40X2 running at 64Mhz.

Pulses (for the injectors) will be in the range of 2-15 mS, with mS accuracy and granularity desired.

My best shot at the moment is to turn on a pin, and set a TO interrupt for X mS in the future. When the interrupt arrives, the pin is set low.

I dont want to sit waiting for X mS, because I have to be reading sensors and updating pulse widths in the meantime.

Setting the pin and using an interrupt timeout to turn it off would seem to be a good approach.

If reading sensors and calculating code has fixed execution time you could set the pin, do some things, pause, set the pin off, then do the rest, perhaps have different code depending on short or long pulse, or for each size of pulse. You could perhaps execute that code in the gaps between pulses rather than during the pulses.

My suggestion is to use an EXTERNAL triggered pulser if you want precise pulses and have to have the 40X2 doing something else while it is pulsing.

Texasclodhopper said:

My suggestion is to use an EXTERNAL triggered pulser if you want precise pulses and have to have the 40X2 doing something else while it is pulsing.

Click to expand...

My thoughts exactly; I would connect up a second Picaxe, say a 14M2, using five pins to interconnect. Four pins could indicate the 2-15 mS in binary and the fifth one could be the trigger. The primary Picaxe can then just determine what pulse length is needed, set four pins to indicate this and then, when ready, set or toggle the fifth pin to trigger the pulse generation from the second Picaxe which is watching out for things in a do:loop program. Surely this would solve your problem with greatest simplicity and reliability of timing?

The calcs are not time dependent. They simply run continouslu as a loop in the background.
The aim is to provide updated pulse width info for the next needed pulse.
The start of the pulse is triggered by an external interrupt.
The end of it would be triggered by a TO interrupt set within the starting routine.

As i said, mS accuracy is enough. At 64mhz even with the intr processing overhead, maybe i can get by. I'll try it.

FYI, if you wait in a loop for the interrupt, don't do anything else in the loop.

Why, what do you mean ?