Author Topic: sprintf(..)  (Read 8085 times)

Offline neil

  • Sr. Member
  • ****
  • Posts: 433
    • View Profile
« on: July 31, 2007, 02:53:39 PM »
  I have included stdio.h within application.c so I can use sprintf(..), but the compiler complains regarding 'typedef unsigned int size_t;' which is in the types.h file of utasker. Any point me to the way around this?


Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3188
    • View Profile
    • uTasker
Re: sprintf(..)
« Reply #1 on: August 01, 2007, 09:45:40 AM »
Hi Neil

I have found that different compilers somehow work a bit differently with this typedef, but I never looked into the details. You should find that your modification will work fine using VisualStudio and some compilers but possibly throws up a warning due to it being defined more than once in the project or else even an error when compiled with others.

Possibly the easiest fix is the following:
1. Remove typedef unsigned int size_t; from types.h
2. Add #include <stdio.h> at the line after #include "types.h" in config.h

I don't have cross compilers handy to check this but I expect that all will compile without warnings.

This subject needs some explanation:
First of all it is important to understand how the project is built up and how the headers are used. It is to be noted that the basic project should work without any compiler libraries - the idea is to make it as simple and compiler-independant as possible. This is the reason why the project also supplies some general purpose routines like uMemcpy() and some formatted output like fnDebugHex(); Not only can a lot of general purpose stuff be realised without using standard libray calls but there are other advantages:
a. When working with simulator and debugger it is then possible to step through such code (generally library functions don't allow this, apart from in assembler).
b. The routines can be optimised for a certain processor. For example they can be set to run from SRAM (for slight speed imporvement) or use HW support like DMA memory-memory transfers (which can result in interesting performace improvements).
c. They don't link in various other standard library routines which can bloat the project size.
d. They do however not restrict in any way the use of standard libraries in user code.

To be compatible with some standard calls, size_t is required and it exists in types.h so that this is the case. In the basic project there are no library headers being directly linked which would otherwise deliver it. Some compilers do however still find a way to supply it and there may still be a warning somewhere, but I have ignored this up to now since it is typedefing with the same value and has no side-effects.

cobfig.h has the following includes

// Project includes are set here for all files in the correct order
#include "types.h"                                                       // project specific type settings
#include "..\..\uTasker\driver.h"                                        // driver and general formatting routines
#include "..\..\stack\tcpip.h"                                           // TCP/IP stack and web utilities
#include "..\..\hardware\hardware.h"                                     // general hardware
#include "..\..\uTasker\uTasker.h"                                       // Operating system defines
#include "TaskConfig.h"                                                  // The specific task configuration
#include "application.h"

In addition, types.h includes a CPU specific file called app_hw_xxxx.h (eg. app_hw_m5223X.h) which can adjust hw specific stuff to a project.

TaskConfig.h, types.h and application.h are taken from the specific project directory so are project specific (and can be freely modified) whereas the others are standard uTasker headers and so shouldn't usually be modified (or need to be modified).

This header file structure was introduced in the V1.3 project to make the management of projects easier.

Using types.h, various types can be optimised for a specific project - for example smaller units can be used to save RAM if certain types only need to be 8 bit wide rather than 16 or 32.

app_hw_xxxx.h allows very hardware specific things to be defined in a way that they are portable. Eg. If the project is running on an M5223X the watchdog toggle LED is workig on PORT TC, bit 0
If the same project is run on the M9S12NE64 it will be operating on port G, bit 0
#define TOGGLE_WATCHDOG_LED()       PTG ^= PTG0

One important goal of the project is the easy moving between supported processors. If both processors do have the necessary HW resources available, it is possible to directly compile the project to the other chip by modifying almost only the 'macros' in its associated app_hw_xxxx.h header!

TaskConfig.h contains everything to do with the task setup in a project.
application.h is used as a general header for application code. Note that this is at the bottom of the list and so doesn't have the same priority as the uTasker defines - it can for example not redefine uTasker defines.

Config.h is the include which is included in all C-files (the only one necessary). It sets the main project settings (like whether HTTP server is to be supported) but it also defines the target. It is possible to move between targets (with the same processor) by adjusting one setting here.
#define M52235EVB   or
#define M52233DEMO  or

This allows the project to fully configure itself for the intended hardware platform. It may be that some members of a development team are working with the production board but some still with an EVB or a demo board. It is probable that not all ports will be at exactly the same locations or possible that the EVB has a chip where the pins are possitioned differently because the package is larger. If you run the simulator with these different settings you will see that the simulated device shows the pins which are really available - this is easily solved in app_hw_m5223X.h by signalling which boards have the 80 pin package!

#if defined (M52233DEMO)
    #define CHIP_80_PIN                                                  // The 80 pin device has various non-connected ports

It was simply found that the project structure in the V1.2 project made it rather mode difficult to configure the project for such flexibility and so the V1.3 solution was an evolution to optimise this requirement (along with various other featiures of course).

Although not many users need the capabilities, the uTasker project can in fact be compiled to run on various CPUs and for each CPU on various target boards by setting one project define (_LPC23XX, _M5223X, _HW_SAM7X, _HW_NE64, _STR91XF) for the CPU and one setting in config.h for the target. If you ever need to be able to do this (even if only switching between a demo board in the evaluation phase to the production board) you will then find out just how practical it can be!!

Back to the original question.
As you see, the files config.h and types.h are 'project specific files' so the user can modify them to best suit his/her own project. This means that the suggested modification to ensure that the size_t is correctly defined in the project is the correct method - if you are intentionally linking a header for a project which is supplying the typedef for that project, it is no longer necessary to supply it in types.h, which is also configurable to suit the specific project.



Additional notes about library use in the project:
So that the library routines can be found by CW, add the library C_4i_CF_SZ_MSL.a, which can be found somewhere like c:\program files\Freescale\Codewarrior for Coldfire V6.3\E68k_support\msl\MSL_C\MSL_E68K\Lib
There may be problems when using the library with CW due to its compatibility with the build options - ensure that you use the mwerks.h file from SP5 (\Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3\include\mwerks.h modified to force function pointers in A0 to be compatible with libraries). For more details about this, see the following Freescale forum posting:

« Last Edit: September 06, 2007, 01:02:38 PM by mark »

Offline tr111

  • Jr. Member
  • **
  • Posts: 72
    • View Profile
Re: sprintf(..)
« Reply #2 on: September 07, 2007, 10:35:29 AM »
Great idea!