I am looking for a PIC or Atmel Micro that has 4-independentl controlled PWM channels of about 10-bit resolution . The frequnenc can be the same but I need simultaneous 0-100% duty cycle control o each channel independently . The max PWM frequncy should be greate than 1KH Price Range $2.00-$6.00/usd. A few A/D channels, interrupts,C-Compile friendly. I have looked @ the PIC18F1220, however , I am not sure o independent PWM control, as the chip still only has one CCP Thank Mik
You could take a look at the Atmel ATmega128 which features two 16 bit timers with each 3 PWM channels and a 8 bit timer with 2 PWM channels; 10 bit ADC, 128Mb of flash, 4K int RAM, runs at 16MHz max. and is C compiler friendly.
18F6520 is roughly within your price range, and has 5 independent PWMs. 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.
Best regards, Spehro Pefhany
"it's the network..." "The Journey is the reward"
email@example.com Info for manufacturers: http://www.trexon.com
I've had this assertion made to me several times. So far no-one has been able to back it up. A CPLD capable of holding 4 10 bit PWMs always seems to be rather more expensive than a few dollars (You still have to add A/D micro etc and fit in the $6 range remember).
From what I've seen so far it's always cheaper to add another micro to act as a PWM peripheral that to add a CPLD to do the same thing.
That's not to say it's impossible, but so far no-ones been able to demonstrate that it's doable.
Atmel sells the 8051 as well, but that does not mean I have to like it privately. I do this mostly on my free time and had to fight to even get access to the newsgroups at Atmel. I doubt that anyone in my management is even aware that the Newsgroups exist.
Just happen to like the AVR, and think that most other people willl, if they try it!
Even when I worked at National Semiconductor in 1995-6, I recommended them to license the AVR (and to start building general purpose micros based on the ARM7).
They licensed the ARM7TDMI (actually ARM designed the synthesizable ARMTDMI-S on Nationals request) and the University of Michigan designed a CPU very similar to the AVR for National but the microcontroller group there is dysfunctional and decided to continure with the COP8 and went ahead with the CR16 (even of the 32 bit CR32 would have been better)
The CR16/32 is not to bad, but totally wrong focus from the wrong company has more or less killed the part.
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.
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.
Ulf Samuelss> > I am looking for a PIC or Atmel Micro that has 4-independently
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.
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
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.
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.
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.