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

    Hi,

    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.

    Thanks!
     
    John, Sep 14, 2006
    #1
    1. Advertising

  2. John

    Tilmann Reh Guest

    John schrieb:

    > 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.


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

    Tilmann

    --
    http://www.autometer.de - Elektronik nach Maß.
     
    Tilmann Reh, Sep 14, 2006
    #2
    1. Advertising

  3. John

    Mad I.D. Guest

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

    Eric Guest

    John wrote:
    > 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.


    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
     
    Eric, Sep 16, 2006
    #4
  5. John

    John Guest

    Hi,

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

    In article <>,
    englere wrote:
    > 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).


    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.

    > 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.


    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.

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


    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.
     
    John, Sep 16, 2006
    #5
  6. John

    Eric Guest

    John wrote:

    > 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


    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.

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


    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
     
    Eric, Sep 17, 2006
    #6
  7. "Eric" <> skrev i meddelandet
    news:...
    > John wrote:
    >
    >> 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


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

    >
    > 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.
    >
    >> Anyway, I'd be interested to hear other minuses/pluses of the LPC parts.

    >
    > 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.


    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.


    >
    > 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.


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

    > 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.


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


    >
    > Eric




    --
    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
     
    Ulf Samuelsson, Sep 17, 2006
    #7
  8. Ulf Samuelsson wrote:
    > "Eric" <> skrev i meddelandet
    > news:...
    >
    >>John wrote:
    >>
    >>
    >>>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

    >
    >
    > For now, a SAM7S16 is in design and is pin compatible with the S321/S32.
    >
    >
    >>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.
    >>
    >>
    >>>Anyway, I'd be interested to hear other minuses/pluses of the LPC parts.

    >>
    >>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.

    >
    >
    > 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.


    How much SRAM is in the SAM7S16 you mention ?

    -jg
     
    Jim Granville, Sep 17, 2006
    #8
  9. >> 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.

    >
    > 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
     
    Ulf Samuelsson, Sep 17, 2006
    #9
  10. John

    rickman Guest

    Eric wrote:
    > John wrote:
    >
    > > 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

    >
    > 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.


    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.


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

    >
    > 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.


    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.


    > 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.


    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!!!


    > 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.


    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
    #10
  11. John

    boB Guest

    On 17 Sep 2006 11:28:11 -0700, "rickman" <> wrote:

    >Eric wrote:
    >> John wrote:
    >>
    >> > 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

    >>
    >> 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.

    >
    >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.
    >
    >
    >> > Anyway, I'd be interested to hear other minuses/pluses of the LPC parts.

    >>
    >> 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.

    >
    >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.
    >
    >
    >> 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.

    >
    >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!!!
    >
    >


    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



    >> 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.

    >
    >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.
     
    boB, Sep 18, 2006
    #11
  12. >>
    >
    > 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.
    >


    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.

    >
    > boB
    > K7IQ
    >




    --
    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
     
    Ulf Samuelsson, Sep 19, 2006
    #12
  13. John

    boB Guest

    On Tue, 19 Sep 2006 08:39:07 +0200, "Ulf Samuelsson"
    <> wrote:

    >>>

    >>
    >> 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.
    >>

    >
    >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.



    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
    > 40 C but could also happen at 25C) and would get worse as the part

    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


    >
    >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.
    >
    >>
    >> boB
    >> K7IQ
    >>
     
    boB, Sep 19, 2006
    #13
  14. John

    boB Guest

    On Tue, 19 Sep 2006 08:39:07 +0200, "Ulf Samuelsson"
    <> wrote:

    >>>

    >>
    >> 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.
    >>

    >
    >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.
    >
    >>
    >> boB
    >> K7IQ
    >>



    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
     
    boB, Sep 19, 2006
    #14
  15. > 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.


    How much are you prepared to bet ;-)

    http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=atml&script=410&layout=-6&item_id=892818

    --
    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
     
    Ulf Samuelsson, Sep 20, 2006
    #15
  16. John

    rickman Guest

    Ulf Samuelsson wrote:
    > > 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.

    >
    > How much are you prepared to bet ;-)
    >
    > http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=atml&script=410&layout=-6&item_id=892818
    >
    > --
    > 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?
     
    rickman, Sep 20, 2006
    #16
  17. >> > 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.

    >>

    > 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 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
     
    Ulf Samuelsson, Sep 20, 2006
    #17
  18. John

    boB Guest

    On Wed, 20 Sep 2006 20:47:16 +0200, "Ulf Samuelsson"
    <> wrote:

    >>> > 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.
    >>>

    >> 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 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


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

    Eric Guest

    Ulf Samuelsson wrote:
    >If you run in Thumb mode, you run full speed


    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)?

    >and since the SAM7 only has a single waitstate it should be faster than the LPC
    >at any given frequency.


    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
     
    Eric, Sep 22, 2006
    #19
  20. "Eric" <> skrev i meddelandet
    news:...
    > Ulf Samuelsson wrote:
    >>If you run in Thumb mode, you run full speed

    >
    > 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?
    >


    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.

    > 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)?
    >
    >>and since the SAM7 only has a single waitstate it should be faster than
    >>the LPC
    >>at any given frequency.

    >

    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)

    > 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?


    (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.

    > 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.


    Yes

    > 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.


    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






    >
    > Eric




    --
    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
     
    Ulf Samuelsson, Sep 22, 2006
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Anthony
    Replies:
    1
    Views:
    289
    Louie
    Aug 21, 2004
  2. Leon Heller

    Philips offering LPC21xx samples

    Leon Heller, Nov 20, 2003, in forum: Embedded
    Replies:
    6
    Views:
    324
    rickman
    Nov 21, 2003
  3. Maciej Kaczkowski

    problem with jtag/ETM on Philips LPC21xx

    Maciej Kaczkowski, Jun 1, 2004, in forum: Embedded
    Replies:
    4
    Views:
    525
    Schwob
    Jun 9, 2004
  4. larwe
    Replies:
    3
    Views:
    417
    Roland Zitzke
    Feb 19, 2007
  5. Didi

    Philips/NXP AN10358 - anybody?

    Didi, Oct 13, 2007, in forum: Embedded
    Replies:
    1
    Views:
    247
    Boudewijn Dijkstra
    Oct 15, 2007
Loading...

Share This Page