|
Viewing 1 to (10 Total) Whats so good about the Atmel atMega? |
Total Posts: 3
Joined: Dec 2009
|
I've been developing embedded systems for over 25 years; started out doing the hardware and software, then hardware technologies out-stripped my need to keep up to date on the 'latest & greatest'. These days I let the new uni graduates do all that stuff.
I was around when Atmel hit the market with the AtMega. It was great stuff at the time; high speed, low current, lots of I/O, memory and on board support peripherals.
Around the same time the atMega hit the market, I migrated from assembler to C as my coding platform. I unintentionally 'blocked' the atMega from my menu of desirable controllers due the inability to use C character strings in an ANSI compliant way and achieve resource efficienvy on the atMega.
This problem still plagues the controller... or am I still tardy with my techniques?
What needles me, is having resigned responsibility for hardware development at my employ, I am constantly given new product for software development from our uni-grad engineers. Why are they using the atMega for commerical products when the architecture is 20 years old and newer, faster, stronger and C compliant architectures are on the market.
What is wrong with other brands and architectures? What have I missed?
Cheers and best wishes for this festive season to all.
Posted on 2009-12-14 19:18:01 at 2009-12-14 19:18:01
|
|
|
Total Posts: 3
Joined: Dec 2009
|
or what's so bad about other MCU's!
Despite no longer being the 'new kid on the block' we need to look at why the ATmega is still so popular. For one, it was the first MCU designed with something other than assembler in mind. The something of course was C and despite your one little niggle of one missing C feature the ATmega still finds wide acceptance by virtue of the range of processors available without going overboard (like Microchip), with a sensible architecture and a workable selection of peripherals.
For some little time it seemed the ARM7tdmi might just displace the ATmega, but it is only right now with he ARM-Cortex M0 and M3 offerings that are appearing form everybody, including Atmel, that there may be something that challenges the ATmega, at least in my office anyway!
For much of the last 4 or 5 years I have made a nice business out of replacing PIC's with ATmega's - to the tune of about 700,000 chips over my customer base in the last year. I suspect that now I will be doing new designs with ARM-Cortex parts but I doubt we will be replacing the ATmega's in existing jobs any time soon.
Of course, low cost development tools, a robust IDE and tool-chain that is free have helped, and continue to do so, as does the active support of the community that has grown around the Atmel AVR family.
J
Posted on 2009-12-14 20:25:18 at 2009-12-14 20:25:18
|
|
Total Posts: 3
Joined: Dec 2009
|
But what is it that's so good?
Thanks for your response, but that has not quenched my quest for an answer...
I return to my original question... "What's so good about the ATMega?"
As you acknowledged, there is that 'niggling point' that shows that the MCU just doesn't meet the C ANSI requirements for C compatibility - especially if the MCU was designed with C in mind!!
I can think of at least a half dozen MCU's that will do everything an ATMega will do (and exceed in some areas) and all of the compilers for those processors do not require specialised handling for C strings to ensure that the controllers resources aren't consumed at a rapid rate.
So why is the AVR controller still being used in commercial product when cheaper, faster, more efficient MCU's compete with it more effectively?
BTW; The guys I work with, that are 'designing-in' the ATMega, have not been able to come up with a plausible answer themselves except that they 'know' the processor...
So is that the real answer?
Cheers,
P.
Posted on 2009-12-14 21:13:49 at 2009-12-14 21:13:49
|
|
Total Posts: 1
Joined: Dec 2009
|
Keep focus on application not code, use what you know.
Unless there is a killing reason for not using a known processor, use it. If that wouldn't be true, x86 would not be alive today if technical merits of a processor were more important than getting the job done. Learning the dos and don'ts of a new processor is time-consuming just as well as getting the development, emulation and debugging platform for that particular processor up and running.
New designs are often building on previous knowledge and code. When working with microcontrollers, programming in C is just replacing the assembler controlling the CPU. The use of interrupts, resources and I/O is still family dependent so moving a C-base from one architecture to another is not just plug and play.
From an application point of view, the microcontroller is just another tool to get things done. If the tool is ok, use it. If it is not, give me a reason to use something else. That reason may be cost and power efficiency, but that reason must come from marketing, the engineer will, and should, use the tools that he knows.
Rephrase the question: Why are still products with 8051 being shipped? Why is 8051 still alive at all when you know that other architectures are more efficient? The answer is probably the same as with ATmega: Stability.
The next reason is Availability. The number of inexpensive development boards and tools is probably more important than being code efficient and power saving. An engineer who can toy at home with the same tools as he use at work, without being ripped off or breaking license agreements, will favor those companies who take small-scale serious. Most MCU manufacturers do not take small-scale serious. Atmel AVR does. When they introduced AVR, they wanted to replace Microchips PIC as the hobbyists choice #1 for his next project. During late 90's I saw a lot of hobby projects start using AVR which would probably have used PIC. Where do people pick up their interest in microcontrollers and decide to become a professional?
Posted on 2009-12-15 07:32:42 at 2009-12-15 07:32:42
|
Total Posts: 4
Joined: Dec 2009
|
Why is AT-Mega doing so well
One reason they are doing so well is the community they have built up in colleges getting students to design with them. I use primarily Microchip PIC processors and have many reasons for focusing on them. The size and viability of the company along with knowing a design I did 5 years ago is still supported and I do not need to worry about a chip going obsolete is big with industrial projects. The breadth of the product line can be intimidating but that makes it easy to select a processor that fits the need. As a consultant I find more contracts wanting PIC expertise than Atmel expertise. Hobbyist and garage start-ups go either way and with all the hobby level things happening with the Atmel chips they are still in there swinging.
Posted on 2009-12-15 10:01:21 at 2009-12-15 10:01:21
|
|
Total Posts: 3
Joined: Dec 2009
|
Every engineer a different reason.
I think svenn hits it pretty well on the head.
Unlike some people I dont use PIC's because I find them so different to what I do know that the learning curve is extremely steep. I use ATmega's because I know them. I have the tool chain all configured for easy use and stepping to new projects. I have the JTAG debugging gear, and I know how to use it. So why change?
Software orthodoxy rarely has a major influence on hardware designers, and as a mixed signal designer I have a foot in both camps. If a chip has the right peripheral mix (priority #1), good development support (priority #2) a stable and well documented tool-chain then it will likely do the job.
However as a matter of interest I would love to know which other machines you advocate as being better 'C' engines than the AVR?
J
Posted on 2009-12-15 12:58:48 at 2009-12-15 12:58:48
|
Total Posts: 7
Joined: Dec 2009
|
The reason I used it...
I am a student and had little money to spend. So, I wanted a low cost processor with a lot of features. My alternatives were the 8051 variants, microchip PIC and ATMEL AVRs.
The AVRs and PICs have a lot more on chip peripherals than 8051s. The *FREE* AVR Studio and the community support was a big reason I like AVRs. WinAVR, the *FREE* C compiler is a shot in the arm. And FREE with AVRs do not mean a object code size limited version as IAR workbench for TI MSP430s or C compilers for PIC which in addition to code limitation have optimization disabled.
AVRs can be programmed using a parallel port without the need for an expensive programmer (89S51s and PIC also do these).
As for the chip selection by other students, what I have noticed is that most students stick to the uC taught as a part of the course. At Texas Tech undergrads use MSP 430 as that the only one taught to them (TI influence). Most Indians and Chinese are patrons of 8051.
Posted on 2009-12-15 13:36:41 at 2009-12-15 13:36:41
|
|
Total Posts: 3
Joined: Dec 2009
|
Is it collective bias or ignorance?
Being perplexed, on my part, comes from the fact that some of my colleagues use the ATMega without thought of the consequences to the software developer.
In my experience, the ATMega is not C string friendly and will require specialised handling when coding, to ensure that the RAM resources of the controller are not eaten away at a rapid rate.
My latest example of this being an issue was that we have a web server in an embedded product, and because HTTP is text intensive, the RAM resources were consumed in 1K chunks at an alarming rate - unless I wrote specialised functions to handle the problem. When I requested an MCU that didn't have this crippling effect, I was 'shouted down' and, instead, external RAM was added to the design... is that efficient design?
I do not recommend any other particular MCU or architecture - I code in C and therefore, once my I/O is catered for, I care little about the specific details of the MCU... C shields me from those nuances.
What does impact me, is having to 'personalise' my C application code (take NOTE: I state 'application code', not I/O code) to cater for a quirk of a microcontroller. This immediately cripples my application code to a specific hardware platform. This is not in the context of one of the biggest advantages of coding in C - portability!
An example that comes to mind where the ATMega (AVR) micro shows itself to be an exclusive product and a 'stick in the mud', is that about 15 years ago I developed a communications product for a company that proved itself to be a 'hot seller' due to the features that out-shined the competitor product. However, the marketing guys couldn't sell the system to clients who had just purchased the node modules from the competitors - the solution marketing wanted was to have our software run on the competitors hardware. This would allow them to sell the lucrative server (and support contracts) to clients.
It just so happened that jurisdiction requirements meant that the node hardware from one supplier to another was peripherally the same - i.e. an LCD display, same number of puch buttons, same I/O for monitoring etc. So, the only difference between our node and a competitors node, was the hardware design. This meant that the node(s) were a suitable target for code migration.
So, I ended up with the task of creating a portable code base. In the end, the SAME code - except the I/O modules - was running on all our competitors hardware. The hardware platforms the code ran on were; a Zilog Z80, Intel 8051, Hitachi H8, Motorola HC11 and TI MSP430. The only hardware that the code couldn't be run was the AVR due to this nuance of its string handling in C - it just ran out of RAM!!!
Note that the code was running (only just) on an 8051 yet couldn't run on an AVR.
What amazes me though, is that though uni grads are being taught the AVR, they don't seem to be taught the limitations of the controller in the C environment...
This leads me to ask: Are uni grads being taught the various benefits/limitations of ALL microcontrollers, or do the uni's just concentrate on one type or brand of controller?
For now...
P.
Posted on 2009-12-15 17:12:28 at 2009-12-15 17:12:28
|
|
Total Posts: 1
Joined: Dec 2009
|
ATmega pro's
Hi,
AVR architecture is old but simple and nice.
SW chain is free, easy, well supported.
A lot of code freely available on the web.
ATmega comes in a cheap and complete set of configurations.
You can run code the same day you mount it on a PCB.
Finally you say you had problems in RAM consumption for string handling and you are right: in another application we had heavy use of strings and we decided to put them all in Flash, the workaround is possible but of course more handling of data(base) has been necessary.
In my experience for simple projects ATmega is well suited, learning curve is fast and I used always only C, so the overall "package" is very good and I'll use until it fits, as said also in other replies.
Best regards,
Federico Aglietti
Posted on 2009-12-22 17:51:19 at 2009-12-22 17:51:19
|
|
Total Posts: 1
Joined: Feb 2010
|
Culture and cost are the real players
In my opinion, culture and cost moves us among the several uC offers.
If I got less than 2 hours to make a simple test jig, I'd probably go for an ATMega-based Arduino, it seems it was tailored-made for the job.
To implement something PLC-like product probably I'd go for a 8051-like architecture.
Automotive 8-bitter, Freescale and so on to get the job done.
BUT if the target is very cost-sensitive than we have to move from our confort zone and run a divergent process when we'll have to search for a brand new competitive solution. Anything could happen: last month I substituted an 8-bit CAN uC for a 32-bit due to... cost. I didn't need extra features.
Regards,
Celso
Posted on 2010-02-04 06:05:39 at 2010-02-04 06:05:39
|