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.
Thanks 4the info :)
I must look into these...
Found this website that is served up using one of these.
8 bit MCus will never die. 8 bit will always be inherently cheaper than 32 bit on similar geometries due to die size. 4 bitters seem to have pretty much disappeared, but I think that's probably due to the huge volumes at 8 bit, reduced software development costs and ratio of die use between core and memory/ peripherals.
There are zillions of applications that simply don't need the extra processing power.
I do think however that with the price of ARMs, 16 bit is looking like something of a dead end, and anyone close to filling one of the bigger AVRs or PICs would probably better off going to ARMs
Are there ARMs with power consumption comparable to the low and mid-range AVRs?
They aren't too bad. Kind of like the prior generation of AVRs--fewer low-power choices and not as many power-saving features as V-chips and P-chips.
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.
I'm surprised that the power consumption issue hasn't featured here. Virtually all of my work goes underwater and has to run forever (or nearly so) on batteries, so power is critical. Mips per joule may be comparable for the bare processors, but as soon as you have to go off-chip to access external memories, you start to see some big gulps of current being drawn (big being a comparative term, of course). And even without that, a good mips/J is only useful if you are making use of the mips. Having your code sitting around spinning its wheels while a 10 or 20 or 50 usec external operation takes place is not putting your joules to good use. Similarly for going-to-sleep/waking-up if it involves a lot of context-change/save-restore etc.
I think it's going to be horses for courses for a long time to come. The 'mega2560 is quite a useful animal these days, and can do a lot of work on the smell of a few electrons. But I would love to see an ARM-sized processor with all the flash and sram on-board.
Whoa, sorry all. I wrote the above from my (obviously) out-of-date organic memory, which was imprinted with |processor|external code memory|external dtata memory| etc. It was only after hitting Submit to the last post that I started to wonder just why Atmel had gotten into the ARM business - after all, their forte was flash memory, etc, wasn't it?
I just downloaded the AT91SAM7 datasheet (book).
Another case of foot-in-mouth disease.
Having been away for some time I enjoyed reading this thread. For some 'freaks' things like the ARM will never be viable, just as there are still many folk using 8051's as has been mentioned.
For many of my clients the issues surrounding CPU change are obvious. Legacy codebase is a HUGE factor. We have one client with Z80 based products going back around 25 years. They have SO much code that it was worthwhile to implement a Z80, an 8251 and an 8255 in FPGA for them so they could continue to run their original code.
In fact of all of the processors we have used since my first microprocessor based designs in the 70's the only ones we have been forced to stop using are the 8008 (all ported to 8080 then Z80) and the TI TMS7000 (originally released in 1981 we ran out of stock in 1997 and the application was ported to a Zilog Z8).
We used 8051's for a time, but the products they were used in have died and we have had no requests to use them again. Much of our activity in new designs is based on ARM7 cored parts (NXP & Atmel) with AVRs a close second particularly where we are porting older PIC designs to AVR processors.
Many applications can easily use one or more different processor types. One of my engineers tends to do his hobby projects in FPGA's using NIOS-IIe processors - because that is what he does most work with! I tend to do mine in AVRs or the FPGA-Z80 because I like AVRs but have been using the Z80 since it was first released.
Our progress with ARM7 applications has been excellent due to most of our usage requiring something like NutOS (which we use in all our current ARM projects). In fact the choice of ARM for a number of jobs has been based on the fact that NutOS has an excellent TCP/IP stack and Ethernet support.
There is an interesting ARM dev board at Mikroelektronika.
I never saw so many buttons and LEDs!
I love the looks of it :)
Virtually all of my work goes underwater and has to run forever (or nearly so) on batteries,
This is interesting. What sort of projects are these??
I made an atmega168 board that fits inside a little tupperware box. It has a speaker that doubles as a crude microphone. It mostly just sleeps but every time it wakes up it listens with the mic for a specific tone and when heard it tries to decode and make sense of a morse code message. It responds by blinking bright LEDs or beeping messages back.
The board pretty much consists of just an Atmega168, ne567 decoder chip, speaker/mic and a few other small parts.
It is sitting at the bottom of the pool in the back yard (8ft)...it has been there for like 4 months and still works :)
I just wanted to play with 2-way communications with a device under water...there are not any deep lakes nearby here in New Mexico..drat. I'd love to see what sort of depth it could work at.
It would be SLOW but you could send up images with this. Low-res 640x480 would take a few minutes I think.
You could hide something under water with a device like this stuck to it....years later you could find it by dropping a speaker in the water and telling it to beep back or inflate a balloon and rise to the surface :)
I have some small surplus speakers that have plastic cones...they seem to be waterproof and work well for this.
What about the differences in ARM processors from different chipmakers?
Listened to some people complaining that they were so diffent. Therefore, it is not so easy to use all the different types from different vendors.
And where do ColdFire and PowerPC fit in in this picture?
You are right, there are many peripherals that differ from one manufacturer to another, thus the code is difficult to port. In example, the differences that worry me more are about the interrupt controller. I had worked (not too much) with AT91SAM7S/X family, and tested a little Philips LPC2103, and they differ really much.
Also another peripheral sets, like I2C/TWI (the latter doesn't work as slave with AT91SAM7 family), PDC (AKA DMA), ADC's, serial ports, etc, can change radically how a program could be better written from one manufacturer to another. Specially PDC, is an unvaluable peripheral when one wants to do do comms.
Although Freescale/Motorola was one of the 32 bits pioneers, it seems to be loosing part of the market, but probably it will be really difficult (most probably impossible) to wipe theyr ColdFire from the uC world. Anyway, my two cents for the ARM rise is the cheap toolset (JTAG, like wiggler clones) and free GCC, that makes really affordable for hobbysts. Also cheap ARM's for low volume, the easyness of integration of them into fpga, and the nice opcodes for it also helps.
"Common sense is the least common of the senses" Anonymous.
It appears that merging of 1)ARM. 2)GNU gcc/gdb, 3)IC manufacturers producing ARM microcontrollers, and 4)a large innovative community is responsible for at least the POTENTIAL that ARM microcontrollers may replace 8 bit microcontrollers in the coming years.
Coldfire (Motorola 68k varient) and PowerPC are targets for GNU gcc, yet ARM leads the market for on-chip peripherals. Why? Dunno. I read earlier about legacy code; more legacy code for ARM than for others? Somewhere, something is tipping the scale.
The ARMtdmi core microcrontrollers provide an ability for developers to fiddle w/ the core itself and how it functions, providing more flexibility than other cores.
Overall, maybe the ARM core is at the root of it's success; time tested and adaptable.
ARM can function like a 8 bit microcontroller, but can also function w/ OS similar to the desktop computer - 'portability' of intuitive use? Maybe developers want portablity of code, but the market doesn't care does it? The end user wants the entire desktop capability on a postage stamp.
at least the POTENTIAL that ARM microcontrollers may replace 8 bit microcontrollers in the coming years.
However when a $1 ARM has dropped to $0.20 then presumably a $0.20 AVR will have dopped to $0.04 ?
The packaging would cost more than 4 cents.
I doubt they could sell little chips of wood in a plastic sleeve for 4 cents and make any profit :)
If a processor can do the job you need done then I guess it matters very little if it is 8 or 32 or 64 bit.
If your project might expand beyond the capabilities of an 8bit AVR then starting with an arm makes sense.
If low-power battery operation is most important then the new pico-power AVRs might be a great choice even if they are just 8bit.
Sorry, I've been away for a couple of days. I design instrumentation for a university research department. Multi-axis laser-doppler velocimeters, acoustic doppler profilers, microstructure profilers, drifting drogues, intelligent drogues (can track density, temperature, or simply depth), etc, etc, as well as stationary (moored) systems. DNA analyzer will be an upcoming addition, for species identification. Lots of interesting things, and a never-ending schedule that disappears into the future.
Apart from the moored systems which can use solar panels, everything else is either SLA or alkaline batteries. Lithium tends to be too expensive.
Hey! that sounds like a description of a lot of the guys in this town :)
Seriously, your projects sound very very cool! :)
... Lots of interesting things, and a never-ending schedule that disappears into the future...
Roger, I am curious, reading about your work...
Let's say that a mysterious force from nature wiped all microcontrollers from the face of the planet. You have the capability of bringing forth one and only one core w/ 6 different peripherals. Your choice will remain for the rest of your career.
With the wave of your hand, what would you bring forth?
what would you bring forth?
Although for something bigger (or equal?) than, let's say M32, then ARM >>are<< a choice, for price, processing power, peripherals, etc.
For smaller micros/applications, right now, they are not a choice, and I thing this will take more time every step down in size.
In my humble oppinion, is not bad to know both technologies, and I would recommend to start with 8 bitties, then switch to bigger ones before jump to ARM's. The latter are not so difficult if one has experience with the 'big guyz', but for a novice...
IMHO the biggest problem with ARM is that they don't train people from complete amatuers. You have DIP AVRs, you have turbocheap programmers, free everything. AVRs are simply amatuer friendly.
And in time some amatuers evolve into pros and what they liked as younglings they will like as elder geeks.
There are pointy haired bald people.
Time flies when you have a bad prescaler selected.
"one and only one core w/ 6 different peripherals" is a tough one. I'd probably give up EE and become a photographer for Playboy...
Before going on to that, you should be aware that the instruments I mentioned previously also use many other processors in conjunction with the AVRs e.g. the laser doppler system uses four Analog Devices DSPs in a dual-pipelined arrangement, and some of the others use 1 or 2 DSPs. Most of my work wouldn't be possible without devices like that. For the most part I use AVRs for system management and control, and manipulation of some of the slower signals. Even then, the 8-bit architecture has me grinding my teeth sometimes. But they are so easy to integrate from both a h/w and s/w point of view that you live with it.
However, to answer your question: If it had to be one of the current off-the-shelf devices, I'd go for the mega2560. The ARM series subconciously irritate me. I don't know why, because they have a number of features that appear most desirable, quite apart from the 32-bit architecture e.g. control of the clocks for various peripheral systems etc, which on paper seem to lead to fairly good power figures. I'll really have to do an ARM project, just to either confirm or erase that irritation.
My ideal would probably lie somewhere between the mega2560 and an ARM-style processor. It must have lots of pins - at least 100 - and the ability to crunch more than 8 bits at a time. Multiple register sets for fast context switching of several high-priority tasks/interrupts, and I really do like instruction sets/architectures that set condition codes with load/move type operations. When you're really counting the microseconds in an isr or some-such, it can help.
© 2020 Microchip Technology Inc.