| Author |
Message |
|
|
 Posted: Jan 13, 2012 - 08:10 PM |
|
Joined: Apr 20, 2007
Posts: 6212
Location: Long Island New York
|
|
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 |
_________________
Jim
I have decided that I am no longer going to plan anything in advance. In a court of law this is called Pre-Meditated, and does not look good for the defense.....
I am trying to 'C' the light. One function at a time.
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 08:13 PM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
| I use whatever device seems best suited to the job in hand, and have used an AVR on several occasions. |
_________________
Leon Heller
G1HSM
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 08:14 PM |
|
Joined: Apr 20, 2007
Posts: 6212
Location: Long Island New York
|
|
|
Quote:
I use whatever device seems best suited to the job in hand, and have used an AVR on several occasions.
By choice?
Jim |
_________________
Jim
I have decided that I am no longer going to plan anything in advance. In a court of law this is called Pre-Meditated, and does not look good for the defense.....
I am trying to 'C' the light. One function at a time.
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 08:17 PM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
| 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 by leon_heller on Jan 13, 2012 - 08:22 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Jan 13, 2012 - 08:20 PM |
|
Joined: Apr 20, 2007
Posts: 6212
Location: Long Island New York
|
|
Question answered.
Jim |
_________________
Jim
I have decided that I am no longer going to plan anything in advance. In a court of law this is called Pre-Meditated, and does not look good for the defense.....
I am trying to 'C' the light. One function at a time.
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 03:55 AM |
|
Joined: Dec 29, 2010
Posts: 466
|
|
|
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! |
|
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 04:12 AM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
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
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 05:41 AM |
|
Joined: Nov 17, 2004
Posts: 6144
Location: Great Smokey Mountains.
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 05:57 AM |
|
Joined: Nov 17, 2004
Posts: 6144
Location: Great Smokey Mountains.
|
|
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
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 06:46 AM |
|
Joined: Oct 29, 2006
Posts: 2690
|
|
| Z80s are still for sale. |
_________________
Michael Hennebry
Iluvatar is the better part of Valar.
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 07:22 AM |
|
Joined: Dec 18, 2001
Posts: 4779
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 07:26 AM |
|
Joined: Sep 12, 2009
Posts: 2471
Location: Sacramento, CA
|
|
| 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. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 08:04 AM |
|
Joined: Jan 08, 2009
Posts: 1199
Location: Lund, Sweden
|
|
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. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 11:18 AM |
|
Joined: Jan 11, 2009
Posts: 208
Location: Stockholm Sweden
|
|
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.
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 11:49 AM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
|
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
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 01:23 PM |
|
Joined: Jul 18, 2005
Posts: 62942
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
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  ) |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 01:40 PM |
|
Joined: Jul 27, 2001
Posts: 7429
Location: St. Leonards-on-Sea (UK)
|
|
| 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
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 02:38 PM |
|
Joined: Jul 17, 2010
Posts: 63
|
|
| [quote="clawson"]
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. |
|
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 02:55 PM |
|
Joined: Jul 18, 2005
Posts: 62942
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
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. |
_________________
|
| |
|
|
|
|
|
|
Posted: Jan 14, 2012 - 03:58 PM |
|
Joined: Feb 13, 2007
Posts: 1026
Location: Gillies, Ontario
|
|
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
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
