Timing pulses

berichtnews: snipped-for-privacy@mid.>>>>>> "BobS" schreef in bericht

Just pick one with two timers or an extra PWM. I am not familiar with Microchip products but the PIC12F683 could be a candidate:

Comes in DFN-8, doesn't get much smaller than that.

At 25Hz PWM frequency, I wouldn't even bother with the "dedicated PWM" bit. A PIC10F200 would be more than adequate, and I'm not sure I'd even bother using the timer.

From just the external I/O stand point the PIC10 series is appealing, since could handle this as a digital task. Since there is a dearth of internal peripherals, the initial thought for firmware is a single loop continuously cycling through input, calculation, and output code. The loop time would be the time base, and would be empirically determined with constants and variables set accordingly. Is there a possibility this would work? What else should be considered?

I wouldn't use loop times as time bases. Can blow you out of the water if something happens in the background, like a WDT handler. Take a look at the one I suggested in anotehr post in this thread. Contains a nice timer plus a PWM.

ost

so

er

Thanks Joerg, Would you consider running with the WDT disabled? Also, it appears that the PIC's mentioned above, and others, can not run a PWM out at 25Hz. with common settings. How can 25Hz PWM be obtained without running the clock insanely slow?

It would certainly work. The main question is the accuracy of the

E.g. if an output PWM frequency of 26.66Hz would work, that's exactly 1/3 the input frequency, so for each iteration which occurs between transitions, the PWM output would be on for 3 iterations. Or for 25Hz PWM,

OTOH, if you need exactly 25Hz PWM with 12.5ms = 100% duty and high linearity, you'll need a higher resolution than you can get with software polling.

Conceptually:

while (1) { if (last_in0 == 0 && IN0 == 1) // IN0 L->H transition pulse_timer = 0; else { pulse_timer++; #ifdef PREVENT_WRAP if (pulse_timer == 0) pulse_timer = 255; #endif }

if (last_in1 == 0 && IN1 == 1) // IN1 L->H transition pulse_delay = pulse_timer;

last_in0 = IN0; last_in1 = IN1;

if (--cycle == 0) { // every 3rd iteration cycle = 3; if (pwm_phase < pwm_value) OUT = 1; else OUT = 0;

if (--pwm_phase == 0) { // new PWM cycle pwm_phase = pwm_period; pwm_value = pulse_delay; } } else delay(); // to balance branches }

There is no problem with the WDT, because it runs in the background and doesn't infer with your main loop. If the WDT triggers, there is something wrong with the hardware or a bug in your software anyway, so it doesn't matter. You could use a PIC10F200.

It seems like you don't know much about microcontroller programming. Then maybe the more expensive parts Joerg mentioned and a C compiler are a good idea :-)

Some years ago I've implemented a 5x5 multiplexed LED scrolltext with clock and key input, where the clock has seconds, minutes, hours and days (yes, I've tested it some days and with an external crystal it was exact), derived from just one timer and switchable with the key:

I used only this one timer, without interrupts or other new-fashioned things, like loading a maximum timer limit where it starts again from 0, and implemented a cooperative multitasking system in assembler with a time slice of 400 us.

If you are doing some more tricks, you could even generate outputs where jitter is about the instruction set clock granularity. I've done this on C64 for exact pixel synchronisation: It is possible to read the current video line number. But reading, comparing etc. needs much more time than the pixel cycle time. So compare it multiple times: With a tricky arrangement of compares and delays you can half the inaccuracy each line, and finally you are exactly at the beginning of a new line, with instruction set clock granularity instead of read-compare-branch granularity jitter.

If you are a hardcore assembler guy, you even don't need a timer. Of course, not with an "emperically determined delay", but with pencil and calculator to write it cycle excact the first time :-) This would need some work, if you have to implement multiple parallel tasks, but would result in the best performance for jitter and resolution.

Have the inputs as edge triggered interrupts with matched length interrupt handling routines. Give the 8 bit timer an 8bit overflow counter and even higher priority that lets you have frequencies down to about 15Hz on a nominal 4MHz clock rate. The main loop then has to look after the pwm transitions and any admin arising from input changes.

If you do it by polling then you will get into some tricky cycle counting timing issues. It may well be doable at these low data rates. You have to decide how much jitter is allowable. I have done it once or twice for example to implement a switchable sidereal or solar clock which runs fast with 24h sidereal = 23h 56m 4.1s. The length of a second was made adjustable to run from a cheap 32kHz watch crystal. Digital fine adjustment allowed it to calibrate itself using an external reference to about 1ppm. No need to trim the crystal.

Regards, Martin Brown

For that kind of slow speed, you perform the PWM in a software loop, using the timers to calibrate your loop.

An interrupt can be used generated via a timer reg that can thus, decrement a count down value. When the value reaches 0, you can then perform what you need and reset the software counter.. This will give you a nice accurate slow PWM output..

For that kind of operation, you don't even need a uC with a PWM output option.

Hz

most

n so

ou

mer

en

of

tput

You have it right, my programming is rather elementary, think PicAxe. Anything else is like a foreign language. Looks like outside help will be needed to pull this project together, or its going to be a long time climbing a curve.

The PWM out frequency does not have to be that accurate, + - 10%, without much jitter (< 1 %) or shifting about. Main thing is the output is proportional to the input delta T.

Running the output at 1/3 the frequency of the input would be ok. For the best response to a rapidly changing input the output must be updated with every input pulse pair. This could cause multiple pulses per output period, a condition that would have to be evaluated and possibly worked around??

It looks like there is a case for using a PIC 10F series, with strictly software conversion. I'm leaning towards a compiled Basic for this task to try to minimize the learning curve for a retiree, is that reasonable? Or is this a software task that can be handled by an accomplished programmer in a reasonably short time?

If you want 25Hz PWM output and the input pulses are 12.5ms apart, you will get 3 input pulses per PWM cycle. You could either compute an average of the three values, or simply use the most recent value and discard the other two.

If you want to use the loop timing as the timebase, the code needs to be written in assembler so that you can ensure a constant number of instruction cycles regardless of which branches are taken. Alternatively, you can use the timer to obtain a consistent timebase, but you still need to ensure that the worst-case loop time is fast enough to measure the pulse delay to the desired resolution.

If you want to simplify the programming, consider a chip with more features; e.g. one which can generate an interrupt when a input pin changes state or when the timer rolls over (e.g. PIC12F609; still only an

The actual code should be fairly trivial; it's mostly a question of being able to specify the problem precisely, including tolerances and handling of error conditions (e.g. what happens if the second pulse still hasn't arrived 12.5 ms after the first?).

Absolutamente no, I would not disable that. The WDT just runs in the background. As long as you ping it regularly it'll be happy and if it missed a few pings it (usually correctly) assumes that the uC or the code froze up.

AFAIU you can hang a prescaler up front on the PIC12F683 timer, via firmware commands. No soldering required :-)

But you'd have to study this for yourself, starts around page 75:

ng

Hz

lmost

on so

You

imer

M"

ven

of

ly

Joerg and others, thanks for the suggestions. I studied over the 583 data sheet PWM section, and could not see how to get a PWM frequency within an order of magnitude of 25 Hz with a

I am not at all a uC guys but just as an idea:

AFAIU most PICs aren't very flexible with CC registers. What if you'd let timer 2 just count at, say, 9.8kHz (4MHz master, prescale 4, PR2 at

I think the clear command would be CRLF but mayeb we have a PIC expert here in the group. Yo, Jan?

No; you can't go any lower than around 244Hz for the PWM frequency. But you really don't need to use a hardware PWM unit for a frequency that low. You can just flip the output bit in software at the appropriate times. Or you can run the CCP module in compare mode, which uses a 16-bit timer.

There are three ways that you can cause something to happen; in increasing order of latency: hardware, interrupt, and polling.

Given the relatively lax latency requirements for this application, it would suffice to enable interrupt-on-change for the two input pins, and to do the rest in software (you could probably do it all in software, but the programming becomes a bit more tricky).

Load it with zero before enabling it.

Wait, what's that based on? If you need something done right away and your only choice is software, you do polling. That's always how it's been on the PC.

Microcontrollers do usually have pretty fast interrupt response, but they can still be disabled (or prioritized).

Mmmh, I suppose you can make the same case where multitasking OSs are used... :rolleyes:

Tim

By "polling", I'm talking about polling once per iteration of a larger main loop, as opposed to "btfss GPIO,0 ; goto $-1".

Not always. PC's can do interrupt handling provided the operating system on there is capable enough and the hardware is conducive to interrupts. For example, QNX does that nicely and preductably. Of course, with Windows and USB that's a whole 'nother story.

There is a reason why hi-rel and industrial engineers cling to their ISA boxes and new ones are built and offered all the time :-)

But only some of them, not the more bloated ones.

Indeed. I still have a couple of unused ISA proto-boards in the junkbox.