Favorite Philips/NXP LPC21xx websites/forums?

John schrieb:

Personally, I really dislike web forums - but there is a reasonably active group on Yahoo:

Tilmann

--
http://www.autometer.de - Elektronik nach Maß.

On Thu, 14 Sep 2006 08:39:55 GMT, John wrote: /cut

I have Keil MCB2100 with LPC2129 ARM7TDMI microcontroller board. There are not many sites with information about LPC.

yahoo lpc2000 group mostly.

Best bet is to ask here if you need something or don't undestand.

Hi,

Thanks to all who resp> The lpc2103 is very attractive (32 bit performance with a cost and

Yes, I heard about this NXP nonsense. I went to the Philips website one day and I was trying to find the LPC datasheet. I accidentally hit play on a flash item (I use "Flashblock" for Firefox so I'm not normally assaulted by this crap) and there was some marketish looking dude spouting nonsense quite loudly.

This has been my past experience as well. In fact, this is the first Philips part I have considered using in 8+ years. They're on my blacklist and except for this, they'll remain there.

It seems their AT91SAM32 is the "low-end". Fortunately with Philips in the game, the price on the AT91SAM parts has come down. They're now $5ish in 100 pcs quantities, DigiKey pricing, where they used to be $6.74 in 1k+.

The only thing I don't like so far about the LPC parts (from looking at the data sheets), it seems they have just plonked down the ARM "VIC" Interrupt Controller instead of making their own. Atmel's interrupt controllers seem much more intelligently designed.

I like the idea of writing interrupt handlers per event (UART_RX, UART_TX). With the LPC parts it seems the peripheral interrupt handler must determine the cause (RX, TX, etc) and then take appropriate action.

Anyway, I'd be interested to hear other minuses/pluses of the LPC parts.

Thanks, John.

Sounds good - it's worth a look. I bet they use more current than the

2103, but that's not an issue if you aren't using battery power.

Despite my negative comments about the company, the 2103 has a lot going for it. It has high speed bit toggling (I think it's 3 or 4 times faster than most Arm7's), and I think all lpc2000 devices have the MAM that lets them run full speed from flash. The SAM devices run about half speed from flash.

Although the lpc on-chip peripherals are simpler than those of the SAM, that simplicity can be a good thing if you're in a hurry to get something working.

I haven't compared the errata sheets, but I'd expect the SAM to have more items there because their chips are generally more complex. But I don't mean this as a slam against Atmel because every company has these kinds of issues when they pack more stuff into the chip.

If you have a need for a battery powered Arm device, the lpc2103 is your best bet today. If power isn't a concern and you just need a low cost device, then compare the SAM32 against the 2103 and see how the specs line up.

Eric

For now, a SAM7S16 is in design and is pin compatible with the S321/S32.

If you run in Thumb mode, you run full speed and since the SAM7 only has a single waitstate, it should be faster than the LPC at any given frequency. If you know you run at low enough temp, you could test setting zero waitstates at 48 MHz. You could be surprised...

Also, if you have some communication tasks, then you find that the PDC will off load the CPU significantly while the LPC gets bogged down. Also, for some small compute intensive tasks, it is quite OK to copy and execute from SRAM, the SAM7 has plenty of that.

Then again, once you are deep in the project and try to solve the hard problems then you appreciate the SAM7 peripherals.

It depends on the conditions. The PDC of the SAM parts allows you to do a lot while the CPU is sleeping.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

How much SRAM is in the SAM7S16 you mention ?

-jg

Not sure, 4-8kB so the idea of copying to SRAM is less useful for this chip. With 64 kB SRAM in the AT91SAM7S256 it is a very good proposition.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Actually my experience is that the Atmel parts are the lowest power you can find. Of course this will depend on any number of things and since Philips is a close second, for any given app the Philips parts may be lower power. But don't assume the Atmel parts are hogs, they are not!

They are a bit more money than the Philips parts. I don't know exactly what makes them more expensive, but we buy a lot of parts and get high quantity pricing with a lot of competition. Even so, the Atmel prices were all a bit higher than the equivalent Philips parts. We went with the Atmel parts on our first few ARM designs because most of our stuff runs from battery and power is very important. The Atmel parts have some clear advantages for low power operation.

The bit toggling on the newer Philips parts is a lot faster than the older Philips parts, but the Atmel parts have always been fast. The original Philips design put the GPIO interface on the slow internal bus. They changed that with the last few iterations of new designs.

You really shouldn't say stuff like this unless you look at the errata sheets. You can assume anything you want, but you know what happens then!!!

You should look harder at the Atmel parts. Not only do they do very well on battery power running full out, they have a lot more potential for power savings by shutting down various sections of the chip and even running the internal Vddcore from an external 1.8 volt source rather than a 3.3 volt on the internal LDO. A very small switcher can give you an 80% boost in battery time just from this feature.

I know as a fact and first hand that Atmel does NOT put full Errata on their AVR documents at least. Don't know about the ARM stuff though. In fact, try to obtain information on Atmel quality control programs. Then look at somebody's quality control program like Microchip. At least Microchip has a quality control program and decent Errata sheets as well as Philips/NXP.

boB K7IQ

This was the problem with ATmega 32s and 128s just over a year ago and lasted about a year. I was evidently the first in north america to find the problem. The Mega32 I was using was full and I was using all of the peripherals to the max, in a power product. They referred to it as the LPM instruction problem where, when run at close to max frequency (16 MHz) the parts would not work correctly. Symptoms were numerous, but random part resetting was one common common symptom.

Turns out the problem would get worse with increasing temperature (say

was powered up longer (say, > 1 day). We had to power up our processors for a day, then carefuly check the parts operation. CRC check worked for a short while but there appeared to be more problems with these parts than just the LPM instructions. Atmel did NOT send out ANY erratas are far as I know on this problem and it was a silicon problem not associated with any one particular batch. Many date codes were affected, or around the first years production. Yes, they supposedly fixed the problem by testing. They must either be throwing away a lot of parts, or selling them as the < 8MHz version. I slowed down the clocks on these and sometimes they would not work at even 10 MHz.

I had to email ALL of the QA email addresses around the world on their website until I got even a seemingly interested response. The local FAE was at the factory the next day. Our company spent probably $100,000 with this problem and not one Atmel engineer or QA person came by. The reports we got from Atmel on some of the parts of ours they "tested" were basically meaningless and worthless. They obvioulsly kept the information to themselves.

Atmel still denies the problem existed. They could not show us a QA program either. Their QA processes were confidential. To me that means it is pretty nonexistent. I was shown QA programs by other vendors and they were proud of their QA.

Because of the way we were treated by Atmel management, I will stay away from them in the future. I was soured. The ARM parts may be designed by a different group, but Atmel management is still the same I bet. I was not the only customer with these problems. I emailed with people in UK and Croatia that had very similar problems and no support. The guy in Croatia reported the problem before me and had I found his posting earlier, I would have not torn out as much hair as I did for as long as I did.

I would sum up my experience as meaning Atmel has very poor customer support.

boB

Here is that very old posting from that guy in Hungary. I thought it was Croatia. I found this on deja-news, google groups.

Also, it looks like we have talked about this issue before, Ulf.

It also looks like Atmel has at least fixed the problem or tested out the bad parts. This was evidently the first year of production for these parts. Mega16s were fine and without problems.

Atmel would not be my first choice for a micro though based on that experience.

Thanks, boB

(the old post)

From: Deni - view profile Date: Sun, Mar 16 2003 8:31 am Email: "Deni" Groups: comp.arch.embedded Not yet ratedRating: show options Reply | Reply to Author | Forward | Print | Individual Message | Show original | Report Abuse | Find messages by this author

Did anybody had any problems using Mega32 device running at 16MHz? We had cca. 20% of devices that do not correctly read Flash memory as data constants...(using LPM instruction). Ocasionally device do not read the contents of Flash correctly, usually one bit fails...If clock frequency is reduced, it starts to behave as supposed...???

Dejan

How much are you prepared to bet ;-)

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

That is one of the strangest replies to a post I have ever seen. When he said he thought the management was the same, he didn't mean the one guy at the top was the same as last year. He meant they share many layers of management and very likely share many management products like work processes and QA methods.

The fact that your CEO was canned is not really relevant unless he was also the head QA manager. Is that what you are suggesting?

The AVR is in the microcontroller division The AT91 is in the ASIC division The divisions do not share managers, but both report to the CEO and COO

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Yes, the layer of management is what I meant. Maybe the new guy at the top will look deeper into the infrastructure and into the QA and customer support.

Having said what I did about the customer support, I DO very much like the basic architecture of the AVR parts.

Thanks guys, boB

I've heard this before but I don't understand it. Are you doing fetches

32 bits at a time in Thumb mode, and doing one 32 bit fetch for every 2, 16 bit opcodes? If so, then this is something like what the LPC MAM is doing, right?

Is the LPC slower than the SAM7 in thumb mode? Is this related to the faster underlying speed of the SAM flash (I understand your flash can run at 30 Mhz, but the LPC flash can only run at 20 Mhz)?

I understand that you're talking about thumb mode, but how can this be faster than the LPC in thumb mode? I guess the LPC in inserting more than 1 wait state in thumb mode? But aren' t they reading from flash in chunks of 128 bits (using MAM) - that speedup should apply in both Arm and Thumb modes, right?

You guys have brought up some new things that I didn't know about the SAM7 devices and this is good information. I started looking at the SAM7X last year, but it got delayed and my interest moved to the Philips devices..

Regarding support issues, I contacted Atmel AT91 support several times last year, and I got great answers. I also like at91.com (it has an ugly look, but excellent content with knowledgeable users). And I didn't have any luck with Philips tech support when I contacted them this year. With the recent change to NXP this might be a good time to "go back to the basics" and revisit my strategy.

The only support I can get for LPC is from the Yahoo forum. That's pretty good, but its not something that's funded or endorsed by Philips, and sometimes I wondor who's right when I see conflicting message posts. At91.com is funded and endorsed by Atmel, if I understand correctly.

The only minor gripe I have with Atmel is that they're very quiet when it comes to their future plans. Philips used to "wow" us with early news on upcoming devices. I'd like to see more info about what Atmel has in the pipeline. We've got a long design and testing cycle so we need to keep our eyes on the future.

Eric

In Thumb mode, the CPU is fetching 16 bit instructions. The memory controller is fetching 32 bits.

If the CPU jumps to 16 bit instruction 'n', it will take two cycles to fetch n & n+1 When the CPU fetches n+1, the memory controller starts fetching n+2 & n+3. When the CPU fetches n+2, the memory controller is in the middle of the access of n+2 & n+3 so the result can be immediately forwarded to the CPU so this is also done with zero waitstates.

Jumps to odd locations will cause a waitstate in the second access.

The SAM7 is faster than the LPC at 20-30 MHz since it is always zero waitstates while the LPC adds some waitstates.

Whenever the chips jump to a new location, then LPC will have one more waitstate. Whenever the chips fetch constants from flash, the LPC will have one more waitstate.

The LPC has a little higher clock frequency than the SAM7. The main reason is that they use the ARM7TDMI-S which is slightly faster than the ARM7TDMI. S stands for synthesizable and while I have not seen the comparision for the ARM7, I know that for the ARM9, this means about 30% higher power consumption. I think I may have created my own problem here, since I badgered National Semiconductor to license the ARM7TDMI (which they never used) and to demand a synthesizable version. The ARM7TDMI was only available as a hard-core at the time... Whenever Philips are on my back on performance (in ARM mode), I can sit back and claim that since they are using "my core" I am not surprised :-)

I think the LPC has some more advanced caching schemes than the SAM7, which will increase its performance for very short loops.

It also has two banks, so if the CPU fetches data which is located in the other bank, it can use the 128 bit line, but I doubt this is very useful with the current set of compilers, since they tend to put data close to the instruction which will then invalidate prefetch buffers.

If your application can copy to SRAM, then of course you do not have any waitstate and the CPU. Often the SAM7 has more SRAM than the equivalent LPC so there is some gains here.

You also have to think system performance. The AT91SAM7 peripherals help out a lot here. What is the performance of an LPC when running a manchester coded serial protocol? Since it does not support manchester coding, it will have to implement it in S/W.

Assume you want to write to a log in external serial flash. The speed of the SPI is significantly faster in the SAM7 so you can complete the job much faster (55 Mbps SPI in the latest chip)

Try running a couple of high speed serial lines, and the LPC is on the floor breathing for air, and the SAM7 has not even worked up sweat due to the PDC.

If you really are after performance, the AT91SAM9261 will run 3-4 times the LPC when executing out if its internal 160 kB SRAM at 200 MHz . Have to boot from a small 1 Mbit dataflash, but otherwise they are similar to a SAM7 (if you can stnad the BGA package). The new AT91SAM9260 will also be a killer chip. Can't really see how you can design an ARM9 without Ethernet and LCD...

When I talk to customers about ARM, more than 60% are looking for ARM9 and most of those want embedded Linux. The AT91 rules there, (even with the LPC3 series)

(3 + 1 + 1 + 1 + 1 + 1 + 1+ 1) > (2 + 1 + 1 + 1 + 1 + 1 + 1+ 1) Not by much, but if you add extra time for 1 more waitstate at each memory fetch I think you will be slightly ahead.

Yes

Noone at Atmel wants to wow Philips. They were out early with single chip flash parts and got a lot of things wrong. The AT91SAM7 then came out, and in many respects, it is is right. Cant complain, since I been badgering them about a lot of things implemented in the SAM7 :-)

Philips then went out and tried to copy a lot of things. They are still way behind in peripherals though.

There are cool things planned (as well as bug fixes) but releasing early just means getting information to Philips. Anyone checking out the datasheets of the AT91SAM9261 real closely might find some Easter Eggs

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB

Yes, but with much less complexity. The LPC fetches 4 words at a time, but as you say, more slowly, so a jump is more costly. Also, the LPC speeds up ARM code to single cycle as well as Thumb code.

But there are more things that determine CPU speed than just Flash speed. The clock speed is a factor even if you are running from Flash with wait states. IO accesses can affect your speed depending on the IO throughput requirements of your app. So look at the chip in the total context of your app rather than considering individual pieces of the MCU.

On the other hand the Luminary Micro Cortex M3 MCUs have 50 MHz flash and can run at full speed with no wait states from Flash without any "special" tricks. Also, most of the instructions are 16 bit Thumb 2. Everything I hear about the LM Cortex M3 parts is good. They don't fit our apps so well because we mostly are looking for minimal power and the ARM7 cores from Atmel and Philips are still lower power for a given clock speed. I have not tried bench marking these parts to see if the higher performance per clock offsets the higher power consumption at all.

BTW, the higher power consumption of the LM CM3 parts is most likely from the slightly older technology, 250 nm vs 180 nm, rather than an intrinsic property of the CM3 core. They tell us that the CM3 core should be lower power if all other factors are equal. But then when has anything been "equal"?

LPC

The SAM7 parts also have DMA for the peripherals which can be a real boon when you have a lot of IO going on.

I personally am not a fan of the AT91.com web site. This is mainly because I don't like having to go to two web sites to try to find the info and not knowing which site it is likely to be hiding. It is more than once that I have looked for info and not found it, then asked the local support for it and told there is none, only to find it later at one of the two sites. If it were at a single site, I would at least know to look a bit harder at that site until I find it. Two poor sites does not equal one good site! Perhaps they sould just give up on providing ARM info at the main site and just put it all at AT91.com?

I believe I will be using Philips parts on my current project. We need two SPI ports and Atmel only supports that on the higher end SAM7X. Now that it is available in the smaller sized 100 pin BGA, it might still be a contender, but the Philips parts look very good for this socket. They have so many options in terms of memory and peripheral combinations. I believe the SAM7 parts all have the same peripherals except for the SAM7S32 and SAM7S16 which is due out.

We get an occasional glimpse into their future offerings. But they seem to be struggling to get their latest SAM9 chips out the door and have not fixed many of the errata on the SAM7 chips. There are some that are significant to us in some apps. Power and size are both very crucial commodities to us. I don't recall hearing about anything other than the SAM9 parts which still very preliminary last fall when they briefed us. Maybe we are due for another peek into the world of tomorrow at Atmel?

I agree it would be a very good if this was implemented. The at91.com web site is under reconstruction, and the new version will be online in a month or two.

The RM9200 (Ethernet ) Production since 2003 The SAM9260 (Ethernet ) is out of the door. First batch of development kits shipped to customers The SAM9260A(Ethernet ) in design (high speed SAM9260A) The SAM9261 ( LCD ) is in production The SAM9261S ( LCD ) in design (SAM9261 w 16 kB SRAM) The SAM9262 (Ethernet + LCD + GPS) is out of the door, but is moved to the GPS team and will be renamed to ATR6... The SAM9263 (Ethernet + LCD ) will be available around the end of the year. The SAM9xxx (-: ............................ :-) First silicon real soon.

Everything points to the SAM9260 cleaning up the low cost embedded Linux market.

--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB