EmbeddedRelated.com
Forums

LPC or SAM7?

Started by Anthony Fremont July 31, 2007
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 \/\/\ \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/