1

I need a fairly deterministic PWM duty cycle. I don't believe it's rocket science to use hardware PWM. Numerous sources tell us that we can modify /boot/config.txt by adding

dtoverlay=pwm-2chan

which defaults to PWM0 = GPIO18 and PWM1 = GPIO19. We also know that we can use

dtoverlay=pwm-2chan,pin=12,func=4,pin2=13,func2=4

to set PWM0 = GPIO12 and PWM1 = GPIO13.

My application has been using software PWM and coincidentally I've elected GPIO13 for this. So it should be quite easy to switch to hardware. GPIO 12, 18, and 19 are already allocated to other functions on a little "hat" I produced, which would be a real pig to modify.

The latter above allows my test code to work, but I am concerned that it will also convert GPIO12 to PWM.

I thought I might be able to use

dtoverlay=pwm,pin=13,func=4

in order to use GPIO13 as PWM1, leaving the other IOs available for normal GPIO, but the pin doesn't seem to produce any output when used in conjunction with the library at [https://pypi.org/project/rpi-hardware-pwm/][1] .

Can you tell me if what I'm trying to achieve is possible, and if I'm going about it the right way? What could I do differently to get a result?

My hardware is B+ v1.2 and my preference is to work in Python. [1]: https://pypi.org/project/rpi-hardware-pwm/

Thanks.

Improve this question
3
  • Very odd. I can't get the pwm dtoverlay to work, but the pwm-2chan one works fine. Yes, I initialised channel 1, and I even whimsically tried channel 0 on the offchance. The code is the library author's own 3-liner.
    – KDM
    Jul 8 at 7:32
  • Channel is set in __init__ .
    – KDM
    Jul 8 at 20:31
  • Indeed. I tried both.
    – KDM
    Jul 9 at 8:19

2 Answers 2

Reset to default
2

It's probably simplest to set up PWM on GPIO 12/13 with

dtoverlay=pwm-2chan,pin=12,func=4,pin2=13,func2=4

and then to use your Python library to override the setting for GPIO 12 by opening it for input or output (whichever you need).

Improve this answer
3
  • Does opening it for IO with GPIO over-ride the dtoverlay? I.e cause it not not be a hardware PWM? If so, I'm sorted. Very grateful. Respectfully suggest the statement about over-riding be added to the answer. Many thanks.
    – KDM
    Jul 7 at 20:48
  • The GPIO will no longer be in the ALT4 mode so will be disconnected from the PWM circuitry. It will be connected to either the INPUT or OUTPUT circuitry depending on how you open the GPIO.
    – joan
    Jul 7 at 21:01
  • Thank you. In that case, I have to wonder why the dtoverlay=pwm even exists. (Maybe it's historical, from the 24 pin boards.)
    – KDM
    Jul 7 at 22:04
0

Original poster has made an error. In fact,

dtoverlay=pwm,pin=13,func=4

works perfectly well in order to use GPIO13 as PWM1, and works perfectly in conjunction with the library at https://pypi.org/project/rpi-hardware-pwm/ .

The problem is that the device being controlled is a Solid State Relay (SSD). The SSD only changes output state when the AC voltage being controlled is zero-crossing. The UK has a nominal mains frequency of 50Hz. For the purposes of our library, that's a duty cycle of 20ms where the AC crosses zero twice in a cycle, so the SSD output is only updated every 10,000,000ns. This means that for certain selections of duty cycle and PWM period, the PWM "on" time could be shorter than the AC halfwave. Nyquist effect means that if the PWM switching happens during this halfwave, this may manifest as the output not changing for long periods of time.

...coupled with the fact that the SSD's built-in LED seems to be dead.

I'm not sure whether to delete the question or leave it as a lesson to the community.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.