0

As I know, the constant value, initialized data of variable will be placed in ROM (Read Only Momory) by compiler in embedded system. But, ROM is Read-only, means that can't write so how can compiler can write these data when programming?

I think ROM in this embedded system case mostly means about EEPROM or flash memory meaning for writing permission.

Is my understanding correct in both embedded system with OS and without OS?

Paul R
  • 208,748
  • 37
  • 389
  • 560
Anhvu
  • 21
  • 2
  • This is not the responsibility of the compiler (all it does is translate high-level language to a lower one). Similarly, OS or no OS has nothing to do with this. The loading of software into an embedded system is often done by a "flash programmer": hardware and software dedicated to writing flash memory. – Ross Aug 19 '15 at 13:34
  • Thanks Ross, I still confuse about the definition of ROM in this case because it is read only, no write permission. When I read some embedded books, it said that const value is put on ROM. – Anhvu Aug 19 '15 at 13:38
  • It is partly the responsibility of the compiler in that it may be required to place constants into a section of the object file written to ROM by the programmer. – Martin Törnwall Aug 19 '15 at 13:55
  • Is Wikipedia down? ROM is "written" at silicon production time (normally the last process on pre-produced dies). You might think of Flash ROM nowadays, or (E)PROM/OTP-ROM. EEPROM is normally only used for calibration or other run-time persistent data. – too honest for this site Aug 19 '15 at 14:14
  • Martin Torn wall, then to write the object file to ROM, how can the system do this? Any special method? – Anhvu Aug 19 '15 at 14:14
  • Olaf, thanks. I am thinking about this way. So in some cases the embedded books should note for this to avoid any confusing. – Anhvu Aug 19 '15 at 14:19
  • The books have to stop somehere. So they have to assume some degree of basic knowledge of the reader. You really should do some research on your own; Please understand that SO is no tutorial site and your question is too broad. – too honest for this site Aug 19 '15 at 14:22

2 Answers2

1

The "read only" part is more about field-programmability than writability in general. Broadly speaking there are three types of ROM:

  • The kind that is programmed as part of the manufacturing process and whose content cannot be changed, such as mask ROM;
  • the kind that can be erased with special equiment, such as EPROM that can be erased with UV light;
  • and the kind that can be erased electrically (usually in circuit), such as EEPROM;
  • also, see the helpful comment left by @Olaf below about the differences between Flash and EEPROM (which admittedly are greater than I thought!)

Many microcontrollers these days – such as Atmel's popular ATmega series – contain some on-chip flash memory for program storage, and may also contain EEPROM for nonvolatile data storage. These memories are written by hardware-specific device programmers.

It is the joint responsibility of the compiler, the linker and the device programmer to make sure that the right data or code is placed in the right type of memory. For example, the compiler likely emits assembly directives that place executable code in the .text section. The linker combines the .text sections of the object files that constitute the program. Finally, the combined .text is written to the device's flash memory.

The device programmer obviously needs some understanding of the executable file format, and a mapping of section names to memory types. Alternatively, an intermediate tool could translate the executable into an input file for the programmer.

Martin Törnwall
  • 9,299
  • 2
  • 28
  • 35
  • EEPROM and FlashROM are very different. While Flash is similar to EPROM, EEPROM is more RAM-like. That's why older MCUs had only EEPROM on-die (the processes of Flash were incompatible with the logic processes). Also EEPROM can be bit/word-wise erased/programmed. Flash OTOH can only be erased per-sector/full array and often programmed only per page (most word-wise programmable FlashROMs internally program whole pages). Furthermore, Flash has a much lower endurance than EEPROM. – too honest for this site Aug 19 '15 at 14:19
  • And there are, of course other persistent memory types, like NV-RAM, MRAM, FeRAM or R(e)RAM, etc. – too honest for this site Aug 19 '15 at 14:23
  • Thanks @Olaf! I edited my post with a reference to your comment. :-) – Martin Törnwall Aug 19 '15 at 14:23
  • Since flash eeproms became mainstream some 15 years ago, there's really just two kinds of nvm: data flash and program flash. Nobody is using mask ROM/EPROM nowadays. – Lundin Aug 19 '15 at 14:29
  • @Olaf What's usually called "eeprom" on modern microcontrollers is actually just flash with small sector sizes. I don't think "true eeprom" is used any longer, at least not on mainstream microcontrollers. – Lundin Aug 19 '15 at 14:32
  • @Lundin: As "EEPROM" is vanishing - except for the "classic" 24xx i2C devices, I'm not that sure. At least their specs often differ from those of the built-in Flash (endurance, e/p cycles). And as a EEPROM-corcess is still compatible with logic, I do not see a benfit to use Flash for those few cells. You can use Flash for many EEPROM-applications, of course. And many MCUs have their Flash split into sectors with different sizes, of course (e.g. STM32). – too honest for this site Aug 19 '15 at 14:39
  • @Lundin: Just checked a STM32L0. You might be right here. But the number of e/p cycles is 1 decade higher than for the program Flash, so it seems not to be the exact same Flash cells. – too honest for this site Aug 19 '15 at 15:00
  • @Olaf Typically they would use higher quality flash for the "eeprom", possibly made in a larger nm to allow smaller sectors. As you have said, the high number of e/p cycles should indicate that the memory is actually flash, because these were quite limited on true eeprom. During the transition to flash in the early 2000s, many microcontrollers still claimed to have eeprom, but if you watched the spec, the high number of e/p cycles, the data retention time (10+ years) and the increased size of sectors all hinted that it was really just flash. Nowadays they just call it data flash, same thing. – Lundin Aug 19 '15 at 15:09
  • @Lundin: " ... high number of e/p cycles ... flash ... limited on true eeprom". Hmm, I remeber the opposite. Flash as using similar cells like EPROM used to have less cycles. These used to be 100k up to more than 1M for EEPROMs back then. For embedded Flash, this was 100 to 1k and is now often 10k (depending on temp.-range, of course). Also EEPROM used ot have longer retention. Just check the 24xx; very sure they are still true EEPROM. About the STM I agree, however. larger cells/floating gates, better/thicker insulation. – too honest for this site Aug 19 '15 at 15:21
  • The larger MCUs do rarely have any kind of explicit persisten data storage. You either have to use the Program Flash or external i2c/SPI. For the latter, there are still true EEPROM versions available (and 24xx04-16 cost few cents nowadays). Applications have changed. explicit data-storage was mostly required for ROM/PPROM-MCUs which could not self-program to customize/calibrate post-production (die or PCB). – too honest for this site Aug 19 '15 at 15:23
1

But, ROM is Read-only, means that can't write so how can compiler can write these data when programming?

To answer the question, the compiler merely creates object files.

These are passed to the linker, which decides at what physical address the variables will end up, typically by reading a linker script of some kind. The linker script might say something like: "program code goes into flash section 1, string literals go into flash section 2, const variables go into flash section 3". The linker creates some binary file format.

The binary is in turn passed to a chip programmer tool or in-circuit debugger, which contains the actual routines for programming the flash.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Thanks Lundin , you gave me a clear example. I can imagine it now. – Anhvu Aug 19 '15 at 14:43
  • @Anhvu So typically the compiler is platform-independent, the linker is specific for the given hardware, and the chip programmer is also specific. A typical setup is for example: the gcc compiler, a linker made by the MCU manufacturer and a chip programmer made by a company that specializes in such. – Lundin Aug 19 '15 at 14:48