avr vs other uC

Go To Last Post
69 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I have general question regarding AVR. Why it is better to use them instead of Microchip of Freescale uC. I am really convinced to avr but I don’t have much experience in other uC and I cant give good explanation. So what do you think?

All the Best
Michal

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

I'll start the ball rolling with "great development tools"

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

If the project manager walks in your office and says 'Spock... here's a spec for a program. The hw guy has done the processor selection. Its a PIC. Start programming!' You salute, click your heels, say 'Yes Sir!' and download the PIC datasheet.

Imagecraft compiler user

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

hehe I know the rules in office. I rather need this explanation form my ENG degree.

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

Mmmm, another uC war...
I'm not really experienced with many uC architectures, mainly trhee: AVR (ATmega 12/32/64/128), ARM (AT91SAM7S/X) and Cypress PSoC.
As far a I can say, everything is up to the application. I mean that for a simple tone generator that can be done with a simple 555/556, you probably would choose a different uC than if you need to perform some audio processing or an embedded web server.

But given an application that can be done wiht about many different uC, then you have more different reasons to choose: your knowledge, C vs Assembler, timers, easy to find, speed, peripherals. In my opinion, the biggest reason to choose between different architectures is the knowledge/experience with them. So since I know ATmegas, I would develop faster an application than if I should learn a new uC like microchip (well, I know a little about them, when I programmed them in assembler, probably the main reason why I don't like them).

If you are new to uC, and you are a hobbyst, then my reasons to choose AVR's are this: They are really powerfull and perfectly capable to do many math and other operations that would need some 16 bit uC. They have a big range of peripherals/models/varitey, etc. They are easy to program in assembler and in C (no banked registers, etc). The tool chain is really cheap, powerful and easy to download/build. It's not too difficult to learn to program (although probably PIC's seem easier since they have less instructions). And there is a really huge solution/knowledge pool: this magnificent forum.

I would encourage you to search through this forum about this kind of questions. It's plenty of them, specially AVR vs PIC, and AVR vs ARM.

Guillem.

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

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

Oh can I add a second one - "they are bloody good value for money"

(Atmel's key skill is in fact flash arrays which means they can deliver MCUs with relatively large flash arrays for virtually peanuts)

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

Hm…What is the MIPS/MHz ratio in other similar uC?

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

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

Are you going to be a Journalist? I think some universities near me also give a degree in Electronic News Gathering

Imagecraft compiler user

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

Quote:

Hm…What is the MIPS/MHz ratio in other similar uC?

https://www.avrfreaks.net/index.p...
http://www.maxim-ic.com/appnotes...

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

Ok, maybe it was really stupid thing to ask this question. I am also convinced that what is better isn’t realy the case. Your knowledge and ability to develop the device fast, tells you what to chose. I have chosen AVR but I was asked why and I thought that maybe there were some obvious reasons.

Thank you all for replays and for links. Sorry I didn’t look for them before asking.

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

spock wrote:
hehe I know the rules in office. I rather need this explanation form my ENG degree.

so let me get this straight..you have a Uni course that asks you to explain why AVR micros are better than Freescale or Microchip micros? No further specifications or criteria? and you need this for your degree?
in humor... do you attend AVR University? :shock:

considering the large number of micro architectures each of the three vendors you mentioned offer, surely the course question narrowed this down to a specific micro like AVRxx vs PICxx vs Freescalexx ??

the only context I would think this question might be relevant in a Uni course would be to get the student to "learn" to compare architectures of specific micro vendors pros and cons for a specific app or possibly to illuminate where one arcitecture might be better than the other for a set of apps...
someday you may have an employer who asks you to do a very similar analysis in selecting the micro for the project.."learning" how to do that is a very important skill for an engineer as the future project and the viability of your employer will be at stake....at the very least you need to "learn" this skill to wade thru the BS the vendor's FAE will tell you....many an engineer has failed when designing in vaporware!

again in humor...did you pose the same question on a Microchip/PIC or Freescale/xx forum? 8)

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

Quote:
again in humor...did you pose the same question on a Microchip/PIC or Freescale/xx forum? Cool

No I did not. My thesis is about building acceleration measurement device and providing storage on mmc card. And I have to explain why avr but I think that I already know the answer.

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

You are asking about 'System Engineering' which is what engineers do. By the time someone with money has decided he wants to build a gizmo and hire engineers, he has to tell them what he wants and about how he invisions it working. This is the 'requirements'. Usually, he will want it real cheap, real reliable, and real soon. Sometimes its tricky guessing how much processor you need.... you'll look pretty silly if you say you need 32k of rom and then the final program fits in 16k.... you just wasted the difference in 10,000 processors. You'll also look silly if the program doesnt fit in 32k. Managers are always worried about risk... one way to make sure a programmer can actually get the program written is to pick a processor that you have seen him write a program for already. Don't assign the new guy right out of school to the complicated project with the complicated processor with the complicated real time operating system unless there is some old guy that will bail him out when he messes up.

Imagecraft compiler user

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

Cool. I am going to write my thesis about a device I designed, which basically dumped a file out of a SD or MMC card to a serial port.

I chose AVR for this because I was already familiar with it and our products have already a lot of AVRs, so basically I just had to pick one AVR out of the few AVR types we had in stock. No other reason. It would have been crazy not to select AVR and learn everything from beginning with other microcontrollers, like tools, compilers, debuggers, programmers, etc..

- Jani

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

spock wrote:
Quote:
again in humor...did you pose the same question on a Microchip/PIC or Freescale/xx forum? Cool

No I did not. My thesis is about building acceleration measurement device and providing storage on mmc card. And I have to explain why avr but I think that I already know the answer.

ahhh..the app reveals itself...knowing that, a Freescale FAE might give you some relevant reasons why a Freescale device might be better choice! 8)

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

Quote:
Cool. I am going to write my thesis about a device I designed, which basically dumped a file out of a SD or MMC card to a serial port.

I chose AVR for this because I was already familiar with it and our products have already a lot of AVRs, so basically I just had to pick one AVR out of the few AVR types we had in stock. No other reason. It would have been crazy not to select AVR and learn everything from beginning with other microcontrollers, like tools, compilers, debuggers, programmers, etc..

- Jani

I totally agree. That’s also my main reason.

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

Quote:

My thesis is about building acceleration measurement device and providing storage on mmc card

Why not ready-made Freescale solutions? Why not ARM, such as the ready-made boards with MMC & sample code for AT91SAM7S or Philips LPC? Why not MSP430? What kind of data throughput do you need--AVR ain't gonna burn up the bus. What kind of number-crunching needs to be done? I love my pickup truck, too, but I ain't gonna use it to haul gravel for a road-construction project.

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

Why not ready-made Freescale solutions? Why not ARM, such as the ready-made boards with MMC & sample code for AT91SAM7S or Philips LPC? Why not MSP430? What kind of data throughput do you need--AVR ain't gonna burn up the bus. What kind of number-crunching needs to be done? I love my pickup truck, too, but I ain't gonna use it to haul gravel for a road-construction project.

Lee

Probably because in my case ENG thesis is rather about making some device than using ready-made one. I also have some prototyping boards and probably I will use them before designing the final circuit.

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

Well if this would have been an one-off experiment, I would have bought some developement board (AVR maybe, I don't know). But as I needed to make a product out of this, I could not buy 200 general purpose ARM dev boards like Gumstix or Rabbit ($80 or $100 a pop + compilers etc), and still do own hardware for connectors and cards and serial ports etc, so by designing own hardware it was a lot cheaper.

So making an AVR board out of scratch is not hard, but it will shorten the developement time to use a dev board and connect whatever needed to it. I used our previous products as a dev board. Perhaps you should buy some STK or Butterfly and connect a SD slot there, and do the code there, and then either build your own hardware or just leave it at the schematic phase for your thesis.

- Jani

EDIT: Oh and in my app, the AVR can read the MMC faster than the USART can spit out data. So depending on the application, a pickup truck can be enough.

Last Edited: Fri. Apr 13, 2007 - 09:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVR for the simple reason that when you need to get a program running you can always get help here even if you might get a hard time once in a while, its all in good fun. Seriously I would have been lost without some of the help I have received here.

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

If you can create a 'requirements matrix' and show the cost and performance prediction for avr, pic and hc08, you might get a good grade. Example: need to read accelerometer at 400hz in order to capture a 200hz vibration to be analyzed... data rate is 800 bytes/sec... x collection time gives size of storage needed.... What about power consumption? Does it need to run from batteries for a long time? Wake up, sample, go bak to sleep? Do you have to select an accelerometer and a processor? Need to pin down those requirements!

Imagecraft compiler user

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

Nobody has mentioned using an 8052 or variant which i find slightly odd as it is still an industry standard and outperforms the AVR in certain respects such as bit manipulation, less restrictive addressing modes and a rather better organised and orthogonal instruction set.
modern varients from the likes of dallas,and philips are low pin count and have the same peripherals as the avr.There are c compilers such as sdcc,kiel and IAR and all the usual assemblers and emulators and simulators that you would expect.
When my boss tries to tell me what processor a particular project is going to use I tell him to get lost.
here is a forum for the 8052 and its tools at http://www.8052.com

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

spock wrote:
Quote:
Cool. I am going to write my thesis about a device I designed, which basically dumped a file out of a SD or MMC card to a serial port.

I chose AVR for this because I was already familiar with it and our products have already a lot of AVRs, so basically I just had to pick one AVR out of the few AVR types we had in stock. No other reason. It would have been crazy not to select AVR and learn everything from beginning with other microcontrollers, like tools, compilers, debuggers, programmers, etc..

- Jani

I totally agree. That’s also my main reason.

If I were you I'd write down that list as project risks and then explain that your knowledge/availability, etc represents a lower risk approach. However, you'll still need to explain why the AVR is suitable to do the job (and maybe put down some of the limitations) within the project parameters.

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

Nobody had mentioned, but Cypress PSoC would also be interesting to review, since the peripheral set is the most flexible and 'reusable' I ever saw. It allows to perform probably all the analog stuff you need within the micro, without any external ADC, amplifiers and so on. Toolchain, as its 'old' (to say something) CPU core are the main drawbacks (with the purposed roadmap leading to ARM powered PSoC with enhanced peripheral up to 16bit/16channel internal ADCs and DACs, that would became 'interesting').

At least, I would encourage you to check they're datashets, since the peripheral is something really impressive for it's flexibility and incredible applications. This is the main reason for small applications (say ATtiny powered ones) is the only uC that I would use.

Guillem.

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

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

Quote:
Nobody has mentioned using an 8052 or variant which i find slightly odd as it is still an industry standard and outperforms the AVR in certain respects such as bit manipulation, less restrictive addressing modes and a rather better organised and orthogonal instruction set.

Well, this is not a retro forum ;-)

I'm gonna keep of this flamewar, sorry

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

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

It appears to be only you who wants to start a flame war,sorry to have to tell you this but the 8052 is alive and well and used in many products,with new variants being produced on an almost weekly basis.I think its also well to point out that the standard of understanding of embedded systems design is a lot higher amongst users of 8052.com

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

Jez_smith wrote:
the standard of understanding of embedded systems design is a lot higher amongst users of 8052.com

Did you get an A in arrogance at school by any chance?

The reason you get a lot of "beginner" questions about AVRs on this forum is for the very fact that they ARE the choice of beginners. And that's because they are very easy to program due to lots of great dev tools (hardware, software, pre-built modules, etc.) available at moderate prices.

I imagine all the old luddites such as yourself are happy to remain in the stuffy old world of technology from several decades ago - so good luck to you with that on your "more informed" forum - it sounds like a really nice place!

Cliff

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

You get a fair share of beginners asking beginers questions on 8052.com as well.I didnt take arrogance at school sorry,I just think that if somebody is considering what processor to use for a particular project then they shouldnt stick to just one particular model.Its like people who use pic procesors for no disernable reason other than they are cheap.
Dont get me wrong I have designed systems using 8052's,avrMEGAs and even the good old HC08 so I dont have any particular processor that i always use.

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

Jez_smith wrote:
Nobody has mentioned using an 8052 or variant which i find slightly odd as it is still an industry standard and outperforms the AVR in certain respects such as bit manipulation, less restrictive addressing modes and a rather better organised and orthogonal instruction set.

I was using the 8052 family since back when I had to program it with switches (not a joke) and I joyfully jumped to the AVR because of all the many advances one gets from the AVR - all more than adequately discussed, actually way over discussed, in the many prior AVR versus whatever posts - some links above.

I guess since the jump was so obvious to me, that I must really be ignorant about an architecture I used for decades and What I'd like to know is how I managed to miss the superior bit manipulation, less restrictive addressing modes and a rather better organised and orthogonal instruction set. Perhaps you could take a moment to explain this in detail to help enlighten those of us who did not notice any of this.

Smiley

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

Quote:

Nobody has mentioned using an 8052 or variant which i find slightly odd as it is still an industry standard ...

Certainly a valid point. I dashed off the list above after seeing the "accellerometer" mention. A lot of "special purpose" micros have an 8051 core. danni regularly reminds us about the x51 benefits.

But--that doesn't mean I have to agree with your "conclusions". :lol:

Quote:

outperforms the AVR in certain respects such as bit manipulation, less restrictive addressing modes and a rather better organised and orthogonal instruction set.

Aah, now we have things to get our teeth into. "Outperforms"? Semantics--how does orthoganality or non-orthoganality of an instruction set mean that the more-orthoganal "outperforms"?

Yes, the x51 is CISCy. Yes, the AVR is RISCy. Yes, they WILL be different. Does that mean one is better or not better or "outperforms"? Typically meaningless as most will program in higher-level language.

Yes, the AVR is Harvard architecture. Is this more restrictive in addressing modes? Certainly different, and you can't write willy-nilly to any byte in the address space. Does that mean "outperforms" 'cause you can do load-and-go compilers and self-modifying code? [Well, you still can on AVR but you gotta do pages, and jump through other hoops.]

Bit manipulation? Perhaps. In practice I've never found it a problem. Use the CV model and allocate a few of the >>many<< AVR GP registers for "bit" variables, giving roughly the equivalent of x51 bit memory. Ouila! Problem goes away.

Quote:

modern varients from the likes of dallas,and philips are low pin count and have the same peripherals as the avr.

And there are x51 cores tucked into more niches as I mentioned. And some are really screamers, but I don't think you find screamer and peripherals and pin count and price and low power all in one package.

But let's look at the TI benchmark quoted in the Maxim study that I linked to above. x51 took more cycles to complete the benchmark suite, and roughly the same code size as the AVR. Not bad for a $2 Mega8 running at modest clock rates.

Quote:

There are c compilers such as sdcc,kiel and IAR

Are any of these a couple hundred dollars like CodeVision and ImageCraft?

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

I agree with most that has been said here, specifically when someone said that the choice of a certain architecture was due to the fact that you had already worked with it.
Even with this strong and valid argument, sometimes you have to "re-evaluate": when the architecture doesn't meet all your requirements, which are not only product features but also things like price (higher importance if bigger quantity), availability and development tools.

Edit: In school, teachers like to see arguments, reasons, of course; and Bob gave you a good advice, do a matrix, comparing a few uC families on several aspects. I think that, for your simple application, almost all (if not all) of them will fit and score equally well (maybe some architectures are more expensive than others), but then you can just pick the one you're already familiar with and state just that (in fact, that aspect is a rather heavy one).

Embedded Dreams
One day, knowledge will replace money.

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

Usually there is one 'zinger' requirement that overrides everything else.... board and processor need to be cheap, fast, low power, and something impossible like 'immune to gamma rays' or 'operate at 150 deg C' or 'has onboard XYZ interface' and this swamps out all the other selection criteria. My old pappy used to tell me 'If the only tool you have is a hammer, then every problem looks like a nail'. Hey! This project looks like a job for an AVR!

Imagecraft compiler user

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

AVR has matured to such a point that one could say "why not choose the AVR ?" rather than "why choose the AVR ?"

AVR is competitive with any 8-bit uC in most anything; performance, price, peripherials.

I looked at PIC, AVR, and Z8; AVR was the best comprimise out of those for my application.

Someone here mentioned Cypress PSOC, I have to agree that PSOC has the possibility of being the best choice by far, if you can manage to properly utilize it. I have the free PSOC eval kit and I played with it a few times. Each time I play with it I unlock a piece of the puzzle to porting my existing AVR project to PSOC.

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

Nobody mentioned the Motorola 68HC11 yet?

I've ran into this more often than a 8051 so far.

- Jani

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

The MIPS/MHZ performance factor is interesting... Dallas makes 50MHz 8051 cores, but the instructions take several clocks, so the 20MHz AVRs with 1 or 2 clocks per instruction have about the same thruput. Now if Intel and AMD can make GHZ cpus, why cant the microcontroller guys? Everyone has their own secret wafer fab process?? Back when I was using HC11s, Moto was making 200MHz 68020s... I kept asking the Moto guys why they just didnt make a 200MHz microcontroller. Its like the microcontroller division and the microprocessor division of the same companies dont talk... like the fbi and the cia dont talk.... the microprocessor guys dont want the microcontrollers to get faster and eat into their sales I guess?

Imagecraft compiler user

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

I think there is no market for higher performance micros, taken the disadvantages in account. I'm sure Atmel could design a 500Mhz AVR, but it would consume 5 Watt when running and the low power mode would be in the mA area compared to the uA's of todays AVR's.
For most applications, if you need that level of performance then you want more of everything else (Flash, Ram, etc) as well and are better off using a AVR32, ARM or something like it.

Markus

Markus

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

Quote:

Now if Intel and AMD can make GHZ cpus, why cant the microcontroller guys?

Well, you can, but us microcontroller guys won't want to pay the price(s).

[Now, Bob, I'm talking >>real<< microcontroller stuff, like $2 Mega8, not starting with Mega128 elephant like you do. ;) ]

The flash pipeline for instruction fetches seems to top out at about 50MHz. (I'm expecting to see the XMega come in a notch higher than current AVRs.) Remember that a microcontroller is under >>all conditions<< of temperature & supply voltage & clock speed--the microprocessors are going to have stricter rules than we want to live by when designing-in.

We want a near-single-chip solution. We don't want no stankin' cache chips or pipelne chips or external memory or boot memory or square inches of board space or cooling fans or heat sinks.

But Atmel has already gone at least one step further. Jez said of x51

Quote:

modern varients from the likes of dallas,and philips are low pin count and have the same peripherals as the avr.

The same can be said of ARM7, can't it? AT91SAM7S32 compared to Mega32; 'S64 and Mega64. Same price, roughly same peripheral set, ARM has lot more oomph in certain areas.

Lower pin count, look at Philips LPC against the likes of Mega8.

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

The way I see it: Engineer/Programmer talent is a big pyramid or bell shaped curve... the 3 sigma guys are designing state of the art processors and programs and getting paid well for it. There are a lot more guys in the middle that can slap an AVR on a board and make it break dance. To sell more microcontrollers, a manufacturer could cater to small designers/users... bigger customer base. If one of these turns into a 'killer app' its a win win situation. I dont think we have pushed the limits of 8 bitter capabilities yet... someone is always running out of ram or uarts... seems like atmel could double the speed of the AVR flash by fetching 2 instruction words at a time... everything else seems to run at 40MHz... cpu, ram. If there is room for 128K on the chip, who cares if its 64kx16 or 32kx32?

Imagecraft compiler user

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

bobgardner wrote:
If there is room for 128K on the chip, who cares if its 64kx16 or 32kx32?

I'm for keeping it simple! It seems that my use of embedded controls over the years has been aimed at very time critical applications.

Yes, yes, I know the assembly fans are going to jump in here and tell me to get off of the C band wagon. But I won't because, I perfer C, and that's the whole story!

I'm very pleased with the resources within the 8 bit AVR. But what I'd like to see, is for Atmel to simply increase the bit width resources within the current AVR family from 8 bit registers/10 bit ADC/16 bit timers to 32 bit registers/14 bit ADC/32 bit timers, along with a 16 x 16 bit multiply with a 32 bit result & 32 x 32 bit divide with a 16 bit result. These things, along with single cycle operation, and bumping the clock frequency to say, 40MHz or 50MHz, would add a tremendous power to the existing AVR family.

But what do I know!!!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

32 registers of 32 bits is an ARM, sparc, power pc and MIPS architecture. 680xx was 16 registers of 32 bits. Whats a pentium? 8 32 bit regs?

Imagecraft compiler user

Last Edited: Sun. Apr 15, 2007 - 05:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
32 registers of 32 bits is an ARM, sparc, power pc and MIPS architecture.

But I don't need all of the other stuff!

But then too, you don't miss what you never had! Like, how did we ever function without the internet or... electricity!!!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

You mean a real simple 32 bit micro that didnt have a complicated memory management unit or complicated 32 bit DMA channels, or a complicated 32 bit instruction prefetch pipeline with branch prediction and complicated set associative 32 bit cache memory with write through? That would be an ARM 1 architecture... I guess it was a pig or they wouldnt have tacked all that performance enhancing stuff onto it. Viagra for microprocessors.

Imagecraft compiler user

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

bobgardner wrote:
You mean a real simple 32 bit micro that didnt have a complicated... Viagra for microprocessors.

Yes!

And the AVR is a microcontroller on steroids, compared to the MC68HC11, as I'm sure you will agree!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

I guess the 1st 32 bit minicomputers like the vax and data general eclipse were sort of like that... cpu on this card, big 32 bit bus connectors to the memory boards..... IO on this card... the vax was real fast... 1 mips.... I guess a 32 bit microcontroller with no external memory bus could be built... but what could you do with a 20MHz 32 bit cpu with 32k words of instructions and 32k words of ram? (128k bytes of each?) Do we get hw floating point so we can make an mp3 player, or does that use up too much wafer space? If you have a 32 bit memory space 4 billion words) but you cant expand past 32k words, its more like a dsp than a general purpose cpu. A slow dsp.

Imagecraft compiler user

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

bobgardner wrote:
but what could you do with a 20MHz 32 bit cpu with 32k words of instructions and 32k words of ram? (128k bytes of each?) Do we get hw floating point so we can make an mp3 player, or does that use up too much wafer space?

I haven't yet used over 25KB for any AVR project that I have done - ever! THe most I''ve used with the MC68HC11 was 8KB and, that was using assembly language. And even at that, a good deal of the FLASH space in my projects is usually consumed by text being sent to an LCD or HyperTerminal. Something like I described would fit real well for the type of embedded controls projects that I seem to take on.

Hardware floating point would really be nice, especially if the result showed up within a clock cycle, or two. And Double floats would really help on some accuracy limitations that I have run into when using the standard float functions within the ImageCraft compiler.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:

You mean a real simple 32 bit micro that didnt have a complicated memory management unit or complicated 32 bit DMA channels, or a complicated 32 bit instruction prefetch pipeline with branch prediction and complicated set associative 32 bit cache memory with write through? That would be an ARM 1 architecture... I guess it was a pig or they wouldnt have tacked all that performance enhancing stuff onto it. Viagra for microprocessors.

I think I'll stay pretty much with the "near single chip" criterion. Whether it has the stuff you listed or not is pretty much immaterial if it is a great "value" in the categories below. It is like my response to Jez--what does orthoganality of instruction set have to do with "outperforms"? Same with this list.

1) Near-single-chip possible for many apps. To me, this is what makes it a great microcontroller. And deliver it at a great/reasonable price. That is why I bring up Mega8/88 in these types of discussions--it has many subsystems, lots of SRAM for an 8k micro, and is inexpensive. So you can have your MMU if you want, and your pipeline, and ... as long as it stays on a reasonable-sized chip, is inexpensive, and ...

2) Can do low/modest power apps. So can it live off a coin cell for a long time in a proper app? AVR V & P can, IMO. They can compete with MSP430 and others. They may not be the "best" in all areas but ain't bad either. And in a "normal" (non-battery) app, do they have a modest power draw so they don't become space heaters? IMO, again, AVR fits this.

3) Has enough processing power to do microcontroller apps. Is there any commercial brand/line that doesn't? If there were, they wouldn't be around for very long, right? And AVRs can hang in with the best of the 8-bitters and at least some 16-bitters. Now, some modern apps may require more crunching than the industrial apps that I do with AVRs. We often answer it here on this Forum: "No way can you do this with an AVR."

My short answer: It seems that Atmel's AT91 series satisfy most of the above. Not quite down to P-chip levels yet for 2), but much more pop for 3). And as I mentioned it seems that Philips LPC will compete with the smaller Megas as SAM7S does with the larger.

How many stages in the pipeline (e.g.) is immaterial to me. I suspect that when you put more stages into the pipeline you increase heat/power [ 2) above], add more cost [ 1)], and increase pop [ 3)].

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

I guess I need to give the ARM a good looking over. I just don't want the expense of setting up for another microcontroller - you know, development boards, compilers, programmers, etc...

I just don't want the danm thing so complicated that I think I'm using an Intel 80x88

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Quote:

I just don't want the expense of setting up for another microcontroller - you know, development boards, compilers, programmers, etc...

And that's why most of us are here, touting our AVRs! It is >>much<< easier/faster for us to do a new quick app with an AVR vs. starting from scratch with another family. We went over the hump of the learning curve a few years ago.

Now, having the "danm thing so complicated" is also realtive. Look at all the people with fuse problems on AVRs, or doing interrupts, or not having interrupt priorities, or getting times & PWM to work, or slowing down the ADC clock, or trying to get a USI to work, or ... I'll bet AVRs are "danm complicated" to them. And if you want to do 100+ ksps with the A/D or other high-speed throughput you'll just have to learn to set up the DMA channels, won't you, just as you will when the XMega comes out? Same with FP especially if some type of co-processor setup.

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

I use both, 8051 and AVR, both are almost comparable, except the higher amount of 863 different derivates on the 8051 family.

I use the Keil C51 and the AVR-GCC to program both. The code size was slightly bigger on the AVR-GCC.

On the AVR-GCC it is complicated to place tables and structures inside the Flash.
Also the AVR-GCC support no generic pointers (memory segment independent).
But the new AVR-GCC4.1.1 drives me totally crazy by destroing most of my timed operations (pulse length, interrupt disable time) by counterproductive reordering of code over volatile instructions.

On the 8051 I like the four level interrupt logic, which make it many times easier to manage the time requirements on bigger projects with many interrupt sources.
Fortunately the discontinuation of the nice P89C668 (64kB Flash, 8kB SRAM) was removed in January.

And for smaller projects I prefer the AVRs, from ATtiny25 up to the ATmega8, because no external clock and reset was needed.

Peter

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

danni wrote:
...
Also the AVR-GCC support no generic pointers (memory segment independent).

Huh? The AVR memories <= 64KB aren't segmented. So ordinary pointers to all C types work, right?
danni wrote:
...
But the new AVR-GCC4.1.1 drives me totally crazy by destroing most of my timed operations (pulse length, interrupt disable time) by counterproductive reordering of code over volatile instructions.
Peter
I make a habit of using assembly language code segments if my code timing is that critical. Any compiler is likely to change.

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

spock wrote:
Hi,

I have general question regarding AVR. Why it is better to use them instead of Microchip of Freescale uC. I am really convinced to avr but I don’t have much experience in other uC and I cant give good explanation. So what do you think?

All the Best
Michal

Cheap, fast, samples available, lots of distribution, loads of free software, tools, a good instruction set (at least 120 instructions, lots of branch), all kinds of housings, lots of features, and Harvard RISC architecture.

RES

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

AVR is simply wonderful..I love it, but I must admit that lacks something about development system...

When I see that for the MSP430 there is a dev-kit (USB) with ICE at only 20$...I ask myself...why for AVR no?

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

macomer wrote:
When I see that for the MSP430 there is a dev-kit (USB) with ICE at only 20$...I ask myself...why for AVR no?

Well, OK, it's $49 but isn't that exactly why Atmel produced the Dragon?

By the way do you have a link to that MSP430 dev system?

(MSP430 was my other potential contender when I first stumbled upon AVRs)

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

macomer will need to correct me if I'm wrong, but IIRC the $20/$0 MSP430 "dev kit with ICE" was either a purpose-built "giveaway" for 4/30 Day (kind of like the Butterfly), and/or a steep discount on a 3rd-party board (kind of like the Kanda STK200). The ICE is a standard JTAG "Wiggler" interface. AFAIK there is no killer $20 "list price" tool.

So the $50 Dragon+STK500 special compares favourably, as does the Dragon+JTAGMkII. As with TI, seminars and dev kit packages greatly reduce the price of tools. Certified developers get half off. Seminar attendance gets half off. Webinar attendance--or even non-attendance if you use the magic code--gets you half off. Seminar attendance gets you Butterflies. Seminar attendance gets you STK500s. If you are lucky at a seminar, you get one of 4 JTAGMkII as a door prize.

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

stevech wrote:
danni wrote:
...
Also the AVR-GCC support no generic pointers (memory segment independent).

Huh? The AVR memories <= 64KB aren't segmented. So ordinary pointers to all C types work, right?

No.

Generic pointers on Keil means to use all functions on every memory segment, e.g. Flash, SRAM, EEPROM or custom (e.g. I2C, SPI).

The trick was, that a third byte mark the memory type.
So no problems on using e.g. printf from Flash or SRAM.
Typically the argument string of printf should be located on Flash.

Nevertheless you can write your own functions to accept only one memory segment (memory specific pointer) to get faster and smaller code.

Generic pointers change the architecture to Von Neumann from the software developers view.

Peter

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

danni wrote:
(...)
Generic pointers on Keil means to use all functions on every memory segment, e.g. Flash, SRAM, EEPROM or custom (e.g. I2C, SPI).

Ah, so what you meant was "memory spaces".

danni wrote:
(...). Generic pointers change the architecture to Von Neumann from the software developers view.

At the expense of performance and code size. It's a trade-off.

Embedded Dreams
One day, knowledge will replace money.

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

Ah, generic pointers - would that be a run-time decision made by either in-line code each time a pointer is dereferenced?

The idea in the AVR C compilers I've used (GCC, Codevision) is that you declare the pointer to point to something in either RAM or FLASH and this permits the compiler to generate the correct code. As to library routines taking FLASH vs. RAM pointer arguments, and being transparent, this is arguably a matter of efficiency vs. too much abstraction for a humble 8 bit micro.

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

In addition to ARM, you may wish to consider looking at Si Labs. Their microcontrollers use an 8051 core but run with a max of 100 MIPS (70% of instructions execute in one clock cycle). It appears they fall between the AVR and the ARM in terms of performance. Has anyone worked with them before? They look very nice and I am very interested in trying them out.

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

@Theusch/Lee:

For 'near single chip solutions' close to $2 ATmega8 I think Cypress PSoC (CY8C27 16KB also about $2) is much more a 'near single chip solution' than AVR. Had you ever took a look at them? You only have to care about pincount and memory needs (OK, not much RAM and not much CPU performance), but not many problems about peripherals, even UART's, SPI's and ADC/DAC's. Also pin placement is not a big deal, since you can place 'HW' resources nearly where you want.

Of course, they are tricky to use (quite complex peripherals, not general used toolchain), and I was into ARM's faster than into PSoC's, but with the new planned 'big guyz' ARM based with JTAG and 'enhanced peripheral set' on the 2008 horitzont, they can beat the hell of may ARM's. Well, at least that would depent on the price, but if one have one uC that can have 8 USART's or 16 bit ADC's or whatever peripheral you want with the same chip, then who cares about the multiple kinds of peripherals, subfamilies, variants and so on? Only one IC reference and that's all. That is the reason why my company only uses PSoC for small applications.

@others:

If one spends some time looking for new chips over there, then one will be really impressed by the big amount of 'flavours' of 8051 derivatives being integrated into many applications (web servers, ZigBee transceivers, MP3 players, USB interfaces), even Atmel has many of them. Definitively they are a choice today.

Guillem.

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

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

One big unmentioned + for AVRs is simply this forum.

Regards
Sebastian

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

clawson wrote:
By the way do you have a link to that MSP430 dev system?

http://www.ti.com/corp/docs/land...

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

I hadn't seen that one. It is a cool little toy--IF you only want to develop for CPUs with no more than 2K of program space.

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

The TI MSP430's are great for apps where you need just a tiny amount of RAM. The low-end AVRs with sleeping can match in terms of average power consumption.

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

Absolutly unbelieveable arrogance displayed by Mr Smiley Micro et al,if anyone is any doubt about the 8052's design's influence on later processors then they only have to read the original 8052 datasheet to se the meaning of terms such as 'independant bit manipulation engine' and orthogonal instruction set'
The only time Ive ever come across arogance as displayed by Mr smiley is when I was stuck working for some cambridge nazis who seemed to think that the sun shone out of the anus of a guy who runs a company called ncipher corporation limited.

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

Jez, be a nice kitty! What processors has the 8051 influenced? None come to my mind. Was the AVR influenced by the 8051? -I doubt it apart from a marketing aspect. It also wasn't influenced by the PIC either (sorry for swearing). I wouldn't call the AVR or 8051's instruction set orthogonal - I think PDP11 took the crown for that title.

Speaking of PICs - I dare say some of them Cambridge nazis had some influence on the PIC - just look at the 'W' register - thats gotta be english fer sure.

My reason for going over the the AVRs many years ago was that they were faster than the 8051 AND they had internal eeprom. I also thought the 8051 had run its course. Seems the manufacturers had different ideas - including Atmel. Seems the 8051 is the Lazarus of the microcontroller world. Now we've got the plethora of ARM architecture products (ARM aren't from Cambridge are they?).

Bob - have a look at the Luminary products, apart from the poxy timers they're interesting little parts. No issue with cache etc since they don't have 'em. The gcc compiler does a good job of creating code for them. The options for each port bit is staggering though and having to enable clocks for each peripheral takes a little reading.

Interesting read is the comparison of various architectures on the FreeRTOS site regarding speed for various operations.http://www.freertos.org/PC/index.html

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

danni wrote:
stevech wrote:
danni wrote:
...
Also the AVR-GCC support no generic pointers (memory segment independent).

Huh? The AVR memories <= 64KB aren't segmented. So ordinary pointers to all C types work, right?

No.

Generic pointers on Keil means to use all functions on every memory segment, e.g. Flash, SRAM, EEPROM or custom (e.g. I2C, SPI).


Generic pointers do exist in at least one C compiler for the AVR -- IAR.

However, I don't know if IAR's implementation includes the ability to add memory-mapped I2C or SPI memories.

So in this case, we're not actually comparing AVRs to 8051's. They're agnostic on that point. We're comparing one software vendor to another.

Quote:
The trick was, that a third byte mark the memory type.
So no problems on using e.g. printf from Flash or SRAM.
Typically the argument string of printf should be located on Flash.

There are extensions to printf() in every AVR compiler I know of that will allow the format string and/or the other data sources to be taken from either Flash or SRAM.

In my experience, I've never encountered a situation where I didn't already know exactly which memory space was being referred to as I wrote any given invocation of printf(). So this seems to me to be an acceptable compromise.

Quote:
Nevertheless you can write your own functions to accept only one memory segment (memory specific pointer) to get faster and smaller code.

Generic pointers change the architecture to Von Neumann from the software developers view.

Peter

As has been pointed out already... Things like generic pointers will always involve a trade-off: It makes things convenient for the programmer, but in an architecture like the AVR (or the 8051), it unavoidably involves performance and code size penalties. Such penalties could be (and in the AVR, typically are) avoided by designing the application from the beginning with clear divisions of pointer scope.

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

The 8051 is like the flint knife, yes it works and still works long after it was first designed but that doesn't make it the best fit for all purposes. Adding a nice handle to the flint knife doesn't make it better than one with a steel blade!

My rule is:
Select the right tool for the job based on the requirements of the job that may be an Avr, Pic, 6811, 8051, Arm7, Arm9, dsp etc. or combinations of.

Lets keep it open minded and real which is the big benifet of this forum.

--

"If it wasn't for bad luck I'd have no luck at all"

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

Kartman wrote:
I wouldn't call the AVR or 8051's instruction set orthogonal - I think PDP11 took the crown for that title.
Yes and I am still kicking myself for not having designed an i/o interface that would have exploited its -(PC) addressing mode. (The program counter would have repeated the same address as the program code moved under it.) The RCA 1802 was a fairly close second for orthogonality.

- John