Yes, the AVR is a good choice. Compared to the 8051, it has 3 index registers which allow to use the ASM quite comfortable. There are some free tools, such as ASM, Simulator available on the Atmel website. There are also some not too expensive compilers : For C have a look at the iccavr (
I can't say I've gone through the change, but I have migrated somewhat from 8051 to AVR ;)
I do enjoy working with AVR very much indeed, and I never enjoyed the
8051 that much (though there was a certain sense of excitement in actually getting something done on that chip).
HOWEVER... can you tell us why you are contemplating this move? If it's merely out of a sense of aesthetics, how much are you willing to invest in migrating to a "nice" processor?
If you are worried that 8051 devices are going to disappear, please don't hold your breath. We will have 8051s as long as we have an 8-bit microcontroller market.
The reason I ask this question is that you MIGHT be better served by leapfrogging AVR entirely and moving into the low-end ARM arena. In this case, your code will be easier to migrate into larger, faster, niftier parts. It's certainly worth thinking about.
BTW, you will observe that 40-pin AVR pinouts suspiciously resemble an
On Sun, 05 Feb 2006 21:47:16 GMT, ziggy wrote in comp.arch.embedded:
Not criticizing, mind you, but merely curious, if you don't mind replying.
Why do you prefer Harvard architecture? What actual difference does it make in your actual development?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
That is actually the one thing I *don't* like about the AVR. It makes it very awkward to handle constant data efficiently. I would second Lewins suggestion of a low-end ARM.
Mmmmmfff... this is a really tough one to comment on usefully. Yes,
8051 is old and scraggly. AVR is clean and modern by comparison. But unless you have a real project that would benefit in a concrete way from AVR, I would not advise moving.
(Price is a consideration... dollar for feature, I think 8051 variants will beat AVRs in the high end at least - maybe not down at the 8-pin end though).
If you are planning some massive upheaval like migrating from asm to C as your language of choice, then yes - run, do not walk to a modern architecture like AVR or MSP430. Otherwise, a careful study of actual dollar benefits is necessary.
I've used the 51 for years too. C mostly with some assembly. Been using the AVR ATmega family for last year or so. The ATmega family is easy to setup, easy to use and very scalable (4K-256K). Initially I looked at the Tiny AVR family and wasn't to enthusiastic. The limitations reminded me of PICs. The ATmega family is much nicer and easy to get started, if you are using C. I've ported 8051 Keil C over to AVR WinAVR in an unexpectly short time.
I found the WinAVR (GCC port) to be easy to use and reliable. (some gripe about it being difficult to setup, but I had no problems).
To get more efficient C code we switched over to $$$$ IAR C compiler. Its really nice, though I have to put up with the IAR dongle.
I suggest skipping the AVR as well. The ARM controllers are getting increasingly smaller and cost effective. I havent been looking very often at the ARM controllers and I recently came across Phillips site and was very impressed with their LPC series ARM based controllers. the noPC board seems to be an inexpensive dev board. Too bad the guy that sells them is in the UK. I would consider purchasing one.
I would add that 8051 cores are available from such a wide variety of sources, too. They are quite modern, in many of these incarnations. Even Atmel has them, if that is one of the reasons ziggy is considering a change towards AVR.
If you already have excellent development tools for the 8051 family, part of the cost of shifting will be both the new costs for equipment as well as the learning curve and possibly for developing software that may be needed to fill in the gaps. The change takes time and money and always adds risk.
For merely a "concern of 'falling behind' a bit" I don't think I'd change.
Not really the change, but did some comparison on different architectures including even modern versions of '51. Taking into account the quality and price of the toolchain i finished up with AVR risc. The gcc is free, eclipse is a great IDE which i use for Java too and the range of processors programmable in C ranges from some 8-pin versions up to large ones like ATMega256.
Regards, Kurt
--
Kurt Harders
PiN -Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.pin-gmbh.com
You do realise you are trading a multisourced core, for a single sourced one ? I don't think there are any USB FLASH AVRs, and No AVRs with 16-24 bit ADC.... ? Priority interrupts, Boolean Opcodes... Oh dear..... ?
Single clock C51 FLASH variants hit 33MHz, 35MHz, 50MHz, 66MHz, 100MHz from various vendors - rather faster than the AVR.
So, why bother ?
Stick with the 80c51, and if you want to play with something different enough to be worthwhile look at the ARMs. Even if you do not need the Core, you can find the peripherals on an ARM have better performance : eg wider counters, some DMA, better FIFOs etc, than most 8 bit peripheral sets.
That would be a concern, except that nobody I know solders cores to boards. :) If vendor X discontinues the 8051 based uConroller I'm using so that I have to switch to something that's not pin-and-register compatible, then it doesn't really matter that much that the new part has the same core. Changing the pinout and perhipheral-interface is where all the work goes.
--
Grant Edwards grante Yow! Isn't this my STOP?!
at
visi.com
You still have all your software tool investments, both time and money, to consider. While the exact instance of a particular part may change, it is still a big advantage to still use the same development tools for the next incarnation of a similar core that does NOT require a software tool change-out.
I do NOT consider the idea of shifting from an 8051 cpu, where I've invested my own time in learning every particular about the instruction set as well as the software tools I'm using to target it, to another cpu core where I will have to spend substantial time building up a new internal mental model and instruction set familiarity as well as making new discoveries with a new tool set, to be something to brush aside as trivial.
In other words, staying with the same core even if it means different peripherals on the 8051, a different footprint, etc., has some value.
Single sourced bites in many ways: There is the serious EOL one, then there is allocation (remember that?), Plus you have _new_design restrictions, after locking yourself into a set to tools, and core : Want a Flash+USB for that new widget; oops - or how about higher precision ADC ? Sorry.... ... Then you have the vendor simply 'terminating' devices, thinking the customers are captive. [ == Short design life ]
A live example is the 90S2313 -> Tiny2313: We have been getting a LOT of requests for 90S2313 devices, from users who do NOT want the migration aggravation of the 'new' device. The Tiny2313 is a nice device, but there are 11 pages of 'migration notes', and new qualification testing needed....
Mostly, companies design staff are too busy on new designs, to re-spin an old design simply for production qualify, so purchasing keep trying to buy the older devices, that work fine... until they cannot...
The 8051 is a great architecture, I moved from the PIC to the 8051/2 and have never looked back. The single cycle cores add life to the 8051 line and it still is a viable competitor to other 8-bit MCU's decades after its first incarnation.
It has tons of free compilers and assemblers out there and lots of example code. It is more mature and is easy to find decent information on it.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.