Heresy! Let's kick it up a notch - ARM vs AVR

Go To Last Post
56 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Taking a breath, he writes, in the AVR forum...)

So I've long been an AVR devotee. Used retched PICs briefly, then AVRs for years.

Lately, I've been working with ARM7's the low end of the ARM processors. Yes, there was much to learn but no more than as an AVR novice, for the same functions on both. But the typical ARM7 has far more capability than the mega128x.

So there's the costs-more scenario. Yes, if a $1 or $3 AVR does the job, there's no debate. But compare the prices of top of the line mega128, 1280, etc. They're as much or more than bottom of the line ARMs. And there are perhaps 10 vendors for ARM chips = more competition = lower cost and hopefully, more user benefits due to competition.

http://www.mouser.com/catalog/63...
and
http://www.digikey.com/scripts/u...
and
http://www.mouser.com/Search/Ref...

And it seems to me that NXP (ex-Phillips) LPC ARMs are 25% or so cheaper than Atmel's ARMs. Maybe not, I did a quick look. The NXP LPCs seem to be very omnipresent though.

and the cottage industries like Coridium.com, SparkFun's reselling, LPCtools.com, Olimex, et al.

It's not all about cost, of course.

I've done C code for the NXP LPC2103 and 2106 of late. Easy. WinARM (GCC) is fine and with Eclipse as the IDE, it's OK. Better, the 32KB limited but free and really great IDE/compiler from IAR. I wrote a clean dual-UART interrupt driver for the FIFO-based UARTS, and a Timer interrupt routine. Hooked UARTs to C lib standard I/O. Easy.

It *is* nice to not fight the dual address space as on AVRs and other Harvard processors, esp. with GCC that has kludges like printf_P() and PSTR() macros. Sans Harvard Arch, we just have one flavor of pointers. And in debugging, you can download to RAM instead of flash, if you want.

Some/most ARMs run CPU clocks faster than flash cycle time, but deal with it by doing 64 or 128 bits at at time fetches from flash.
It's also nice to have, relative to AVRs, gobs of on-chip RAM.

I found that in thumb mode, the code is 20-30% smaller for a minor speed penality, as compared to the full 32bit ARM mode. And 32bit registers everywhere sure are nice.

I adapted FreeRTOS to the LPC2103 (32KB flash, 8KB RAM, one address space). Only about 6KB including the C library for printf() and malloc() and my serial and timer drivers and a demo program. Most of that flash is for printf() and friends.
==========

Since Atmel is in the Arm game, I though I'd bring this up here.

What the ARM world lacks is an "ARMfreaks.net". The embeddedRelated.com group for ARM fans is a poor substitute for this forum and its great support net.

In closing, I'd like to say: "I bet I get in trouble for posting this!"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If ARMs came in through-hole versions and you could get a USB programmer for them for $30, the hobbyists would be all over them!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Steve,

I have been doing some investigation in "what to move to next", so found your posting quite interesting.

A couple of questions:

Have heard that the tools to do proper work on the LPC series are quite expensive. I think it was to do with the debug interface, ie not open source. True?

Also, issues about real-time performance. Either it was related to the architecture used on the ARM (no MMU?) or maybe it was comments made by people running LINUX on ARM chips to the effect that you need kernel (patches?) that help get around limitations.

Are there are such issues with FreeRTOS on the LPC2103?

Appreciate your comments.

davef

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

davef wrote:
Steve,

I have been doing some investigation in "what to move to next", so found your posting quite interesting.

A couple of questions:

Have heard that the tools to do proper work on the LPC series are quite expensive. I think it was to do with the debug interface, ie not open source. True?

Also, issues about real-time performance. Either it was related to the architecture used on the ARM (no MMU?) or maybe it was comments made by people running LINUX on ARM chips to the effect that you need kernel (patches?) that help get around limitations.

Are there are such issues with FreeRTOS on the LPC2103?

Appreciate your comments.

davef


tools: No, as I said, GCC exists for ARMs and it's wrapped in several different IDEs or no IDE, just make files (yuck). But the real deal is the free IAR compiler for up to 32KB of code. That's more than you'd think, as I summarized with FreeRTOS' size. ImageCraft has a low cost one too. Rowley has an IDE for GCC but it's overpriced, IMO. Keil's compiler and IDE are good but costly; only 16KB limit in free version.

As to no through-hole ARMs: yes. But things like the $39 LPC2103 from Coridium and similar from Olimex and Embedded Artists, and ETT via Futurlec are low cost and have prototyping areas, despite the SMD ARM.

Some of the higher up ARMs have MMUs. And gee, I've read about a skinny Linux sans MMU for the low end. I personally don't want/need Linux on an embedded processor. I can play with it on an old-dog AMD or Pentium motherboard. But lots of folks do lots with embedded Linux.

FreeRTOS on the 21xx is just a preemptive or cooperative RTOS, or both. I don't think there's an MMU version. But there are lots of OSes for ARMs, some free.

The LPC21xx chips seem to all come with a permanent serial port bootloader pre-installed, at least from NXP. I think Atmel has something similar.

A JTAG for these, if you need that elegance, is kind of pricey, like $200 or so, such as J-Link. There's an open source one called OCD.

Check this one out: $60 for an LPC2148 (512KB flash) based board with USB, memory card reader, and so on. And free source code!
http://www.sparkfun.com/commerce...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Another differentiating issue, as far as I can tell, is power consumption. I have not found any ARM chips which can go as low as the picopower AVRs, or have I missed something?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dtlinker wrote:
Another differentiating issue, as far as I can tell, is power consumption. I have not found any ARM chips which can go as low as the picopower AVRs, or have I missed something?

probably quite true. I do see some "low power ARMs". But you know, lots of GPS Nav, cell phones, PDAs use ARMs. But low power consumption can mean much lower than even these in some embedded use cases.

Of course, the power (battery?) consumption is given by the processor clock speed - which today is often programmable on the fly- and sleeping CPU or sleeping I/O port strategy. The ARMs I've worked with all have a phase locked loop CPU clock oscillator so that the crystal freq. is much much lower, e.g., 20MHz crystal and 60MHz CPU.

Atmel is claiming specialization in low power ARMs. I'm not learned in this though...
http://www.atmel.com/dyn/product...

They talk about "SAM7L", the low power (small memory) chips
http://www.atmel.com/products/AT91/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
So there's the costs-more scenario. Yes, if a $1 or $3 AVR does the job, there's no debate. But compare the prices of top of the line mega128, 1280, etc. They're as much or more than bottom of the line ARMs.

I wonder how you calculate the costs.
On my experience the cost of the microcontroller was fully irrelevant, since the additional costs are bigger.

An ARM pcb was many more complicated and expensive as the AVR pcb.
Furthermore the ARM can not be battery powered, since it has no wide VCC range (AVR: 1.8 - 5.5V)
It need always one or two high precise voltage regulators.
Also the output stages can not drive the same load current as an AVR.

So in the sum the ARM costs are always higher.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If ... you could get a USB programmer for them for $30

$20.95 = http://www.sparkfun.com/commerce...

However I'd recommend a USB interfaced one - they start around the $50 mark.

I just took delivery of a $49 Flyswatter:

http://www.tincantools.com/produ...

But to be clear this is not just a programmer. It's also a JTAG debugger so in that sense I guess it offers similar functionality to something like the Dragon.

Cliff
(also a closet ARM fan - but for different applications)

EDIT actually a $3.31 LPC2101 at Digikey offering 8K program and 2K SRAM compares with something like a $3.48 mega88 I guess. (and it does 70MHz!)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cortex ARM chips from Luminary come in SOIC packages which are quite easy to work with. A simple parallel port JTAG interface can be built very cheaply, and works very well. I've designed a PCB for one that is in the LPC2000 Yahoo Group files section.

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I hope that the price of high end AVRs will go down.

hello world!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I hope that the price of high end AVRs will go down

Well the actual strategy (with the Xmegas) seems to be more goodies for the SAME money in fact.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:

...
Furthermore the ARM can not be battery powered
...

The iPod is ARM-powered. Many cell phones too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The iPod is ARM-powered. Many cell phones too

Yes but they have the cost of regulators in them - that was Peter's point

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Davef-> there's many flavours of ARM. We have microcontrollers and microprocessors - the defining difference is that microcontrollers have the ram and flash built in whereas the microprocessors have external flash and ram. For Linux you need a few Mb of flash and ram, so you usually use an ARM9 style microprocessor. Note that the AVR32 comes in both types also. The microprocessor devices usually have a cache, much higher clock speed and maybe a MMU.

I'm playing around with the SAM7S at this very moment. You want to be able to read datasheets pretty well as the peripherals are generally a bit more complex, so beginners might want to start with the 8bit AVR first up, get a bit of experience, then move up (as it were). The main reason I'm using the Sam7s is that it has the SSC that can talk to a codec chip so I don't have to use a DSP.

I've used the NXP chips - the earlier ones had some nasty peripheral bugs with the timers and uarts. I've also used the Luminary chips - their timers are crappy - no prescaler when in capture mode! Useless when running at 50MHz and only 16bit. Their ethernet MAC has only a 2K buffer - easily overrun on a busy network unless you spend all your time servicing the ethernet. 8K would've been much nicer. They have added DMA on a couple of the higher end parts that would get around this issue.

Also, be sure to read the errata on the chip you want to use - most of these ARM devices have some interesting quirks - usually affecting the very thing you want to do!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MicCYB wrote:
I hope that the price of high end AVRs will go down.
The xmega's (while not yet shipping) are quoted with a significantly lower price than current high-end AVRs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel has announced the AT91SAM3 line of 32-bit ARM microcontrollers (see http://www.atmel.com/dyn/corporate/view_detail.asp?ref=&FileName=ARMCortexLicense_6_24.html&SEC_NAME=Product). They will be based on the ARM Cortex-M3 core that is designed for embedded applications and includes power management capabilities.
Other manufacturers are already using this core in their microcontrollers and marketing them as 32-bits for less than $1 (in quantities).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wish I knew more about Cortex-M3 - there are several vendors of this ARM-like chipset and the compilers seem to support it. But it is not in the mainstream (yet?) of ARM-TDMI based chips.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With regards to power consumption, stevech said

Quote:
Atmel is claiming specialization in low power ARMs. I'm not learned in this though...
http://www.atmel.com/dyn/product... ... rt_id=4293

I am also not familiar with ARMs, but looking at the data sheets for that device, it looks like the lowest-power mode that can be awakened from an on-chip clock is "Backup mode", which consumes 3.5 uA typically.

For a mega168P, the equivalent mode is "Power save mode", which consumes 0.8 uA.

In Active mode at 1 MHz, the ARM consumes 0.5-0.7 mA, while the mega168P consumes 0.3 mA.

My conclusion is that the differences are not huge. The deciding factor for me is the tools for development, and of course the fantastic resource represented by AVRFreaks! :D

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Other manufacturers are already using this core in their microcontrollers and marketing them as 32-bits for less than $1 (in quantities).

I looked at the Luminary "Cortex for $1" offerings briefly. My impression was that (at least at the models I looked at) micro >>controller<< features seemed to be a bit lacking.

But the Atmel AT91SAM7 models and the Philips LPC do seem to have a full complement of features that we might use in an AVR8 design, more features such as DMA, and attractively priced. IMO there is now a definite overlap between ARM7 and AVR8. Xmega adds some of the features (DMA, DAC, 12-bit fast A/D, interrupt priorities, more USARTs and timers, more clocking options) but still won't have the raw crunch of the ARM7.

Those closer to the LPC will need to comment, but I don't think you have as many low-power options as with an AVR8 P or V chip.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tools for LPC ARM7TDMI's: there are NONE needed.. You just connect the ARM's UART to the PC properly, and program away all you want... If you need/want a JTAG interface you can build one for less than 10$, it's a standard interface. My biggest feud with Atmel has always been their tendency to make things more complicated than they truly need to be in terms of ISP.

I don't think it's fair to compare ARM7's to AVR's, they are different animals. Xmega is probably closer to the Cortex M3 devices, operate in the same range of clock, and have similar peripherals.

As far as code complexity, look at it this way. The AVR instruction set has +-120 instructions. The ARM7TDMI (ARMv4T architecture) instruction set has 32 instructions, with conditional execution flags for each, all 32-bits, and word-aligned. If you need to manage more 16-bits data, you have the THUMB instruction set available as well.

If you intend to process mostly 8-bits data, the ARM is probably not the best horse for the job, as it means you will lose about half of all the memory you will use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also the Cortex M3 (ARMv7 architecture) was originally designed as a trimmed down ARM core, with lower power usage, lower clock rate, etc.. Luminary was the first to offer a Cortex core in their chips, and honestly I have never used ANY of their product... You can bet your sweet arse that when NXP and Atmel start making them for good, they will be much more attractive...

There is no denying ARM has more subtilities than AVR for a lot of stuff.. For example programming in ARM you want to avoid conditional jumps at all costs if you run the program from flash, as each time one occurs the flash accelerator (usually a 3 or 5 stages pipelined cache) has to reset, and you will lose some valuable clock cycles. But then again you can simply run your program from RAM at full speed with no worries, which you can't on AVR....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK this is my input.
Price for dev. board: You can buy a LPC2103 on a PCB for $7.5 and the programmer is $17. (this is DigiKey's price). So it's cheap to get started !
When you first learn how a ARM works it's easy to use.
The hardware is better (for most parts) to time and lock values so interrupts can be handled in C, (On a AVR I normaly have to write IRQ's in ASM).
The down side
Like Peter I will say that the big voltage range and farly robost I/O compared to the ARMs (I know of) is is where the AVR is better.
The easy EEPROM use on the AVR most ARM's don't have EEPROM.

I have not used the cortex M3 but that will take a big part of the high end AVR and ARM7 marked when the big players like NXP. get's into the game.
In the beginning the compiler tools was a problem, but that will be fixed.

Jens

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a lot of the thrust of development of the Cortex cores seems to be so they can be used in FPGA's I wonder if we'll see a lot of folks moving towards total SoC FPGA solutions?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sparrow2 wrote:
OK this is my input.
Price for dev. board: You can buy a LPC2103 on a PCB for $7.5 and the programmer is $17.

Jens

where is that $7.5 (US?) dev board?? Cheapest I've seen is Coridium's $39 LPC2103 board and Embedded Artist's "stamp" - a 40 pin DIP package, using a '2106.

Programmer: I've been using the built-in serial port bootloader and the freeware loader for PCs. I have JTAG too, but not using it yet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech and kartman,

Thank you for your specific comments. The experience of others in moving to the 32bit world is really valuable.

davef

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
As a lot of the thrust of development of the Cortex cores seems to be so they can be used in FPGA's I wonder if we'll see a lot of folks moving towards total SoC FPGA solutions?
Hasn't this been the next big thing for the past 20 years?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

As a lot of the thrust of development of the Cortex cores seems to be so they can be used in FPGA's I wonder if we'll see a lot of folks moving towards total SoC FPGA solutions?

It sure seems attractive. I even went to a Xilinx class on developing systems usign their microblaze softcore. It really is pretty cool...but, when it comes right down to it, it seems like the cost is just way too much. I have found that using an FPGA with a microcontroller (I have used both AVRs and ARMs for this) is by far a lot less expensive than using an FPGA to do both...(and I have done one project where I used the microblaze...and I probably won't do that again).

-Jim
http://www.noniandjim.com
Analog and Digital Electronics
Music Synthesizers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it seems that Cortex M3 are faster at the excution of ISR's also, and allow a more compact code (Thumb II, IIRC), while it is cheaper through reduction of gates to do the same. It seems that the marked of the low ARM, high 8 bitties is moving towards this guys.

And Cypress plans to release some PSoC with Cortex M3 AND FPGA or CPLD embedded. A nice beast to look for when finally released.

I agree that with many 'high end' applications for the AVR big guyz, like M128 or M2560, or XMegas, are probably also suited to be done with ARM's, and probably at a lower price. So I must agree with others here that right now there is an overlaping between them.

And development tools, as well as firmware, are pretty easy and cheap to find. BTW, www.at91.com is another good forum for this ones, but it will be really difficult to beat AVRFreaks.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Due to growing popularity, shrinking costs, and multiple vendors, I've also decided it's time to move up in horsepower for minimal (if any) additional costs.

To get started, I chose the Olimex tools since I've had good luck with their JTAG programmers for AVR. These tools can be purchased from a number of distributors (SparkFun in the US).

Arm-USB-Tiny (USB-JTAG for Arm), $51.95 from Spark
LPC-H2103 (ARM7, LPC302 target), $30.95 from Spark

For the compiler/IDE, I chose Rowley Crossworks. Crossworks has an interface to the GCC C compiler for ARM. Hopefully, this will ease the pain of using GCC. In addition, Crossworks advertises that they will inteface with the Olimex tools. A personal license (non profit) for Crossworks is $150.

With any luck, the startup will go smoothly (yeah right). The good part is that most of my hair is already gone anyway.

I'll still be using AVR's, but next time when I'm using 99.999% of the processor's time and resources, and I'm searching through the list files to find inefficient compiler code to squeeze out another microsecond out of an interrupt, and my RAM is using "time shared" variables, THEN - I will slip an ARM into that product.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since Rowley is an IDE atop GCC, here's another to consider: YAGARTO, this being the Eclipse IDE integrated with WinARM (GCC). Freeware, but you have to spend a few hours getting its pieces downloaded and diddled just right. Doesn't use Cygwin which some argue is a big plus.

http://www.yagarto.de/index.html

I suppose it supports Atmel's ARM-TDMI products as well all the other chip-makers' ARMs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried Yagarto - ran into problems (maybe caused by myself). Since I've got Delphi loaded, it has it's own Make program - this seems to interfere with what Yagarto wants. I got bored quickly, so I'm using the
Keil UV3 front end with GCC compiler. considering I've also got the Keil ULINK jtag thingy, makes it easy for me to compile/download/debug. Downside is the Keil debugger is limited to 16K in demo mode.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There is another cheap beast that can also be used as dev board with integrated JTAG. It also cames with GCC, support programs for Windows and some firmware. The worse part is that the JTAG can't be reused.

I mean the STM Circle product, for around 30€ with an ST CortexM3, three axis accelerometers, USB, JTAG and 128x 128 colour LCD. I tested one and it was funny to play with it.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guillem,

I agree for anyone wanting to dip a toe into the ARM pond then that STM32 Circle is an amazing value for money. See:

http://www.stm32circle.com/

The most important thing about this being that it can run Pac-Man!

It's $38.57 at Digikey: http://parts.digikey.com/1/parts...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like Mouser has the STM3210B-PRIMER for a bit less cost ($36.25): http://www.mouser.com/Search/Ref...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like a nice way to get your feet wet on the arm (my feet and arms are separate, though).

I may sell my unused Raven kit to buy a new toy. Although the arm may turn out to be like the Zilog kit I bought once (pre avr)- I was so lost, I sold it after one week.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I always judge device complexity on that totally accurate guage of complexity - number of pages in the datasheet:

http://www.st.com/stonline/produ...

has 681 pages in the 11MB manual.

So fairly complex but nothing says you have to use the DMA, CAN or the USB blocks on day one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I usually get scared straight ever time I look at an arm datasheet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I always judge device complexity on that totally accurate guage of complexity - number of pages in the datasheet:

LOL.

OK, let's see how we stack up vs. modern AVR8:

"Small" device--Mega88 family: 374
"Medium" device--Mega324P family: 436
"Large" device--Mega640 family: 448

So let's call ATmega at about 400 pages (of course the bigger devices will have bigger datasheets since there are more pins, more timers, more interrupts, and the like but the "complexity" of the subsystems is about the same).

For the Xmega, we need the family document plus the model datasheet.
A family plus ATxmega64A1 : 375 + 82 = 457. A big asterisk, 'cause there is a lot of stuff especially Electrical & Typical characteristics that isn't fully shown yet, so let's say 500 pages.

For Atmel's ARM7TDMI microcontroller offerings, I'll use AT90SAM7S as "closest" to AVR8. That datasheet (rev. H) is 733 pages. But wait--that doesn't tell you anything about the ARM core, and you need another 284 for ARM7TDMI tech ref, or 1000+ total for the whole family.

Using your metric, moving from AVR8 to ARM7TDMI or Cortex is then ~2x more complex. ;)

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

curtvm wrote:
Looks like a nice way to get your feet wet
I decided to take the plunge and just ordered one from Mouser. In some respects, it reminds me to being introduced to AVRs via the Butterfly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I usually get scared straight ever time I look at an arm datasheet.

Which seems to be the common barrier for a lot of people moving from 8bit to 32bit. Sure (apart from the bottom end like the $1-$2 LPCs) these SoC's tend to have "more on them" as they are bigger devices than your average AVR but I guess anyone looking at the mega640..2561 datasheet (4MB, 449 pages by the way!) for the first time might think that looks daunting yet we know that to get an LED to flash off one of the 100 pins on that device is not really any more complex than getting it to flash on one of the 8pins of a tiny25 (2MB, 220 pages ;))

There's no reason why the "simple" use of an ARM, MIPS or AVR32 or whatever should really be any more complex. On the whole you can forget about spinning up PLLs and setting DRAM refresh or whatever in the start up code - that might appear daunting - most of these chips will power up and clock enough to flash an LED pretty much the same as the simplest 8 bit micro.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What confused me more when I begin to play with AT91SAM7S64, was the startup sequence and the complexity to start the simpliest of the tasks: blink a LED. That forces to use an start-up program that prepares the internal PLL and the internal Interrupt controller, then initialize the paralel peripheral.

And all registers are 32bit wide, and all peripherals have more registers, and usually there are trhee of them for each purpose: one to set the bit, another one to clear the bit, and the last one to read the bit status.

Even in this way, I had more troubles switching from AVR's (mostly M64 and M128) to Cypress PSoC than to ARM's.

Definitively, ARM's are not the best microcontrollers to start in this nice business, but for someone experienced with 'big' AVR's, that should be not really difficult.

BTW, PIC users claim that the reduced instruction set is a key point for the 'simplicity' of the microcontrollers. So by their point of view, ARM's would be more simple than AVR's... Well, PIC programmed in ASM means a totally different way to think, huh? ;)

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having just been down the noobie to ARM7 road...
Of course, you start, as with the AVR, by running and embellishing example code.
Setting up the PLL is at first daunting, but in hindsight, easy.

Writing the dual-UART ISR for me was a struggle, not because of the ARM, but because of the FIFO-based UART - same as used on PCs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The lenght of the datasheet is not a good metric arcoss companies. Looking at standart parts available from more than one company, datasheets are quite different in length. A bigger problem is the length of the errata section, which can be really long and still incomplete for some chips.

The initila setup of PLL can be a little confusing, but you have to find out only once and much is done by the compiler anyway. After that its much more important that things are consistant and you don't have to learn about 5 slightly different types of timers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The lenght of the datasheet is not a good metric arcoss companies.

LOL -- take THAT, Cliff.

Quote:

A bigger problem is the length of the errata section

Take THAT, Xmega.

;) Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
LOL -- take THAT, Cliff.

I kind of understand the point. A device I'm working on at present has a 3,000 page datasheet that is 22MB but if it were actually documented with the clarity and detail of an Atmel datasheet that would probably have been more like 50MB and 6,000..7,000 pages!

(it's an ARM11 based TV decoder with 5 other DSPs on the same chip of silicon)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, IIRC, AD microconverters ARM based have a pretty sparse datasheet. As well as pretty sparse peripherals or goodies like Interrupt controller and DMA.

@stevech: DMA for USART's is a pretty nice feature once you have experience with them. Switch back to AVR's to do the same job without DMA becames a pain if you need high baudrates. And I didn't find it too difficult to use.

@Cliff: now that datasheet that you explain, and that's not to mention the chip of silicon itself, would be something to put into a nice glass box with some light and be shown as an Art Piece (well, isn't that called 'State of the Art'? ;)).

@Kleinstein: I also agree with you about datasheet length across different companies. And I would add that even across the same company, it couldn't be compared. As an example, compare the datasheet for ATmega64 (by Atmel Norway) with AT91SAM7S64 (by Atmel Rousset, IIRC).

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In this list, Atmel has a good showing
http://www.onarm.com/devices/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just to note that's nowhere near being a definitive list. In fact I'm not sure uder what criterion it's been compiled. It says "available microcontrollers" so maybe that's the intention but given that ARM is just a core and so every piece of silicon is a core plus some support blocks where do they draw the line between calling that a "microcontroller" and (I guess) a "System on Chip" ? I'd almost be moved to call some of the large AVR8s (even) an SoC, especially the big Xmega's so like I say, I wonder where the list compiler drew his line?

According to this page:

http://www.arm.com/products/lice...

there are, for example, 249 silicon fabricators that licence the ARM9 core.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had a chuckle regarding the Sam7's - I'm working on one at this very moment and had just read up about the PLL and are tweaking the divisors to suit. Yesterday was the struggle with the SPI and later will be the SSC interfacing with a CODEC. One pleasant surprise was the receive timeout on the USART. Saves using a timer for Modbus RTU protocol.

You need to be able to comprehend the datasheet to get anywhere with the ARM devices. AVRs, like the classic 8051's have quite straightforward peripherals and a simple interrupt structure. As others have mentioned, it helps to have some experience under your belt.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
struggle with the SPI

Not looked myself but is SPI on a SAM7 radically different to SPI on an AVR8 then?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, it is totally different. It allows for different Chip Select lines that can be automatically selected from memory, so you can DMA different streams at once at different SPI peripherals. Of course, that means that the RAM should store the data and the 4 bit adress (it allows for even multiplexed peripherals, up to 15) for the SPI that should be adressed. Definitively more features with more complexity. And 32bits of RAM for every data to send (up to 16 bits, though).

SPI also have other different modes to work, that have lower RAM requirements, but more frequent reprogramming it.

And for ModBus data streams, DMA + timeout IRQ is a wonder. Few registers setups, and the peripheral does all the job. Meanwhile, with any ATmega, one needs three interrupts (UDRE/TX for sending, RX for receving) and also a timer.

Communications with AT90SAM7 are pretty nice, fast, and with light CPU load thanks to the DMA. That is quite a 'sexy appeal'.

Guillem.
"Common sense is the least common of the senses" Anonymous.

Pages