0

I need to implement PWM-module for linux kernel, it should be high resolution ( will be cool more than 10kHz on my 400MHz ARM cpu) Can anyone give me an advice, what I can use for that purpose? Kernel version is 2.6.28.9. Device hasn't a harware PWM driver. Now I use a kernel timer the frequency of which is set by CONFIG_HZ. Default value of this config is 100HZ, but it too little for me, maximum value is 4kHZ, but this is still insufficient

Dcow
  • 1,413
  • 1
  • 19
  • 42
  • What is "pwm"? And which CPU is that? Does it have HPET? https://en.wikipedia.org/wiki/High_Precision_Event_Timer – Aaron Digulla Jun 05 '15 at 11:19
  • Use a hardware PWM if you want somewhat precise timing. Software will have too much deviation, jitter, etc. Even with massive effort it will be far from being good (not to speak of perfect). – too honest for this site Jun 05 '15 at 11:41
  • Pulse-width-mudulation http://en.wikipedia.org/wiki/Pulse-width_modulation I have ARM926EJ-S based CPU (NXPs ASC8848A), it haven't HPET – Dcow Jun 05 '15 at 11:42
  • @AaronDigulla: The question mentions ARM 400MHz. HPET is x86-specific (although new ARMs have something similar). – too honest for this site Jun 05 '15 at 11:45
  • Many ARm devices include hardware timers with PWM outputs, but the [ASC8848A](http://www.nxp.com/products/identification_and_security/security_and_surveillance_ip_camera/ASC8848AET.html) is a intended for video encoding applications. It currently lacks a data sheet or manual but the information available does not suggest it has hardware PWM. – Clifford Jun 05 '15 at 15:58
  • @Clifford: I have a datasheet, but I don't found any references about HW PWM, so... – Dcow Jun 05 '15 at 16:03
  • I appreciate that you as a customer may have been provided a data sheet but the link in my comment does not make it available, so we have no way of determining that. There are plenty of parts with hardware PWM; but presumably your applications needs video encoding? An external PWM chip connected to your device via the SPI port may be in order, or even a small microcontroller with hardware PWM that can perform other hard real-time tasks without the encumbrance of Linux. – Clifford Jun 05 '15 at 18:25

2 Answers2

1

Pulse-width modulation is very, very hard to do in software. In theory, all you have to do is to find a timer in your CPU which has a good enough resolution, attach an IRQ handler and kick it off.

If you look at the clocks, it feels insane that you can't do a 10 kHz PWM on a 400 MHz CPU - you would have 400000/10 = 40000 CPU cycles per pulse which is surely enough?

Maybe not. The linux kernel uses interrupts itself to do kernel calls. Then you have other interrupts (DMA, NMIs, other timers, ...). Depending on the priority of the timer interrupt, some of them can block it. Which means that a network operation or something else can delay your IRQ handler. If you're using Linux kernel APIs to handle the interrupt, then you have more problems: The kernel won't call your handler. Instead, the real IRQ handler will collect some information about the interrupt and append this as a task to a chain.

Eventually, the kernel will look at that chain and process the tasks in it.

Another problem is that the CPU won't respond to an IRQ right away as well. There are op codes which you can't interrupt.

This leads to a lot of jitter.

If you want to try it, then you should write your own IRQ handler in assembler which does all the processing - taking the IRQ and writing the new output values. Don't use the standard linux interrupt API. Then you will have to disable the interrupt API for this timer (or the kernel might remove your handler).

You must use a timer which has a very, very high priority in your CPU - anything that can delay it will ruin your day.

And even if you have 40K CPU cycles to spend: There is always other software which also wants a bite. So you may not be able to run anything else.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
0

"Use a hardware PWM if you want somewhat precise timing. Software will have too much deviation, jitter, etc. Even with massive effort it will be far from being good (not to speak of perfect)."

The above answer is not entirely correct, even though it shows some of the problems with PWM:

The thing is, that independantly of whether the output signal comes from hardware PWM generator or from software-controlled GPIO, the application must perform all the computations within a single PWM period. Otherwise the jitter will be observable as an incorect averaged PWM value or incorrect averaged signal phase shift.

In other words, the only benefit of using HW PWM is that the computations can be done asynchronously to the PWM pulse edges, but they must be sychronized with the begin/end of PWM period.

vtomazzi
  • 1
  • 1