CW 6.3 Special Edition - 32K C code limit, s08 Target

[nhpete]

I am an electronics hobbyist.  In past projects, I have always programmed in assembly using a stand-alone absolute assembler.  Since my next project will utilize a bit of floating point math, I plan to utilize some C floating point routines in addition to a number of assembly routines and wish to develop all code in CW Special Edition.  However, I am a bit confused (and concerned) about the 32K C code limit in CW Special Edition.  In the course of experimentation, I find that the floating point libraries alone contain close to 32K of C code.  Will this code count towards the 32K limit?  If yes, it sounds like I cannot use Special Edition for this project.  I would hate to spend lots of time front ending my familiarity with CW only to find that the time was ultimately wasted due to C limits. Can anyone clarify for me what goes into the C code size limits of CW Special Edition?  i.e. which files are actually counted towards this limit?  Thanks.

[NavidadRedivivu]

Afaik, the limit pertains to the total size of the code that gets linked, meaning that the code that comes from the libraries Freescale provides is indeed counted. However, there are a couple of things that work in your advantage. First, the linker strips all the code that is not used by your project (directly or indirectly). For instance, if you never use floating point multiplications, the code for those routines will not be linked and hence not counted. Another detail is that the limit is only imposed on C code, while the assembly code is not subject to any limits.

[nhpete]

Thank you very much for the concise response, that certainly makes sense and helps a lot.  As a follow up, is there any way I can determine how close I am to the 32K C limit at any point in code development, or do I just have to wait until I get an error message after trying a build?  Can the size of the executable .S19 file (or perhaps some other file) serve as an indicator?  e.g. If I examine the size of the .S19 file before and after a  component is linked to the project, can I assume the change in size is the amount of C-based machine code which has been added, and is this code the basis of the C-code limit? Assuming that the .S19 file was less than 32K, does that imply that the C code must also be less than 32K, or is the C code size measured in some other way? 

Please forgive these very basic (stupid?) questions, but CW and compilers are all new to me and I don't want to start down the CW road unless I can satisfy myself that I won't hit a wall after spending lots of time on development. If I have to, I can do all routines in assembly but that isn't what I want to do.

Thanks.

[bigmac]

Hello,

The S19 file size will exceed the program size by a factor of maybe 2.5 to 2.8 times.  Since this file is an ASCII text file, each byte value is expressed as two hexadecimal characters.  In addition, each line contains some overhead characters, typically 12 including EOL characters.  When a line defines 16 byte values (typical), this would require 44 ASCII characters.

You should be able to progressively determine the progam size by examining the project.map file.  This is a text file that is generated by the compiler/linker.

A word of caution - to keep the program size to a minimum, never make use of the library functions printf() and sprintf().  These are very large functions.

Regards,

Mac

[NavidadRedivivu]

Sorry for the late reply. Apart from what bigmac already underlined: the map file provides the information you need in the "MODULE STATISTIC" section, where you get the code and data size on a per-module basis. What is not so obvious is that the displayed sizes are computed after stripping down all the unreached code/data (I hope I'm not wrong here). It is a bit unforunate that there is no grand total computed, but this should give you an idea.

[bigmac]

Hello,

Another useful part of the project.map file is the section headed "Object list sorted by address".  This shows the sequence of all objects, including registers, RAM and flash.  It is easy to determine the first flash object at the start of flash.

Then look for the start address of the final flash object, ignoring any vector table entries that may be present.  To this address, add the size of the final object to determine the total flash resources currently in use.  It is possible that the last group of objects will be associated with the library functions in use (that commence with an underscore character).

Regards,

Mac

[nhpete · Accepted solution]

Mac and Navidad:

Thanks very much for the very helpful and timely information.  CW seems to be very powerful and, consequently, is a bit daunting at first.  Without the jump start provided by you two I didn't even know where to start in the help files to answer my concerns.  The info you provided has gotten me to some very pertinent areas in the help files and has allowed me to do enough experimenting with the examples to become reasonably confident that I will be able to complete the entire project with CW Special Edition.  Again, most of the code will be in assembly, only the math routines and maybe the initialization will be in C.  If the initialization gets me into trouble with the C code size limit, I'll do it in assembly.  My output devices will be LEDs, all related routines will be in assembly, and I will have no need to use printf(), etc.

Once again, tnx to both of you for your time.  I think I am good to go!

Pete