PWM on the MPC850

PWM on the MPC850

[Donald MacArthur]

Does have any information regarding generating RC spec PWM signals using the
MPC850
that does not bog down the processor?  Also does anyone know how to expand
the number
of RS232 ports for the MPS850 from two to 2+.

Thank You
Donald MacArthur


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PWM on the MPC850

[Wolfgang Denk]

In message <NDBBIHDFKLJKGJJGMFJOOEILCGAA.dmacarth@ufl.edu> you wrote:
>
> Does have any information regarding generating RC spec PWM signals using the
> MPC850
> that does not bog down the processor?  Also does anyone know how to expand

You can, to a certain degree, use the RISC timers to set up a  couple
of  PWM  channels  that run with zero CPU load (just some load on the
CPM). See the PWM driver (arch/ppc/8xx_io/pwm_8xx.c)  in  our  kernel
source tree.

But be warned: do NOT use any of the port B pins for I/O  in  such  a
setup. There is a race condition within all MPC8xx CPUs.

> the number
> of RS232 ports for the MPS850 from two to 2+.

Add one or more external  UARTs?  This  has  been  done  before  (for
example, we have a design with 2 x octal UARTs on a MPC8xx system).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
An age is called Dark not because  the  light  fails  to  shine,  but
because people refuse to see it.           -- James Michener, "Space"

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PWM on the MPC850

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > But be warned: do NOT use any of the port B pins for I/O  in  such  a
> > setup. There is a race condition within all MPC8xx CPUs.
>
> hmm, we access a few port B I/O pins from user space. What/where is the
> race in kernel?

It's not in the kernel, it's in the MPC8xxL.

The RISC timers are implemented in softtware (microcode)  running  on
the  CPM.  To  toggle  a PWM output pin, the CPM will read the port B
data register, modify the bit, and rewrite the port B data  register,
This  access is NOT synchronized against any accesses by the CPU. You
can test this by toggeling a port B pin with software running on  the
CPU:  after  each write to the port B data register read the register
back for a couple of times. You will find that,  as  soon  as  a  PWM
timer is running, the value you write will not "stick".

It's a classical race condition: the CPM reads PBDAT to modify a  PWM
pin, then the CPU writes a new value (modifying a different bit), the
the  CPM writes his copy back - and the value written by the CPU gets
lost. You can see this on an oscilloscope: the data  written  by  the
CPU will be actually there onthe outputs for some 15...25 ns (nano!),
and then drop back to the old state.

Moto never officially confirmed the problem, but the  MPC823E  UM  (I
didn't find this anywhere else) contains the traitorous words:

    [16.2.6.4.4 PWM Mode] ... Because the CPM has to read the
    data register, modify it and then write it back, you cannot
    use open drain output with the PWMs if the output can be
    forced to 0 by external devices.

This is IMHO related to the same problem.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Writing a book is like washing an elephant: there's no good place  to
begin  or  end,  and  it's  hard to keep track of what you've already
covered.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: PWM on the MPC850

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLAELKFIAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > But be warned: do NOT use any of the port B pins for I/O  in  such  a
> > setup. There is a race condition within all MPC8xx CPUs.
>
> hmm, we access a few port B I/O pins from user space. What/where is the
> race in kernel?

I should add that it is non-trivial to work around this issue. We had
a case where even the short spikes on the output caused by this  race
condition  were not acceptable. The only way to make this work was to
disable the PWM timers (and wait for them to shut  down  -  which  is
another  issue)  before moifying the port B data, and then start them
up again. Of course this is unacceptable when you need high precision
PWM signals (but the you would not use a MPC8xx RISC timer anyway).

My recommendation is: never, ever use the RISC timers if you need  to
know hwat's going on on port B.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"Free markets select for winning solutions."        - Eric S. Raymond

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/