readme

用于TM1300/PNX1300系列DSP（主要用于视频处理）的动态下载程序源码。

This is an example of how systems can be partially upgraded in-the-field,
i.e. on some remote site at which no TCS development kit is available for
building a new application. 

It is based on dynamic loading, and the fact that dynamic libraries are
interchangeable as long as the list of exported functions and variables
are 'consistent' (this concept is not explained further here).

A dynamic loader- based system consists of functional parts represented by
dynamic libraries that get loaded during system startup. Each of these functional
parts can be simply replaced with a newer version that is consistent with it; 
upon subsequent start of the system, the newer version will be used. This is so 
embarassingly trivial that this is not demonstrated here; instead, it is 
demonstrated how a functional component in the form of a dynamic library can be 
replaced *in a running system*.

Before that: the real problem of in field upgrading is making sure that
the upgraded system remains consistent, i.e. that all functional components
`fit together`. This seems mainly a version control problem:
inconsistency is hard to detect, and once it occurs then it might easily
represent itself in system crashes. This example goes into the technical
details of upgrading; it disregards versioning problems.

The example consists of the following files:

  - lib.c	a preliminary library exporting a not-yet-fully 
                implemented function
  - lib_new.c	the same library, now completed
  - main.c	the `system`, first using the preliminary library, then 
                upgrading it, and finally using the upgraded version.
                Note the transparent update of the version string.
  - Makefile	builds all dlls and the main program, and runs the system

Upgrading a dll in a running system merely involves replacing the 'current' version
on the storage medium where the dlls are stored (e.g. flash) with a newer one,
unloading the library from the application's SDRAM, followed by loading the now
replaced, upgraded dll. This is all taken care of in main.c.

One technical detail: the application must make sure that there are no users of
the library during the switch (i.e. the library's functions are not currently 
invoked, and there are no pointers to the library's data- or code sections).


---------------------------- OUTPUT OF THE EXAMPLE -----------------------------

[77] make
/t/qasoft/build/tcs1.1z/1037/SunOS/bin/tmcc lib.c -btype dll -bexport _version,_square -o lib.dll
/t/qasoft/build/tcs1.1z/1037/SunOS/bin/tmcc main.c -bdeferred lib.dll -btype dynboot -o a.out
tmld warning :   Reference to variable _version in segment lib.dll with deferred loading
tmld warning :   Reference to variable _version in segment lib.dll with deferred loading
/t/qasoft/build/tcs1.1z/1037/SunOS/bin/tmcc lib_new.c -btype dll -bexport _version,_square -o lib_new.dll
/t/qasoft/build/tcs1.1z/1037/SunOS/bin/tmsim a.out
Dynamic loader: status= 0 after loading lib.dll; 
 function square has not yet been implemented
 square(0)= -1
 function square has not yet been implemented
 square(1)= -1
 function square has not yet been implemented
 square(2)= -1
 function square has not yet been implemented
 square(3)= -1
 function square has not yet been implemented
 square(4)= -1
 function square has not yet been implemented
 square(5)= -1
 function square has not yet been implemented
 square(6)= -1
 function square has not yet been implemented
 square(7)= -1
 function square has not yet been implemented
 square(8)= -1
 function square has not yet been implemented
 square(9)= -1
Library version: 'Preliminary version'

Dynamic loader: unloading lib.dll; 
Dynamic loader: status= 0 after loading lib.dll; 
 square(0)= 0
 square(1)= 1
 square(2)= 4
 square(3)= 9
 square(4)= 16
 square(5)= 25
 square(6)= 36
 square(7)= 49
 square(8)= 64
 square(9)= 81
Library version: 'Upgraded version'