Has ARM destroyed market for 8 bit micros?

Last post
186 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seems every job around now use ARM for everything. Are 8 bit micros becoming extinct?

:cry:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

HELL NO!!! :(

The 8051 is a great example. The bugger is still used in new designs and there are so many variants with added features.

Plus look at some of the designs out there. Do you really need an ARM when a simple 8bit avr can run a programmable thermostat?

If 8bit micros are becomming extinct, the Mfr.s would be dropping some warnings like EOL, oe Not recommended for new designs....

I personally hope the 8bit micro never dies because I cannot count past ten ;)

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CC58 wrote:
Seems every job around now use ARM for everything. Are 8 bit micros becoming extinct?

:cry:


May be... in a couple of tens years... Not yet. I believe so.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And some 8 bit MCU cores are part of bigger ICs, like USB memory card readers, USB flash drives etc.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

I personally hope the 8bit micro never dies because I cannot count past ten ;)

Jim


I also think so. I prefer using 8-bit uC where they perform their work completely well and theirs features are enough.
Of course I've been learning ARM (LPC2468) to know much more. But I don't want to use TQFP (more than 100 pins) or BGA package for a simple device like a climate control or something else.

But for main processing unit ARM is vacant. Why? Because of its ability to work with SD-cards (not only in SPI-mode), because ARMs have a lot of interfaces (Ethernet, CAN, USB and so on), because they can run desktop OS (Windows, Linux and so on...) I know much of them we can make using AVR. But I say about full-function ones...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not this same old thread for the five billionth time. Did you even bother to search to see if this had been asked before?

I'm tempted to lock this as yet another cross-post, but I suppose the situation varies every few months as more and more cheap Coretex M0 and M3 become available.

BTW I don't know why Leon saw the need to try and advertise MCHP devices for the bazillionth time either. If the argument is that 8bit manufacturers continue to make new 8bit devices that's as true for AVR as anything else. There's just been a whole raft of new USB enabled Xmegas released for example.

Moderator.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
And some 8 bit MCU cores are part of bigger ICs, like USB memory card readers, USB flash drives etc.

Yeah. Let's remember old RS-232 (USART). It is still used. Where? In USB CDMA modems, for example. Connect such modem to Windows or Linux-based PC and you'll see at least one or even two serial ports. One port can take AT-commands, another one can take binary data.
Let's look at Bluetooth dongles. The contains Bluetooth module inside equipped with serial port that exchanges with PC through USB/Serial bridge...
As far as I know serial port lives since 1960s...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Connect such modem to Windows or Linux-based PC and you'll see at least one or even two serial ports.

You do know they are not real don't you? The whole reason they are called V-COMs is because V=Virtual - they don't physically exists - only logically. The hardware is USB and it's all but taken over from RS232.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, most beginners want using the ARM.
Because they are thinking, that bad program flow and bad programming style can
be compensated by bigger data width, faster clock and bigger memory.
But this was a mistake. :!:

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CC58 wrote:
Seems every job around now use ARM for everything.
The key word here is "seems".

They simply scream louder, sorry, have better publicity.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are wise Peter, some people will wrote a bad application on a 700MHz 32bits ARM with Embedded Linux that drive an LCD display, and some others will write the same application on a 16MHz 8bits CPU...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
only logically. The hardware is USB and it's all but taken over from RS232.

Of course I know :-) But RS232 logic is still inside. Why? Isn't there any progressive protocol? I thing it's been done for compatibility with old software, for example.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Magister wrote:
You are wise Peter, some people will wrote a bad application on a 700MHz 32bits ARM with Embedded Linux that drive an LCD display, and some others will write the same application on a 16MHz 8bits CPU...

Yes, it's right! But there are a lot of task where ARM is really needed. Everyone choose his way to build a system. He can take ARM, he can take AVR, PIC, STM8 and so on...
But it should be wise choice.
I saw some tries to implement video processing on AVR(8), PIC(8). I think it must be study task not real product...
It should be taken into account that people use familiar instruments. And it is sometimes obvious if someone (who knows AVR very well) tries to make video compressing on AVR :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's just say it's amazing that for less than the price of a mega48 one can get an ARM with 2x the flash, 4x the RAM, more than double the raw speed, better timer capabilites, more IO, 1% internal clock, etc.

But mega48 has 5V operation, much better output drive, EEPROM, among other advantages. Since I need some of those in my latest project, I'm using the AVR part. But now for every design I look first at ARM, and only if it doesn't cut the mustard do I look at 8 bit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And you can have this for $25...
http://www.raspberrypi.org/archives/106

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

And you can have this for $25...

No you can't. See:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=115370&start=0&postdays=0&postorder=asc&highlight=

Then:

http://www.ebay.co.uk/itm/Raspberry-Pi-Model-B-beta-board-10-limited-series-10-/180786734741?pt=LH_DefaultDomain_3&hash=item2a17baa695#ht_500wt_1334

So the current price for that board (of which there only actually appears to be one so far) is £1,900 !

(you will see my cynical suggestion that this may be deliberate to sell a handful of boards at a stupidly high price to the first idiots that turn up - I still believe that - see also my comment about €35 buying this: http://www.watterott.com/de/FriendlyARM-Micro2440-64MB - I confirm that really exists as I've used one and it is phenomenal value for money)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, the beta board was bought and gave to a museum (and they sold 10 beta boards, not one).
Also they started manufacturing the Pi in China, so wait a couple of days/weeks before seeing it.
http://www.raspberrypi.org/

If it's really $25, even $35, I will test it for sure :)

A quick google search gave me a couple of link that should be trusted, I still highly doubt it's vaporware.

http://arstechnica.com/gadgets/news/2012/01/raspberry-pis-35-700mhz-linux-computer-enters-manufacturing.ars
http://www.reghardware.com/2012/01/13/raspberry_pi_foundation_rolls_out_linux_based_pcs/
http://www.engadget.com/2012/01/11/raspberry-pi-begins-production/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh I'll grant you they have a great marketing department. Either T3 or Stuff even mentioned the thing. But having worked for a company that used to have one of the most aggressive marketing departments you've ever met I know it doesn't actually take much to circulate a sexy looking press release and get it listed as news in various magazines, websites and so on. The proof of the pi will be in the eating I guess!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Microchip is the market leader in 8-bit devices. They recently announced several new 8-bit chips with some interesting new features, as well as 16-bit and 32-bit devices, so they must believe that there is a market for them.

I don't like Microchip's spaghetti approach: build it, throw it at the wall and hope for something to stick.

Instead of reducing the errata on their dspic stuff they're releasing more and more designs.

Last Edited: Fri. Jan 13, 2012 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are far more, and much more serious, errata for the Xmega devices.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey Leon,
I was wondering, have you ever done a design using an avr and not going near your beloved Mchp? Where you used the avr because it was the best chip for the job?

I have yet to see you support Atmel without bringing up the "M" word in some fashion.

Just for the record so I don't sound hypocritical, I am using a Mchip eeprom in something I am working on because it was the best chip at the moment. It came in DIP packaging so it fit in my breadboard.

.....The final product though will have an smd part TBD

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use whatever device seems best suited to the job in hand, and have used an AVR on several occasions.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I use whatever device seems best suited to the job in hand, and have used an AVR on several occasions.

By choice?

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I'm working for a client, I take his wishes into account, of course. I even used a large PIC with three 2313 AVRs on the same board, on one occasion.

Leon Heller
G1HSM

Last Edited: Fri. Jan 13, 2012 - 08:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question answered.

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
There are far more, and much more serious, errata for the Xmega devices.

Seriously, with this being a none issue with the A4U devices, how do you expect us to believe your false statement .

Errata on both sides is grounds for recall. The only difference is that Atmel has already addressed the errata with the new devices, which you conveniently omit.

Meanwhile, Microchip users are expected to live with their buggy chips. I have seen no serious progress on Microchip's part except for the release of more buggy devices.

Also, have you actually programmed an Xmega? Users here assume you have done so yet you have not posted anything to prove it.

You are not here helping readers with their issues, or bringing insight to their projects. In deed, after going over several of your posts, it seems your intentions with your comments have a different agenda: Sir, you seem to be here mainly regurgitating competitor propoganda.

If you want us to respect you as a poster than contribute to forums other than what your employer expects of you as a Microchip employee.

It bugs me that most of the threads involving your participation have to end this way.

I apologize gentlemen, but somebody had to address this white elephant.

It also bugs me that the moderators are too diplomatic to not have done something about this considering that this is an AVR fan site!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I bought a couple of Xmega chips when they first came out, some years ago, and started designing a PCB so that I could try them. I lost interest in the project when I saw the serious problems there were with the devices. Atmel made no attempt to fix them.

An Xmega board using the A4U is on its way to me, I'll be able to see how it compares with the 16-bit PICs for myself.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
Atmel made no attempt to fix them.
That is absolutely not true!

How stupid do you think the folks at Atmel are? Do you really think they've made no attempt to fix the errata for the Xmega? Do you really think the company is suicidal? Microchip (and all other major players ) release chips with errata and they try to fix them. You know this is true so why can't you give the same credit to Atmel?

Look at the more recent releases. From what I'm seeing most of the more significant problems are already fixed. And they are ramping up delivery.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And since I'm in a rant mode, back on topic. For the past 20 odd years or so I've snorted every time I see the prediction of the imminent demise of the 8-bit microcontroller. These predictions seems to happen every couple of years and it ain't happened yet. One of the things people don't understand is the the market is expanding so when new more powerful systems start to get traction, and take total market share, it may not matter in an expanding market since the devices with smaller total share may still be experiencing profitable growth. If I have a market that doubles and I loose 40% total share, my sales still increase.

That said, for the first time I'm thinking these 32-bit ARMs may just move into the space formerly owned by the 8-bitters. With the shrinking die size and prices for these things all that stands in the way is the learning curve. I hear that ARMs typically have multi-thousand page data sheets, and little I've heard here make me think that implementing an ARM design would warrant the extra work I'd need to do when the AVR does the job and I already know how to use it. I can't be the only person who sees this, so I fully expect to see easier tools to be made available and then things like the BeagleBone might become not just cheap but easy.

I think the 8-bit market will continue to increase - though probably not as fast as the overall market for CPUs. But the 8-bits may just end up under epoxy blobs on Chinese commodity products and the sort of stuff we do may well migrate to 32-bits.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Z80s are still for sale.

Anyone remember International Theophysical Year?
Someone, please answer "Yes."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm a big champion of the ARM family, from small to large.

I do have some reservations that ARM Holdings, Inc. owns the intellectual property. Qualcom's Snapdragon, used in many smart phones - has Qualcom a licensee. As are hundreds of others. Maybe ARM holdings (non-fab) is better than the ARM being proprietary to a chip vendor like AMD or Intel. At least ARM Inc. will license anyone with the dough to sign up.

This is different than the 8051 being licensed to quasi competitors.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just as a point of info, I checked the mega48 datasheet - 448 pages - and the LPC111x (the part that sells for less than a mega48) data sheet and user manual - 490 pages combined.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You also want the user manual for the CortexM0 family, 326 pages.

If we take stm32f107 as an example we have data sheet 96 pages, reference manual 1072 pages, programming manual 154 pages, Cortex-M3 technical reference 384 pages. That's 1706 pages.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When you come to real volume stuff like the chip on a bank card what is it?

I work at the other end and would happily pay a lot more for a chip that was a lot better (fast and easy to program) but dont know what that is either.

John

If all else fails, read the instructions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
leon_heller wrote:
Atmel made no attempt to fix them.
That is absolutely not true!

How stupid do you think the folks at Atmel are? Do you really think they've made no attempt to fix the errata for the Xmega? Do you really think the company is suicidal? Microchip (and all other major players ) release chips with errata and they try to fix them. You know this is true so why can't you give the same credit to Atmel?

Look at the more recent releases. From what I'm seeing most of the more significant problems are already fixed. And they are ramping up delivery.

Smiley

They never fixed the bugs in the original devices, AFAIK, and it's taken them many years to release relatively bug-free versions. The original Xmegas were probably the most "bugfull" (a word used by one of my students in an essay) devices ever put into production!

The new A4U parts do seem to have few bugs.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

With the shrinking die size and prices for these things all that stands in the way is the learning curve. I hear that ARMs typically have multi-thousand page data sheets, and little I've heard here make me think that implementing an ARM design would warrant the extra work I'd need to do when the AVR does the job and I already know how to use it.

Take any datasheet for an ARM, a MIPS, an MSP430, an AVR, whatever and read the chapter on the CPU/ALU and system memories. How many pages? 20 to 50. That is what differentiates an ARM from an AVR from an MSP430 from ...

Now if the rest of the datasheet is 250 or 500 or 750 or 1000 pages then surely it's simply reflecting the number and complexity of the peripherals the silicon vendor has chosen to dot around the core. I imagine the ARM that has 1000 pages has complex devices like DMA and PIC and SDRAM refresh and so on. If you took an AVR and gave it all those devices then I imagine for it too the data would be 500-1000 pages too.

Now dig out the (two) manuals for the top of the range Xmega and sum the number of combined pages. Are we not in "ARM territory".

So datasheet length/complexity has a whole lot to do with how many complex peripherals have been added to the core and very little about the core itself.

An ARM core is different to an AVR (interrupt handling especially) but I would not have said it was really any more complex - just different that's all.

This is why I never understand this reticence to use ARM because they are "far more complex". Switching AVR to ARM is no more complex than AVR to PIC. It's just different but an 8 bit to 8 bit switch is really no more complex than an 8 bit to 32 bit.

It'd be interesting to hear here from any who've switched from AVR to UC3 - how did you actually find it? (maybe also interesting to hear from those who switched from AVR8 to Xmega in fact ;-))

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are some 32-bit devices with multiple cores such as the Parallax Propeller and XMOS chips which have their peripherals implemented in software. They have data sheets which are much shorter than those for 8-bit devices.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

It'd be interesting to hear here from any who've switched from AVR to UC3 - how did you actually find it? (maybe also interesting to hear from those who switched from AVR8 to Xmega in fact ;-))

I've been using AVRs for a little over a year, and though I don't know about UC3, I just started a project at work using an AT91SAM9 series processor. My experience is in line with what you're saying - the data sheet is mostly descriptions of peripherals. (It's also missing information, and Atmel tech support has been less than helpful, but that's another story.)

We're running a version of linux that was patched for the AT91, and writing drivers can take advantage of special purpose code in the kernel, so it's not nearly as complicated as I thought it would be.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

We're running a version of linux that was patched for the AT91, and writing drivers can take advantage of special purpose code in the kernel, so it's not nearly as complicated as I thought it would be.

Yup I've done that (AT91SAM9G45 in fact) and really enjoyed the experience. In fact the drivers for SAM9 that Atmel have provided in the kernel are so much better than their attempts at other "software libraries" (eg ASF) that programming it is really little more than "plug and play" (a bit like grown up Arduino in fact!). I guess this is because they have had to make their drivers adhere to the well designed and documented Linux driver model so you know most of it before you start.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting discussion again.

It does raise the question of why drop an 8bit down when an ARM actually costs less? To me, it would not matter that 90% of the chips muscle would go to waste if a final product cost me $2 less to manufacture. It just makes the most sense really.

But the learning curve!

That's what holds me back. I am a cycle counting assembly freak and always will be. It takes me much longer to code anything in C than it does in assembly, and I always like to know exactly how many cycles everything I code takes. It is an obsession. I tried this in an ARM and failed horribly.

C on AVR or ARM seemed about the same using either Codevision or CodeRed, so if I was to code in C and bring something to manufacture, for sure it would be an ARM. No point paying more for less power, right?

From my failed experiments, I have concluded that ARM cannot be cycle counted and coding assembly is going to be a lost art. With so much bang for the buck, just drop a load of spaghetti on the compiler and let it patch up the bleeding edges. Certainly not saying all coders do this, but now bad coders could do this.

Yeah, I am an AVR assembly fan boy all the way and the only way I will part with my single cycle instruction set is from my cold dead hands!

But I am sure tempted by the thought of cycle counting on a $2 chip that can push 75MHz! Hmmm... that's what FPGAs are for.

Dear Atmel, please give your loyal fans the following...

ATXmega-II
- 512K program space
- 512K internal SRAM
- 32,48,52,78 IO pin variants including DIP
- 100MHz internal clock speed
- 256 working registers r0 to r255
- ability to execute code from external SRAM

And price this new chip to be competitive with ARM.
Let me know when the first batch of silicon is ready so I can test them for you.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jhalpin wrote:
We're running a version of linux that was patched for the AT91, and writing drivers can take advantage of special purpose code in the kernel, so it's not nearly as complicated as I thought it would be.
Running a 32-bit chip with Linux isn't more complicated than running an 8-bit chip with a while(1) loop in main()?

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I tried this in an ARM and failed horribly.

Why is Asm and cycle counting in ARM any more of a problem than doing it in AVR? I cannot see it myself.
Quote:

I have concluded that ARM cannot be cycle counted and coding assembly is going to be a lost art.

Nope still not getting it.

BTW the LPC1769 can do 120MHz not just 70MHz.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

I tried this in an ARM and failed horribly.

Why is Asm and cycle counting in ARM any more of a problem than doing it in AVR? I cannot see it myself.
Quote:

I have concluded that ARM cannot be cycle counted and coding assembly is going to be a lost art.

Nope still not getting it.

BTW the LPC1769 can do 120MHz not just 70MHz.

It becomes difficult to impossible to cycle count on an ARM due to the pipeline. There are many good discussions on this, and most end up with the agreement that it is not really feasible.

http://electronics.stackexchange.com/questions/16424/cycle-counting-with-modern-cpus-e-g-arm

I managed to do some video but had to resort to PWM or timers, which is severely limiting in the end.

AVR is just awesome for assembly programming whereas ARM assembly seems reserved for the clinically insane hacker. One day I hope to learn it well!

LPC1769 and Cortex M0 are the ones I mess around with.

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Personally I've never needed to look at the ARM core manuals, beyond the few pages that describe the NVIC registers (oh, and the system tick stuff). Maybe the target audience for those are people implementing the cores on their own devices?

And clawson is exactly right, that most of any datasheet/manual is about the peripherals anyway. 98% of the time I look at a datasheet/manual, it's to search out new info for some peripheral, or to look up electrical info or package info.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the piepline is deterministic isn't it? The only thing that upsets pipelines are when branches are taken but even that behaviour should be deterministic too (if it weren't how could the ARM core execute it!)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I apologize gentlemen, but somebody had to address this white elephant.


You owe no one here an apology. Especially me, I am the first to admit, that I don't use ATMEL exclusively..I use the AVR exclusively, but I do not always use their CPLD because they do not make one bigger than 128 macrocells.

In fact every one of us uses other devices besides Atmel at times. You have to. But unlike Leon we don't come back time and time again and hawk the other guys wares. It is basically rude.

Quote:
It also bugs me that the moderators are too diplomatic to not have done something about this considering that this is an AVR fan site!

I agree, they are beyond polite. A while back they managed to ban a jerkoff that was taking code from the site, posting it on his as his own.

Why Leon continues to get away with it is bullsh**. I used to find him amusing, then just annoying, but I elevated him to a total DB.

Our elders drummed it into us to just ignore DB's like him and they go away. Too bad there is no ointment that can get rid of this DB of a rash. The moderators won't. I probably will get kicked out for saying what has been on other peoples minds for a while.

And to Leon, unless you can provide help, or positive information when someone is talking about ATMEL AVR's

SHUT THE F*** UP!!!!

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
But the piepline is deterministic isn't it? The only thing that upsets pipelines are when branches are taken but even that behaviour should be deterministic too (if it weren't how could the ARM core execute it!)
Is it documented where mere mortals can find it?
Is it simple enough that mere mortals could use it?
Is it consistent between chips?

Anyone remember International Theophysical Year?
Someone, please answer "Yes."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jesus tapdancing christ Leon. Atmel aren't about to go to everyone's house and personally desolder every first revision XMEGA and replace it with a newer version. The latest XMEGAs fix all the old errata, what more do you want?

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
what more do you want?

For you to jump ship to Micro... ;)
THAT would tilt the earth I am sure

Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What has caused all the complaints about the Xmega has been the length of time that has elapsed before the bugs were fixed. Why couldn't Atmel fix them earlier?

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why couldn't Atmel fix them earlier?

Look at the silicon revision of the released silicon. The new chips went through an enormous amount of testing to try to prevent you from having any more whining fodder.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I noticed that, they are Rev E.

It's not just me that has complained about the earlier Xmegas, have you seen all the negative comments about them?

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
jhalpin wrote:
We're running a version of linux that was patched for the AT91, and writing drivers can take advantage of special purpose code in the kernel, so it's not nearly as complicated as I thought it would be.
Running a 32-bit chip with Linux isn't more complicated than running an 8-bit chip with a while(1) loop in main()?
Smiley

Yes, of course it's more complicated than an AVR. It isn't as complicated as I thought it would be.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Running a 32-bit chip with Linux isn't more complicated than running an 8-bit chip with a while(1) loop in main()?

Linux is just an environment (that happens to provide more pre-canned computing services available to the programmer than any other system bar none). It's no real different to, for example, FreeRTOS. I can write a program:

#include 

int main(void) {
  while(1) {
    printf("Hello world\n");
  }
}

build and run it on a Linux system and it does exactly what it says on the tin (in fact I guess it would do the same in MS-DOS too). In that sense writing a program that runs under Linux is no real different to writing one that runs under Windows or FreeRTOS or whatever other 8 bit "RTOS" you care to mention.

True, in Linux you cannot just say:

PORTB = 0x55;

but you can say:

ioctl(link_to_my_PORTB_driver, PORTB, 0x55);

and then have a small piece of kernel code that makes h/w access to PORTB.

This sounds complex - it isn't really.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It's not just me that has complained about the earlier Xmegas, have you seen all the negative comments about them?

Yes I have, and those comments are why we now have fixed versions. I was pointing out the reason for the lengthy delay.

Quote:

For you to jump ship to Micro... Wink
THAT would tilt the earth I am sure

Actually funnily enough I would never work for Microchip, and Leon is the reason why. I considered an offer from NXP before signing on to Atmel, but however irrational it may be I now associate Leon with the Microchip brand and so wouldn't/couldn't take up a job working at Microchip regardless of pay.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, you may rue the day you made that comment. I paid dearly for saying something similar years ago. Company loyalty is good, but things change.

I don't know why you guys are dumping on Leon in this instance. He stated a fact that no one has disproved - brand X sells more chips. We all know ( or should know by now), that Leon is not wedded to any one brand. Seems what is practised here is "brand racism". It probably doesn't happen in other similar forums as people there don't give crap.here there a very few unanswered posts, compare this with some other forums.

Let's face it, how much of the advice that is given here affects Atmels bottom line? Well, apart from the canning of the xmega?

Leon, in order to assuage the ruffled feathers here, maybe refer to the unmentionable company as "brand X". Not sure how we would refer to the other competition, eg TI could be " brand Y", ST as "brand S" and NXP as " brand N", Zilog would be "brand Z" then.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Dean, you may rue the day you made that comment. I paid dearly for saying something similar years ago. Company loyalty is good, but things change.

To be clear; I could certainly work for other companies one day, it's just Microchip that I wouldn't work for due to Leon's influence. I'm not narrow minded to the point that I am willing to live and die by Atmel (although I do like Atmel a lot for obvious reasons) but every time I think about Microchip I get a weird repulsive shiver when I think of his posts here. Irrational, but there it is.

Quote:

Leon, in order to assuage the ruffled feathers here, maybe refer to the unmentionable company as "brand X".

I really, really don't want to get into this here again, especially given my time is limited now that I'm working. Leon's behavior here has been ranted about to death by myself and others many times, and while I would love to (and now can) delete his account I would rather save my breath and assist others instead.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used to be an Atmel fanboy RAH RAH!. Then I realized that nobody at Atmel was a: aware of AVR Freaks, or b: gave a sh**. Long gone are the days of 'My microcontroller can beat up your microcontroller' and promotions such as the AVR Man Super Hero. Replaced by the land of the timid sheep bah bah. So we are forced to put up with obvious trolls that any other self-respecting forum would block. If you guys grow a pair and start acting with reasonable defense of yourselves, I might just pick up the flag again myself. Until then, rah freaking rah.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Dean,
While it is refreshing to see someone from Atmel show some bollocks for a change, if I were you I would keep a low profile as grandstanding about an ability you now have could be taken in the wrong tense and cause you more grief than it would be worth.

Leon is a DB, and as noted he is a rash that won't go away. I for one am going to do my best not to allow the DB to get under my skin. The rest of us should just IGNORE the DB and keep to the topic in the thread.

As for the administrative staff whomever they may be, along with the pair that you have been requested to grow, might I add that you also look into a stick to go with it....OR whenever someone signs up for an account, before the account becomes active a warning of a DB disquised as a cat lurks within.

Every dog has his day. Let's hope the cats 9 lives are up soon as well.

Jim

Edit: I spelled the DB's name wrong....sorry :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dean, you mentionedMicrochip! It's now Brand X. This is part of the re-education. Brand X, doesn't it just roll off the tongue and none of the bitterness. the advertising industry figured it out years ago.

Leon, whenever you want to mention the unmentionable, use Brand X. If someone asks what is Brand X, leave it to them to figure out. If someone says Microchip, you respond with Brand X.

All solved guys!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This is funny question IMHO. Of course the 8-bit MCU market is not destroyed and certainly not by ARM.

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?

In our applications we run a 8-bit MCU at 1.8MHz. The MCU market is way bigger than all the 'heavy' application which need high speed MCU's. People tend to forget that there is a world outside their own designs...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Now for Atmel, Microchip or any other controller: main concern for us is: will the MCU we use still be available in 10 years and more?

There is no best, they are all evil buggers protecting their own product by making porting as difficult as possible.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I don't know why you guys are dumping on Leon in this instance. He stated a fact that no one has disproved - brand X sells more chips. We all know ( or should know by now), that Leon is not wedded to any one brand. Seems what is practised here is "brand racism". It probably doesn't happen in other similar forums as people there don't give crap.here there a very few unanswered posts, compare this with some other forums.

I agree 100%. The mantra may get a little boring, but Leon is honest.

Perhaps if he offered constructive advice when appropriate, people would be less offended.

As a general rule, you can do most things most of the time with an 8051, AVR, PIC, ARM or whatever. Sometimes one family is easier / faster / better / cheaper than another.

It seems quite reasonable to point out these occasions. All the same, design choices are made on several criteria. So you choose one family even though it is not ideal for one particular task.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?

Only if a chip offering all the facilities you need in your design happens to be cheaper than the 8bit you were previously considering. Sure it may have 8 times as much flash and 4 times as much SRAM but if it's cheaper who cares? That (IMAO) is the real threat to 8 bit - when chips with the same spec or higher start to cost less why wouldn't you switch?

The arguments used to be (a) ah, but 8 bit are in DIP and I need that for small production runs and (b) ARM limits me to 3.3V design. Well apart from the fact that there are now (a) some ARM in DIP and (b) some 5V ARM, the fact is that most small (100 to 1000 units) producers can (a) now cope with SMD and (b) can find most solutions for the design in 3V3 anyway - in fact things like SD/MMC push them in that direction.

PS let's not make this thread about Leon and Microchip - he's ruined enough threads previously - don't let this be just another casualty - keep it on on-topic about ARM v 8bit

(Atmel probably wouldn't want us discussing even that here on their 8bit message board if it were not for the fact that they make quite a range of ARM and now Coretex themselves so you can stay loyal to Atmel).

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Power consumption is an important consideration these days, which no one has mentioned. I can't see any 32-bit device approaching the power consumption of many of the current low-power 8-bit chips, they simply have too many transistors.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

they simply have too many transistors

Does an M0 really have more transistors than, say, an Xmega?

(the core price of chips is set by their silicon area, which is set by the number of transistors. The fact that some M0 cost less than 8bit seems to suggest they may actually have fewer transistors in fact).

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking of smaller devices than the Xmega, which typically consume 20 nA or less in deep sleep mode. The low cost of some 32-bit parts is probably more to do with the manufacturing process than the number of transistors - they get a lot more die out of a wafer than is possible with the less advanced processes used for most 8-bit devices.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does an M0 really have more transistors than, say, an Xmega?

(the core price of chips is set by their silicon area, which is set by the number of transistors. The fact that some M0 cost less than 8bit seems to suggest they may actually have fewer transistors in fact).

Hmmm--There is still "what the market will bear" factor.

Does a Mega329 have less transistors than a Mega169? No? Then why did, for several years, the '169 price be higher than the '329 price?

A certain model could even be a loss leader--lose only a penny each but make up for it in volume. ;)

In general I'd assume that the cost to produce corresponds to the selling price.

[In the 1970s a model of mainframe computer had twice the clock speed/performance of the next lower model. And cost many $10000 more. One changed from the slower model to the faster model by snipping a clock-divider jumper on the backplane.]

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

jan_dc wrote:
This is funny question IMHO. Of course the 8-bit MCU market is not destroyed and certainly not by ARM.

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?


But what if all that unnecessary RAM/ROM came on a chip that still cost less? Surely you wouldn't buy the more expensive chip just because it was 8 bits, or had less RAM/ROM, any more than you'd buy a 6.3v 0603 cap that cost more than a 10v 0603 cap, because you didn't need a 10v cap.

Quote:
In our applications we run a 8-bit MCU at 1.8MHz. The MCU market is way bigger than all the 'heavy' application which need high speed MCU's. People tend to forget that there is a world outside their own designs...

There's no penalty in running a fast micro slowly.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
I can't see any 32-bit device approaching the power consumption of many of the current low-power 8-bit chips, they simply have too many transistors.(...)I was thinking of smaller devices than the Xmega, which typically consume 20 nA or less in deep sleep mode.

This is not a power consumption but a power-down current.
Don't you think it does not matter what the power-down mode current is, as far as it is within the order of magnitude of self-discharge rate (shelf-life) of the cell/lemon that powers it?

Lets face it: the smallest commercial batteries are about 40mAh, which, with 20nA discharge rate give:

40e-3Ah/20e-9A=2e6h (of sleeping time).

Do you know how long it is? I don't, but it falls somewhere in XXIV-th century.

Why does it matter if the chip has below 20nA deep sleep current, or below 200nA, like CM0? Or below 100nA like P-AVRs? What is the advantage?

Perhaps if there were 0805-like cheap-as-dirt 5mAh cells that have the shelf-life of 50 years.. But I have never heard about those.

@leon_heller
Could you give an example of the (hypothetical) application where such insanely low power-down current would be of any practical value other than a marketing slogan for the manufacturer?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Consumptions in other modes are typically very low, also.

Such devices are claimed to be useful for applications where a single cell has to last for up to 20 years. Power by energy harvesting is another area.

I can't see 32-bit devices being suitable for such applications.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Hmmm--There is still "what the market will bear" factor.

Does a Mega329 have less transistors than a Mega169? No? Then why did, for several years, the '169 price be higher than the '329 price?


Lee, I take your point but I was talking more "industrial pricing" where market economics don't usually play too much part and silicon tends to sell at "cost + 10..30% profit for silicon vendor". In that realm silicon area is key.

BTW Leon is wrong - Atmel closed their fabs and contracted out to modern fab plants so the whole point of all the "A" devices is surely that they are now being made on a fairly contemporary process (0.12um? maybe smaller still?) which is probably very similar to M0/M3 in fact.

Quote:

I can't see 32-bit devices being suitable for such applications.

Someone tell my mobile phone!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking of applications which don't need a lot of processing power that might have to run for months or years on a single cell.

Leon Heller
G1HSM

Last Edited: Sun. Jan 15, 2012 - 07:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My crystal ball says that someday they'll put an ARM with all the desirable peripherals and pre-programmed with Arduino-simple methods to use them, all on a sub $1.00 chip. And since the silicon will be so tiny that it will be a sub 1 volt device that uses almost no power, so they will build in a battery that lasts 20 years. The PC will be so powerful that you'll just tell it what you want you micro to do and it will write the program for you. And my wife will leave me because I'm spending too much time with my sex-bot.

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That might happen, but 8-bit devices will be needed for a good few years yet.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I was thinking of applications which don't need a lot of processing power that might have to run for months or years on a single cell.

Past a certain point, the biggest issue is self-discharge of the battery cell. For some appplications super-super-super low power is great, but in most cases the battery will deplete itself at a rate faster than the processor is consuming it anyway.

Quote:

My crystal ball says that someday they'll put an ARM with all the desirable peripherals and pre-programmed with Arduino-simple methods to use them

If I remember right Arduino is branching out into the ARM devices, so your future might come faster than you'd think. Who knows what we'll all be using in 10 years time, if the software tools catch up to the device complexity.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
jan_dc wrote:
This is funny question IMHO. Of course the 8-bit MCU market is not destroyed and certainly not by ARM.

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?


But what if all that unnecessary RAM/ROM came on a chip that still cost less? Surely you wouldn't buy the more expensive chip just because it was 8 bits, or had less RAM/ROM, any more than you'd buy a 6.3v 0603 cap that cost more than a 10v 0603 cap, because you didn't need a 10v cap.

Quote:
In our applications we run a 8-bit MCU at 1.8MHz. The MCU market is way bigger than all the 'heavy' application which need high speed MCU's. People tend to forget that there is a world outside their own designs...

There's no penalty in running a fast micro slowly.

ok, I was a bit unclear I'm afraid. I'm not talking about mega and xmega cores. I'm talking about tiny stuff. Of course if a 32 bit fits the job and is cheaper, I'll use that. Haven't found any 32 bit yet that is overall cheaper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Such devices are claimed to be useful for applications where a single cell has to last for up to 20 years.

Either it is some niche market of tailor-made devices you mention (medical? aerospace?) or there is a technology I am not aware of. AFAIK the longest shelf life of the batteries are the lithium type primary cells which are capable of 10 years shelf-life/operating life (and perhaps 15 years with some extra design and conditions).

Are there any 20 years*20nA= +- 3,5mAh cells on the market?

What I wanted to ask about was

Brutte asking Leon Heller wrote:
"How is an engineer like me able to exploit the 20nA feature using contemporary technology?"

because you didn't give the direct answer. I understand there are 20nA chips, but are there "20nA compliant batteries"? I am sure Brand X made a significant (and costly) effort to compete with Brand N to reduce the leakage of their design. If they did it - great, but how am I able to use their product? Some kind of reference design, success story?

A device designed to be capable of running 20 years is rather peculiar. If the device has to perform some useful computations, apart from being in deepest power-down, the 3,5mAh is playing less and less significant factor in the total energy consumed when the computations demand (taken as a variable in the design) rises. So I can imagine a hypothetical device which runs for 19,999 years pretending dead, just to blink a LED on it's twentieth birthday. Even then the feature is pointless because we are not able to buy the 3,5mAh battery.
I personally doubt that any of the commercial battery manufacturers can guarantee his product is able to withstand this time (self-discharge current manufacturing variations).
If we assume a more reasonable 10 years operating time, rising the active time requirement we come to a point where there are batteries of adequate size available, but then even a 10x1,7mAh=17mAh leakage current(200nA) is still insignificant.

My conclusion is that I do not really understand why did Brand N make an effort to design LPCs with 200nA power-down/leakage current. This feature is useless, because there are no adequate (small capacity) batteries available.

EDIT: Corrected 3,5mA to 3,5mAh

No RSTDISBL, no fun!

Last Edited: Mon. Jan 16, 2012 - 01:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LPC1111 is $2 retail, $0.88 in 1000s.

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lithium iodide batteries can last over 15 years, and new chemistries will probably become available. Then there is energy harvesting, for which very low power is desirable.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

in real application, there are likely more devices than just the MCU, so that adds to the energy consumption.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jan_dc wrote:
kk6gm wrote:
jan_dc wrote:
This is funny question IMHO. Of course the 8-bit MCU market is not destroyed and certainly not by ARM.

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?


But what if all that unnecessary RAM/ROM came on a chip that still cost less? Surely you wouldn't buy the more expensive chip just because it was 8 bits, or had less RAM/ROM, any more than you'd buy a 6.3v 0603 cap that cost more than a 10v 0603 cap, because you didn't need a 10v cap.

Quote:
In our applications we run a 8-bit MCU at 1.8MHz. The MCU market is way bigger than all the 'heavy' application which need high speed MCU's. People tend to forget that there is a world outside their own designs...

There's no penalty in running a fast micro slowly.

ok, I was a bit unclear I'm afraid. I'm not talking about mega and xmega cores. I'm talking about tiny stuff. Of course if a 32 bit fits the job and is cheaper, I'll use that. Haven't found any 32 bit yet that is overall cheaper.


OK, understood. I think price tracks IO count as much or more than 8/32 bit core. And I wouldn't claim that 32 bit will replace 8 bit, as much as that 8 bit will become more and more a niche market where extremely low cost, or low power, or low something else, override other concerns. And those applications will always be in a minority.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
LPC1111 is $2 retail, $0.88 in 1000s.

Just designed my first one into an application, based on price and the copious timer capabilites.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
jan_dc wrote:
kk6gm wrote:
jan_dc wrote:
This is funny question IMHO. Of course the 8-bit MCU market is not destroyed and certainly not by ARM.

Why? The answer is simple: why should I use a 32 bit micro controller with way to much RAM/ROM when I don't need it?


But what if all that unnecessary RAM/ROM came on a chip that still cost less? Surely you wouldn't buy the more expensive chip just because it was 8 bits, or had less RAM/ROM, any more than you'd buy a 6.3v 0603 cap that cost more than a 10v 0603 cap, because you didn't need a 10v cap.

Quote:
In our applications we run a 8-bit MCU at 1.8MHz. The MCU market is way bigger than all the 'heavy' application which need high speed MCU's. People tend to forget that there is a world outside their own designs...

There's no penalty in running a fast micro slowly.

ok, I was a bit unclear I'm afraid. I'm not talking about mega and xmega cores. I'm talking about tiny stuff. Of course if a 32 bit fits the job and is cheaper, I'll use that. Haven't found any 32 bit yet that is overall cheaper.


OK, understood. I think price tracks IO count as much or more than 8/32 bit core. And I wouldn't claim that 32 bit will replace 8 bit, as much as that 8 bit will become more and more a niche market where extremely low cost, or low power, or low something else, override other concerns. And those applications will always be in a minority.

Correct. For our applications peripherals and a large ROM (and/or EEPROM) are important. Speed is not important. Price is important of course and some other parameters such as having a free/cheap compiler/debugger.

It'll all change of course. But you can't say that the current 8-bit market is overthrown by ARM 32 bit cores.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Will resistors destroy a capacitor market? :lol:

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Who knows what we'll all be using in 10 years time, if the software tools catch up to the device complexity.
Oh, yes.

The tools are complex enough now...

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
LPC1111 is $2 retail, $0.88 in 1000s.

STM8S beats the price over twice!
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113998

leon_heller wrote:
Then there is energy harvesting, for which very low power is desirable.
Then 20nA is an advantage only when it harvests 40nA-20nA=20nA, about this quantity is left (there is no point considering 20nA leakage as practical when the application harvests 1uA or more). Apart from the lack of energy storage with such small leakage (I do not think even a polypropylene capacitors would be of any use then) how do you imagine playing with a device with a budget of ~1,7mAh after 10 years of harvesting?

Either you got caught on a catchy tune of Brand X, or there is a technology/market I am not aware of.

Again: Could you post a link to some reference design (with a basic budget calculation) to show me/us any practical use of 20nA (or even 100nA) power-down current (by "practical" I mean that the lower power-down current in a general purpose (not asic) microcontroller reduces BOM of some design more than, lets say, 10%, w.r.t. the Brand N having 200uA leakage)?

Sorry for asking again, but you are repeating the Brand X marketing slogan all over again, instead of answering to my question. I am sure that at some point in the future there will be 5mAh, 0805 primary cells lasting 20 years, 1 cent in 1k quantity, but AFAIK this is not happening now.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
STM8S beats the price over twice!
Since when the STM8S has became a 32-bitter? :lol:

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
MBedder wrote:
LPC1111 is $2 retail, $0.88 in 1000s.

STM8S beats the price over twice!
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113998

leon_heller wrote:
Then there is energy harvesting, for which very low power is desirable.
Then 20nA is an advantage only when it harvests 40nA-20nA=20nA, about this quantity is left (there is no point considering 20nA leakage as practical when the application harvests 1uA or more). Apart from the lack of energy storage with such small leakage (I do not think even a polypropylene capacitors would be of any use then) how do you imagine playing with a device with a budget of ~1,7mAh after 10 years of harvesting?

Either you got caught on a catchy tune of Brand X, or there is a technology/market I am not aware of.

Again: Could you post a link to some reference design (with a basic budget calculation) to show me/us any practical use of 20nA (or even 100nA) power-down current (by "practical" I mean that the lower power-down current in a general purpose (not asic) microcontroller reduces BOM of some design more than, lets say, 10%, w.r.t. the Brand N having 200uA leakage)?

Sorry for asking again, but you are repeating the Brand X marketing slogan all over again, instead of answering to my question. I am sure that at some point in the future there will be 5mAh, 0805 primary cells lasting 20 years, 1 cent in 1k quantity, but AFAIK this is not happening now.

It's a new technology and a new market for 8-bit devices. The applications will start to appear now that suitable MCUs are available.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can still purchase 74 logic DIP parts.
... just sayin!

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
Brutte wrote:
STM8S beats the price over twice!
Since when the STM8S has became a 32-bitter? :lol:

You mean 48-, 64- or 128-bit?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AtomicZombie wrote:
I can still purchase 74 logic DIP parts.
... just sayin!

We still use them...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I like the small AVRs.
They have lots of advantages in comparison to ARM, e.g.:
- small pin count (6, 8, 14, 20, ..)
- easy to solder
- wide VCC range (1.8 - 5.5V), no regulator needed.
- internal clock and brown out reset
- easy hardware, no external components needed
- easy initialisation (software)

The ARM has advantages only on bigger projects, e.g. with GUI, Ethernet, Filesystem and so on.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Peter,

Just hypothetical but if you were paying say $0.80 for the AVR chips and then an ARM that offered pretty much the same for $0.50 appeared would you switch?

Cliff

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just hypothetical but if you were paying say $0.80 for the AVR chips and then an ARM that offered pretty much the same for $0.50 appeared would you switch?

No, because the CPU cost was irrelevant.
If I need a more complex pcb and more external components around the CPU,
then the ARM was many more expensive in the sum.
Also it's easier to solder SOIC8 instead LQFP100.

But I miss more AVR with CAN, e.g. something like:
- ATtiny84CAN
- ATmega328CAN

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
ATmega328CAN
What's wrong with Mega32M1 then?

Warning: Grumpy Old Chuff. Reading this post may severely damage your mental health.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Peter,

Just hypothetical but if you were paying say $0.80 for the AVR chips and then an ARM that offered pretty much the same for $0.50 appeared would you switch?

Cliff

Sorry to interrupt... but do you realise the cost of grabbing this $0,30 advantage? Suppose your working place costs $100 or $200/h. Your pennywise choice affects many other people in your company. Also you have to make design changes.
Change costs (a LOT of) money. Conservatism often pays better.

It happened many years ago, but I still feel ashamed of having a stupid little plastic part on my drawing board for more then a month because this kind of cent discussions.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Sorry to interrupt... but do you realise the cost of grabbing this $0,30 advantage?

Suppose you make 2 million units per year (my old company did - and that was just one of several products). Then 2,000,000 * $0.30 = $600,000. So, yes, we would most definitely change micro if we could take $0.30 out of the bill of materials by doing so! Heck, we used to change capacitors if it would save $0.01 or even less.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I know you are very clever. So please show us a frequency distribution graph of the series quantity of electronic products. I mean: how many products are there made in 2,000,000 series compared to series of 1, 10, 100, 1000 and so on.
I think there will be many, many more designs realised in small quantities.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MBedder wrote:
What's wrong with Mega32M1 then?

Still hard to get it (not on stock at Mouser, Farnell, RS, ...).
We need only small quantity.

Thus we use for new projects still the old AT90CAN128, which was good available from many distributors.
But I miss some features (UARTs as buffered SPI, pin change interrupts).

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So please show us a frequency distribution graph of the series quantity of electronic products. I mean: how many products are there made in 2,000,000 series compared to series of 1, 10, 100, 1000 and so on.

I don't understand your question. We made 2,000,000 of this single product:

That has an Atmega16 operating the front panel buttons and LEDs. We supplied these to BSkyB who actually have 10 million of these in some of the 25 million households in the UK. Without giving exact numbers the box cost in the region of $200 to make (there is some powerful MPEG2/MP4 decode silicon based on an ARM9 CPU in there together with 250GB..1TB hard drive). If you can save $1 per unit the company puts $2m on the bottom line.

We also make similar products for other European and Australsian markets - but in smaller numbers (100,000 .. 500,000)

EDIT: fixed image link

 

Last Edited: Tue. Jan 17, 2012 - 12:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are loads of products that are sold in millions. Motor cars, fridges, TVs, mobile phones, toys, ...

The mathematics alters greatly when you have different quantities. This is why people often ask "why".

Most often, someone is pursuing a cent or a byte when their time or costs vastly exceed any savings.

As hobbyists, we actually pick up the crumbs from the big boys' table. An MCU would not exist for the current price if only hobbyists used them.

Having produced a chip, a manufacturer is only going to continue if sales / goodwill justify it. Hence many chips are no longer available in DIP.

There will always be a market for a simple chip. If the sales drop, the price may well go up. Hence a 2102 SRAM or 2704 EEPROM might still be available, but you probably have to pay more for them than for a Gb of modern memory.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Our products go by the 10's to 1000's a year. And we've got quite some PCB's (not all with MCU's of course) so we like to stick to just 1 MCU if possible (it's 3 in real).

So yes, we stick to the good old through hole components and even some very old IC's. MCU cost is not that important so we can afford using an 'expensive' one. Then we could buy it in larger numbers making it cheaper than using lots of different MCU's. Downturn: the MCU must fit almost all applications and some are battery operated.

Believe me: it's quite difficult and challenging (and fun) to build a device that can do more with less.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Believe me: it's quite difficult and challenging (and fun) to build a device that can do more with less.

But if cost doesn't matter then why not go for an all singing all dancing $10 ARM (say)? It could be applied equally to both the $1 micro jobs as the $10 jobs where all it's CPU bandwidth and other resources really are required. As such I'd have thought this was a strong argument for 32bits displacing 8bit.

(the through hole thing could be a bit of a challenge though!)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Believe me: it's quite difficult and challenging (and fun) to build a device that can do more with less.

But if cost doesn't matter then why not go for an all singing all dancing $10 ARM (say)? It could be applied equally to both the $1 micro jobs as the $10 jobs where all it's CPU bandwidth and other resources really are required. As such I'd have thought this was a strong argument for 32bits displacing 8bit.

(the through hole thing could be a bit of a challenge though!)

Price does matter. For that 10$ I've got a small module with a large XMEGA and extra EEPROM on board. This replaces quite some components on our PCB's and cost is almost the same except that we'll have much more memory and consumes less power.

Changing the whole PCB to SMD would be very costly due to the low volumes. Now we can tune our PCB's in low volumes by not using certain parts on the PCB (not using expensive components). With SMD it's more difficult.

We've got quite some PCB's and I did a test once. I calculated the time it takes to mount all components on the different PCB's and solder (using a machine). The conclusion was that size of the PCB is an overrated factor. Manhours for tiny boards of 2x2 inch is about 70% compared to larger 5x10 boards. There is a lot of overhead besides mounting... So since we always will have certain components in TH and mounted in house our production in general wouldn't change that much. Putting everything in SMD production would just be an extra cost with little gain.

The only reason to have SMD for us is to be able to use components that do not exist in TH (such as XMEGA, FTDI chips,...)

It's completely different than for high volumes. Much more manual labour (and it's cheaper).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Changing the whole PCB to SMD would be very costly due to the low volumes.

Sorry but since when has there been a DIP packaged Xmega? Or are you saying you have a small SMD board (with Xmega + EEPROM) that sits atop a thru-hole board? If this - then why can't that "module" be ARM instead of Xmega?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There’s maybe one aspect that hasn’t been mentioned in the 8 vs 32-bit ‘war’; isn’t it likely that formally only ARM developers will now also jump into the 8-bit market?

I mean, they have all the resources to develop/produce ARM based products, and now that cost isn’t a major factor anymore, they may as well start developing products which weren’t interesting before, but now do, especially with the current financial crisis?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Changing the whole PCB to SMD would be very costly due to the low volumes.

Sorry but since when has there been a DIP packaged Xmega? Or are you saying you have a small SMD board (with Xmega + EEPROM) that sits atop a thru-hole board? If this - then why can't that "module" be ARM instead of Xmega?

It's indeed a module with a bunch of pins. Sure, it can be ARM. We'll reach about 3000 pieces a year when everything has been converted to this new module. What would I gain with using an ARM core and what is the cost (development software, cores,...).

The ATXMega we're going to use will cost us 'bout 4 EUR a piece or something like that. MCU will be running at 1.8MHz so plenty of speed left when needed. Why should I need an ARM? What is the power consumption of an ARM compared to XMEGA?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Don't take any of this as a knock on AVRs - I like AVRs and just designed them into about half-a-dozen different devices. I have mentioned before that their advantages include 5V operation, lots of DIP parts, onboard EEPROM and high drive capacity. But it's wrong to equate ARM solely with "big iron".

danni wrote:
I like the small AVRs.
They have lots of advantages in comparison to ARM, e.g.:
- small pin count (6, 8, 14, 20, ..)
- easy to solder

There are now some DIP28 Cortex M0 devices, as well as lots of TQFP48 parts
Quote:
- wide VCC range (1.8 - 5.5V), no regulator needed.
- internal clock and brown out reset

Many of the Cortex M parts have 1-2% internal clocks and BOR
Quote:
- easy hardware, no external components needed

Same for many Cortex Mx parts
Quote:
- easy initialisation (software)

I truly haven't noticed the difference to be significant.

Quote:
The ARM has advantages only on bigger projects, e.g. with GUI, Ethernet, Filesystem and so on.

Well, I just designed an LPC1111 on a board 0.5" x 1.5" with none of those things, based on price and the 4 onboard timers w/ 13 match outputs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gdhospers wrote:
clawson wrote:
Peter,

Just hypothetical but if you were paying say $0.80 for the AVR chips and then an ARM that offered pretty much the same for $0.50 appeared would you switch?

Cliff

Sorry to interrupt... but do you realise the cost of grabbing this $0,30 advantage? Suppose your working place costs $100 or $200/h. Your pennywise choice affects many other people in your company. Also you have to make design changes.
Change costs (a LOT of) money. Conservatism often pays better.


There's another side of this coin, which is that in lower volumes the economically optimum approach means choosing hardware with _more_ resources, since trying to cram an application into a system with marginal resources quickly becomes a very expensive proposition. Which is why a $3 ARM could save one a ton of money over a $2 AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
- small pin count (6, 8, 14, 20, ..)

This is supposed to be an advantage? Then take a knife and cut out some of those 48 pins if that bothers you. Or solder together each adjacent two, making a 24 pin QFP, if 48 pin QFP has too many pins :)

Small package size or low weight could be an advantage, but considering that CM0 are available in chip scale package, even 3mmx3mm Tiny2313A/4313 will not beat the size!

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jan_dc wrote:
The ATXMega we're going to use will cost us 'bout 4 EUR a piece or something like that. MCU will be running at 1.8MHz

The cost of development environment starts from 4x100ohm resistors + LPT plug ( <1$ ) to a full featured IDE, compiler, RTOS licensing, ETM dongle with profiler, code coverage analysis, and of course with support/training (>5k$ and up).

What is the power consumption of X w.r.t M? Take some of your projects, compile -O3 for XMega and for some ARM (CM0 are the cheapest) and you will know the difference. First, there would be difference in timing, because I suppose even CM0 will cope with the 1,8MHz XMega program in no time (AFAIK LPC CM0 are the most efficient at about 12MHz), spending rest of it in sleep. Second, depending on peripherals, CM0 [may/may not] have the peripherals you require so the task can take more/less computations with it.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Sorry but since when has there been a DIP packaged Xmega?

http://fourwalledcubicle.com/blog/2011/09/oh-and-that-robot-thing/

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Believe me: it's quite difficult and challenging (and fun) to build a device that can do more with less.
a prime example being Wozniak's original Apple II floppy disk controller. Brilliant.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

There's another side of this coin, which is that in lower volumes the economically optimum approach means choosing hardware with _more_ resources, since trying to cram an application into a system with marginal resources quickly becomes a very expensive proposition. Which is why a $3 ARM could save one a ton of money over a $2 AVR.

My philosophy, exactly. Really important to keep the NRE $ down in low volume projects. That's where the small ARMs really shine (small meaning those not intended to run embedded Linux)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cost of developement tools for ARM? The LPCXPRESSO gives more debug functionality than a AVR Dragon for less cost. Whilst the Code Red tools are size limited to 128k, that is not an issue for many of the parts. If you want free,free, there's gcc (which is what Code Red uses) and you can configure Eclipse and open ocd yourself. With Brand ST parts, there's the free Atollic tools that have no code size limitation, but only one debug breakpoint, again based on gcc and Eclipse. GCC for ARM has less compromises than the AVR GCC as the ARM is half normal and doesn't need the progmem style workarounds. Downside of the little ARMS vs the AVR? No eeprom as such, but you can fudge up a flash page to do much the same,predominantly smt packages but smt stuff is piss easy to hand solder and I notice NXP have a 44PLCC package device. The ARMs are predominantly 3V, but Nuvoton and others have 5V parts. If you're happy with the AVRs, then keep using them, I'd still be using 8051s if the AVRs didn't come along and were better at the time.

Just been reading up on the Cortex M4F floating point instructions - most at 1 clock with 14 clocks for a divide. With a STM32F4 discovery board at 168MHz, I can scale my adc values using floating point without feeling guilty. For a bit of nostalgia, I got CP/M working on it with a sdcard. Not sure what the equivalent Z80 speed is, but Turbo Pascal seems responsive enough. No click and clank of the old 8" disk drives though.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've looked at several NXP parts and Nuvotron too but they all consume a lot of power.

The ATxmega256A3B has about all we need: RTC, DAC, ADC, I2C, SPI, UART, lots of ROM, EEPROM and the core consumes less than 1.8mA at 2MHz. The only downturn: pins are not 5V compatible. This device at 5V would be ideal. I can't do anything with USB, EThernet,... unless there is an electrical isolation in the MCU.

As far as I have seen the ARM core based MCUs with the same features all consume (much) more.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
1.8mA at 2MHz

1,8e-3A*1,8V/2e6Hz=1,62e-9J/clock

LPC111X/YY2 consumes 1,5mA at 1,8V at 12MHz (with peripherals off, I do not know the details of your design)
1,5e-3A*1,8V/12e6Hz=0,23e-9J/clock

AFAIK all CM0 are up to 128kB, perhaps you should check CM3. But CM3 is an overkill for such slow application.
How is it possible that you are energy concerned in the application requiring UART?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anybody experience, how robust and reliable the ARM in comparison to the AVR was?

I made a 4-layer pcb with the LPC2129 and many 2-layer pcbs with ATmega or ATtiny.
So the ARM has separate planes for VCC/GND, but the AVR not.

I got the impression, that the ARM was many more sensitive against noise and spikes.
Often the ARM was alive on the next power on, but some times the ARM was broken permanently.

In opposition the AVR looks rock-solid.
No crash and no damage occur on all the AVR projects.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
Quote:
1.8mA at 2MHz

1,8e-3A*1,8V/2e6Hz=1,62e-9J/clock

LPC111X/YY2 consumes 1,5mA at 1,8V at 12MHz (with peripherals off, I do not know the details of your design)
1,5e-3A*1,8V/12e6Hz=0,23e-9J/clock

AFAIK all CM0 are up to 128kB, perhaps you should check CM3. But CM3 is an overkill for such slow application.
How is it possible that you are energy concerned in the application requiring UART?

Comparing a 3.3V operation with a 1.8V operation is not really fair.

We need preferably 5V or at least 5V IO. 3.3V IO is usable but anything less is unusable.

So I look at the specs at 3.3V and 5V.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

http://www.energymicro.com/products/ perhaps?

Just picked an example from the bottom of the range:

Quote:
• 20 nA @ 3 V Shutoff Mode
• 0.6 µA @ 3 V Stop Mode, including Power-on Reset, Brown-out
Detector, RAM and CPU retention
• 1 µA @ 3 V Deep Sleep Mode, including RTC with 32.768 kHz
oscillator, Power-on Reset, Brown-out Detector, RAM and CPU
retention
• 50 µA/MHz @ 3 V Sleep Mode
• 150 µA/MHz @ 3 V Run Mode, with code executed from flash

and from the top:
Quote:
• 20 nA @ 3 V Shutoff Mode
• 0.4µA @ 3 V Shutoff Mode with RTC
• 0.9 µA @ 3 V Stop Mode, including Power-on Reset, Brown-out
Detector, RAM and CPU retention
• 1.2 µA @ 3 V Deep Sleep Mode, including RTC with 32.768 kHz
oscillator, Power-on Reset, Brown-out Detector, RAM and CPU
retention
• 50 µA/MHz @ 3 V Sleep Mode
• 200 µA/MHz @ 3 V Run Mode, with code executed from Flash

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Quote:

Believe me: it's quite difficult and challenging (and fun) to build a device that can do more with less.
a prime example being Wozniak's original Apple II floppy disk controller. Brilliant.

Cheers to that!

Brad

I Like to Build Bikes : http://www.AtomicZombie.com

I Like to Hack Stuff : http://www.LucidScience.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jan_dc wrote:
We need preferably 5V or at least 5V IO. 3.3V IO is usable but anything less is unusable.

He may be referring to the core which runs 1.8V on a 3.3V device. The IO would be 3.3V (which is often usable in a 5V system if the inputs are 5V tolerant and the outputs drive TTL-compatible inputs, which are quite happy with a 3V '1').

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm interest, if anybody made the same experience, that ARM are significant less robust and reliable than AVR :?:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=914082#914082

On my applications reliability was always the main point.
A cheaper device was never an option, if the reliability decrease :!:

On my products there are high voltages up to 30000V inside the same device with the microcontroller.
Thus I need a very robust micro, which continue to work even on a sparkover on the load outside.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

On 3v devices you have less voltage swing, thus less immunity to interference. Ultimately, the reliability is going to be down to what external protection you provide and the circuit layout methinks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
On 3v devices you have less voltage swing, thus less immunity to interference. Ultimately, the reliability is going to be down to what external protection you provide and the circuit layout methinks.

Not quite true. The 'high' voltage level is also lower. So if a line goes to f.i 2V due to interference on a 3.3V system it's considered to be 'high', while on a 5V system it's still low.

It's getting worse at lower voltages. And solution to that is differential pairs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:

On my products there are high voltages up to 30000V inside the same device with the microcontroller.
Thus I need a very robust micro, which continue to work even on a sparkover on the load outside.
Peter
Then you no doubt know that protecting the logic circuits is all about mechanical design, power supply design, power distribution, grounding, EMI shielding and the like. It has little to do with brand A vs. B of microprocessor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

stevech wrote:
Then you no doubt know that protecting the logic circuits is all about mechanical design, power supply design, power distribution, grounding, EMI shielding and the like. It has little to do with brand A vs. B of microprocessor.

Yes, I know.
The gadget with 30kV output use ATtiny25 and ATtiny861 inside and both runs very nice.
Thus I think, it's a good idea to stick on the standard AVRs.
Even if other micros may be cheaper.

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

danni wrote:
I'm interest, if anybody made the same experience, that ARM are significant less robust and reliable than AVR :?:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=914082#914082

On my applications reliability was always the main point.
A cheaper device was never an option, if the reliability decrease :!:

On my products there are high voltages up to 30000V inside the same device with the microcontroller.
Thus I need a very robust micro, which continue to work even on a sparkover on the load outside.

Peter


I’ve got the same experience with Luminary(TI) CortexM-3 devices, from what I remember it’s mostly the internal LDO that goes bad, and the µC stops working, I also had on one µC where a GPIO or two stuck at a specific voltage. This was on a prototype board, and I accidently shortened some pins(or VDD and ground) when debugging the board with the oscilloscope which fried the µC. Never had this with AVR chips(shortening yes, but the AVR was still alive after that).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fleemy wrote:
from what I remember it’s mostly the internal LDO that goes bad, and the µC stops working, I also had on one µC where a GPIO or two stuck at a specific voltage. This was on a prototype board, and I accidently shortened some pins(or VDD and ground)(...)

I would call it a "more RTFM resistant" chip, but definitely not "more reliable".

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does anybody know of a company that made a large or total shift to using 32 bitters due to pricing, but their products are strictly for 8 bitters ? If not , I wonder what companies are waiting for ...

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

indianajones11 wrote:
Does anybody know of a company that made a large or total shift to using 32 bitters due to pricing, but their products are strictly for 8 bitters ?

Does anybody know a 32-bitter which is cheaper (in volume) than any available 8-bitter of comparable parameters (ignoring MIPS, which IMHO is a useless feature IMHO in 90% of small embedded applications)?

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
Does anybody know a 32-bitter which is cheaper (in volume) than any available 8-bitter of comparable parameters (ignoring MIPS, which IMHO is a useless feature IMHO in 90% of small embedded applications)?

Well, that's a bit of a loaded question, isn't it? All I can offer is a single data point. I just designed in an LPC1111 because I needed a lot of 16-bit compare/match channels. The LPC1111 has 13 total. Is there an 8-bit device at lower cost with 13 16-bit compare/match channels? I dunno, I'd be interested to find out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does anybody know a 32-bitter which is cheaper (in volume) than any available 8-bitter of comparable parameters (ignoring MIPS, which IMHO is a useless feature IMHO in 90% of small embedded applications)?

It is indeed a bit "loaded". What is "volume"? I assume Brutte is discounting anecdotal qty. 1 pricing, which may be all over the place.

But also "medium" and "high" volumes may well depend on how hard the manufacturer wants the design win and how important it is to build volume for that particular model.

Before looking for the AVR-killer pricing I'll put a couple of models into my head...

Mega164, 16KB program storage, 1KB SRAM, twin USART, I2C, SPI, ADC, ~32 I/O TQFP44
Mega88, 8KB program storage, 1KB SRAM, USART, I2C, SPI, ADC, ~24 I/O, TQFP32

Those are low-end Mega. I pick that arena because to me it "proves" that the ARMs have become true microcontrollers, and not the microcomputer PDA engines that were ARMs a few years ago.

Our builds at board houses are usually a few hundred pieces. Qty. 100 price of the Mega164PA is ~$2.95; the Mega88PA ~$2.25. those are the numbers in my head when doing designs: $3.00 and $2.25. A Cortex family would need to be in the same range to get my interest.

At DigiKey, let's compare LPC1111 with Mega88. Same flash size, twice as much SRAM, about the same complement of peripherals and I/O count. $1.46/qty. 100. LESS THAN $1 IN 1000 OR MORE. So much for that.

It is a hair harder to match up the Mega164 against the LPC11 line. However, consider that the LPC11C12 in 48LQFP with an added CAN controller, 8KB of SRAM, a few more I/O is $2.85/qty. 100 and less than $2.00 in qty. 1000 or more.

I'd say that is evidence.

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.

Last Edited: Mon. Jan 23, 2012 - 12:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Almost all pins have poor drive capability compared to AVRs, which is about the only disadvantage.


Leon--you haven't used the Tiny48 or similar then--really wimpy pin drive IMO/IME.

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

I have, but it didn't matter.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

Does anybody know a 32-bitter which is cheaper (in volume) than any available 8-bitter of comparable parameters (ignoring MIPS, which IMHO is a useless feature IMHO in 90% of small embedded applications)?

It is indeed a bit "loaded". What is "volume"? I assume Brutte is discounting anecdotal qty. 1 pricing, which may be all over the place.

But also "medium" and "high" volumes may well depend on how hard the manufacturer wants the design win and how important it is to build volume for that particular model.

Before looking for the AVR-killer pricing I'll put a couple of models into my head...

Mega164, 16KB program storage, 1KB SRAM, twin USART, I2C, SPI, ADC, ~32 I/O TQFP44
Mega88, 8KB program storage, 1KB SRAM, USART, I2C, SPI, ADC, ~24 I/O, TQFP32

Those are low-end Mega. I pick that arena because to me it "proves" that the ARMs have become true microcontrollers, and not the microcomputer PDA engines that were ARMs a few years ago.

Our builds at board houses are usually a few hundred pieces. Qty. 100 price of the Mega164PA is ~$2.95; the Mega88PA ~$2.25. those are the numbers in my head when doing designs: $3.00 and $2.25. A Cortex family would need to be in the same range to get my interest.


--LPC1111 (Cortex M0) 8k program, 2k RAM, USART, I2C, SPI, ADC, 28 I/O, HVQFN33, $1.29@100
--LPC1113 (Cortex M0) 24k program, 8k RAM,..., 42 I/O, TQFP48, $1.69@100
--STM32F100R6T6B (Cortex M3) 64k program, 8k RAM,..., 51 I/O, TQFP64, $1.49@100

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys, most of the discussion centers around the processors from NXP.

I have no experience with the 32bit stuff and have not looked at anything from NXP or Atmel (or any other manufacturer for that matter) . The 8 bit micros have enough features and speed to handle my hobby work.

Still, without (hopefully) starting a war, may I ask, why is it that the Atmel SAM processors have not entered the conversation?

I would like to know why developers are not so excited about them. From reading the posts, it seems like the price point of the NXP stuff is what has you guys excited. Can the SAM stuff not compete on features? Am I right/wrong?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Still, without (hopefully) starting a war, may I ask, why is it that the Atmel SAM processors have not entered the conversation?


Look at the prices then report back ;-)

(presumably Atmel is trying to service some other part of the potential Cortex M3 market?)

 

Last Edited: Mon. Jan 23, 2012 - 11:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Atmel ARM7TDMI chips were ancient devices compared to the Cortex parts from NXP and ST, and overpriced. They have recently updated their range with Cortex-M3 and -M4 parts, but don't supply the popular -M0 chips which compete with the AVR. Perhaps they are worried about damaging the market for the latter.

Leon Heller
G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even comparing M3's they don't look competitive (and esp. not if you are thinking of displacing an 8bit MCU with one). Try this exercise. Go to digikey.com and simply search "cortex", in stock and select the 569 "microcontrollers". Then sort by price and look down the Core Processor column. Which M3's do you come to first? Not Atmel.

The first "in stock" M3 you come to is the LPC1311 @ $2.48

The first "in stock" M3 from Atmel you come to is ATSAM3N1AA @ $5.89

Now that's not a fair comparison, One has 8K, the other 64K - but that's kind of the point. Presumably Atmel doesn't want to tread on the toes of mega, xmega, UC3 even? Given the popularity of the small LPC and ST32 models perhaps that's where they should be pitching devices?

OTOH it's the big customers who drive their plans - not those buying 1/10/100/1,000 or even 10,000

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mario, the SAM7 devices were good for their day. I designed a product using the SAM7S256. To do the same today, I could use a NXP or ST part quite easily as these have much the same features. The NXP would be the first choice as the LPCXpresso tools are a cheap entry and quite well featured. The ST boards are cheaper but the Atollic tools are not quite as good feature wise as the CodeRed tools for the LPCXpresso - my opinion. You were wondering about FFT performance on the AVR - the ST STM32F4 discovery board has a fpu and many floating point ops are done at 1 clock at 168MHz. This is significantly faster than the AVR. The STM board is < $20USD and the free Atollic tools are not code size limited although limited in other ways.

As for the 'NEW' SAM3 series parts, they just haven't appeared on the radar as there doesn't seem to be the same cheap tools/boards carrot dangled in front of us.

Basically the big decider for me is the debugging. The ST discovery and the LPCXpresso boards come with the debug hardware for less cost than the Atmel Dragon itself. Couple that with a GUI that is a bit more advanced than Studio 4, then you might start to see the picture. 32bits and faster speed are just icing on the cake for me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

there doesn't seem to be the same cheap tools/boards carrot dangled in front of us.

$95 : http://search.digikey.com/us/en/products/ATSAM3N-EK/ATSAM3N-EK-ND/2451232 (no debugger included - they suggest getting $100 SAM_ICE http://store.atmel.com/PartDetail.aspx?q=p:10500253)

Meanwhile you can get an Xpresso for $20 or one of the STM32 VL Discovery kits for $12, both complete with debugger. It's a "no brainer" isn't it?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I now see your point. Even 8k is a generous amount when compared to some of the megas. The NXP stuff is full featured and an obvious choice if price is a concern.

The new guys are disrupting the market and Atmel has some tough decisions ahead.

They're probably waiting for their distributors to clear current inventory before making the much needed price adjustments. Otherwise, they're going to continue to lose interest from you guys.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The new guys

Philips (NXP) date from 1891
ST Micro date from 1957

Atmel date from 1984

so who are the "new guys" here? ;-)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't really expect the price of AVRs to drop significantly.i dare say many of them are made using an older process technology that will probably get less economic as time goes on. Everything has its time in the sun - how many people use the Z80 in new designs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

how many people use the Z80 in new designs?

Yeah but - the Z80 became available in 1976 while the Atmel SAM3's only became generally available in 2011.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Mario, the SAM7 devices were good for their day. I designed a product using the SAM7S256. To do the same today, I could use a NXP or ST part quite easily as these have much the same features. The NXP would be the first choice as the LPCXpresso tools are a cheap entry and quite well featured. The ST boards are cheaper but the Atollic tools are not quite as good feature wise as the CodeRed tools for the LPCXpresso - my opinion. You were wondering about FFT performance on the AVR - the ST STM32F4 discovery board has a fpu and many floating point ops are done at 1 clock at 168MHz. This is significantly faster than the AVR. The STM board is < $20USD and the free Atollic tools are not code size limited although limited in other ways.

As for the 'NEW' SAM3 series parts, they just haven't appeared on the radar as there doesn't seem to be the same cheap tools/boards carrot dangled in front of us.

Basically the big decider for me is the debugging. The ST discovery and the LPCXpresso boards come with the debug hardware for less cost than the Atmel Dragon itself. Couple that with a GUI that is a bit more advanced than Studio 4, then you might start to see the picture. 32bits and faster speed are just icing on the cake for me.

Hi Kartman,

I'm going to end up drawing a daughter board to compliment my board's circuit instead of relying on my mega328, and after having learned of these newer devices, the argument for basing this new project around the xmega is now rather weak. Your mention of hardware support for an FP unit on the ST micro just made my interest on ST peak.

I visited the ST Discovery forums and member participation is rather scarce. However, looking through some code cases there, it does seem like ST is making an effort at making their processors very accessible. I don't require as much baby sitting as I once did, so support is not that big of an issue ( you along the other members do spoil the newbies, I always thought).

Anyway, I'm going to assume their tools are also publicly available? After experiencing the megas, I must admit at being spoiled and will lose interest if ST wants some ridiculous amount for their development tools.

Can you provide just a few more information regarding their tools? how are they limited? since you do mention their tools being limited for novices?

Is there not a free gcc compiler available?

Overall, you would recommended the LPCXpresso for an easier transition from the megas?

Thank you

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

there doesn't seem to be the same cheap tools/boards carrot dangled in front of us.

$95 : http://search.digikey.com/us/en/products/ATSAM3N-EK/ATSAM3N-EK-ND/2451232 (no debugger included - they suggest getting $100 SAM_ICE http://store.atmel.com/PartDetail.aspx?q=p:10500253)

Meanwhile you can get an Xpresso for $20 or one of the STM32 VL Discovery kits for $12, both complete with debugger. It's a "no brainer" isn't it?

I do think this will change once the Arduino folk release their board.

From what I have read, the Due will be based on the SAM3U4E processor. The one with the 144 pins.

It will come with debugging and be cheap. There's no reason to think Atmel will not bring this same order of support to their ASF toolset.

From the look of things, in 2012 Atmel might just bring on some heat....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

It will come with debugging and be cheap.

Are you sure? The one thing that lets all the existing Arduino down is their lack of debugger (and an attempt to use an external dW debugger with them is "fraught" as they already have their own ideas about how the _RESET pin is controlled).

What suggests that the "big picture" will be any different with an ARM based one?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Can you provide just a few more information regarding their tools?

I posed similar " 'best' way to start with ARM" in a thread that got lots of good information. Searching...

First, search the Off-Topic forum for ARM in the title for prior discussions--very similar to this thread, in fact (some of them). Repeat for "cortex".

These are some of the ones I was thinking of:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=112808&highlight=
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=111454&start=all&postdays=0&postorder=asc
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=102706&start=all&postdays=0&postorder=asc

Same-old same-old a year ago:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=89609&highlight=
...and before that:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=86367&highlight=nxp

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

clawson wrote:
Quote:

It will come with debugging and be cheap.

Are you sure? The one thing that lets all the existing Arduino down is their lack of debugger (and an attempt to use an external dW debugger with them is "fraught" as they already have their own ideas about how the _RESET pin is controlled).

What suggests that the "big picture" will be any different with an ARM based one?

I have tried finding the posting confirming their debugging support. I know I did read it somewhere, but can not find it. It does seem like they want to address their lack of debug support from the original Uno in the Due.

Those guys haven't announced much in a while, and it has frustrated many people eager to hear more information regarding this new product.

One thing is for sure, it is difficult finding the reference chip in stock any where. I guess philanthropists have taken notice and have begun the hoarding.

Arduino was not the reason why I took notice of Atmel and their processors (their free/powerful development tools was the reason), so I have always stood at a distance glancing at the Arduino platform with a curiosity.

That's what is now keeping me from jumping over to ARM. I have always thought people needed some $3000 worth of development tools.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have always thought people needed some $3000 worth of development tools.

No ARM (because or arm-gcc which is much more mature than avr-gcc) has always had one of the lowest cost setups for development.

(Having said that if one of your partners has tied themselves to ARM's own compiler and debug tools at $6,000 a seat so you have no option but to get the same for 50 engineers it can get pretty expensive (don't ask!))

BTW if ARMDuino is to have debug electronics that impies a MAJOR change to the IDE as it'll now have to put a GUI interface onto the front of gdb. That sounds VERY expensive!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
It is indeed a bit "loaded". What is "volume"?

This forum is intended mainly for hobbyists so the arguments of "I have just found a 128kB ARM sold-outs for 1$" is not an argument in the discussion about the pricing of 8vs32. By "in volume" I meant the quantity for ~medium production. Definitely not 100pcs as then the chip pricing is not a significant factor of the final cost. Several reels I think is worth a consideration. If it is a volume for hobbyists (10-100), there is not much to discuss about - go for 32-bitter.

Now in the subject of 2k RAM vs 1k RAM on a 8kB chip:

The embedded market has settled on some reasonable ratios between resources of the general purpose micros. These are ratios between pin count, SRAM, ROM, EEPROM etc. What I mean is that one can market a 128kB flash chip in SOIC8, but this is not what is usually sold, being far away from the "trend line". Same as 2k SRAM on 8kB chip(1/4). I could understand a 128kB chip with 32kB SRAM (also 1/4) required by some OS resources. But it is of little use in a tiny 8k (IMHO).
How to utilize this 2k? Stack? Heap? Lots of globals in 8k application?

I like the idea of 13 compare match channels in 8k chip. But again, it is far away from the trend line (3 to 6).

This is because the LPC1111 chip is made compatible with the family reaching 32k devices, where 2k or 4k SRAM is ok.

So I come to a conclusion you cannot compare LPC1111 with 8-bit world product as this chip does not go along the general purpose micros trend. So the advangtage of 2k SRAM is similar to the advantage of 20nA current in a typical application.
In such situation one can:
- neglect the resource which will not be utilized by a typical design anyway.
- find a different 32-bitter which can be compared with 8-bitters.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:

.....
So I come to a conclusion you cannot compare LPC1111 with 8-bit world product as this chip does not go along the general purpose micros trend.

You're ignoring the impact of core performance on the selection and ratios of memory and peripherals. Part of the reasoning behind the "typical" ratios of memory and peripherals must surely be based on what a typical 8-bit core can effectively support. Add a core that is 3-5x more powerful and suddenly the calculation changes.

Besides, it costs nothing to ignore the "extra" memory or peripherals on a 32-bit chip, if the device is still as cheap or cheaper than a smaller 8-bit device. And I fall back on the documented results that using no more than half a chip's resources has a total economic benefit (cheaper total cost) in small/medium volumes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MarioRivas wrote:
I have tried finding the posting confirming their debugging support. I know I did read it somewhere, but can not find it. It does seem like they want to address their lack of debug support from the original Uno in the Due.
Arduino folks think a debugger is fly-swatter or a can of Raid. This system is for artists and designers who can barely find a wall socket, much less anything more technical. I doubt if Mario will allow a debugger unless it is something so dead-nuts simple that a retarded cave-man can use it. They may add something in the background for their developers, but I just can't see a debugger on the public face of the Arduino. I could be wrong.

And besides IMHO the bootloader provides one of the best debugging tools I've come across, since it allows you to make rapid code changes and upload to test the changes. I haven't needed to debug any other way for several years now. But that may just be an experience thing.

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As to the original question:

Of course! What do you expect? When the price of these chips gets down to the dollar each range, we'll quite messing with the smaller ones. Like we've abandoned 555's for ATTiny's now.

No matter how big and bad you are, when a two-year-old hands you a toy phone, you answer it.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

fly-swatter

You know not the irony of what you say! ;-)

I actually have one of these:

http://www.tincantools.com/product.php?productid=16134

Quote:

I haven't needed to debug any other way for several years now

Yup, as long as there's at least one LED on the board what else could you need? Real men don't need no fancy debuggers! ;-)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

LED?
Luxury!
I use two PCB pads and my tongue.

Act now, think later.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
LED?
Luxury!
I use two PCB pads and my tongue.

I've always liked the small resistor & finger approach for it's analog properties

Cold -- good
Warm -- hmmm
Hot -- hmmmmmmmmmmm
Burn -- damn!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Like we've abandoned 555's for ATTiny's now.

Really? This afternoon I studied the schematic of one our recent mains LED drivers, only to find they used a 555 there... while they you could have used a pin on the ST7LITE MCU for that... so there must be a reason for that.

And I also found one on a car combined rear/brake light LED replacement module.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
Besides, it costs nothing to ignore the "extra" memory or peripherals on a 32-bit chip, if the device is still as cheap or cheaper than a smaller 8-bit device.

Is it?
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113998

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
kk6gm wrote:
Besides, it costs nothing to ignore the "extra" memory or peripherals on a 32-bit chip, if the device is still as cheap or cheaper than a smaller 8-bit device.

Is it?
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=113998

Note what I said. I said "if the device is still as cheap or cheaper". I never said or intended to claim that there are 32-bit chips as cheap as the cheapest 8-bit chips, and I would be astonished if that were true. But we have seen in this thread that there are 32-bit chips that are cheaper than a couple of representative 8-bit AVRs. And in my recent LPC1111 design I needed low cost and lots of >= 16-bit PWM outputs, and the LPC1111 fit the bill better than any AVR.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

I haven't needed to debug any other way for several years now

Yup, as long as there's at least one LED on the board what else could you need? Real men don't need no fancy debuggers! ;-)
Seriously! When I was at Philips I had over $40,000 dollars worth of debugging equipment on my desk and used it. But now with a good complier/uploader/bootloader combo, I just take care to write the code a short piece at a time, test it, then add the next possibly buggy piece. I don't try to write the whole program at once, which would require a good debugger, but my bit at a time and using lots of pretested libraries is proving to be much more efficient and a heck of a lot cheaper.

Maybe by now I've made enough stupid mistakes that I've got a better feel for where the traps lie and avoid them?

Smiley

FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com

Last Edited: Mon. Jan 23, 2012 - 07:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yah know, the thread title invited this spirited discussion in one word: "destroyed".

Quote:
destroyedpast participle, past tense of de·stroy (Verb)
Verb:

Put an end to the existence of (something) by damaging or attacking it.
Completely ruin or spoil (something).

The end to the existence of the 8-bit micro? No. At least not now, it hasn't (past tense) destroyed the market.

Has ARM, especially the Cortex Mn, >>affected<< design-in of 8-bit micros? Yes. Or soon will.

Other than that, pricing and comparable features has been hashed over at least once a year here on 'Freaks since ~2007.

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

kk6gm wrote:
And in my recent LPC1111 design I needed low cost and lots of >= 16-bit PWM outputs, and the LPC1111 fit the bill better than any AVR.

And in some other design you need 20x20mA, 5V outputs, or an EEPROM is required..

Making such 8vs32 comparison one:
- either ignores the extra memory or peripherals which do not fit the trends and agrees that 13 channels of 16-bit output compares among 8k devices is rare as hen's teeth,
- or insists on some out-of-main-stream features (like 20nA power-down current or 2k SRAM in 8k device) and continues the comparison of "which is best" without the chips to compare.

Do you think I cannot believe some application requires a 20nA power-down current or 8k flash with 13x 16-bit PWMs? I do believe, it is theoretically possible, but it will not lead the discussion any closer to a conclusion, as these features are far away from the main stream (w.r.t proportions of typical requirements).

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Quote:
Like we've abandoned 555's for ATTiny's now.

Really? This afternoon I studied the schematic of one our recent mains LED drivers, only to find they used a 555 there... while they you could have used a pin on the ST7LITE MCU for that... so there must be a reason for that.

And I also found one on a car combined rear/brake light LED replacement module.

I said, "We've abandoned." Of course, we're smart ;) Of course, avr's don't like 14v supplies (yet).

No matter how big and bad you are, when a two-year-old hands you a toy phone, you answer it.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Of course, avr's don't like 14v supplies (yet).


???
Quote:
• Operating Voltage: 4.0 - 25V
• Maximum Withstand Voltage (High-voltage pins): 28V

Over 5 years ago:
Quote:
37.4 Rev 2548B - 04/05

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

Mario, you need to work your mouse a bit! Google 'stm32f4 discovery' and that will get you to the st site. There will be a link to the Atollic site. There you will find a comparison between their free tools and the paid ones. Similarly for the CodeRed tools.
Basically:
Atollic - no code size limit, only one breakpoint, no reading of peripheral registers in debug and a handful of other things. And a pop up to tell you to buy the full package.

CodeRed, code size limited to 128k but with reasonable upgrades for nxp only.

Overall, Codered is nicer to use. again, my opinion. The suppliers have to put some limitation to compel you to buy their full ticket offerings. What you get for free is not to be sneezed at compared to only a few years ago.

Free compilers? Gcc of course. Its just about what everyone uses apart from IAR, keil/ARM or windRiver. You really want the gui to handle the make and startup files though.
Codesourcery is the usually gcc build of choice for arm. Going command line for a beginner is daunting.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jayjay1974 wrote:
Quote:
Like we've abandoned 555's for ATTiny's now.

Really? This afternoon I studied the schematic of one our recent mains LED drivers, only to find they used a 555 there... while they you could have used a pin on the ST7LITE MCU for that... so there must be a reason for that.

And I also found one on a car combined rear/brake light LED replacement module.

A 555 doesn't need to be programmed. And I think it is more robust than a MCU. I've no idea about EMC but I guess a 555 scores better too.

There are many applications in the world. 555's wouldn't be made anymore if it wasn't used. Same for 8-bit MCU's, same for TH components,...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And a 555 has a strong output, about ten times more drive capability than your average AVR. So it saves on extra transistors too.

It's only 8.2 euro cents at 1000+ quantities at Farnell, so at mass production quantities with prices like a Philips can command I won't be surprised it would cost around one or two cents, or maybe even less.

I don't think any tinyAVR can beat that.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jan_dc wrote:
A 555 doesn't need to be programmed. And I think it is more robust than a MCU. I've no idea about EMC but I guess a 555 scores better too.

On an older product we had big problems with the 555.
It must be repaired again and again.
We add tons of protection resistors and diodes, but with no effect.

Then we replaced it with the Attiny25 and it works reliable.
No one with the ATtiny must be repaired again.

Yes, the ATtiny must be programmed.
But it need less external components (only one 100nF on VCC).
And it need no time adjustment.

I made also bad experience with the 555 on several other projects.
Thus the 555 was forbidden for all our new projects.

It seems, every 555 has a self destruction unit inside. :twisted:

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

CodeRed, code size limited to 128k but with reasonable upgrades for nxp only.

I just reinstalled/reactivated CodeRed on a new PC the other day and note the 128K limit it mentions is for "debug". So it may be possible to generate code larger than 128K if development is done in smaller modules.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
the 128K limit it mentions is for "debug".

http://knowledgebase.nxp.com/showthread.php?t=948

Code Red Support wrote:
The LPCXpresso IDE does impose a limit of 128KB on the files it will allow to be downloaded into flash (...)

AFAIK the limit is only for a download of a flash space. No limits on the compiler or debugger or download or upload of other memory spaces. Looks like you can install a bootloader, download anything into the chip and then connect to a >128kB flash application running. Or even to download a 200kB SRAM code.
I didn't find any explicit information about the limits of this tool.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:

Plus look at some of the designs out there. Do you really need an ARM when a simple 8bit avr can run a programmable thermostat?

Not if the 32-bit part is as cheap or even cheaper than the 8-bit part, which now seems to be the case. The 32-bit part gives you more 'headroom' for future expansion, even if you don't currently need it. And let's face it, when you want a GUI or operating system running on it you can't get around 32-bit ARM. It means you'll be able to reuse all your code, which is a great time saver.

For me, the future seems clear, it's ARM Cortex M0. 8)

Building my dreams!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it's ARM Cortex M0
If you don't use printf anywhere, otherwise 30% of your "arable land" disappears in just 1 function. :shock:

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
it's ARM Cortex M0
If you don't use printf anywhere, otherwise 30% of your "arable land" disappears in just 1 function. :shock:

So what? printf() has always been a code hog in any C-library implementation.

Building my dreams!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
always been a code hog in any C-library implementation
With the AVR it can be less than 1K and up to 4K with "the lot".

And will we see 6 or 8 pin ARMs?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

If you don't use printf anywhere, otherwise 30% of your "arable land" disappears in just 1 function.

30% of what exactly? IOW how many K of code are you talking about and are you sure that the build system (like most AVR compilers) does not offer a number of printf() implementations to choose from in increasing sizes. Perhaps it has the all singing all dancing float supporting one selected by default?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
And will we see 6 or 8 pin ARMs?

Nope 11 IO in a 2.2 x 2.3 mm house.
And if it's to small to handsolder only use the 12 edge "pins". :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
always been a code hog in any C-library implementation
With the AVR it can be less than 1K and up to 4K with "the lot".

And will we see 6 or 8 pin ARMs?

Again: so what? I'm pretty sure someone will be able to do this for ARM to if they hand-code it in assembly.

And why not? There will be fewer I/O's but there's no real difference in that sense between AVR and Cortex-M0, save for the fact that the Cortex-M0 is 5 times faster. Hopefully in the future they'll be able to fit a 50Mhz RC or crystal oscillator on chip or with a digital PLL so one can select any clock frequency up to the maximum rated.

Building my dreams!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Hopefully in the future they'll be able to fit a 50Mhz RC or crystal oscillator on chip or with a digital PLL so one can select any clock frequency up to the maximum rated.

I think it's already established that the majority of the switching inside recent Xmega is at up to 48MHz (because of the USB support) so they are already close to this figure. Video systems over-driving those chips to ~72MHz have recently been shown too so there seems to be quite a lot of "headroom".

But when does one step out of the realm of "microcontroller" exactly? If you are switching pumps/valves and monitoring fluid flow what's wrong with doing it at 1MHz..2MHz. Does doing this at 50Hz or 72MHz or 120MHz or something make it a better controller solution? For years we've seen people asking how to make AVRs go beyond 16MHz, then 20MHz then 32MHz and yet most of the time this "need for speed" is completely bogus. Admittedly there are a few apps like video generation where more CPU speed means more pixel or colour resolution so you want to push it as far as possible but this is generally the exception. Audio is another - above about 48MHz you can do a fair MP3 (lower bit rates) soft decode on an ARM which is something an AVR would always struggle with.

But to claim a speed win for M0/M3 is moot for the kind of apps a 16/20/32MHz AVR would originally have been chosen for.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

But to claim a speed win for M0/M3 is moot for the kind of apps a 16/20/32MHz AVR would originally have been chosen for.

I agree, but if an M0 is cheaper than an AVR, why not take advantage of the extra speed? Like I said, there's a drive towards color UI touchscreens and wireless connectivity. For that you ussually need a 32-bit ARM anyway (if not a complete Linux OS), so you might as well start using an M0 part now so you can swap it out with an M3 easily whilst keeping all your code more or less intact.

Two decades ago it was cool for you device to sport an LCD character display, a decade ago people switched to graphical monochrome LCD's, today it's color UI touchscreens, tomorrow...who knows, but it will be even more CPU intensive I'll bet.

Building my dreams!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

(if not a complete Linux OS), so you might as well start using an M0 part now so you can swap it out with an M3 easily whilst keeping all your code more or less intact.

M0 and M3 are in a different realm to Linux. They are modern equivalents of ARM7. The modern equivalent of ARM9, that has the MMU necessary to run anything but ucLinux is the Cortex A8 not M0/M3.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All,

If you want to discuss Atmel's SAM series of ARM chips, please go to www.at91.com.

If you want to discuss ARM devices from other manufacturers, please go to their forums, or the comp.arch.embedded newsgroup.

This thread is closed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
30% of what exactly?
Of flash. The simple "hello world" using printf takes just over 10K out of the 32K flash.

A simple(r) newer version without floating point takes about 7K.

Mind you it took me over 3 months before I got a sample project where the stupid thing would print to the UART instead of the "console". :evil:

This is using Code Red compiler, maybe other "more expensive" compilers will do better.

NAH, 8 bit will go on forever. :wink:

OOPS did not see the locked thread. Please delete if offensive.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Topic locked