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 <[email protected] > <mailto:[email protected]>> 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 [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
