Atmel Micro controllers suggestion required

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

Hi,

 

We are searching for atmel micro-controller on mouser and digikey with following specifications shown in figure:

 

Which gives the following microcontrollers list:

All these shown micro-controllers do not have internal eeprom, that we require for data storage and retain that data until we force to erase. We were using Atmega 1281 which have 128Kb of program memory and 4096 Bytes of eeprom that is not enough in our case because our code increases whenever we a add new functionality, so we require a atmel micro-controller of supply voltage of 5V and at least 512Kb program memory with eeprom of at least 4096 Bytes or greater. Please suggest a atmel family micro controller.

 

Regards: Shahzad Raza

 

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

Are you sure you need so much flash storage for the program?  Often rethinking things can bring a large reduction--it is easy to waste space.

Why not simply add an spi EEPROM for your data storage?...then you can have as much as you desire.

When in the dark remember-the future looks brighter than ever.

Last Edited: Tue. Apr 17, 2018 - 07:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can change your specs to 3V and forgo eeprom you’ll have many more choices. On modern chips eeprom is emulated in flash.
Note that AVR32 is going or gone EOL for most parts.

Last Edited: Tue. Apr 17, 2018 - 07:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Note that AVR32 is going or gone EOL for most parts.

 

See: https://www.avrfreaks.net/commen...

 

("EOL" = "End Of Life"; ie, these chips are on the way out - not something to be starting a new project on)

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

A common storage option in a lot of embedded devices these days is the SD/MMC card (also microSD and eMMC) - you could use that to store the "data" parts of your program (like LCD fonts or whatever it is that is using the 100's of K) and by writing/reading files there it's effectively "infinite EEPROM" ;-)

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

clawson wrote:
A common storage option in a lot of embedded devices these days is ...  eMMC

Indeed.

 

See, for example, the Beagle Bone Black ...

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

shahzadsialvi@gmail.com wrote:
We were using Atmega 1281 which have 128Kb of program memory and 4096 Bytes of eeprom that is not enough

What is not enough - the 128K Flash, or the 4K EEPROM? Or both?

 

case because our code increases

Surely, that would impact Flash - not EEPROM?

 

 

so we require a atmel micro-controller of supply voltage of 5V and at least 512Kb program memory with eeprom of at least 4096 Bytes or greater.

Well, strictly, Atmel no longer exists - it's now Microchip.

 

Does it have to be Microchip?

 

Don't be fooled into thinking that the "AVR" in both "AVR8" and "AVR32" means that AVR32 is just a bigger AVR8. 

It isn't - it's a whole different beast.

 

So you might as well go to Cortex-M

 

shahzadsialvi@gmail.com wrote:
supply voltage of 5V

It's going to be a major hardware redesign anyhow - so why not also make the switch to 3V?

 

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

awneil wrote:
Don't be fooled into thinking that the "AVR" in both "AVR8" and "AVR32" means that AVR32 is just a bigger AVR8.
This is one of the most misleading things Atmel ever did - they presumably thought they'd catch AVR8 users looking for a bigger/more powerful AVR by calling the AP7000 / UC3 chips "AVR32".

 

If "AVR"really are the initials of the original designers of the RISC core then were they really involved in the design of the UC3? Otherwise it truly is a misnomer.

 

(AFAIK the AVR32 was done in France by the same team that had previously done the SAM7/9 chips - and that's why there's so much commonality in a lot of the peripherals).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1
  1. When searching vendor sites like mouser/digikey/etc and you need "at least 64k of memory", be sure to select search criteria that include chips with MORE than that requirement.  Mouser has a >= selection on some fields, or you can manually select more than one value on most sites with Shift or Command.  (with >=64k RAM, >=512k flash, I see 1200+ matches.)
  2. Same with voltage.  If it's OK to operate a 3.3V, you need to include the search term for all the "x-3.3V" as well as "3.3-5V."  Especially since a lot of chips are 1.8V-3.3V or so.
  3. Sometimes chips don't have proper values set in the parametric tables, and don't show up when they should.  Do your search on multiple vendors' web sites.
  4. EEPROM doesn't seem to be compatible (semiconductor-process-wise?) with the processes used on newer chips.  However, many of them allow you to write flash memory from user programs, which is frequently sufficient.  Sometimes there is even an "EEPROM Emulation Library", or a special area of flash that is set up to be more EEPROM-like (smaller pages?)
  5. You probably don't want an AVR32.  There a significant number of SAM4 chips that fit, plus the new SAMD5x.
  6. Do you really want to restrict the search to Microchip/Atmel?  Over 3000 matches on just the memory requirements, if I allow any vendor...

 

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

There is no inherent difference between FLASH and EEprom, but the number of erase cycles it can endure is dependent on process technology. Like Kartman says, when a uC is capable of writing it's own "FLASH" ( bootloaders and such) there is not much use anymore to add an extra EEprom peripheral. (Except for the endurance thing).

I haven't worked with it yet (Most programming I did was for AVR), but I've seen linker scripts where a section of flash was reserved for "EEprom emulation".

 

Combination of a "decent size uC" and 5V is hard to meet.

Most 5V controllers are small, "bigger" uC's are (almost ? ) always 3V3.

I did not do extensive research, but I have not seen a 32 bit uC with a 5V power supply yet.

 

I can understand you want to stick with a single uC family and you are currently using the atmega128.

To me it looks like you are outgrowing the ATMEGA range of controllers and it is time to be seriously considering a "bigger" range of uC's.

One of the ARM architectures seems the most logical choice nowaday's. Atmel has the atSAM range of uC's, but there are plenty of other bidders on the market. ( The mbed website has a nice overview of ARM development boards from different manufacturers and much more).

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Paulvdh wrote:
here is no inherent difference between FLASH and EEprom
I thought it was about "page sizes". Flash typically has pages that must be totally erased that are anything from 32/64 bytes up to lots of MBs in huge devices. EEPROM (like NOR) has no such requirement so there is no "page updating" requirement as every byte can be individually addressed.

 

Sure recent devices like Cortex etc "emulate" EEPROM in flash but surely this is just being done by a "page manager" of some sort?

 

One could presumably implement such a page manager in AVR8 too if you wanted to use part of the program flash for "emulated EEPROM". But it does mean that when even a single byte in the middle of a page has even just one 0 to 1 bit transition it will involve caching the entire page contents (and applying the byte modification), then erasing the whole page, then writing the page back. Which is both time and erase cycle wasting.

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

Yes, true, of course. With "No inherent difference" I only thought about the implementation of the memory cells on the silicon.

https://en.wikipedia.org/wiki/Flash_memory

The cells themselves are (pretty much) the same, but the logic around them can be quite different.

 

https://en.wikipedia.org/wiki/Fl... wrote:
Although flash memory is technically a type of EEPROM, the term "EEPROM" is generally used to refer specifically to non-flash EEPROM which is erasable in small blocks, typically bytes. Because erase cycles are slow, the large block sizes used in flash memory erasing give it a significant speed advantage over non-flash EEPROM when writing large amounts of data.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Kartman wrote:
Note that AVR32 is going or gone EOL for most parts.
Specifically, UC3 is NRND on current Microchip web pages.

Some UC3 are in Microchip's automotive catalog; one doesn't want to PO automobile manufacturers wink

UC3C has recent maintenance activity though it will not receive design activity.

An alternative is the 5V SAM though I don't know the parts that would meet the requirements in post #1 (I didn't search)

 

https://www.microchip.com/wwwproducts/en/AT32UC3C1512C

http://www.microchip.com/mymicrochip/Reports.aspx?type=cpn&filter=AT32UC3C1512C

http://www.microchip.com/design-centers/32-bit/sam-32-bit-mcus/sam-c-mcus

 

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

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

Quote:
... so we require a atmel micro-controller of supply voltage of 5V and at least 512Kb program memory with eeprom of at least 4096 Bytes or greater. Please suggest a atmel family micro controller.

 

Regards: Shahzad Raza

Max in AVR is XMEGA384C3 but it will need level converters to reach 5V.

Level converters come in small packages or with multiple widths and are common parts.

Level conversion is common in cPLD.

https://www.microchip.com/wwwproducts/en/ATxmega384C3

 

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

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

I have not seen a 32 bit uC with a 5V power supply yet.

I've been someone preoccupied with 5V 32bit CPUs.  Here's a (partial?) list:

 

Atmel SAMC series  (Cortex M0)

Most Cypress ARM chips (PSoC AND FM-series.  CM0, CM3, CM4)

NXP (Freescale) Kinetis E series (CM0, CM4)

Some Toshiba arm chips.

 

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

westfw wrote:

I have not seen a 32 bit uC with a 5V power supply yet.

I've been someone preoccupied with 5V 32bit CPUs.  Here's a (partial?) list:

 

Atmel SAMC series  (Cortex M0)

Most Cypress ARM chips (PSoC AND FM-series.  CM0, CM3, CM4)

NXP (Freescale) Kinetis E series (CM0, CM4)

Some Toshiba arm chips.

 

Yup, and Nuvoton M0 & M4 series.... and Infineon XMC, (but I think for Infineon, larger parts ~  512k are not 5V, smaller ones are)

and Renesas have expanded their 1.8~5V offerings, 

https://www.renesas.com/en-us/ab...

https://www.renesas.com/en-us/pr...

 

 

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

Are 5V-capable pins adequate?

(Yes if CMOS-to/from-TTL)

35 5V-capable pins in the 100 pin QFP PIC32MK (motor control)

Approx 10mA drive if I correctly read the datasheet.

http://www.microchip.com/design-centers/32-bit/pic-32-bit-mcus/pic32mk-family

 

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

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

gchapman wrote:
 5V-capable

Note that some manufacturers call this, "5V tolerant"

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