UC3 vs ARM in 2016

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have been using UC3 for previous projects in the past and also wanted to use the UC3 in future.

We are starting development of a new device now. Basically we need to be reading sensor data ( about 6 sensors, 3 via USART, 3 via ADC), communicating over 2-3 Bluetooth connections (mostly appear as another USARTs to us), driving a TFT LCD, writing data to an SD card and doing some relatively low-demanding calculations. There will be also 1-2 device on SPI and I2C interfaces connected. I will also read about 4-6 buttons available to the user.

I will probably have to multiplex heavily or use additional UC3 chip to collect all the sensor data as the UC3 does not have enough interfaces for this task.

The device is battery powered and needs to have low power consumption (such as UC3A0).

I am quite happy with the Atmel Studio and the development tools for UC3 and I am also happy with the FreeRTOS on the UC3.

 

However, knowing the UC3 is an old part from 2005 - 2010 (anyone knows how long will it even stay in production???) and current growth of ARM-based chips, should I consider moving to such a solution (by Atmel) for this new project? The range of ARM-based chips offered by Atmel is so large I don't even know where to start choosing what might be the best for me (all the Cortex M0, M3, M4, A5 options etc. etc). What could I gain by going to ARM? Most importantly - is it the more future-proof device compared to UC3? Will I get significantly better MIPS performance at similar power consumption? Can I get a chip with many more peripherals on it compared to the UC3? Are the development tools any better or worse? Will the device have significantly more Flash and RAM (I have 512kB/64kB on UC3).

 

To be honest I strongly lean towards just working with UC3 which I am a bit familiar with already. However, I'd like to make a good choice for my new project on which I can run for another 5-8 years at least. My project in my view fits a pretty standard embedded device definition (sensor data collection, communication with a few other chips, LCD and buttons for UI) and I don't need work with multimedia, video capturing or high performance data processing with large amounts of data.

 

Thanks!

 

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

anb8 wrote:
... (such as UC3A0).

...

... (anyone knows how long will it even stay in production???) ...

As long as there's demand.

Consider moving to UC3C as that's in Microchip/Atmel automotive products; automotive parts usually have a longer lifetime due to time to re-develop and re-qualify customer's products.

UC3C with UC3L are in the current, and likely last, revision of the UC3 architecture (FlashVault was added and IIRC a bit more).

http://www.atmel.com/products/automotive/automotive_microcontrollers/default.aspx

anb8 wrote:
... and current growth of ARM-based chips, should I consider moving to such a solution (by Atmel) for this new project?
Yes; UC3 is legacy.

anb8 wrote:
What could I gain by going to ARM?
The answer would be an "answer".

Conversely, gain by MIPS in the form of PIC32?

anb8 wrote:
Most importantly - is it the more future-proof device compared to UC3?
Yes though consider tolerant instead of proof wink

(where's my crystal ball?)

anb8 wrote:
Will I get significantly better MIPS performance at similar power consumption?
Yes though UC3L competes well; UC3C might (haven't compared it).

anb8 wrote:
Are the development tools any better or worse?
No answer though the creator of the NuttX RTOS does not use Atmel Studio to build.

http://www.nuttx.org/Documentation/NuttX.html#armcortexm7

anb8 wrote:
Will the device have significantly more Flash and RAM (I have 512kB/64kB on UC3).
Yes.

anb8 wrote:
My project in my view fits a pretty standard embedded device definition (sensor data collection, communication with a few other chips, LCD and buttons for UI) and I don't need work with multimedia, video capturing or high performance data processing with large amounts of data.
LCD -

Most SAMA5 have an LCD controller; some SAMA5D4 are for watches so the power dissipation is low enough for that use case.

IIRC, no SAM V have an LCD controller but the NuttX RTOS does have an LCD interface :

https://bitbucket.org/nuttx/nuttx/src/9bd8070b34d2fda8ea53fb70e6edcbfd88f79d0e/configs/samv71-xult/README.txt?at=master&fileviewer=file-view-default

(search for RGB8)

video capture - SAM V and SAMA5 have camera interfaces.

multimedia - most of the SAMA5 have hardware and software for that (codecs, crypto for video).

Otherwise, might start your search at Microchip/Atmel automotive MCU then expand from that (if no go there).

"Dare to be naïve." - Buckminster Fuller

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

anb8 wrote:
 What could I gain by going to ARM?

It is pretty much an "industry standard" and very widely - almost universally - supported. 

 

That's "support" in terms of available chips, tools, communities, training, etc, etc, etc ... 

 

So the big thing that you gain is not being stuck in a niche, proprietary, single-source architecture.

 

Will I get significantly better MIPS performance at similar power consumption?

Probably?

Chipmakers are very much focussed on this these days!

 

is it the more future-proof device compared to UC3?

Absolutely!

 

Can I get a chip with many more peripherals on it compared to the UC3?

Yes. And, if not from Atmel, then from the scores of other manufacturers.

 

Are the development tools any better or worse?

Almost certainly better - not least because they are so much more widely used and, therefore, more people to find the bugs!

And more demand to justify the development.

 

Will the device have significantly more Flash and RAM (I have 512kB/64kB on UC3).

Again, the choice available is so huge that there's bound to be something!

512kB/64kB is pretty middle-of-the-road these days.

 

 

To be honest I strongly lean towards just working with UC3 which I am a bit familiar with already.

You may well find that Atmel use similar peripherals in both ARM and AVR32; and, of course, Atmel Studio is the same.

So that should ease your transition...

 

run for another 5-8 years at least.

Definitely ARM, then.

 

My project in my view fits a pretty standard embedded device definition (sensor data collection, communication with a few other chips, LCD and buttons for UI) and I don't need work with multimedia, video capturing or high performance data processing with large amounts of data.

A Cortex-M, then. Probably M3 or M4 would be the place to start looking ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Sat. May 21, 2016 - 07:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Again, the choice available is so huge that there's bound to be something!
and that is the problem !
I find the range of available ARM-based processors to be nearly overwhelming.

Beyond simplistic similarities (such as ARM and AVR32 all have timers), the peripherals will be different, hence more read-and-decipher-the-datasheet exercises.
Atmel Studio with the ASF tries to be platform independent but it has its' own steep learning curve.

I 'lean' towards automotive variants of complex-devices for exactly the reason that gchapman stated.
The era when one could expect parts (or functionally identical versions) to still be available in 10 years time, has well and truly vanished.

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

Thanks for all the comments so far.

I agree the choice of ARM-based processors is overwhelming.

However, I've been going through Atmel product selector and I think the SAM S70 (Cortex M7) might be the ideal solution for me. Of course the performance difference appears to be huge (15x the UC3 performance), but also there is an S70 Atmel processor with 8 UARTs which is a great benefit for me as I can avoid using two UC3 MCUs in my project since each has only 4 UARTs and I may need more than that.

The SAM S70 looks just ideal. Lots of Flash and RAM (2MB/384KB), great performance, lots of peripherals. The only thing I haven't found anywhere is power consumption. If it's much higher than UC3 that might be a big problem.

 

Any ideas/commnets on my S70 choice?

 

Thanks again!

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

I would advise you to bail on the UC3 line.  The development tools are tagged as LEGACY and from what I have read in other threads getting them is becoming a tough chore.

 

Go with the ARM.  As many of us already have, or are slowly migrating there.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

anb8 wrote:
... S70 Atmel processor with 8 UARTs which is a great benefit for me as I can avoid using two UC3 MCUs in my project since each has only 4 UARTs and I may need more than that.
fyi, XMEGA128A1U (and 64kB) also have 8 UART.

Some systems have an 8bit MCU as a board controller (serial ports, time critical bit flipping, real-time, critical event processing) connected to a 32bit MCU for the remaining functions (non-real-time, operator interface, mbed OS, security, secure boot, etc)

http://www.atmel.com/devices/ATXMEGA128A1U.aspx?tab=parameters

mbed - Microchip/Atmel is an ARM mbed partner; but, not all Atmel boards are yet in it :

https://developer.mbed.org/platforms/?tvend=42

anb8 wrote:
The only thing I haven't found anywhere is power consumption.
Ideally preliminary values in the datasheet; it's relatively new so might not yet be completely characterized.

Otherwise, it's try an E70 Xplained.

http://www.atmel.com/tools/ATSAME70-XPLD.aspx

anb8 wrote:
Any ideas/commnets on my S70 choice?
Others have made the same choice; browse and inquire in the SMART ARM community.

 

"Dare to be naïve." - Buckminster Fuller

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

jgmdesign wrote:
... and from what I have read in other threads getting them is becoming a tough chore.
Might depend on the model.

UC3A3 appear to have reasonable stock at Mouser though the UC3A3 Xplained went out-of-stock with a 23 week lead time on its re-order.

Similar for UC3C at Mouser; one large flash 100 pin UC3C shows a 9 week lead time.

Nitrokey Storage (UC3A3) is late due to an enclosure problem.


http://www.mouser.com/Search/Refine.aspx?Keyword=at32uc3a3
http://www.mouser.com/Search/Refine.aspx?Keyword=at32uc3c

https://www.nitrokey.com/news/2016/delivery-date-nitrokey-storage-and-other-news (13.5.2016)

 

"Dare to be naïve." - Buckminster Fuller

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

gchapman wrote:
a 23 week lead time 

Sounds like just code for, "we have no idea when (or even if) we will be able to get any more"

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

IIRC Digi-Key, not Mouser, is the distributor linked to from MCU on Atmel's pages after the demise of Atmel Store.

http://www.digikey.com/product-detail/en/atmel/AT32UC3A3-XPLD/AT32UC3A3-XPLD-ND/2522717 (currently 183 in-stock)

 

"Dare to be naïve." - Buckminster Fuller

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

As I say get a few and compare. The decider these days could well be how good the support library code is. Sadly Atmel don't score too high with their convoluted ASF library code. 

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

mikech wrote:
 ASF tries to be platform independent 

I'm not sure it even tries that hard!

 

From what I remember, the SAM3/4 stuff was very different to SAM D ...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I love the UC3 Chips :)  I am using them in the aerospace industry and they perform very well in the tough environments we put em through. 

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

Would you say they are "better" than ARM then? In what sense? Noise immunity? Power requirement? Something else?

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

Hello,

Does anyone knows where it is possible to consult the status of Atmel parts (in terms of lifetime), and what parts are covered by the compromise of a 12-year longevity program ?

Regards,

Moises

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

moisescastillo wrote:
Does anyone knows where it is possible to consult the status of Atmel parts (in terms of lifetime), ...

Home > About > Quality > PCN and PDN

Atmel Product Change and Product Discontinuance Notifications

http://www.atmel.com/about/quality/pcn-eol/pcn-eol-notifications.aspx

moisescastillo wrote:
... and what parts are covered by the compromise of a 12-year longevity program ?
Am uncertain how to answer your question.

Best ask a FAE; maybe your local sales rep :

http://www.atmel.com/about/contact/distributors/default.aspx?contactType=Sales%20Representative

 

Edit : last URL

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Fri. Jun 10, 2016 - 05:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have the searched the http://www.atmel.com/about/quality/pcn-eol/pcn-eol-notifications.aspx for AT32UC3C, and with the exception of the audio versions, there are no other partnumbers with EOL Change Notices.

Should one conclude that these parts (for instance, the AT32UC3C0512C) will stay on the market more 7-8 years before a EOL statement?

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

What you should perhaps pay more attention to is this:

 

which is page 4 here:

 

http://www.atmel.com/Images/Atme...

 

Of course that was in 2015. Since then Microchip have taken over and may have chosen to reverse that decision but I some how doubt it.

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

Yes, that is true. I mean, there are interesting developments in the ARM devices. And on that perspective, the previous parts, like the UC3C will not be upgraded. That is more or less predictable.

 

But my question, or doubt, is about  how much time these parts (UC3C) will stay on the market, without serious problems in terms of delivery time/price?

 

If the AT32UC3C0512C was released more or less in 2011/12, it is expectable that will be in normal production up to 2022, or this is simply a crazy though?

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

Who can possibly know. Usually what drives the production/stock of chips is demand from large customers. So if some automotive or white goods manufacturer or something is ordering 5m parts each year I imaging they'll keep on fabbing them as long as it continues to make money. But it just takes a big customer to pull out and they could be immediately abandoned. Remember the AP7000 for instance - that was the original AVR32 - the UC3 is basically just a cut down spinoff of that abandoned project.

 

I imagine if you placed a letter of intent with Atmel-Microchip to keep taking 1..2 million parts per annum for the next 10 years or something they'd be able to guarantee a continuation of supply.

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

You are right on this:

...is ordering 5m parts each year I imaging they'll keep on fabbing them as long as it continues to make money.

Anyway, the question is that I don't need the extra performance of an ARM device if compared with the UC3C. And if I have experience in the avr devices, why should I change to the ARMs, if the cost is similar?

Why should I invest time in learning a (more powerful) platform that don't bring me any direct benefit. The only benefit is that it has parts that were released in the last months and the UC3C was released, more or less, 4 years ago. This should not be a so long time period to enter in EOL. But in the present times, who knows?