avr vs other uC

Go To Last Post
69 posts / 0 new

Pages

  • 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

Pages