// flame bait ... proceed w/ caution
Hi,
During a lengthy discussion w/ a small group the other day, the topic turned to the viability of the 8 bit µC, specifically the AVR8 bit. I would like to know your op on the matter. Why stay w/ the 8 bit AVR?
ARM7 poised to replace 8 bit µC in coming years?
Author
Message
Sonos wrote:
Why stay w/ the 8 bit AVR?
The price.
What about power consumption, on-board peripherals, ...?
Thinness of the datasheet. The arm datasheet is 800+ pages.
> The arm datasheet is 800+ pages.
Not too long until the first AVR will match that. ATmega640/... is at
429 pages already.
Because there are thousands of applications which would be a waste of an ARM processor!
I think its only a matter of time until there are simple ARM chips with pricing structures very similar to AVR.. Hell the LPC2101 at $3.15 is cheaper than the mega88 at $3.87. While the ARM might be more complicated it also has scads more performance. There will always be a place for a $0.25 8 pin 8bit chip but ARM is looking like it will take over the vast majority of the market.
dl8dtl wrote:
What about power consumption, on-board peripherals, ...?
less power consumption and more on-chip peripherals are current trends for ARM. ARM µCs are taking the same peripherals from the 8 bit markets, according to one in the group.
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 19708 View posts
Location: Basingstoke, Hampshire, UK
I should think that these "low-end" ARMs will kill-off the market for "high-end" 8-bitters.
It is amazing to see the number of people still struggling to push 8051s beyond their design limits with banking and all sorts, when they could just use an ARM for little or no extra cost, and way less struggle! :roll:
But, when all you need is a really cheap and really simple micro, I'm sure 8-bitters will retain an edge
After all, 4-bitters aren't dead yet...
another point of contention was the better matured GNU ARM toolchain, especially gdb/jtag when compared to the AVR.
I just ordered some LPC2119 arm stamps and a little dev board.
The stuff was cheap....but I also ordered Atmega128 stamps and dev board :)
Will comment more on the arm after I try to get the free C compiler for it working and dig through the huge datasheet.
But I bet I still love my Atmega168's most of all :)
EDIT:
Was just looking up more info on the arm architecture and discovered that the chief designer was a woman named Sophie Wilson....cool! a female role-model for me:)
I also discovered that Sophie started life as a man! And decided to make the switch and join me as a female...very cool! (He joined the winning side haha :) )
Now I know I have to play with the arm chips a bit.
I also will see if I can contact Sophie via email and chat a bit.
Quote:
Sophie Wilson is a highly talented British Computer Scientist, under-recognised outside the ARM and Acorn community. She is responsible for some ingenious innovations in her field in the past twenty years, including the immensely successful ARM processor's instruction set, the operating system for the BBC Micro, and the technically unsurpassed BBC BASIC language and interpreter.
Feeding Cows and Making AcornsAs a young Mathematics and Computer Science student at Cambridge University, Sophie Wilson (born Roger Wilson) designed an embedded system for a Harrogate company in the summer of 1977. She based it on one of her previous home-brew designs, using a 6502 processor, a number pad, 7-segment LEDs, and a non-volatile EEPROM. The system was to be used by farmers to regulate cow feed, and as such had to be robust and free of bugs. The "most hair-raising thing", she recalls, was the implementation of the cow feeder's program: "I didn't own a PROM blower, so I had to write the whole thing by hand and send it off to a company, who hand entered it into a machine and sent me back the PROM. That worked first time."
Here is a pic of Sophie that I found :)
Attachment(s):
Level: Raving Lunatic
Joined: Wed. Nov 17, 2004
Posts: 6320 View posts
Location: Great Smokey Mountains.
I think I'll leapfrog the gender identity dysphoria and make a bet about 8-bit micros. Arm type processors will slowly take market share from 8-bit processors in a continuously growing market. 8-bits will grow slower, but they will still be ubiqitous and likely the greatest volume long after we are all, including the kiddies, quite dead.
I remember clearly the big push that was going to have 16-bit micros kill 8-bits. They sneered, they cajoled, they implied that we were atavistic luddites, and we continued happily 8-bitting along as they drained their marketing budgets and failed to get much traction. The 32-bit will probably hurt the 16-bit a lot more than the 8-bit.
Smiley
I just wish there were some cheap 40-pin arm chips so you could experiment without having to solder sm stuff.
Level: Raving Lunatic
Joined: Fri. Jun 11, 2004
Posts: 2418 View posts
Location: Vilanova (Barcelona)
I'm finishing a project with some ATmega64's on it. At the beggining, I would replace one of them by a Philips LPC2103. It costs about the half (1.65€ Kunits per year), more processing power (that I needed) and more RAM (I also would need it). Developing time forced us to use it.
At this price, with better and faster peripherals (take a look at AT91SAM7S64 and made a close comparison to ATmega64), I bet that 'big guyz' like M128/M256 can be beated in a near future.
Of course, for the small end, an 8 pin/8 bit uC for .40 € would be harder to kill (ARM are so complex and need much more code to do the same, specially initiasation), but anyway I'm using Cypress PSoC for that purposes, and the new planned family for PSoC is ARM based, but with even improved peripheral set.
I'm playing at home with AT91SAM7S/S dev boards (from Olimex) and the tool chain is cheaper than others (JTAG @ 9€, IAR KickStar for free limited at 32KBytes), and I found them really interesting, but too complex for beginners, like comparing a M128 with the simpliest ATtiny, when comparing the simpliest AT91SAM7S32 with M128.
Guillem.
I've had a bit of fun with the Philips (NXP) offerings. There seems to be a little black magic especially when using interrupts and the uart transmit. When having these problems you think of the simplicity of the AVR & 8051 interrupts. Nevertheless, these are stunningly fast parts - too fast in some cases especially when writing to lcds you are wasting a substantial amount of cycles waiting around just to meet the bus timing let along the instruction timing of these. At least having a faster cpu means your defects will happen faster.......
> another point of contention was the better matured GNU
> ARM toolchain, especially gdb/jtag when compared to the AVR.
Curious about what exactly is better maintained there?
GDB works on the AVR, it's only that most Win32 users appear to
prefer using AVR Studio anyway.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
I had a visit from the Atmel sales rep and an FAE on Wednesday just to give an "up to date" presentation on the AVR range. We discussed this exact subject. The fact is that the days of sub-$1 ARMs are almost upon us but the fact is that I can buy an AVR for $0.17. It's going to be a fair while until ARMs get down to that price and until they do there is a place for AVRs as low end controllers.
I did ask them about the thinking behind the "large" devices like the behemouth 2560 though. My own personal opinion is that if you need a controller with this much resource you may have outgrown AVRs - for the same money you can get a reasonably specd. ARM but the Atmel argument goes along the lines of (1) investment in legacy tools, (2) growing legacy AVR code that the customers doesn't want to port to ARM and finally, (this one tickled me!!) (3) engineer fear of working with 32 bit architectures.
They did, of course, point out that Atmel themselves do a range of ARMs starting with the SAM7 and some of these are quite agressively priced and it's a trend that will strengthen (I'll say no more!)
Personally, having used all sorts, I'm fairly agnostic on CPU choice - the key decider for us (we tend to make things in quantities of 1,000,000+) will ALWAYS be value for money.
Cliff
@ Jörg
better matured != better maintained
one of the participants brought up the better matured GNU toolchain of the ARM; that the ARM gdb/JTAG is more mature than the gdb/JTAG of the AVR. I suspect there is a higher rate of hacking on the ARM GNU toolchain than the AVR GNU toolchain, but it's just a guess. Also, avrdude and uisp are **too** easy to use and may be a reason in part as to why gdb has not been as developed for AVR. >make clean >make >make program ... does it work now? is the mantra for the AVR without a fully functional gdb stub. ARM gdb/JTAG stubs are fully functional, if I am understanding the group's discussion properly.
clawson wrote:
... the Atmel argument goes along the lines of (1) investment in legacy tools, (2) growing legacy AVR code that the customers doesn't want to port to ARM and finally, (this one tickled me!!) (3) engineer fear of working with 32 bit architectures.
...Personally, having used all sorts, I'm fairly agnostic on CPU choice - the key decider for us (we tend to make things in quantities of 1,000,000+) will ALWAYS be value for money.
Cliff
I think these points are best interpreted within the confines of proprietary dev platforms. However, if you look at these points raised by Atmel from the GNU toolchain perspective, they don't hold up, especially the porting of code. Properly written AVR code should be easy to port to any GNU gcc target, keeping in mind the on-chip peripheral registers are different. When using the GNU toolchain, CPU core choice becomes somewhat transparent.
I would tend to agree there is a mystic quality to the 32 bit targets. After a few hours of reading however, the mysticism for me became an enthusiastic 'wow, I can't feel the 8 bit ceiling any more'.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Are you saying it's easy to port an AVR app to ARM then? Sure porting between AVR compilers or between ARM compilers should be fairly painless but if I've got 100K of Mega128 code that I've spent the last five years developing I can't believe it's going to be that easy to make the app work identically on an ARM.
But I guess the "legacy" argument only applies to existing developers. If you have a $1-$2 chip application and no existing tools or source then there probably would be a strong inclination to head off in the ARM direction these days. Not least of which is the fact that probably at least half the embedded engineers in the world these have some ARM experience so it's going to be that much easier to get answers (AVR Freaks excepted or course!)
Cliff
Also if ARM goes cheaper as the AVR, it is still many more complex and so it is harder to learn, need more time to write software and there is more danger to make faults.
E.g. writing interrupts is many times harder on the ARM.
So you need always a spurious interrupt handler, if interrupts must be disabled for atomic operations.
Also you must do many things inside the handler to terminate the interrupt right.
No pending flag was cleared automatically, it must be done manually in a determined order.
Furthermore if interrupts fired to often no chance for the main to do something (AVR was always doing at least one main instruction between interrupts).
Thus I see many potential still for the 8 bitters (easier to program, less error sources).
Also, since 8-bitter contain less transistors, they should be more robust, reliable and less sensitive against EMI.
Also the ARM portpins can not drive 40mA high or low.
Peter
clawson wrote:
Are you saying it's easy to port an AVR app to ARM then? Sure porting between AVR compilers or between ARM compilers should be fairly painless but if I've got 100K of Mega128 code that I've spent the last five years developing I can't believe it's going to be that easy to make the app work identically on an ARM....
Cliff
Sorta. I see this discussion centered more on dev platform choices than ease of portability. The GNU gcc compiler is perhaps the most actively developed compiler on the planet. If GNU gcc is your compiler, then you have greater portability options to other targets. AVR >> ARM >>
Cliff, 'easy' is a relative term. However, if you can separate your code into chip dependent and chip independent functions, I would think you are in the right track. I don't think you should look back on the last 5 years as lost, but realize 1 year AVR >> ARM porting may actually leapfrog your app by 3 years! With more peripherals becoming available on the ARM core, your app may work better on ARM than on AVR. YMMV.
The GNU toolchains let you work w/ more options without breaking your budget. Rather than push your dev platform (AVR) onto a problem, you can pull the GNU toolchain your direction, possibly with a better end result and maybe pull ahead in your market nich.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Peter,
Nope, sorry I don't follow that. I've brought several ARM boards up from dead implementing the initialisation stuff to get a bootloader operational. There's nothing particularly "clever" about ARMs or their interrupt systems. Like all chips it's just a case of reading the datasheet until you understand it. About the most complicated thing is usually configuring the SDRAM controller so it does the refresh correctly but even that isn't rocket science. Sure the datasheets may be larger but that's usually because the ARM is at the heart of a larger chip of silicon and there's more/complicated sub-systems around it. Granted the configuration of the MMU on an ARM9 maybe isn't for the feint hearted but that's about as bad as it gets and in reality I found it no more complicated than programming the IDTs and GDTs on an 80286/80386
Anyway, you only really have to get the chip as far as running the C compilers pre-amble by wading into the Asm code, then everything else you do can be in C and C on ARM is no more/less complicated than C on an AVR or a Cray or whatever else.
Cliff
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Sonos,
But AVRs are controllers, almost all that they do are chip specific, hardware based things (you don't use them to solve differential equations or predict the weather!) so when you break your app into chip dependent and chip independent then about 95% of it is going to fall into the chip dependent pool for an AVR app (and probably most of the rest comes from a generic lib like avr-libc anyway providing stuff like printf() and FP libs anyway). If you have 100K of controller app then most of it will require porting to the ARM and to what end? Do you save $1 per chip by doing this? Say it takes 6 man months. That's $50,000 of engineering effort. Can you amortise the $1 saving over 50,000 units to simply break even? (all of which is based on you investing the time/effort because ARM is a cheaper solution than AVR - but it isn't!)
Like I said previously a new developer might head straight for ARM because of the amount of example library code already available but ultimately it comes down to dollars and cents - which ends up being the overall "cheapest" solution. For small apps (say up to 16K or perhaps even 32K) then surely AVR will always win while for larger stuff ARM may now be the cheaper overall solution
Cliff
@ Cliff,
You have a better 'in the trenches' understanding than I as to business decisions for chip selection and your points are well received.
clawson wrote:
...But AVRs are controllers...
yet ARM is moving away from pure processing power into the melting pot generally reserved for 8 bits. w/ an ARM controller, it is possible to have your cake and eat it too.
...from arm.com :: embedded market
Quote:
Around $4Bn of Microcontrollers or (Application Specific Standard Products) ASSP’s are used each year in the vehicle electronics market. Automotive manufacturers agree that 90% of the innovation in vehicles is driven by electronics.Today, a similar size Microcontroller market is made up of applications such as Industrial Control, Metering and Measurement, Motor Control, Medical electronics and Consumer Appliances. The need for increased functionality and integration is driving the move from traditional 4 and 8 bit Microcontrollers toward the greater performance and flexibility provided by cost effective 32 bit designs.
I am still debating with ARM and AVR. It seems that some ARM chips are very powerful, faster, and even cheaper than AVR.
The only drawback is most of ARM runs at 3.3V, so some peripherals will not be available . . .
Just one more question (and don't mean to hijack this thread): how good are those free compilers and software development tools for ARM? I am reluctant to install WinARM as I am running out of hard disk space to experiment. Are they as easy to use as WinAVR? Do I need to do MAKE file (which I hate) Any ideas? Thanks.
I think the ARM crowd has some work to do before they'll be well accepted by the microcontroller marketplace. They're currently rather different "philosophically." The comment about the 800 page manual is more telling than you know. But it just starts there; that's only the basic ARM architecture reference manual. Before you can understand things well enough to write efficient code for that $1 Luminary ARM7 Cortex M3 chip, you also have to wade through the manual that differentiates ARM7 from ARM in general, and then the manual that differentiates Cortex M3 from other ARM7s. "You don't have to do that; just use our C driver library" (200 pages documentation) the ARM crowd will say; "You don't need to worry so much about efficiency!" Which is nice in some ways, but if the microcontroller market were (emotionally) ready to do all their programming in C, they'd already be doing that on other micros. (Now, the people that program existing micros exclusively in C or other HLL are more likely converts, I think.)
Westfw raises some interesting issues. The ARM is one of the few cpus i've used and not been conversant with the architecture. I just rely on the 'c' compiler to do the work for me. Depending on your requirements this could be reasonable or could be construed as dumb blindness. I've done my years of looking at what the compiler spits out and how I could do it better - in many cases I could. Could I do it faster in terms of coding time? No. In my projects the coding time tends to dominate the project cost. If I was designing items for production quantities of > 10,000 units, then I would re-adjust my priorities. Having to choose over a $1 cpu vs a $2cpu doesn't touch the code budget. If the $2 cpu saves me time in coding, then that is my choice. Trying to squeeze the code into a smaller micro for 'efficiency' won't keep my boss happy - even if I tell him how I coded in assembler and pulled just about every trick in the book to make it fit. I'm sure most of us would say 'use a larger micro' and we have this choice. In days gone by you had 4k to play with or you had to go to external eproms. I try to do most of my coding in 'c' with the emphasis on defect free code rather than the smallest,fastest code. Defects cost money. With the extra performance the ARMs give, I can worry less about timing issues. Also the 32 bits arithmetics help the performance in some instances. The 32bit timers in some of the ARM devices are a double edged sword - you don't need to compromise resolution, but get your calcs wrong and they take a while to roll over! By the same token ARMs are not the be-all and end-all, my last project used a mega128 simply because it had enough performance, I had them on hand, they were 5V and I was under the pump to get the project out. Had I more hands on experience with the ARM units, my decision may have been different. In this instance I didn't have any gotchas from the cpu since I've used the mega128 in many projects. I try to stay architecture neutral - I'll use whatever cpu meets my requirements. I write my code to steer away from processor specifics - apart from the i/o so if the cpu disappears, then I'll just choose another.
Another similar question is "are soft core cpus going to replace hard core cpus?" I refer to cores like the Altera Nios - are we all going to use fpgas and select the required peripherals from a drop-down box on the pc? My answer is: not today, but tomorrow it is not unreasonable to think this is where we are heading. And should we use hand coded logic vs HDL generated logic? The main arguments against the soft core approach are: cost and power. These issues will dissapear over the coming years.
Doda wants to know about the gcc compilers - the ARM compiler is more mature (the ARM has been around longer than the AVR), also the ARM is more like a standard processor rather than a microcontroller - thus the compiler doesn't have to work around the memory quirks some microcontrollers have. Apart from that, they're both similar in operation so you need the dreaded MAKE file. Some front ends isolate you from these horrors!
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
doda wrote:
Just one more question (and don't mean to hijack this thread): how good are those free compilers and software development tools for ARM?
I can't comment on WinARM specifically but I spent 2003..2005 working on a 12MB code project based on ARM9 which was Linux based. Naturally this meant we used arm-gcc as the compiler along with gdbserver/gdb/ddd for the debugging and I can honestly say it's a wonderful set of development tools. Never a moment's worry with them. Having previously spent a few years working on ARM7s (non Linux) with ARM's own SDT 2.50 it was a really welcome breath of fresh air! Sure we were developing at the Linux command prompt and having to write Makefiles to invoke the dev tools but even that part of it is not THAT complicated. Perhaps WinARM has some template solutions for that in the same way that WinAVR has Mfile which might make the process easier?
It was the great experience I'd had with arm-gcc that made me want to use avr-gcc when I started working on a little AVR project!
In fact, now you have mentioned, I'm feeling the need to go off and download WinARM to see what it offers !
Cliff
Level: Raving Lunatic
Joined: Fri. Jun 11, 2004
Posts: 2418 View posts
Location: Vilanova (Barcelona)
I will fit better to the definition by Cliff Lawson about 'new developers', and I fully agree that for new developings, ARM's are considered as competitors for AVR's. But I fully disagree with other points, since I'm currently developing a product with m64 (something like a datalogger), where about 80% of the code is hardware independend, and all hardware related procedures are in a separate .c and .h files, so recompile many parts of the code for an ARM would be not so difficult.
But anyway, if I had to recompile for a new ARM, I would instead rewrite all and use some OS. That would save me from the actual programming nightmare for many screens, parameters, and user oriented code. Also developing time would be decreased by this tools, the application can run faster (anyway, AVR's are quite powerfull for that), and comms (I have many of them, specially serial comms) would be more transparent and easy to handle by the ARM.
Is a common opinion in our company that in a near future, for new developments, ARM is a choice, and probably it will be the way. One of the reasons is the big amount of manufacturers that sell this kind of core, and since the new Cortex 3M seem targeted to avoid one of the backdraws of the ARM's that are the IRQ handling, they will be more attractive to many microcontroller developers. Also new versions running at 5V (see ST new ARM7 family), and the Cortex uses less transistors, thus reducing price, and the peripherals also are updating to drive more current, and also Cypress will upgrade they PSoC (with a PIC/accumulator style core) also with ARM7 (¿Cortex M3?) core, then probably we would have the most versatile uC possible. This makes the market competitive and forces the uC manufacturers to lower prices and offer more versatility/prestations to avoid the migrations of the customers to another competitors using the same core.
USB also seems to be an standard peripheral, as network and CAN. All this is also attractive for new developments, since they offer 'up to date' conectivity avoiding FTDI/Silabs external IC's. If many applications demand this kind of 'user friendliness', they are becoming a big player on the uC solutions. Of course, it would be harder to develop, even with profussion of libaries, operating systems and so on.
But for the small applications where ATtiny's or small PSoC, PICs and other 6-20 pin uC are widely used, probably our kids would work with 8 bitties for theyr whole life.
Guillem.
The positive sides of using ARM to me are its speed, built-in peripheral (CAN, USART, EtherNet, etc), and HUGHE RAM (compared with AVR).
To me as a hobbist, I don't care about architecture, nor do I care about how many manufacturers are supplying it, all I care is ease of development, less part count, cheap (yet powerful).
So far, I like AVR development environment, almost like PC development, no MAKE file, visual debugging, good editor. But my complain is AVR is too expensive (well cheaper than PIC where I came from) compared with ARM (say LPC2119) and less speedy. LPC2119 costs about $9.5 @ one, yet, comparable (two USART) AVR Mega128 is about $15 @ one. I'd rather learn a new set of tools to save that $6.5 . . . why? I don't have time constrain but I DO have cost constrain. This might sound stupid to many, but it is just me :-)
The size of the document does not bother me, most of them are for serious system architects which can be overlooked by hobbist who just want to code it.
The amount of RAM is a key factor to me, too. Not from a hobbist point of view, but, seriously, if you want to implement any of the basic computer science algorithm, you need a lot of RAM. How many times that one has to watch and count amount of RAM left when coding a project? Even I, as a hobbist, run into this. This is why now, I just buy a Mega128 board and play with it, see if I can port any code to Mega16 or something less expensive.
Just a few cents here.
Last Edited: Sat. Nov 11, 2006 - 03:26 PM
Quote:
In fact, now you have mentioned, I'm feeling the need to go off and download WinARM to see what it offers !
Let me know your professional opinions! Thanks.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
doda wrote:
But my complain is AVR is too expensive (well cheaper than PIC where I came from) compared with ARM (say LPC2119) and less speedy. LPC2119 costs about $9.5 @ one, yet, comparable (two USART) AVR Mega128 is about $15 @ one.
But that's just a consequence of the pricing structure for one-off hobbyist parts. If you look at the LPC part in quantities of 5,000 (say) then it's $6.84 whereas Mega128's in that kind of quantity are probably $3-$4 and if you up that to 50,000 you'd pay less again for the AVR while I guess the ARM price doesn't have the same latitude for reduction.
BTW I downloaded the small, self extracting version of WinARM (the small one is just 44MB - gulp!). There are some examples which come with Makefile's that I guess could be adopted for one's own projects. Similarly there's some chip initialising .S files that will probably be fairly generic and could be re-used. But the thing that's missing (compared to AVRs) is the equivalent of an AVR Studio to bind it all together into an easy to use IDE. Like WinAVR before Studio got the gcc-plugin the beginner is faced with configuring Prorammer's Notepad.
Cliff
Quote:
but, seriously, if you want to implement any of the basic computer science algorithm, you need a lot of RAM.
Gross generalization. If true, PDP8s or any small microcontroller could not do "basic computer science algorithms". Apparently, then, all of the production apps on modest-sized AVR microcontrollers are lacking in any of these algorithms?
Sure, there are tasks/apps that suck up RAM, and may not be feasible without. But I fail to see how it applies to microCONTROLLER apps in the general sense.
[edit] The Philips (now NXD?) parts sure are nice, tho, as are the AT91SAM7s. And roughly comparable pricing to an AVR of the same "class". The model you mentioned looks nice if you would need the twin CAN. If I needed USB or Ethernet I'd look at the SAM7S or SAM7X. I believe that Philips had LPC models with USB, right? At a quick glance the one thing that I did not like from a system design standpoint was the lack of an on-board regulator for the 1.8V core supply.
Lee
clawson wrote:
doda wrote:But my complain is AVR is too expensive (well cheaper than PIC where I came from) compared with ARM (say LPC2119) and less speedy. LPC2119 costs about $9.5 @ one, yet, comparable (two USART) AVR Mega128 is about $15 @ one.
But that's just a consequence of the pricing structure for one-off hobbyist parts. If you look at the LPC part in quantities of 5,000 (say) then it's $6.84 whereas Mega128's in that kind of quantity are probably $3-$4 and if you up that to 50,000 you'd pay less again for the AVR while I guess the ARM price doesn't have the same latitude for reduction.BTW I downloaded the small, self extracting version of WinARM (the small one is just 44MB - gulp!). There are some examples which come with Makefile's that I guess could be adopted for one's own projects. Similarly there's some chip initialising .S files that will probably be fairly generic and could be re-used. But the thing that's missing (compared to AVRs) is the equivalent of an AVR Studio to bind it all together into an easy to use IDE. Like WinAVR before Studio got the gcc-plugin the beginner is faced with configuring Prorammer's Notepad.
Cliff
Yeah, I was only looking at buying these MCU's at less than quantity of 10.
On the other hand, this is why I am still playing with AVR because it seems that WinARM is a bit troublesome for a PC developer who is so spoiled by Microsoft Studio. WinAVR is really good when integrated with AVR Studio. This is outstanding given the fact that it is FREE!!!
theusch wrote:
Quote:
Gross generalization. If true, PDP8s or any small microcontroller could not do "basic computer science algorithms". Apparently, then, all of the production apps on modest-sized AVR microcontrollers are lacking in any of these algorithms?
Well, if a MCU is used to turn on and off something based on some conditions, it is adequate. But if you want to build (slightly) complicated ones, very soon, one will run out of RAM.
Take RTOS for example, after the kernel (even the tinniest one), how much RAM are left for each task on a Mega128? On top of that, maintaining some sort of state machine for 32 outputs with feedbacks/events via USART, along with an event driven architechure that processes events asynchronously . . .
With more and more intelligence being built into MCU enabled products (even for my home automation project), very often I find myself that I am running out of RAM, yet using very little (20%) Flash ROM (code size is relatively small).
Well, the key here is, modern MCU's enabled products needs a lot of intelligence built-in (ie, a lot of basic computer science algorithm -- queues, linked lists, stacks) and that requires a lot of resources. That was my point.
theusch wrote:
Quote:
[edit] The Philips (now NXD?) parts sure are nice, tho, as are the AT91SAM7s. And roughly comparable pricing to an AVR of the same "class". The model you mentioned looks nice if you would need the twin CAN. If I needed USB or Ethernet I'd look at the SAM7S or SAM7X. I believe that Philips had LPC models with USB, right? At a quick glance the one thing that I did not like from a system design standpoint was the lack of an on-board regulator for the 1.8V core supply.Lee
Yes, I was looking at LPC2364 . . . 34K RAM, 2 USARTs, 2 CAN, 1 USB, and 1 Ethernet. Only costs about $7.58 at quantity one. I have not looked at AT7SAM's from Atmel yet.
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
doda wrote:
Yes, I was looking at LPC2364 . . . 34K RAM, 2 USARTs, 2 CAN, 1 USB, and 1 Ethernet. Only costs about $7.58 at quantity one. I have not looked at AT7SAM's from Atmel yet.
The SAM7 closest to that spec looks like being the AT91SAM7X128 which is $12.58 one-off at Digikey:
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
doda wrote:
Well, if a MCU is used to turn on and off something based on some conditions, it is adequate.
Isn't that almost exactly the definition of "microcontroller"? If you want something to solve differential equations or predict the weather you are probably looking for a microprocessor, not a microcontroller.
Cliff
Quote:
But if you want to build (slightly) complicated ones, very soon, one will run out of RAM.Take RTOS for example, after the kernel (even the tinniest one), how much RAM are left for each task on a Mega128?
Bull to the first, and what does RTOS have to do with "basic computer science algorithms"?
You kids have probably never heard of Donald Knuth. Which of the algorithms in these books will require you to run out of SRAM on an AVR? Which of the examples in Numerical Recipes? Or any other standard text on basic computer science algorithms?
>>Certainly<< there are tasks that aren't appropriate for the resources of an AVR--but your ARM or whatever other microCONTROLLER is not going to have enough onboard SRAM for [say] a graphics display buffer of decent resolution.
An RTOS is not a "basic computer science algorithm". I wouldn't even call it an algorithm.
Lee
clawson wrote:
...I spent 2003..2005 working on a 12MB code project based on ARM9 which was Linux based. Naturally this meant we used arm-gcc as the compiler along with gdbserver/gdb/ddd for the debugging and I can honestly say it's a wonderful set of development tools. Never a moment's worry with them....
Testament to the power of open source leading the industry - and profitable too.
TiVo
http://www.tivo.com/linux/linux.asp
was developed using the very same tools as the ARM. Tivo's CPU is a PPC chip running at 60mhz.
clawson wrote:
...Sure we were developing at the Linux command prompt and having to write Makefiles to invoke the dev tools but even that part of it is not THAT complicated....
absolutely.
clawson wrote:
...It was the great experience I'd had with arm-gcc that made me want to use avr-gcc when I started working on a little AVR project!...
With a good working knowledge of the GNU toolchain, discussions on which microcontroller to use becomes quite dynamic. This is where the GNU toolchain shines; it can be pulled in almost any direction.
Kartman wrote:
...The ARM is one of the few cpus i've used and not been conversant with the architecture. I just rely on the 'c' compiler to do the work for me. ...
Transparency of core choice for your application is a great aspect of the GNU toolchain. If you have GNU gcc in your pocket, you have a ticket into any market you want.
doda wrote:
...Well, if a MCU is used to turn on and off something based on some conditions, it is adequate. But if you want to build (slightly) complicated ones, very soon, one will run out of RAM....
If you are like me, I get halfway through an application and begin realizing I initially underestimated the potential of the end application. That happened more often when I was using CodeVision. It's not so depressing w/ GNU gcc because other cores are a few steps away, rather than 15,000 USD. I guess I grew tired of that. Maybe I just can't plan properly.
doda wrote:
...Take RTOS for example, after the kernel (even the tinniest one), how much RAM are left for each task on a Mega128? On top of that, maintaining some sort of state machine for 32 outputs with feedbacks/events via USART, along with an event driven architechure that processes events asynchronously...
As a Linux enthusiast, it took some humble pie to accept that the Linux kernel isn't really a true RTOS. But it performs. Frankly, I've come to view definitions of RTOS as pure semantics. Most 32 bit microcontroller applications, like the ARM, probably use only 1 thread but w/ interrupts. So the practical difference between AVR and ARM in the respect of threading is a moot point. However, you might need step up and run a hacked Kernel like ecos. W/ ARM, you have that choice. With AVR, you don't.
clawson wrote:
doda wrote:Well, if a MCU is used to turn on and off something based on some conditions, it is adequate.
Isn't that almost exactly the definition of "microcontroller"? If you want something to solve differential equations or predict the weather you are probably looking for a microprocessor, not a microcontroller...
2 bit decisions with 32 bit brains can become quite sophisticated! PID, a frequent topic on avrfreaks, reveals some of the frustration w/ 8 bit targets. Thinking that a 32 bit target is too sophisticated for 2 bit decisions may be a bit myopic.
edit :: 1 bit decisions, not 2 (on/off)
Last Edited: Sun. Nov 12, 2006 - 02:46 PM
Doda, I don't think you've done your research on ARM tools - I would dare say they outstrip AVR tools in numbers. If you want something free/cheap - look at the Keil uvision tools for ARM. Code limited in the debugger but open in the compiler if you use the GCC tools. There's also Imagecraft for $199usd, they have a try before you buy but I'm not sure of the limitations. There's also various front ends for the gcc compiler (Keil included) like the programmer's workbench. If the choice is based on tools alone, ARM wins hands down.
If you want to write large programs the have large linked lists etc - use an embedded linux box like a NSLU2. More than enough grunt to do the whole thing then have it talk to small distributed microcontrollers to get the data. Have the small micros read the temperature, sense the pushbuttons and flash the lights.
Personally, I'd suggest you start with the AVRs since they're a little more 'friendly'. Get your feet wet then you'll be in a better position to determine what you need next.
Quote:
use an embedded linux box like a NSLU2
Are you talking about this thingie???
Quote:
Bull to the first, and what does RTOS have to do with "basic computer science algorithms"?
I thought most OS are built with basic components that utilize "basic computer science" algorithms, no? like linked list, queues, stacks . . .
What I am trying to say is, if you want to build an application with structure, built on top of an OS, resources are important.
For those algorithm in numerical recipe, I think they belong to application level, pretty higher up in design.
Kartman wrote:
Doda, I don't think you've done your research on ARM tools - I would dare say they outstrip AVR tools in numbers. If you want something free/cheap - look at the Keil uvision tools for ARM. Code limited in the debugger but open in the compiler if you use the GCC tools. There's also Imagecraft for $199usd, they have a try before you buy but I'm not sure of the limitations. There's also various front ends for the gcc compiler (Keil included) like the programmer's workbench. If the choice is based on tools alone, ARM wins hands down.If you want to write large programs the have large linked lists etc - use an embedded linux box like a NSLU2. More than enough grunt to do the whole thing then have it talk to small distributed microcontrollers to get the data. Have the small micros read the temperature, sense the pushbuttons and flash the lights.
Personally, I'd suggest you start with the AVRs since they're a little more 'friendly'. Get your feet wet then you'll be in a better position to determine what you need next.
Thanks for the advice. I am not building a LARGE linked list, just a message pump queue, each message is 24 bytes long and I need at least 32 of them to be shared by 32 IO's state machine . . . when something happens on IO, a message is sent, get into wait for acknowledgement state, if no ack and timed out, send message again, in the mean time, message could come in via USART, need to be queued up before
etc, etc.
Yeah, Linux would be nice :-)
clawson wrote:
doda wrote:Well, if a MCU is used to turn on and off something based on some conditions, it is adequate.
Isn't that almost exactly the definition of "microcontroller"? If you want something to solve differential equations or predict the weather you are probably looking for a microprocessor, not a microcontroller.Cliff
Totally agree with you. But I think the intention of thread is whether ARM7 is going to replace 8bit uC, and my point is, as more intelligence are being put into these "uC" based products/projects, ARM7 has the potential to REPLACE 8bit uC's. In fact, I think it WILL do that.
I will not be surprised when some sort of design framework come out just for "embedded" applications to make it easy to develop. Of course, these framework will be "fat" in our eyes, but then again, which of the successful applications on PC is written in assembly?
Doda, Lotus 123 was written in assembly. This is, of course, history and stunningly successful for Lotus.
The market for microcontrollers is incredibly diverse, to say that the ARM will wipe 8bitters is not true. A wash machine controller doesn't need 32bit processing - but it does need super low cost. As one ofthe other respondents mentions that there's still a market for 4bit micros. The stuff us hobbyists work on, cost is not so much the driving issue apart from the cost of tooling up for each processor. Personally, a micro is a micro to me except if its a PIC) it all comes down to the feature set for the task at hand. The techniques for embedded systems aren't tied to a processor architecture, what you learn on one micro is of use on another micro- sure there's differences. So don't get too uptight about 'backing the wrong horse' - there's no right or wrong, just get your feet wet and enjoy the experience. My first processor was the now obselete national semiconductor sc/mp - if someone told me it would die a death at the time I might have been worried. I learnt machine code on that, then the z80 then just about any other micro you'd like to name since then.
As for embedded system 'frameworks' - again do your research - there's a few out there.
Part of the skill of embedded systems is squeezing the max out of a constrained system. Sometimes you really have to think about how to minimise the memory required to achieve a goal - this may not be exactly the same as you would on a larger system - like avoiding floating point, large data structures etc. For your application, look to avoid having queues - structure the tasks to work without a queue. If this is impossible, then you need more ram. Simple. Look at how some of the TCP/IP stacks work on small micros - you see a few tricks at work here.
Gwen, yes, the picture looks remarkably like the box I have on my desk. These are dirt cheap and power packed - the problem is you've gotta use Linux! This can be a mixed blessing. If you need a box to be a web server and data logger and you don't want to use a PC - this is the bomb. It talks ethernet and USB and I use a USB-> serial converter for serial RS232. It runs off 5V and draws heaps less power than a PC. Just the thing for home automation etc. It has a StrongARM cpu in it for what it's worth.
Level: Raving Lunatic
Joined: Fri. Jun 11, 2004
Posts: 2418 View posts
Location: Vilanova (Barcelona)
To add more fuel to this fire, my two cents for both sides:
I'm developing a system that the main task can be done with an ATmega16 (datalogging) and a FlashROM. But since there is a big 64x128 pixels LCD, comms, and other stuff, I need an ATmega64 where more of the horsepower is used to display messages, graphics, menus, etc.
I can see in the next future that the 'user interface' need much more processing power than the really one needed for the process itself. In other examples: PID algorithm for thermal control can be really simply done with a simple ATtiny without RAM. But the menu management, parameter settings, and the Autotune algorithm need more RAM, so this should work with an ATmega8-16-32 depending on the optimization of the code and RAM usage for the autotuning.
The ultrasonic level controller that I developed used some DSP techniques from Numerical Receipes and from DSP guide, and never ended RAM (4KBytes) even when I capture a big array of 1700 bytes to post-process on the PC. And I found that many 'math intensive' algorithms that can be implemented in an AVR are not really RAM consuming, but MHz. And then, if I use an ARM, even less RAM can be neded, since I have the power to process it in real time, so I can shurely say that usually the processing power and RAM can be interchanged as a tradeof: pre/postprocessing (Batch processing) on RAM data can be avoided by processing power in real time. And even then, the really hughe RAM consuming resources are usually 'user oriented'. Ie: a micro can work on an status byte, when a human need something like a 'Yes' or 'Not' string as a minimum.
On the other side, I could see that the marked is always demanding (for new applications) more and more features that probably are not needed, that consume tens or hundreds more resources than the real application, like a Web Server enabled thermostat or temperature datalogger. Even the modern desktop computers need more horsepower for the graphical display (a really powerfull 'numer crackers' embedded processors), while the CPU is generally idle or doing something like control windows, keyboard, calculating the bitmap for the fonts and so on instead to write the single byte (or int) for the text that is currently written on the .txt file. So if the application is to write a text, that can be easily done from a command line, why we need all this big graphic card, graphic gui and OS? And what about to play computer games?
Guillem.
Kartman wrote:
Doda, Lotus 123 was written in assembly. This is, of course, history and stunningly successful for Lotus.
What is Lotus 123? :-) just kidding.
Quote:
The market for microcontrollers is incredibly diverse, to say that the ARM will wipe 8bitters is not true. A wash machine controller doesn't need 32bit processing - but it does need super low cost. As one ofthe other respondents mentions that there's still a market for 4bit micros. The stuff us hobbyists work on, cost is not so much the driving issue apart from the cost of tooling up for each processor. Personally, a micro is a micro to me except if its a PIC) it all comes down to the feature set for the task at hand. The techniques for embedded systems aren't tied to a processor architecture, what you learn on one micro is of use on another micro- sure there's differences. So don't get too uptight about 'backing the wrong horse' - there's no right or wrong, just get your feet wet and enjoy the experience. My first processor was the now obselete national semiconductor sc/mp - if someone told me it would die a death at the time I might have been worried. I learnt machine code on that, then the z80 then just about any other micro you'd like to name since then.As for embedded system 'frameworks' - again do your research - there's a few out there.
Part of the skill of embedded systems is squeezing the max out of a constrained system. Sometimes you really have to think about how to minimise the memory required to achieve a goal - this may not be exactly the same as you would on a larger system - like avoiding floating point, large data structures etc. For your application, look to avoid having queues - structure the tasks to work without a queue. If this is impossible, then you need more ram. Simple. Look at how some of the TCP/IP stacks work on small micros - you see a few tricks at work here.
Agreed. I am not saying AVR or 8bit uC is gonna go away, what I am saying is, however, ARM7 is a threat to 8bit uC, particularly the high end AVR's.
Or, let me phrase it this way, ARM7 will open up new frontier that some of the high end AVR might not be suitable, though capable under skilled hands.
Thanks for the advices on TCP/IP stack, I will dig into this. This is another thing that I want to explore -- make my home automation ethernet enabled. I know there are modules out there, like Digi and Lantronix, but I think I have seen some free TCP/IP stack for ARM7, so why not?
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Drifting off topic - but if you want to see some source for TCP/IP that works nicely on an ARM then have a look at the source for Das uBoot - http://u-boot.sourceforge.net/
The network stuff is (perhaps not surprisingly?) in the net/ subdirectory
In fact uBoot is a gentle way into MCU networking as it's kind of a "minimal subset" without all the baggage. You just need to provide a MAC/PHY driver for the interface you have and then you can get as far as TFTP which is a nice protocol for bootloading over Ethernet with TCP/IP
Cliff
I looked also on the STR71x ARM7 from ST.
It has the impressive capability to implement up to 17 interrupt priorities.
But it looks so damned complicated (over 35 pages on the data sheet), that I stopped the development for it.
Furthermore the development software crashed about every 30min and needed always a connection to the target board, even if you only want to write source code.
Peter
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99901 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
I'd compare ARM interrupt systems to something like AVR timers. If you read your average AVR datasheet about timers as a complete beginner you may be confused about all the talk of phase correct PWM modes, out compare pin switching, input capture modes. Yet if you just want a timer to tick in the simplest way possible you can generally do this by nothing more than setting a single CS0 prescaler bit. So it is with "complicated" architectures like the ARM - you don't have to switch on ALL the "bells and whistles" on day one!
Wonder if there's a www.armbeginners.net or something that outlines the basics in the same way that www.avrbeginners.net does? (except that there's too many "flavours" of ARM to speak too generically I guess)
Cliff