My understanding of "global" variables is that anything declared outside of a function definition is allocated in the heap at link time, and the final size of that heap is what is reported as RAM usage. All variables inside functions (that are not labeled static in real C) are just names for stack locations at runtime.
Initialized globals will have a value stored in ROM, and the compiler/linker will insert code to copy those values from ROM to RAM at startup. Uninitialized globals _may_ be set to zero if the startup code is nice and does a memset(0) to the heap before copying, but counting on that is an example of chickens-before-hatching. There is also a boot-loader pre-installed on the motes that implements the USB/serial download behavior. I've found very little mention of this, so I don't know how one gets it initialized. But it does add a bit of overhead to the ROM size of your final program. I would also take minor issue with the idea that the .hex file is "human readable"... I guess it depends on the human in question... It's probably in ASCII because early systems often had difficulty with 8-bit data on serial ports used to connect to programmers, because the serial lines were most often connected to 7-bit ASCII teletypes. MS Urs Hunkeler wrote: > Hi Ricardo, > > I'm not sure I understand your explanation. Also, I'm not entirely sure > how this works on the microcontroller. Essentially, a program consists > of a number of sections. One section is the actual program code (i.e., > the instructions in binary form), and for the programs generated by > TinyOS there is another section with the initialization values for the > variables that are initialized (there is also a section with interrupt > vectors). Normally, the operating system would load the different > section into the memory (where each section also gives the address where > it should be stored in the memory), and then start program execution at > a specified program counter address (the memory address of the first > instruction to execute). > > The differences with microcontrollers and TinyOS compared to regular > computers is that the program image also contains the operating system. > What I can say for sure is that the actual program code (the machine > code) gets stored at the right position in the flash when you program a > mote. Basically, each line in the HEX file gives an address and then a > piece of binary code (in human readable HEX form, hence the file type > name). The programmer copies this binary code as-is to the FLASH (FLASH > is a form of rewritable ROM) of the microcontroller at the addresses > specified in the HEX file. When the microcontroller is reset, it will > always look at the same address for the first instruction to execute, > and hopefully the program start of your program has previously been > written to this exact address. > > So the HEX file contains (in some bloated form so that it is > human-readable) the exact binary image as it is going to be copied to > the microcontroller. The actual memory used for the program code is this > ROM value (13800), and the actual memory statically reserved for global > variables is the RAM value. I am not sure whether the ROM value includes > the initialization values or not. The RAM value is how much memory is > statically reserved, but the program might need more RAM because local > variables (variables inside functions, etc.) get dynamically added to > the stack. > > It is important that the size of the HEX file does not matter much. It's > sort of an inversely compressed binary image (i.e., it is much larger > than the actual information contained within). I think the actual FLASH > usage is what is given at the end of the compile phase. The RAM usage is > at least what is given at the end of the compile phase, usually you > should have a couple of hundreds of bytes free for the heap. > > Cheers, > Urs > > > On 7/16/10 4:13 PM, Ricardo . wrote: >> Thanks for the reply. >> >> Let me get this straight, the actual occupied memory is provided as a >> value for the ROM (13800). The flash memory contains the .hex file, >> which is then decomposed into the ROM and RAM. >> >> Is my understanding correct? >> >> Regards, >> -- >> Ricardo >> >> On Fri, Jul 16, 2010 at 2:40 PM, Urs Hunkeler <urs.hunke...@epfl.ch >> <mailto:urs.hunke...@epfl.ch>> wrote: >> >> Hi Ricardo, >> >> The HEX file is a text file. Every byte of the binary is written >> as two characters (human readable hex values). In addition, there >> are addresses, checksums and other programming or control information. >> >> If you don't assign any value to a variable declaration, that >> variable will get a reserved space in the RAM, but this space is >> not initialized. Hence there is nothing to do, the code "might" >> execute a little bit faster and "might" be a little bit smaller, >> but you have to be sure to do the right thing. If you assign a >> value to a variable at initialization, this value has to be stored >> somewhere and the variable needs to be initialized before it can >> be used. I think (please, someone correct me if I am wrong) this >> concerns only global variables, and the mote will copy part of the >> FLASH to the RAM when booting to initialize these variables (they >> always have exactly the same address in the RAM, determined at >> compile-time). >> >> Cheers, >> Urs >> >> >> >> On 7/16/10 2:55 PM, Ricardo . wrote: >> >> Hello everyone, >> >> I'm trying to understand the relationship between ROM and RAM >> .hex file >> generated in the build. >> It has been said here that: >> >> > In words few ROM includes the code and initialized data >> RAM and includes >> > BOTH initialized and uninitialized data (note the stack >> That Is Not >> > Included). >> >> >> But for example, when compiling the code this values are >> displayed: ROM: >> 13800 bytes, RAM: 594 bytes and the .hex file generated has 38 832 >> bytes. I can not see how it goes from 38832 bytes to (13800 >> +594) bytes. >> >> What is the advantage of uninitialized data in RAM? >> >> Someone help me understand this? >> Regards, >> -- >> Ricardo >> >> >> > > _______________________________________________ > Tinyos-help mailing list > Tinyos-help@millennium.berkeley.edu > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help _______________________________________________ Tinyos-help mailing list Tinyos-help@millennium.berkeley.edu https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
