Micro with 4-independent PWM channels

"Mike" <chimera-electronics@sympatico-dot-ca.no-spam.invalid> wrote in
message news:xsmdnW3PdY08mm_cRVn_vQ@giganews.com...

>I am looking for a PIC or Atmel Micro that has 4-independently
> controlled PWM channels of about 10-bit resolution . The frequnency
> can be the same but I need simultaneous 0-100% duty cycle control of
> each channel independently . The max PWM frequncy should be greater
> than 1KHz
> Price Range $2.00-$6.00/usd. A few A/D channels, interrupts,C-Compiler
> friendly. I have looked @ the PIC18F1220, however , I am not sure of
> independent PWM control, as the chip still only has one CCP?

The Philips LPC2131 (ARM7, 32KB Flash, 8KB RAM, 6 PWM, 8ch 10bit A/D etc.,
GCC C compiler) should fit.  Or LPC2132 if you need more flash and RAM and a
10bit DAC.

Regards,
Karl Olsen

> Is it just me, or is this getting to sound like a vendor forum?

I'd much rather have a vendor forum than a politics-and-theology forum, 
which is what sci.electronics.design has turned into.  Over there, whole 
days go by without any electronics :)

Hi Rich,

>>Is it just me, or is this getting to sound like a vendor forum?
>>    
>>
>
>I'd be happy if MORE vendors frequented the group.
>  
>

Exactly! I think it is great that Ulf is here for Atmel and I'd hope 
Texas Instruments, Microchip, Philips and others would also see the 
benefits of a close-up contact with their customer base. Or with 
potential customers. After all, we are the folks who are rendering 
pretty final decisions about which products are being released and which 
ones are not. Fact is, once a part is released it is next to impossible 
for another manufacturer to get a foot in the door unless they have a 
100% compatible device. Except for the 8051 world that isn't generally 
possible for micro controllers.

Ulf, you can quote me on that if it helps with your bosses.

Regards, Joerg

http://www.analogconsultants.com

Hi,

a significantly better device than the AT91SAM.. would be the Philips
LPC2131.
It is fast, gives you much more I/O pins and a growth path if needed up
to 512K flash.
Boards are already available from Keil or LPCtools.com.  The 32k IAR
compiler applies as it does with the Atmel device.

An Schwob

Ulf Samuelsson wrote:
> > I am looking for a PIC or Atmel Micro that has 4-independently
> > controlled PWM channels of about 10-bit resolution . The frequnency
> > can be the same but I need simultaneous 0-100% duty cycle control
of
> > each channel independently . The max PWM frequncy should be greater
> > than 1KHz
> > Price Range $2.00-$6.00/usd. A few A/D channels,
interrupts,C-Compiler
> > friendly. I have looked @ the PIC18F1220, however , I am not sure
of
> > independent PWM control, as the chip still only has one CCP?
> > Thanks
>
> Maybe one of the new ARM based AT91SAM7S chips should do the job.
> You get a 32 kB limited IAR C compiler for free.
> AT91SAM7S32 should be witin your price limit
> 
> > Mike
> >

> Mike wrote:
> 
>> I am looking for a PIC or Atmel Micro that has 4-independently
>> controlled PWM channels of about 10-bit resolution . The frequnency
>> can be the same but I need simultaneous 0-100% duty cycle control of
>> each channel independently . The max PWM frequncy should be greater
>> than 1KHz
>> Price Range $2.00-$6.00/usd. A few A/D channels, interrupts,C-Compiler
>> friendly. I have looked @ the PIC18F1220, however , I am not sure of
>> independent PWM control, as the chip still only has one CCP?

10 bit narrows the field a little.

a) There are many 80C51's with the FX core PCA, which offers 5 channels
of PWM, but at 8 bits. You can expand that to 10, under SW with the
low 1KHz target. ie 8 bits jitter-loaded at 4KHz gives 10 bits @ 1KHz.
  use a fast core and high priority interrupt for the PWM resolution
expansion.

b) For devices with actual HW support, you need to find a PWM with
a SW controlled Counter Reload value, and then you can set the 
bit-precision.

  A good device might be the P89LPC932, which has a high-performance
4 channel PWM, all in HW.

c) A PLD could do, but usually you use PLDs only when uC cannot do the
task - ie speed, or some reset/protect operation.
  For a PLD you need 40 bits to store the 4 PWMs, 10 bits to count,
and ideally, prescale and load-buffers, so a 64MC PLD is looking
tight, and 128MC is comfortable.

-jg

On Sat, 22 Jan 2005 11:24:24 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>18F6520 is roughly within your price range, and has 5 independent
>PWMs.

And at 10 bits.  Looks like it may be a fit.

>You really need to search through the data sheets yourself to
>optimize this sort of thing. I also suggest looking at the MSP430
>series from TI. 

This one has particularly effective timers, with associated capture compares
that can be used for PWM.  It would be worth considering for the application,
too, I'd imagine.

Both good recommendations to start.

Jon

Hi,

another point may be worth mentioning. There are 2 more LPC900 devices,
the LPC935 and LPC936 with the same PWM unit (it is called CCU).  All
of these devices are typicaly below $2!!
If you need a 10-bit ADC the LPC938 will fit the bill. I have seen it
in a Philips presentation recently and it is a LPC932 with a 10-bit ADC
and suppossed to be availble within Q1-05

An Schwob

Jim Granville wrote:
---------- snip ----------
> b) For devices with actual HW support, you need to find a PWM with
> a SW controlled Counter Reload value, and then you can set the
> bit-precision.
>
>   A good device might be the P89LPC932, which has a high-performance
> 4 channel PWM, all in HW.
------------  snip  -----------------
> -jg

> Hi,
>
> a significantly better device than the AT91SAM.. would be the Philips
LPC2131.
> It is fast, gives you much more I/O pins and a growth path if needed up to
512K flash.
> Boards are already available from Keil or LPCtools.com.  The 32k IAR
> compiler applies as it does with the Atmel device.

The LPC2xxx parts are interesting devices, and compared to the SAM7 parts
they have both strengths and weaknesses.

The speed of the part is depending on the mode.
The SAM7 uses a 32 bit bus running at 30 MHz
the LPC part uses a 128 bit bus running at 20 MHz

This makes the LPC the best part for fetching 32 bit ARM code (3 + 1 + 1 + 1
= 6 clocks).
I ghuess it will satrt to prefetch, so for additional accesses it is 1+1+1+1
= 4 clocks.
The SAM7 will use (2+2+2+2 = 8 clocks) in ARM mode.
Whenever there is a datafetch from flash,
the SAM7 will use 2 clocks and the LPC will use 3 clocks and
It is not clear to me, if that flushes the instruction buffer.
There is a mode to buffer dataaccesses as well so sequential accesses are
fast.


For 16 bit Thumb mode, the SAM7 has an advantage
since it can fetch the first access in 2 clocks where the LPC will need 3
clocks
The SAM7 will then fetch 2 instructions at the time so
it will use (2+1+1+1+...) �ntil a jump,. while the LPC uses 3+1+1+1
and for datafetches, the 2 clcok cycle accesse makes the SAM7 faster
unless sequential datareads are performed.

ARM mode is about 12 % faster than Thumb mode, but use 30 % more code.

If you use the ARM mode, then I think the LPC should be faster
but if you run in Thumb mode, as many do, then the SAM7 is slightly faster.

If you have a small critical loop in ARM mode, then you can copy that into
SRAM
and run 32 bit zero waitstate.

The big disadvantage of the 128 bit memory access is that the LPC
has 2 x  the core power consumption of the SAM7 series.

The DMA of the SAM7 serial peripherals are pretty useful if you
want to run at high speed and if you compare the throughput of the
two parts then peripherals have to be taken into account.
At least the earliest LPC devices .had problem toggling I/O.
I heard 1 Mhz or so, but users may be able to provide more detailed info
The SAM/ can toggle I/O at 5 - 6 MHz, and the SPI runs at 55 Mhz.
allowing about 5-6 MByte per second download from dataflash.


As for I/O,  Atmel is more conservative on power pads having 14 instead
of the Philips 9. There is also a 1.8V regulator output which could be
useful
for other parts of the system.
You lose the JTAG on some of the parts, and the SAM7 has a special interface
for speeding up production programming. Have not seen any ciomparision of
programming time for the different devices, so I have no clue whether
this makes sense or not.

The biggest selling point at the moment is probably the onchip USB.

In the end, I think that both companies will be in strong competion and
emulate the successful features of the other party, making the 32 bit ARM
micros a very attractive proposition over some competing 8/16 bitters.

/Ulf

>
> An Schwob
>

On 22 Jan 2005 14:42:55 -0800, "An Schwob in USA" <schwobus@aol.com>
wrote:

>Hi,
>
>a significantly better device than the AT91SAM.. would be the Philips
>LPC2131.
>It is fast, gives you much more I/O pins and a growth path if needed up
>to 512K flash.
>Boards are already available from Keil or LPCtools.com.  The 32k IAR
>compiler applies as it does with the Atmel device.
>
>An Schwob

The peripherals on the Philips devices are not even remotely as well
sorted out as they should be. Doing things such as : Cannot read the
state of an input pin if it has been defined as a capture input. 
Ditto for defining a pin as an external interrrupt, and then of course
putting a PC compatable UART in the thing. 

Regards
   Anton Erasmus




>Ulf Samuelsson wrote:
>> > I am looking for a PIC or Atmel Micro that has 4-independently
>> > controlled PWM channels of about 10-bit resolution . The frequnency
>> > can be the same but I need simultaneous 0-100% duty cycle control
>of
>> > each channel independently . The max PWM frequncy should be greater
>> > than 1KHz
>> > Price Range $2.00-$6.00/usd. A few A/D channels,
>interrupts,C-Compiler
>> > friendly. I have looked @ the PIC18F1220, however , I am not sure
>of
>> > independent PWM control, as the chip still only has one CCP?
>> > Thanks
>>
>> Maybe one of the new ARM based AT91SAM7S chips should do the job.
>> You get a 32 kB limited IAR C compiler for free.
>> AT91SAM7S32 should be witin your price limit
>> 
>> > Mike
>> >

Hi Ulf,

guess you forgot something about the clocks. While Philips seems top be
more conservative about the flash access time, specofying it with
approx 50 ns access time over temperature, Atmel claims 33 ns quite
good.
Now about the cycles.  While Philips might need a clock cycle more at
60 MHz compared to a SAM7 at 30 MHZ to execute the first instruction
after a branch that leaves it still a lot faster. SAM7 has the max
throughput @ 30 MHz, LPC2000 @ 60 MHz. The cycles you mentioned are
clock cycles not bus cycles ;-)

We tested the port switching and because the ports are connected to the
peripheral bus the limit is 4 MHz while Atmel can do a little more than
5 MHz connected to the AHB.  Point taken and accepted. Unfortunately
you have to run the SAM7 with wait states when doing that. Running at
30 MHz which provides max. performance and best power / performance
ratio gives you even less than 4 MHz switch frequency.

According to a Philips presentation on the ARM developers conference
there is a Data Bypass Buffer for data fetched from flash, it does not
interfere with the instruction pipeline.

The presentations I have seem from Atmel state a power consumption of
approximately 50 mA @ 50 MHz, the measurement we did with the LPC2131
showed 43 mA @ 60 MHz, giving twice the performance at less power, I
have no idea where you got your power numbers from.  To be fair, we did
not measure the SAM7 yet because the performance is just not enough for
what we are doing.

USB is a good point for the Atmel devices, but the SAM7S32 does not
have one or did I miss something?  The S64 pricing announced at the ARM
devcon was 50% higher than that of the S32! USB comes at a price and
with some delay.  Looking forward to the Philips USB devices as well.

May be Philips uses a lower power process? because I would have
expected the SAM7 to be lower power given the performance difference.

In the end we totally agree that both companies will be strong
competitors and the ARM micros are highly competitive against high end
8-bit and the full range of 16-bit micros.

btw. although we might somewhat disagree which devices to use I really
appreciate your postings because you try very hard and successfully to
stay on a technical level.