> At 04:15 PM 6/6/96 -0400, you wrote:
> >I am like to use one of Microchip microcontroller that has on board UART to
> >handle some serial communication.  However, I don't know which one to
> >get.
> >
> >I don't want to use the 16C74 because is has a bad baudrate generator.
>
> This brings up an interesting point.  I have heard several (actually more
> than several) complaints about hardware problems in the mid to upper level
> PIC devices.  I even had someone tell me they were going to stop designing
> with Microchip parts because of the hardware errors.
>
> Now I know how easy it would be every time a program isn't operating
> properly to blame the hardware, but I am getting the impression there are
> actually a few problems other than the "baud rate generator=1" problem he
> mentioned above.  Has anyone been keeping a list of the problems so we don't
> all learn the hard way?  I know there have been revisions to some of the
> chips (xxxA), but I understand even the revisions aren't quite perfect.
>
> Can someone spread some light on the matter?  Hopefully I'm way off base here.

I suspect [beware: this is a WAG] that the problems with the PIC stem in
large measure from the fact that the higher-end devices evolved from an
architecture in which certain critical items were not issues.  For ex-
ample, the general design of the original PIC CPU would probably result in
a register read every instruction cycle whether it was called for in the
instruction or not.  Since register reads had no effect, this was not really
an issue.  Unfortunately, later PICs have registers which are affected by
reads; these registers can thus sometimes get hit unintentially.

Note as well that in the original PIC design, there were no asynchronous
events as far as the CPU was concerned.  Although the timer prescalar
could run asynchronously with the rest of the system, its output was run
through a simple synchronizer [i.e. a double-latch] before activating any-
thing the CPU controlled.  The effects on the CPU were thus easy to model
and understand.  In the newer PICs, however, there are more asynchronous
features and this in turn causes more risks of failure.

Without knowing the internal details of how Microchip's new designs are
implemented, it's hard to know what parts might cause marginal or wrong
behavior given unfortunate timings between events, but I would think the
best ways to avoid trouble would probably be to:

  [1] Run the UART shift clock synchronously with the instruction cycle.
      If finer control of the baud rate is desirable (which IMHO would be
      a great feature) it should IMHO be obtained by using a 4089-style
      circuit rather than merely dividing from a faster clock.  In fact,
      use of a 4089-style circuit would probably allow even a 4MHz PIC
      to operate its UART at _ANY_ speed up to 62Kbits/second within 1%,
      or a 20MHz PIC to operate at any speed up to 300Kbits/second.  If
      anyone wants details on how this would work, e-mail me.

  [2] If fast counters are going to run asynchronously, it might be useful
      to have them count graycode, then go through a latch, then through
      an XOR network [to convert the graycode to binary], then to the CPU.
      This should allow the CPU to read the counters at arbitrary times and
      get reliable results.

  [3] No port/register should be affected by both writing and reading.  If
      a read-only port has side-effects when it's read, that's no problem
      provided that the port is not affected by any asynchronous external
      events.

What do other people think of these design principles?