linux-embedded.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Aras Vaichas <arasv@magellan-technology.com>
To: Bill Gatliff <bgat@billgatliff.com>
Cc: David Brownell <david-b@pacbell.net>, linux-embedded@vger.kernel.org
Subject: Re: [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer  and a GPIO pin
Date: Thu, 19 Nov 2009 08:02:46 +1100	[thread overview]
Message-ID: <ed62800911181302j7e1f22bera62b8846f29707fb@mail.gmail.com> (raw)
In-Reply-To: <4B02C8AE.8050600@billgatliff.com>

2009/11/18 Bill Gatliff <bgat@billgatliff.com>
> The jitter can be quite low (100's of usecs) on a 200 MHz ARM9 chip, in
> fact, but you'll eat your battery alive if it's a portable device.  And
> the jitter will also destroy your waveform at high or low duty cycles.

I agree with both of you, and I have physically tested bit-banged PWM
with an LED, a servo and a speaker. In all cases the jitter is
immediately obvious. The LED flickers noticeably (it is a very good
candle effect and system load indicator), the speaker crackles with
the white(ish) noise of the jitter, and the servo becomes unuseable.

It's pretty easy to do some math to prove it. Assume 100usec jitter.

Say you want to run a speaker at 1kHz. You need a 50% duty cycle PWM
running at a 1ms period. 100usec is a 10% error on 1ms. Therefore the
frequency will shift by 10% or 100Hz. Frequency resolution of the
human ear is 0.36 Hz within the octave of 1,000–2,000 Hz so you will
notice a 100Hz shift. What you end up hearing is 1kHz + noise.  Look
at it musically, C6 is 1046Hz and D6 is 1174Hz. So a jump of about
130Hz is a full 2 semitones! Totally useless for playing any sort of
music or pleasant sounding warning tones.

Servo motors require a 1ms to 2ms pulse to hold a position between
about 0 and 180 degrees. A jitter of 100usec is physically equal to an
error of 100usec/1ms = 10% on the servo output arm which is equal to
10% x 180 degrees = 18degrees of positional error! It is alarming to
watch what happens as the CPU is loaded.

For non-commercial products these artifacts might be acceptable, but I
wouldn't use it for anything that a customer will comment on.

Aras

  reply	other threads:[~2009-11-18 21:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-19 20:32 [[RFC] 0/5] Generic PWM API Proposal Bill Gatliff
2009-10-19 20:32 ` [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface Bill Gatliff
2009-10-19 20:32   ` [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin Bill Gatliff
2009-10-19 20:32     ` [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API Bill Gatliff
2009-10-19 20:32       ` [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load Bill Gatliff
2009-10-19 20:32         ` [[RFC] 5/5] Incorporate PWM API code into KBuild Bill Gatliff
2009-10-19 22:30           ` Mike Frysinger
2009-10-19 21:51         ` [[RFC] 4/5] An LED "dimmer" trigger, which uses the PWM API to vary the brightness of an LED according to system load Mike Frysinger
2009-10-20  1:42           ` Bill Gatliff
2009-10-20  3:58             ` Mike Frysinger
2009-10-30 14:03             ` Luotao Fu
2009-10-31  7:43               ` Trilok Soni
2009-10-31  7:45                 ` Trilok Soni
2009-10-19 22:34       ` [[RFC] 3/5] Expunge old Atmel PWMC driver, replacing it with one that conforms to the PWM API Mike Frysinger
2009-10-20  2:02         ` Bill Gatliff
2009-10-19 21:56     ` [[RFC] 2/5] Emulates PWM hardware using a high-resolution timer and a GPIO pin Mike Frysinger
2009-10-20  1:47       ` Bill Gatliff
2009-11-17  8:29     ` David Brownell
2009-11-17 16:00       ` Bill Gatliff
2009-11-18 21:02         ` Aras Vaichas [this message]
2009-10-19 22:29   ` [[RFC] 1/5] API to consolidate PWM devices behind a common user and kernel interface Mike Frysinger
2009-10-20  1:59     ` Bill Gatliff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed62800911181302j7e1f22bera62b8846f29707fb@mail.gmail.com \
    --to=arasv@magellan-technology.com \
    --cc=bgat@billgatliff.com \
    --cc=david-b@pacbell.net \
    --cc=linux-embedded@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).