Libraries
Background
Tollos code and libraries are held in a simple directory structure, where all applications and libraries have a unique name and are held at the same ‘level’ in a common directory (typically called ‘tollos’).
Each application or library directory contains:
- the .c source code and .h include files for the application or library
- a script (churn.bat) that will build the application or library
- once built, the resulting binary file (.bin or .hex) or archive (.a).
There may also be additional material (notes, documentation, link scripts, etc.).
Keeping both the .c and .h files in the same directory is somewhat unconventional, but is convenient because they often have to be edited at the same time, and they form a logical unit.
Some devices also require manufacturer-supplied header or source code files (for example, for definitions of register names, addresses, and bits). These are always held in a subdirectory named ‘public’. The header files for a library can therefore be found by adding to the include path (a) the name of the directory and (b) a subdirectory of it called public.
The name of the final application binary or library archive is always the same as the name of the directory in which it is constructed; this similarly allows easy location of any libraries needed at link time.
In the sample application distribution, each directory has a short script that can be used to build it (on Windows, XP or later). This script is called churn.bat, and simply sets a few environment variables to indicate
- which C files are to be used
- which other libraries (directories) are needed for their header files (or for linking, if building an application) – tollos will almost always be needed
- any additional (extra) compilation flags, etc.
- whether to build the result as a library or application binary.
The charm.bat script (in the tollos directory) is then called to effect the build. This compiles all the modules specified, combines the object files as requested to form the final binary or archive, and then deletes the object files. This approach keeps the directories uncluttered and avoids any need to specify dependencies.
Please see the start of charm.bat for the environment variables that may be used to affect its operation.