PWM'ing a hardware LED

[spamiam]

I have a ZX-328nu device.

It has an active low Red LED on pin 14 (B.3) which is the PWM A output for Timer/Counter2.

I have a stupid question. I know I have successfully done this before, but it has been a while.

I want to PWM this LED, and do it slow enough to see it by eye. So, 1-4Hz and 50% duty would be fine as a test.

I tried to do this with the following code, but the LED is simply "ON", no flashing that I can determine at all.

Code: Select all

     Call PinOutput(B.3, 0)
     Call OpenPWM8(1,1.0, zxFastPWM)
     Call PWM8(1,0.5)

I assume that I have not been able to get the timer to actually switch the pin. What more do I need to do to get pin B.3 flashing?

[dkinzer]

What more do I need to do to get pin B.3 flashing?

There are two issues in the code you've used. Firstly, the lowest attainable PWM8 frequency is about 56Hz when running at 14.7MHz (see the table of minimum frequencies in the discussion of OpenPWM8). Secondly, when the duty cycle parameter is a Single value the units are percent so if you want a 50% duty cycle you should use either 50.0 or simply 50.

If you want to get PWM output at a frequency lower than the minimum, you could configure the timer to generate an interrupt at a convenient frequency and then count the number of interrupts in the ISR. When your count gets high enough you can then toggle the output state. This is the technique used for "software PWM". It works best when the desired frequency is low with respect to the CPU frequency so that the overhead of servicing other interrupts doesn't interfere too much. You'll still get "jitter", however, due to interrupt latency and (possibly) due to differing execution time of the various paths through the ISR code.

[spamiam]

There are two issues in the code you've used......

Ah, that solved it. I set it to phase correct and got the frequency down to 28.2Hz. I can just barely see a flicker in the LED at 50% duty.

Now the next problem. I have never used WaitForInterrupt() before.

I want to use B.3 (being toggled by the timer) as a pin change interrupt, if possible. This is to simulate an external pulse that will be eventually used for the interrupt source.

I have written the following:Private Sub Interrupt()

Code: Select all

	Call WaitForInterrupt(&H08, WaitPinChangeB) ' await a change on Port B, bit 3 (zero based)
	count_total = count_total +1
	buffer1 = buffer1+1
	buffer2 = buffer2+1
	count_flag = TRUE
End Sub

But the count_total value never seems to increment. In the same module (separate form the module with main()), I have accessor functions to get at the counts. They will eventually be atomic, hopefully, but right now they are quick and dirty.

[dkinzer]

I want to use B.3 (being toggled by the timer) as a pin change interrupt, if possible.

I've never tried that but I suspect that it won't work. If you look at the diagram in the datasheet showing the structure of an I/O pin it looks like the pin change won't be seen unless the pin is in an input mode.

To test this hypothesis, modify your code to sense a pin change on a different pin and hard wire B.3 to that pin.

[spamiam]

If you look at the diagram in the datasheet showing the structure of an I/O pin it looks like the pin change won't be seen unless the pin is in an input mode.

To test this hypothesis, modify your code to sense a pin change on a different pin and hard wire B.3 to that pin.

Now that you mention it, I think you are precisely correct. I used a pin change interrupt once in C many years ago and I think I had to make it an input pin, and I toggled the pull-up.

I believe this is working now withthe change you suggested, but it is part of a larger piece of code that is NOT working and will be the subject of a new post with the correct subject line. It has to do with the WaitForInterrupt() command.

[spamiam]

Don, I actually got the WaitForInterrupt() working without having to ask a question. Actually, as I wrote the forum post, it made me think about it clearly. My main problem was my thinking in terms of a C ISR that will get executed automatically for every interrupt whereas in ZBasic I need to create a separate task and have that task loop itself. It isn't an interrupt service routine as such. It is a task that polls the interrupt flag.

I did find out that the pin change interrupt WILL trigger from a pin that is configured as output! So, I can use the PWM A output of T/C2 as a pin change trigger source.

One last question (last?). I want to detect only a rising edge OR falling edge (for instance on pin B.2). The command

Code: Select all

Call WaitForInterrupt(&H04, WaitPinChangeB)

Triggers on both rising and falling edges. In your documentation, I do not see a way to trigger only on one of the edges. Is this possible?

[dkinzer]

I want to detect only a rising edge OR falling edge [...] Is this possible?

No. Pin change interrupts on the AVR devices are sensitive to both edges. You have to examine the state of the pin in the handler to determine whether it was a rising or a falling edge and respond differently if needed. Short pulses could be a problem in the general case.

[spamiam]

Short pulses could be a problem in the general case.

I am not sure how short the pulses will actually be.

I have what is in effect a rotating bar magnet. And I will either use a reed switch or a hall sensor. The reed switch is susceptible to bounce and this could require extra hardware/effort to debounce. So, I may go with the hall sensor.

The bar magnet will be rotating at up to 2000 RPM (33.3 RPS). The end of the magnet is maybe about 25% of the circumference of the 180 degree arc. So, the duty factor will be about 25%.

There will be two switching events per revolution if I use a reed switch The period for the events will be 1/(66.67Hz) which is 15mS. The ON time will be 3.75mS. I measured switch bounce for one of these reed switched and it bounces 1 or 2 times, with a period of 20uS, only when switching ON (contacts are touching). No bounce going OFF.

I think the latency of servicing the WaitForInterrupt() could be over 1mS. Could it be over 3.75mS?

-Tony

[dkinzer]

I am not sure how short the pulses will actually be. [...]

I think the latency of servicing the WaitForInterrupt() could be over 1mS. Could it be over 3.75mS?

It wasn't the total time of the interrupt handling that I was referring to. Rather, if the strategy is to check the state of the input shortly after receviing a pin change interrupt then a short pulse could trigger the pin change interrupt and then be back in the initial state before the input is sampled when trying to distinguish rising and falling edges.

I doubt that the execution time of WaitForInterrupt would be as high as 3.75mS. At 14.7MHz that is over 55,000 cycles.

You could add external hardware to detect either a rising edge or a falling edge. What I'm thinking of here is an edge triggered flip-flop that is wired to toggle on the edge trigger, thus providing a pin change signal corresponding to the desired edge.

[GTBecker]

FWIW, I suggest that you use Halls; IMO dealing with contact bounce is
wasted time, and I've had reed switches stick closed.

One of my projects was a steered marine searchlight. I opened the
brushed DC motors in a stock GoLight and found room to mount a 6mm disk
magnet on the end of the motor shaft (before gearing) and two Halls in
quadrature. Between the two axes and two indexes - six interrupts - a
BX-24 (with some glue logic), then a ZX-24, had no difficulty keeping up
with the bidirectional PWM'd motors at full speed, ~3000RPM.

Incidentally, as it happens I fired up the prototype light a few weeks
ago. It has been on the bow of my boat, unpowered, for eight years and
has seen two hurricanes and lots of salty wet Florida weather. It
booted and found home accurately. I was amazed.


Tom

[spamiam]

FWIW, I suggest that you use Halls; IMO dealing with contact bounce is
wasted time, and I've had reed switches stick closed.

Wow, you made those units really well!

I agree, a hall sensor will work well in this application. In general I like the simplicity of reed switches, but it would be no problem to run power, ground and signal for the hall instead of power in and out for the reed.

I would have made a cute version of a RS latch that has a capacitively coupled feedback so it can work with SPST switches instead of SPDT switches. I THINK it will also create only a short pulse signal, so maybe there is no need to have a flip-flop as Don suggested.

The feedback creates a reset signal that can be tuned to be longer than the bounce time.

No such glue logic is needed with the hall, not for debouncing, though maybe the flipflop is needed to eliminate the double edges.

-Tony