Hi Marc
If you want to go back to absolute basics I suggest the following:
1. Make a new project directory as described in
http://www.utasker.com/docs/uTasker/uTaskerV1.3_user_guide.PDFThis means that you can change anything you want but still have the demo project for reference if you need it.
2. In TaskConfig.h strip down the task table and node list to just TASK_WATCHDOG and fnTaskWatchdog()
3. In config.h stript everything down to just your processor configuration
4. Remove all C files from your new project directory - they are not needed for the minimum project.
I think that you will get 2 linking errors like this due to two routines which are needed so add a temporary C file with dummy functions for extern void fnUserHWInit(void); and extern QUEUE_TRANSFER fnNetworkTx(unsigned char *output_buffer, QUEUE_TRANSFER nr_of_bytes);
If you compile this you do not have any application code and the only thing that operates is the watchdog (blinking an LED as long as you set the macro INIT_WATCHDOG_LED() in app_hw_xxxx.h to configure the port to drive it). The code will probably be quite smalle (a couple of kbytes) since it will not link anything from the TCP/IP stack, uFileSystem etc. but it will configure the board and run the uTasker scheduler so all resources can be used if required.
Then you can decide what your project needs and add this as follows.
1. Add a new application task (it doesn't have to be called this but it is best to have one which you know is responsible for configuring the system).
2. Decide which drivers you need (Ethernet, UART etc.) and which protocols (HTTP, FTP etc.): add these options to config.h (you can copy parts of the original config.h file) and ensure that the task you add starts any services which need to be started (eg. ftp or http), opens interfaces it wants to use (eg. UART or I2C).
3. Add your new application code (either as a part of the application task or as other tasks - helps keep things modular).
This procedure allows you to start with absolute minimum and then build up bit by bit so that you known exactly which code is being added and which options are being configured. This is probably better than trying to strip down the demo project since it does contain some things which have dependencies so you may find it failing when removing something which may looks unrelated at the first glance.
You may find a couple of things which don't link or run on at the first attempts but these should be quite obvious (I haven't actually tried this myself)
Good luck
Regards
Mark
