1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

Favorite Philips/NXP LPC21xx websites/forums?

Discussion in 'Embedded' started by John, Sep 14, 2006.

  1. John

    John Guest


    I've recently started development with a Philips LPC2103. I know Atmel
    has a site, AT91.com, which I found useful for AT91SAM stuff. I'm
    looking for suggestions or recommendations on websites/forums that
    discuss using the LPC21xx parts.

    I did the Google search already but ended up at sites that archive "the
    real" forums.

    If it makes a difference, I'm planning on using the GNU toolchain
    w/Eclipse and a Chameleon POD/OpenOCD for JTAG. I already have an
    Olimex board with the 2103.

    John, Sep 14, 2006
    1. Advertisements

  2. John

    Tilmann Reh Guest

    Personally, I really dislike web forums - but there is a reasonably
    active group on Yahoo: <http://tech.groups.yahoo.com/group/lpc2000/>

    Tilmann Reh, Sep 14, 2006
    1. Advertisements

  3. John

    Mad I.D. Guest

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

    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.
    Mad I.D., Sep 14, 2006
  4. John

    Eric Guest

    The author of OpenOCD is active in a forum with that name at the
    Sparkfun web site (US distributer of Olimex products). Sparkfun is a
    good company and they have other families of devices also.

    The lpc2103 is very attractive (32 bit performance with a cost and
    power consumption profile of an 8 or 16 bit processor). I really wish
    they didn't get bought by an investment group with a mixed history,
    though (I assume you know Philips Semiconductor is now NXP).

    Philips always seemed to offer poor support to small companies and I
    can't imagine that this will improve with their new owners. They always
    seemed to have too few people handling customer service and those
    limited resources were apparently targetted at their bigger customers.
    However, the Yahoo lpc2000 group is very good. I wish some of the
    posters there wouldn't check their manners at the door, though.

    Atmel is quite different but they don't have any low-end Arm7 parts in
    this category. I've been looking at Luminary lately...

    Eric, Sep 16, 2006
  5. John

    John Guest


    Thanks to all who responded, this is exactly the information I was

    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.

    John, Sep 16, 2006
  6. John

    Eric Guest

    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, Sep 17, 2006
  7. 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
    from SRAM, the SAM7 has plenty of that.

    Then again, once you are deep in the project and try to solve the hard
    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.
    Ulf Samuelsson, Sep 17, 2006
  8. How much SRAM is in the SAM7S16 you mention ?

    Jim Granville, Sep 17, 2006
  9. Also, if you have some communication tasks, then you find that the PDC
    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.
    Ulf Samuelsson, Sep 17, 2006
  10. John

    rickman Guest

    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

    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.
    rickman, Sep 17, 2006
  11. John

    boB Guest

    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, Sep 18, 2006
  12. The ARM and AVR are in separate division within Atmel, and they make their
    own decisions.

    It would be interesting to know which AVR bugs you are referring to.

    I think that if a problem can be caught at test time, it is better to fix
    the test
    program, and replace the bad parts than introduce an errata.
    You want of course to inform people of a problem with a specific batch.
    Ulf Samuelsson, Sep 19, 2006
  13. John

    boB Guest

    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

    boB, Sep 19, 2006
  14. John

    boB Guest

    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


    (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
    the contents of Flash correctly, usually one bit fails...If clock
    reduced, it starts to behave as supposed...???

    boB, Sep 19, 2006
  15. Ulf Samuelsson, Sep 20, 2006
  16. John

    rickman Guest

    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?
    rickman, Sep 20, 2006
  17. Because of the way we were treated by Atmel management, I will stay
    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
    Ulf Samuelsson, Sep 20, 2006
  18. John

    boB Guest

    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, Sep 20, 2006
  19. John

    Eric Guest

    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, Sep 22, 2006
  20. 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
    while the LPC adds some waitstates.

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

    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
    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
    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
    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
    with the current set of compilers, since they tend to put data close to the
    which will then invalidate prefetch buffers.

    If your application can copy to SRAM, then of course you do not have any
    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
    Since it does not support manchester coding, it will have to implement it in

    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
    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
    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
    I think you will be slightly ahead.
    Noone at Atmel wants to wow Philips.
    They were out early with single chip flash parts and got a lot of things
    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
    Ulf Samuelsson, Sep 22, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.