RE: There is NO adl_main() function when using multitasking

Legacy Open AT
1

The documentation seems pretty vague (nothing new there, then :unamused: ) about how the system decides whether your application has multiple tasks, or just the “classic” single task with the adl_main entry point. :angry:

I guess it must first look for an adl_InitTasks table:

  • if it finds one, it assumes multi-tasking;
  • If it doesn’t find one, it assumes a “classic” single task, and requires the adl_main entry point

Does that sound right?

Is there any restriction on not naming one of your entry points “adl_main” in the Adl_InitTasks table…?

eg,

const adl_InitTasks_t adl_InitTasks [] =
{
{ adl_main, 3*1024, "MAIN", 3 },    // Main task
{ SubTask1, 3*1024, "SUB1", 2 },    // Sub task 1
{ SubTask2, 3*1024, "SUB2", 1 },    // Sub task 2
{ NULL, 0, NULL, 0 }
};

IS there any difference between a “classic” single-task application (with adl_main entry point), and a “multi-tasking” application that has only one entry in the adl_InitTasks table?

2

Hiya,

That’s been my experience to date. My bet is that the OS internally defines the adl_InitTasks table with one task called adl_main(), and the references to this internal adl_InitTasks table are overwritten (wrong term. Replaced? ) by the linker at compile time if the linker finds an explicitly defined adl_InitTasks in an object file.

Probably not - but may not be advisable to do this. However, having a adl_main() function defined in your application when using multitasking doesn’t seem to cause any hassles - it’s just never called.

I’ve found that multasking/multi threading works a treat as long as you can get your head around the asynchronous nature of the application. Also works well for decomposing your app into separate ‘modules’ that can only interact via a specific interface (messages). Makes a complicated application that much easier to debug.

ciao, Dave