<?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: Uncertainty of modification in .prm-file QD4</title>
    <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199864#M16303</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Patrik,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Since the linker&amp;nbsp;will usually&amp;nbsp;not be attempting to place any variables or code into the stack area, the absence of a placement for the stack&amp;nbsp;should not generate a link error or warning.&amp;nbsp; I can think of only one exception to this, when a "dummy" variable is required at the bottom of the stack, to dynamically check for stack overflow.&amp;nbsp; A placement would then be needed to create the variable.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The allocation of a stack segment requires the use of STACKTOP, rather than STACKSIZE.&amp;nbsp; The different method of handling the stack was probably dictated by the very small RAM resources for this device.&amp;nbsp; This basic method will also happily work for larger devices, provided the use of&amp;nbsp;a heap is not required, as is likely for an 8-bit device.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;With the usual STACKSIZE method, the position of the stack will change, depending on the allocation of static and global variables immediately below the stack.&amp;nbsp; With the STACKTOP method, the position of the stack does not alter, and would usually be placed at the very top of RAM.&amp;nbsp; This means that any unallocated RAM will form a gap between the variables and the bottom of the stack.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Mac&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 25 Jan 2012 14:33:40 GMT</pubDate>
    <dc:creator>bigmac</dc:creator>
    <dc:date>2012-01-25T14:33:40Z</dc:date>
    <item>
      <title>Uncertainty of modification in .prm-file QD4</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199863#M16302</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I am wondering if the lines where I have a comment is needed or not (the stuff about STACK in PLACEMENT). It works great without it, but I have seen in some other threads that it is used.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I have looked at the .map-file and variables are placed from 0x060 and up and the Stack is placed where it should be.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;So to finalize, is it enough to have things about the stack in the SEGMENTS area or do I need the extra lines in the PLACEMENT area?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks for any answers!!&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;/Patrik&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;PRE&gt;/* This is a linker parameter file for the mc9s08qd4 */NAMES END SEGMENTS&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; Z_RAM&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_WRITE&amp;nbsp;&amp;nbsp; 0x0060 TO 0x00FF;&amp;nbsp;&amp;nbsp;&amp;nbsp; RAM&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_WRITE&amp;nbsp;&amp;nbsp; 0x0100 TO 0x012F;&amp;nbsp;&amp;nbsp;&amp;nbsp; STACK_AREA&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_WRITE&amp;nbsp;&amp;nbsp; 0x0130 TO 0x015F;&amp;nbsp;&amp;nbsp;&amp;nbsp; ROM&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_ONLY&amp;nbsp;&amp;nbsp;&amp;nbsp; 0xF000 TO 0xFFA9;&amp;nbsp;&amp;nbsp;&amp;nbsp; ROM1&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; =&amp;nbsp; READ_ONLY&amp;nbsp;&amp;nbsp;&amp;nbsp; 0xFFC0 TO 0xFFCF;ENDPLACEMENT&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; DEFAULT_RAM,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; Z_RAM, RAM;&amp;nbsp;&amp;nbsp;&amp;nbsp; STACK&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; STACK_AREA&amp;nbsp; // &amp;lt;-- is this neccessary?!&amp;nbsp;&amp;nbsp;&amp;nbsp; _PRESTART,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; STARTUP,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; ROM_VAR,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; STRINGS,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; VIRTUAL_TABLE_SEGMENT,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; DEFAULT_ROM,&amp;nbsp;&amp;nbsp;&amp;nbsp; COPY&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; ROM;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; _DATA_ZEROPAGE,&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; MY_ZEROPAGE&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; INTO&amp;nbsp; Z_RAM;ENDSTACKTOP 0x15FVECTOR 0 _Startup&lt;/PRE&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Mon, 23 Jan 2012 22:28:51 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199863#M16302</guid>
      <dc:creator>P_B</dc:creator>
      <dc:date>2012-01-23T22:28:51Z</dc:date>
    </item>
    <item>
      <title>Re: Uncertainty of modification in .prm-file QD4</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199864#M16303</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hello Patrik,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Since the linker&amp;nbsp;will usually&amp;nbsp;not be attempting to place any variables or code into the stack area, the absence of a placement for the stack&amp;nbsp;should not generate a link error or warning.&amp;nbsp; I can think of only one exception to this, when a "dummy" variable is required at the bottom of the stack, to dynamically check for stack overflow.&amp;nbsp; A placement would then be needed to create the variable.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;The allocation of a stack segment requires the use of STACKTOP, rather than STACKSIZE.&amp;nbsp; The different method of handling the stack was probably dictated by the very small RAM resources for this device.&amp;nbsp; This basic method will also happily work for larger devices, provided the use of&amp;nbsp;a heap is not required, as is likely for an 8-bit device.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;With the usual STACKSIZE method, the position of the stack will change, depending on the allocation of static and global variables immediately below the stack.&amp;nbsp; With the STACKTOP method, the position of the stack does not alter, and would usually be placed at the very top of RAM.&amp;nbsp; This means that any unallocated RAM will form a gap between the variables and the bottom of the stack.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Regards,&lt;/P&gt;&lt;P&gt;Mac&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 25 Jan 2012 14:33:40 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199864#M16303</guid>
      <dc:creator>bigmac</dc:creator>
      <dc:date>2012-01-25T14:33:40Z</dc:date>
    </item>
    <item>
      <title>Re: Uncertainty of modification in .prm-file QD4</title>
      <link>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199865#M16304</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Hi BigMac&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Thanks for the reply!&lt;/P&gt;&lt;P&gt;Just what I needed &lt;IMG alt=":smileyhappy:" class="emoticon emoticon-smileyhappy" id="smileyhappy" src="http://freescale.i.lithium.com/i/smilies/16x16_smiley-happy.gif" title="Smiley Happy" /&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 01 Feb 2012 16:10:58 GMT</pubDate>
      <guid>https://community.nxp.com/t5/8-bit-Microcontrollers/Uncertainty-of-modification-in-prm-file-QD4/m-p/199865#M16304</guid>
      <dc:creator>P_B</dc:creator>
      <dc:date>2012-02-01T16:10:58Z</dc:date>
    </item>
  </channel>
</rss>

