<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>8-bit MicrocontrollersのトピックRe: Watching the use of RAM during development....</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180645#M13085</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;Simple answer? Use simple tricks!&lt;BR /&gt;&lt;BR /&gt;I always put my 'fixed' variables at the bottom and fill up. I always put my stack at the top and fill down. If I have variable variables, like variable size buffers, I always put them just on top of my fixed variables.&lt;BR /&gt;&lt;BR /&gt;And one of the first things I do when I init in my code, is fill all the RAM with an easily recognizable pattern. They just stop and look to see where you pattern still exists. Hopefully it will still be there! At least somewhere.&lt;BR /&gt;&lt;BR /&gt;No matter how much you calculate, there's always some kind of gotcha that can step in and take up ram, usually from nested interrupts or something you were sure wouldn't happen. It's nice to be able to just look as see if your microworld is what you expect!&lt;BR /&gt;&lt;BR /&gt;Mike&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Sat, 19 Jan 2008 05:16:32 GMT</pubDate>
    <dc:creator>mke_et</dc:creator>
    <dc:date>2008-01-19T05:16:32Z</dc:date>
    <item>
      <title>Watching the use of RAM during development....</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180643#M13083</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;SPAN&gt;I'm new to uC programming.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Question: Is there a way to monitor RAM usage during software development?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Background: I am developing on the MC9S08QG8 Demo Board using CodeWarrior 5.7.0. The plan will be to use the MC9S08QG4. I want to be able to monitor the overall RAM usage so that I know that the code will run on the MC9S08QG4. I ran across the Project.map file but I'm not sure if I can totally rely on it for monitoring the overall RAM usage. I'm pretty sure there is a general method for doing this, I just haven't found it. Any documentation on the subject would be great.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Question: Does the size value for "READ_WRITE (R/W):" under the "Summary of section sizes per section type:" in the Project.map file provide the actual RAM usage? Or is it found in another part of the file?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;My other thought would be to just swap out the MC9S08QG8 and install a MC9S08QG4 on my Demo Board.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Question: Will the Demo board support both uC versions?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Thanks for your help.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;DIV&gt; &lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 18 Jan 2008 12:49:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180643#M13083</guid>
      <dc:creator>awilliams</dc:creator>
      <dc:date>2008-01-18T12:49:58Z</dc:date>
    </item>
    <item>
      <title>Re: Watching the use of RAM during development....</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180644#M13084</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Hello, and welcome to the forum.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;The project map file will detail the use of RAM for global and static variables only, that are assigned to a specific address.&amp;nbsp; For C programming in particular, the total stack usage will not be known, and is difficult to estimate.&amp;nbsp; It&amp;nbsp;could be a significant portion of the total RAM available.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;For the QG4, with only 256 bytes of RAM, make sure that the global variables commence at the lowest RAM address (within zero page), and that the stack pointer is initialised to top of RAM.&amp;nbsp; This will keep the stack and the globals as far separated as possible, to lessen the chance of the stack usage over-writing the variables.&amp;nbsp; This may require optimisation of the PRM file, and the use of #pragmas within the code.&amp;nbsp; It is possible for the stack size allocated within the PRM file to be exceeded during operation of the code.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;During testing and debug of your code, it is a good idea to check for the amout of stack used at various times.&amp;nbsp; Initialise all RAM available to the stack&amp;nbsp;to a known value (perhaps 0x00 or 0xFF).&amp;nbsp; Then periodically enter a break point so that the contents of RAM can be examined.&amp;nbsp; The lowest address that does not contain the pre-determined value will indicate the current extent of the stack.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;You can use a QG4 on the demo board.&amp;nbsp; Another possibility is to leave the QG8 device in situ, and simply assign the QG4 device to your project.&amp;nbsp; The QG8 will be directly compatible with any code written for the QG4, but not vice versa.&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Regards,&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;Mac&lt;/FONT&gt;&lt;/DIV&gt;&lt;DIV&gt;&lt;FONT size="2"&gt;&lt;/FONT&gt;&amp;nbsp;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 18 Jan 2008 13:45:36 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180644#M13084</guid>
      <dc:creator>bigmac</dc:creator>
      <dc:date>2008-01-18T13:45:36Z</dc:date>
    </item>
    <item>
      <title>Re: Watching the use of RAM during development....</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180645#M13085</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;Simple answer? Use simple tricks!&lt;BR /&gt;&lt;BR /&gt;I always put my 'fixed' variables at the bottom and fill up. I always put my stack at the top and fill down. If I have variable variables, like variable size buffers, I always put them just on top of my fixed variables.&lt;BR /&gt;&lt;BR /&gt;And one of the first things I do when I init in my code, is fill all the RAM with an easily recognizable pattern. They just stop and look to see where you pattern still exists. Hopefully it will still be there! At least somewhere.&lt;BR /&gt;&lt;BR /&gt;No matter how much you calculate, there's always some kind of gotcha that can step in and take up ram, usually from nested interrupts or something you were sure wouldn't happen. It's nice to be able to just look as see if your microworld is what you expect!&lt;BR /&gt;&lt;BR /&gt;Mike&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 19 Jan 2008 05:16:32 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180645#M13085</guid>
      <dc:creator>mke_et</dc:creator>
      <dc:date>2008-01-19T05:16:32Z</dc:date>
    </item>
    <item>
      <title>Re: Watching the use of RAM during development....</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180646#M13086</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;I recommend the same approach of filling the RAM with a known value and go one step further.&amp;nbsp; I have a routine which is called periodically from the main loop which begins after the last used heap memory and counts upward to find the beginning of stack usage and can send this count out a convenient communications channel if there is one or maybe just set an LED to flash if it gets within ten bytes of RAM left.&lt;BR /&gt;&lt;BR /&gt;All of my projects have this routine.&lt;BR /&gt;&lt;BR /&gt;Good Luck,&lt;BR /&gt;&lt;BR /&gt;Peter House&lt;BR /&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Sat, 19 Jan 2008 05:48:50 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180646#M13086</guid>
      <dc:creator>PeterHouse</dc:creator>
      <dc:date>2008-01-19T05:48:50Z</dc:date>
    </item>
    <item>
      <title>Re: Watching the use of RAM during development....</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180647#M13087</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;Quick followup. I applied the suggestions that you guys recommended and am able to watch my stack usage.&lt;BR /&gt;The suggestion to put static variables at the bottom of memory and the stack at the top of memory....NICE!&lt;BR /&gt;&lt;BR /&gt;Thanks bigmac, mke_et, and PeterHouse.&lt;BR /&gt;&lt;DIV&gt;&lt;/DIV&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Fri, 07 Mar 2008 11:41:08 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Watching-the-use-of-RAM-during-development/m-p/180647#M13087</guid>
      <dc:creator>awilliams</dc:creator>
      <dc:date>2008-03-07T11:41:08Z</dc:date>
    </item>
  </channel>
</rss>

