Has ARM destroyed market for 8 bit micros?

Last post
186 posts / 0 new

Pages

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

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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.

  • 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

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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

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

Question answered.

Jim

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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.

Is it racist to discriminate against someone who changes species?

  • 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

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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?

Is it racist to discriminate against someone who changes species?

  • 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

I would rather attempt something great and fail, than to attempt nothing and succeed. - Fortune cookie

George Orwell wrote about the future, and people called it fiction.

  • 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!

Pages

Topic locked