• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 33 subscribers
  • Views 3850 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Memory in a microcontroller

Tuan Hua
Prodigy 200 points


I know that I am asking a basic question, but I am new to embedded. My questions is about memory in a microcontroller, Tiva C for example.

1/ As I know, heap is the memory that we can allocate and deallocate arbitrarily, stack is the memory that is allocate and deallocate automatically by the controller. Is it right? And, heap and stack is located in flash or RAM?

2/ In a tiva C, the tivaware is stored in ROM. Why this way make our code run faster?

3/ What is the role of RAM, ROM and flash in a microcontoller?

Please help me and thanks for reading. :D

  • 0
    TI__Guru**** 244410 points
    Hello Tuan

    1. Heap and Stack are RW memory so it has to be in RAM
    2. ROM has a single cycle access path compared to the same API in flash as the flash run using multi cycle wait
    3. ROM and Flash are NVM memory, so good to have code stored there when the device is powered down. RAM is the compute memory
  • 0 in reply to Amit Ashara
    Prodigy 200 points
    1. Heap and stack are stored in RAM, binary of source code and global and static variables are stored in flash?
    2. I have just read a document in this link : courses.cs.washington.edu/.../lec07.pdf
    It says that " — In a basic single-cycle implementation all operations take the same amount of time—a single cycle. A multicycle implementation allows faster operations to take less time than slower ones, so overall performance can be increased". It sounds like multicycle is faster. I also have another question: If storing source code in ROM speed up the process, so why we still store our code in flash?\
    3. Done :D

    Thanks for your help. :D

    Tuan
  • 0 in reply to Tuan Hua
    Guru 27665 points

    There should be a reference book for this somewhere but I don't have a link so a few thoughts. Note that this is C/C++ centric. Other languages have different concepts.

    Tuan Hua said:
    1. Heap and stack are stored in RAM, binary of source code and global and static variables are stored in flash?

    Heap and stack are allocated to RAM

    So are non-const global and static variables. The initial values for these variables are stored in flash and the RAM values are initialized to these on startup by the C runtime.

    Tuan Hua said:
    2. I have just read a document in this link : courses.cs.washington.edu/.../lec07.pdf
    It says that " — In a basic single-cycle implementation all operations take the same amount of time—a single cycle. A multicycle implementation allows faster operations to take less time than slower ones, so overall performance can be increased". It sounds like multicycle is faster. I also have another question: If storing source code in ROM speed up the process, so why we still store our code in flash?\

    multi-cycle operations - an operation that requires multiple instruction cycles to access (multiply and divide are classic operations that may require multiple cycles). Multiple cycles obviously takes longer

    multi-cycle memory access - multiple memory cycles are required to read and/or write to the memory. Obviously code that needs to acces this will run slower. Often there will be some form of cache to reduce the effects of multiple cycle access.

    Amit did not mention the other reason for using Flash to store code. It's erasable. ROM is not.

    Robert

  • 0 in reply to Tuan Hua
    TI__Guru**** 244410 points
    Hello Tuan

    1. Constants and binary of the application are in stored in flash
    2. The TM4C129x device has a wait state which causes a execution halt while the instruction is fetched.
  • 0 in reply to Tuan Hua
    Guru 13040 points
    About "If storing source code in ROM speed up the process, so why we still store our code in flash?"

    A: Because you can't store anything in ROM! ROM comes ready when you buy the IC and you won't be able to change it.

    The concept and advantage of using TivaWare functions stored in ROM is that TI has already included all those functions in ROM for you! So if for example, you need to send bytes via a serial port, and you use ROM_UartCharPut(), the code to execute such function is already in a certain location in the chip's ROM memory.

    If that was not the case, your compiler would have to create the code, this code would need to occupy some space in your FLASH memory, and the execution of the function would require program flow to divert to that particular location of your FLASH memory. Then comes Amit's explanation: diverting to a place in FLASH is slower than diverting to a place in ROM.

    And obviously, your application code requires less FLASH space if you use all your TivaWares from ROM!


    Bruno
  • 0 in reply to Robert Adsett
    Prodigy 200 points
    1. Done :D
    2. Done :D
    thank you very much

    I have a another question:
    4. Can you explain about the process of a uC when it is powered on? As I know, when the uC is powered on, it load binary code to RAM, isn't it?

    Thank you, again :D

    Tuan
  • 0 in reply to Tuan Hua
    TI__Guru**** 244410 points
    Hello Tuan

    The code is stored in Flash. On a power up it may be copied to the SRAM and executed from SRAM, based on the linker directives.
  • 0 in reply to Tuan Hua
    Guru 27665 points

    Tuan Hua said:
    4. Can you explain about the process of a uC when it is powered on? As I know, when the uC is powered on, it load binary code to RAM, isn't it?

    Some high power controllers work that way but most start executing the user's program in Flash immediately. Some, run a short ROM based program before jumping to the user program.

    Robert

  • 0 in reply to Robert Adsett
    Prodigy 200 points
    Hi Robert,

    when you said "run a short ROM based program before jumping to the user program", you mean something like bootloader?
  • 0 in reply to Tuan Hua
    Guru 27665 points
    Yes, It may do more or less than what you may be expecting from a bootloader but it's the same type of program.

    Robert
  • 0 in reply to Robert Adsett
    Guru 11940 points

    Some high power controllers work that way but most start executing the user's program in Flash immediately. Some, run a short ROM based program before jumping to the user program.

    The boot behavior is very vendor-dependent, and one can hardly get around reading the datasheet ...

    I know of Cortex M devices that allow immediate code execution from RAM, depending on the selected boot mode (GPIO pin combination). This is mainly useful for debugging.

  • 0 in reply to f. m.
    TI__Guru**** 244410 points
    Hello f.m.

    But the code fetch to RAM still has to be done from an NVM
  • 0 in reply to f. m.
    Guru 27665 points
    I'm glad you mentioned debug, I was beginning to wonder why it would be useful to execute uninitialized RAM. ;)

    Robert
  • 0 in reply to Robert Adsett
    Guru 11940 points

    Correct, this makes only sense in connection with a debugger, who initalized the RAM beforehand. For anyone interested in this "feature", look at the STM32 datasheets...

  • 0 in reply to f. m.
    TI__Guru**** 244410 points
    Hello f.m.

    That is possible on TM4C as well under a debugger connection....
  • 0 in reply to Amit Ashara
    Guru 27665 points
    Without the debugger attached and running on reset? That's the kind of behaviour f.m. is referring to.

    Robert