LPC or SAM7?

Does it even matter?  I've been doing the smaller micros (PIC, 8052, etc) in 
assembler for quite a while now, and I'd like to tinker with some ARM type 
stuff using C (gcc will be fine).  I want to be able to use TCP/IP on the 
board.  Looks like Olimex makes some pretty decent looking dev boards for 
cheap, but I don't know if I should lean towards the LPC line or the SAM7. 
What say ye?

thanks for reading 

On Jul 31, 9:08 am, "Anthony Fremont" <any...@nospam.com> wrote:
> Does it even matter?  I've been doing the smaller micros (PIC, 8052, etc) in
> assembler for quite a while now, and I'd like to tinker with some ARM type
> stuff using C (gcc will be fine).  I want to be able to use TCP/IP on the
> board.  Looks like Olimex makes some pretty decent looking dev boards for
> cheap, but I don't know if I should lean towards the LPC line or the SAM7.
> What say ye?
>
> thanks for reading

It only matters if LPC or SAM7 have the right combination of
peripherals that you will think you will need.  I personally use
analog devices and st micro ARM's.

Anthony Fremont wrote:
> Does it even matter?  I've been doing the smaller micros (PIC, 8052, etc) in 
> assembler for quite a while now, and I'd like to tinker with some ARM type 
> stuff using C (gcc will be fine).  I want to be able to use TCP/IP on the 
> board.  Looks like Olimex makes some pretty decent looking dev boards for 
> cheap, but I don't know if I should lean towards the LPC line or the SAM7. 
> What say ye?
> 
> thanks for reading 
> 
> 

I've used both and now prefer Atmel. I found the interface to internal
flash on the LPC's to be a bit quirky, and the SAM7's UART has more
features. It's really splitting hairs. If you find a chip with the
right set of peripherals, then use it.
Most of my code can be ported between SAM7/LPC with minimal effort.
It's nice to have a second source ;)

</A>

On Jul 31, 9:08 am, "Anthony Fremont" <any...@nospam.com> wrote:
> Does it even matter?  I've been doing the smaller micros (PIC, 8052, etc) in
> assembler for quite a while now, and I'd like to tinker with some ARM type
> stuff using C (gcc will be fine).  I want to be able to use TCP/IP on the
> board.  Looks like Olimex makes some pretty decent looking dev boards for
> cheap, but I don't know if I should lean towards the LPC line or the SAM7.
> What say ye?
>
> thanks for reading

There is a comparison of many ARM7 devices at www.gnuarm.com.  Go to
the Resources page and click on the Device Comparison link.  You will
find a table with many devices although the table is not up to date
and there are several new devices that are not included.

I agree with the others that the differences are small compared to the
similarities.  Both Atmel and Philips have a wide range of peripherals
available in many flavors of their devices.

Other than the details of the peripherals, the main difference between
the SAM7 and the LPC2 lines are the speed of the CPU and the DMA.  The
LPC parts run a bit faster with the SAM7 requiring a wait state at
speeds above 30 MHz, IIRC and top out at 55 MHz.  Some LPC devices
rurn at up to 70 MHz for inline code with no wait states, although
branches require a flush of the memory buffer.  The SAM7 parts can use
DMA for peripheral access while the LPC must use program controlled I/
O.

Both families are very low power and all of the others are around
double these power levels at full speed.  In fact, these 32 bit
devices are thriftier than many 8 bit devices when normalized for
speed!  At very low speeds the other devices use *much* more power
than either of these two.  Someone has said that they found the SAM7
parts to run at lower power than the LPC, but I don't see that
reflected in the data sheets.  I have not worked with the LPC parts
myself so I can't say.

On the other hand, I don't think any of the ARM families will operate
at less than 3.3 volts for I/O, although the cores can run directly
from a lower supply saving even more power.

So to say which ARM family is better, you need to define your
requirements and see which has strengths that match your
requirements.

On Jul 31, 11:55 am, Anders <nos...@spam.nope> wrote:

> Most of my code can be ported between SAM7/LPC with minimal effort.
> It's nice to have a second source ;)
>
> </A>

Really? Don't  SAM7's and LPC's peripherals have different software
interfaces? DMA is a big one.

> Other than the details of the peripherals, the main difference between
> the SAM7 and the LPC2 lines are the speed of the CPU and the DMA.  The
> LPC parts run a bit faster with the SAM7 requiring a wait state at
> speeds above 30 MHz, IIRC and top out at 55 MHz.  Some LPC devices
> rurn at up to 70 MHz for inline code with no wait states, although
> branches require a flush of the memory buffer.  The SAM7 parts can use
> DMA for peripheral access while the LPC must use program controlled I/
> O.

Just to add to that, I think also the SAM7 parts have a memory interfaced 
designed predominently for efficient THUMB mode code.  They will be slower 
in ARM mode.  Someone correct me if this is wrong.

I particularly like the DMA interface on the SAM7 peripherals.  It frees up 
a lot of CPU cycles for you.

-- 
Regards,
Richard.

+ http://www.FreeRTOS.org
A free real time kernel for 8, 16 and 32bit systems.

+ http://www.SafeRTOS.com
An IEC 61508 certified real time kernel for safety related systems.

steve wrote:
> On Jul 31, 11:55 am, Anders <nos...@spam.nope> wrote:
> 
>> Most of my code can be ported between SAM7/LPC with minimal effort.
>> It's nice to have a second source ;)
>>
>> </A>
> 
> Really? Don't  SAM7's and LPC's peripherals have different software
> interfaces? DMA is a big one.
> 

Sure - the BSP/HW abstraction module takes care of that, and relative
to the rest of the code that's a tiny piece and actually pretty simple
to rewrite. But you're right, the details of direct hardware access
is obviously different, although the concepts are very similar and if
you've done it once, porting the BSP is not that difficult.

Granted there may be situations where you have extreme requirements
on timing, and need to play around with single instructions to make
things work, but I have never had such requirements. That little ARM7
at 47MHz is plenty fast for my apps :)

</A>

"FreeRTOS.org" <noemail@address.com> writes:

> Just to add to that, I think also the SAM7 parts have a memory interfaced 
> designed predominently for efficient THUMB mode code.  They will be slower 
> in ARM mode.  Someone correct me if this is wrong.

I guess this makes sense, since critical ARM mode code can always go
in RAM, and is likely a small part of the program.

> I particularly like the DMA interface on the SAM7 peripherals.  It frees up 
> a lot of CPU cycles for you.

-- 

John Devereux

> I agree with the others that the differences are small compared to the
> similarities.  Both Atmel and Philips have a wide range of peripherals
> available in many flavors of their devices.
>
> Other than the details of the peripherals, the main difference between
> the SAM7 and the LPC2 lines are the speed of the CPU and the DMA.  The
> LPC parts run a bit faster with the SAM7 requiring a wait state at
> speeds above 30 MHz, IIRC and top out at 55 MHz.

The SAM7A3 is 60 MHz.

It generally does not require a waitstate if you run in Thumb mode,
and if  you need a few routines running at high speed, then
you can copy it to the SRAM, which has slightly higher
bandwidth than the LPC flash and is more predictable.

If you start to do heavy communications, then the DMA is your friend.
An ARM without DMA on the SPI cannot do too many Mbits before
the CPU is using all its MHz on SPI interrupt routines so even
if the LPC is running at higher MHz, the SAM7 will maintain
its performance even with heavy communication activity.

> Some LPC devices
> rurn at up to 70 MHz for inline code with no wait states, although
> branches require a flush of the memory buffer.  The SAM7 parts can use
> DMA for peripheral access while the LPC must use program controlled I/
> O.
>
> Both families are very low power and all of the others are around
> double these power levels at full speed.  In fact, these 32 bit
> devices are thriftier than many 8 bit devices when normalized for
> speed!  At very low speeds the other devices use *much* more power
> than either of these two.  Someone has said that they found the SAM7
> parts to run at lower power than the LPC, but I don't see that
> reflected in the data sheets.  I have not worked with the LPC parts
> myself so I can't say.
>
> On the other hand, I don't think any of the ARM families will operate
> at less than 3.3 volts for I/O, although the cores can run directly
> from a lower supply saving even more power.

SAM7L is soon here and will support low voltage I/O.

>
> So to say which ARM family is better, you need to define your
> requirements and see which has strengths that match your
> requirements.
>



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

In article <13aud1rfiloof27@news.supernews.com>, Anthony Fremont 
<anyone@nospam.com> writes
>Does it even matter?  I've been doing the smaller micros (PIC, 8052, etc) in
>assembler for quite a while now, and I'd like to tinker with some ARM type
>stuff using C (gcc will be fine).  I want to be able to use TCP/IP on the
>board.  Looks like Olimex makes some pretty decent looking dev boards for
>cheap, but I don't know if I should lean towards the LPC line or the SAM7.
>What say ye?
>
>thanks for reading
LPC  see

http://www.embeddedinternet.org/embedded/default.aspx

A book on the tcp/ip (with source code) based on an IAR/Olimex kit using 
LPC parts.

Caveat
1 I sell IAR kits (and Olimex and many others but only inthe UK)
2 I know the author of the book


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/