Hello,
It is my understanding that the simulation error occurred because the stack attempted to exceed the boundary
of the segment used by the stack, and not when the STACKSIZE parameter was exceeded. Had the boundary
not been exceeded, but more than the STACKSIZE limit used, an error would not have been reported, but
serious problems could still potentially occur.
It would appear that the default PRM file generated by CW, specifically for the HC908QB8 device, has
significant shortcomings for all but the simplest of projects. The following is the default arrangement
generated by CW.
/* This is a linker parameter file for the QB8 */
NAMES END
SEGMENTS
ROM = READ_ONLY 0xDE00 TO 0xFDFF;
Z_RAM = READ_WRITE 0x0040 TO 0x00FF;
RAM = READ_WRITE 0x0100 TO 0x013F;
ROM1 = READ_ONLY 0xFFB0 TO 0xFFBD;
ROM2 = READ_ONLY 0xFFC2 TO 0xFFCF;
END
PLACEMENT
DEFAULT_RAM INTO RAM;
DEFAULT_ROM, ROM_VAR, STRINGS INTO ROM;
_DATA_ZEROPAGE, MY_ZEROPAGE INTO Z_RAM;
END
STACKSIZE 0x30
VECTOR 0 _Startup
Because there is no segment specifically allocated to the stack, the stack automatically becomes allocated to
DEFAULT_RAM. Additionally, any global variables are also allocated to DEFAULT_RAM. This means that,
by default, the stack and any global variables must share a total of only 64 bytes, with every chance that the
variables will be over-written by the stack, without any warning whatsoever.
Daniel's alternative PRM neatly solves this problem by providing an explicit segment for the stack, and by
DEFAULT_RAM being allocated to the Z_RAM segment. Thus there is much wider separation between the
global variables and the stack, and a simulation error should occur if the stack usage exceeds its segment
boundary. The STACKSIZE value would appear unimportant if using a separate stack segment.
The alternative PRM would seem a much better default arrangement for the QB8 device, to suit a wider
variety of projects.
I totally agree with Lundin's comments concerning use of sprintf() - more than 1.5K just for that function, in
a device with 8K total flash - very expensive! I recall that there are other threads within this forum that address
binary-to-BCD conversions. These should be easily adapted for 16-bit binary-to-ASCII.
Regards,
Mac