Reducing amounts of EEPROM on newer chips

Log in or register to post comments
Go To Last Post
13 posts / 0 new
Author
Message
obdevel
obdevel's picture
Level: Resident
Joined: Sun. Dec 22, 2019
Posts: 529 View posts
Location: Cambridge, UK
#1
Posted by obdevel: Wed. Jul 29, 2020 - 03:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed that the amount of on-chip EEPROM has been reducing, from 1K on the 328P and friends, down to 256B on the 0-series and 512B on the DA (and none on Arm chips). (I limit myself to chips that have an Arduino core available, which is fairly broad).

 

I tend to use EEPROM extensively for infrequently-changing user data and for me this is a bad thing. Heck, I even used it for temporary bus scan results in one project when I ran out of everything else. I don't really want to add another chip to my designs, even if serial EEPROMs cost pennies.

 

I assume it reduces the die complexity or frees up space for other stuff, and maybe reduces cost too. I don't recall being asked for my opinion; maybe I missed the email ;)

 

Yes, I know about the user row, and that flash can be co-opted for the same task, albeit at the cost of additional code complexity/size.

 

Is it the case that most projects don't use it and its loss is no great shakes ?

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
Bronze Markawneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 25563 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Wed. Jul 29, 2020 - 03:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

obdevel wrote:
none on Arm chips

and not just Microchip (or Atmel before them) - this is pretty much the norm across all chip makers.

 

Most of the ARM-based chip makers (including Microchip) publish schemes to simulate EEPROM in the Flash ...

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 oscillator: https://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: Wed. Jul 29, 2020 - 03:18 PM
Top
obdevel
obdevel's picture
Level: Resident
Joined: Sun. Dec 22, 2019
Posts: 529 View posts
Location: Cambridge, UK
Posted by obdevel: Wed. Jul 29, 2020 - 05:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to use the EEPROM emulation on an ATSAMD11 and the additional code took 15% of the available 16K flash before I'd even stored anything useful. Had to upgrade from a 4mm sq chip to a 5mm sq one, which is a lot on a 15x10mm board.

 

 

Top
jgmdesign
jgmdesign's picture
Level: Moderator
Joined: Mon. Mar 19, 2007
Posts: 18820 View posts
Location: Long Island New York
Posted by jgmdesign: Wed. Jul 29, 2020 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
Most of the ARM-based chip makers (including Microchip) publish schemes to simulate EEPROM in the Flash ...

 

Hmmmmm...I wonder what the total execution time for writing to emulated eeprom in Flash as opposed to an external EEPROM connected via SPI would be.

 

obdevel wrote:

I tried to use the EEPROM emulation on an ATSAMD11 and the additional code took 15% of the available 16K flash before I'd even stored anything useful. Had to upgrade from a 4mm sq chip to a 5mm sq one, which is a lot on a 15x10mm board.

 

 

 

Was your code generated by START by chance?  That will bloat the boat for sure....

 

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

Top
obdevel
obdevel's picture
Level: Resident
Joined: Sun. Dec 22, 2019
Posts: 529 View posts
Location: Cambridge, UK
Posted by obdevel: Wed. Jul 29, 2020 - 09:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ASF I believe, from this AN: http://ww1.microchip.com/downloa..., so almost certainly bloated driver code, especially as it needs to do caching, write-levelling, page-level writes, erase-before-write, etc, etc.

 

Maybe they did survey their more valuable customers and found nobody used all that EEPROM.

 

To answer my own question, I guess the silicon overhead of real EEPROM is no longer justified when flash and processor cycles are abundant and emulation schemes are available. It probably makes the memory controller simpler as well.

Top
Kartman
Kartman's picture
Level: 10k+ Postman
Joined: Thu. Dec 30, 2004
Posts: 24979 View posts
Location: Melbourne,Australia
Posted by Kartman: Thu. Jul 30, 2020 - 12:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Atmel probably set the bar as they were the first, if not one of the first to include eeprom and flash on a single chip micro.When the AVR appeared it was cheap, didn't require an expensive programmer, had adc, eeprom and was faster than the 8051 and the dev board was cheap (for the time). It was pretty compelling compared to the other offerings. 

 

It is my understanding (and I could be totally wrong) that implementing high endurance eeprom along with everything else on the smaller geometry processes is a challenge. Even the flash itself is a compromise - the high performance micros use external flash.

Top
avrcandies
avrcandies's picture
Level: Raving Lunatic
Joined: Wed. Jun 30, 2004
Posts: 9429 View posts
Location: Cincinnati Oh
Posted by avrcandies: Thu. Jul 30, 2020 - 01:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Takeaway seems to be the name of the game...take away ext xtal, take away EEPROM...what next?  

EBAY is the king of takeaway.... no more wildcard searching,  no more final selling price offer, no more sort by total cost, no more completed item history (now limited to 30 days)...etc.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 105109 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Jul 30, 2020 - 08:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Presumably it's a question of cost. AVR costs (in fact all chips costs) are directly related to silicon area so presumably this is a trade-off between making the chips smaller/cheaper and more competitive and what Microchip/Atmel's major customers actually want.

 

(question yourself - exactly how many bytes of EEPROM does an "average" app really use? You may well have 256/512/1024 bytes of EEPROM but if actually you use more than 50 (if that) I'm guessing it's quite an unusual application?)

Top
obdevel
obdevel's picture
Level: Resident
Joined: Sun. Dec 22, 2019
Posts: 529 View posts
Location: Cambridge, UK
Posted by obdevel: Thu. Jul 30, 2020 - 11:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tend to make things highly-configurable; a case of form leading function. I have the space so I may as well use it, to store more configuration items or sets.

 

Of course, that falls down when the next iteration of the family removes or reduces something you had come to rely upon. (ATMega328P -> ATMega4809)

 

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5642 View posts
Posted by skeeve: Thu. Jul 30, 2020 - 07:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How much bigger is an EEPROM cell than a PROGMEM cell?

IIRC they are both kinds of flash.

If EEPROM uses a process step that PROGMEM does not,

the first EEPROM cell might cost rather a lot.

That would be an incentive for manufacturers to get rid of EEPROM altogether.

 

Since it's been done, clearly EEPROM emulation can be done with flash.

I'm not surprised the code is complicated.

Real EEPROM had a guaranteed number of writes several times that of PROGMEM.

Write amplification from PROGMEM's pages would seem to make that difficult with emulation.

 

Moderation in all things. -- ancient proverb

Top
sparrow2
sparrow2's picture
Level: Raving Lunatic
Joined: Mon. Oct 7, 2002
Posts: 7580 View posts
Location: Denmark
Posted by sparrow2: Thu. Jul 30, 2020 - 08:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have to remember that Atmel was based on memory (e)(e)prom flash etc. patents. (low voltage programming)

To get into the microprocessor marked they made 8051 products with a Intel license ( AT89C1051 2051 4051 ), and later (I think) chips like AT89S8252 that had eeprom.

The Atmel started the AVR's to avoid paying licens.

Because of this background Atmel chips have always had a bigger amount of eeproms on the AVR's than others.

For a long time is was like if you don't need eeprom use a PIC else use an AVR.

And since it's now all microchip I guess they want to do as they normally do (could also be the proces they use that make a eeprom relative big)     

 

Top
obdevel
obdevel's picture
Level: Resident
Joined: Sun. Dec 22, 2019
Posts: 529 View posts
Location: Cambridge, UK
Posted by obdevel: Thu. Jul 30, 2020 - 08:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excluding the Arm parts (with zero EEPROM) from the argument, just reducing EEPROM still requires the gate/process type and the memory controller. Which leaves real-estate as the only saving.

 

Perhaps die space is really at a premium and increasing SRAM and flash (328 = 2K/32K, 4809 = 6K/48K) required a saving elsewhere.

 

Or the pennies saved per part add up when you're making tens of millions of them. Rather like the ever-shrinking packets of peanuts on flights, for those that remember that mode of transport.

Top
ki0bk
ki0bk's picture
Level: 10k+ Postman
Joined: Mon. Sep 8, 2014
Posts: 10649 View posts
Location: Over the rainbow
Posted by ki0bk: Thu. Jul 30, 2020 - 08:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You may well have 256/512/1024 bytes of EEPROM but if actually you use more than 50 (if that) I'm guessing it's quite an unusual application?)

True, most of the apps I have made use only a few bytes to store calibration data into, so write endurance was not an issue, still having byte addressable eeprom is nice to have.

I would miss it if it was removed.

 

Jim

 

 

FF = PI > S.E.T

 

Top