How many Maximum task are supported for UCOS?

[savaliya_ambani]

Dear SIr,

I am working on MOD5282 with the ucos RTOS. And i am facing difficulty in my development. THe problem is that ,I have total 18 Tasks, and hence the priority list also goes to the Main_Prio+18.

Now when i load the code with only kepping 5 Tasks ,but lowest Priority of one of the task is Main_Prio+14. SO when code get started executing,it only runs in the while(1) loop defined inside User Main,which we can is a Idle Task. Only Interupt request gets served. Nothing else.

So,does any body know why does this happening? and what can be the solution,if i want to run 18 Task which are the must. Thanking you.

[Chris Ruff]

There are around 31 tasks on uCOS and Netburner uses 5 or so of them. Your problem is that at least one of your tasks is not releasing or allowing other tasks to run.

Tasks must either use blocking constructs (such as select(), semaphore, mailbox, etc. ) or you must place OSTimeDly() in each task to relinquish that task's context and allow other tasks to run if you have a loop that does not block.

in uCOS the highest priority task will own the processor unless it lets go...

Chris

[Ridgeglider]

The default number of tasks is 20, but can be changed. I've bumped this to 30 successfully. However, if you do this you may want to avoid the OSSimpleTaskCreate and instead use OSTaskCreate so you can explicitly specify the stacks for each task as needed rather that just allocating the default size that may be larger than req'd.

Next, with regard to task priorities, the default NB task prios don't leave too much room for user-related tasks below UserMain and above the essential resources of ftp, http, tcp, etc. However there is a big empty block from prio number 0 to 35...

Therefore, with due caution, when I have lots of tasks I have occasionally moved most of the default NB task prios below UserMain down into this empty region (to lower prio numbers) by subtracting a constant offset to the system tasks listed in constants.h. This allows these system tasks to retain their priorities relative to each other but provides a much larger open block of room for additional user tasks with less priority (higher num) above these system essentials. That way, the user tasks created in the resulting block (prio num 19 to 49) can depend on well-functioning, more important system tasks operating below them. It also lets UserMain have the least importance.

Finally, be careful to note that FTP prio default is 48 so it needs to get moved too, although I can't remember exactly where it's definition is located... I don't think there are others...?

For example:

Code: Select all

#define OS_MAX_TASKS        30 /* MODIFIED -- was 20 Max number of system tasks */

/* System task priorities */
/* IDLE task is set at lowest priority, 63 */
#define MAIN_PRIO           (50)  /* used for UserMain , kept the same, see below.*/

// Modify (increase) the following NB system task priorities by subtracting a
// standard offset of 30. That way these tasks retain their priorites in
// relation to each other, but become higher than the USER application prios.
// The system MUST be rebuilt after this change.

#define NB_TASK_OFFSET      (30)
#define HTTP_PRIO           (45 - NB_TASK_OFFSET)
#define PPP_PRIO            (44 - NB_TASK_OFFSET)
#define TCP_PRIO            (40 - NB_TASK_OFFSET)
#define IP_PRIO             (39 - NB_TASK_OFFSET)
#define ETHER_SEND_PRIO     (38 - NB_TASK_OFFSET)
#define WIFI_TASK_PRIO      (37 - NB_TASK_OFFSET)
#define ENC_TASK_PRIORITY   (36 - NB_TASK_OFFSET)

////Standard, original:
//#define HTTP_PRIO         (45)
//#define PPP_PRIO          (44)
//#define TCP_PRIO          (40)
//#define IP_PRIO           (39)
//#define ETHER_SEND_PRIO   (38)
//#define WIFI_TASK_PRIO    (37)
//#define ENC_TASK_PRIORITY (36)

[rnixon]

Hi,

There are a total of 64 possible tasks, each with its own priority. 0-3 are reserved, and NetBurner uses some per the earlier posts. For example, 64, the lowest priority is the idle task. Each task needs its own task space allocated at compile time, so that is why I think the default is set at 20 in the constants file.

[thomastaranowski]

Another gotcha is that other components have independent limitations. For example, EFFS can only serve a max of 10 separate tasks.

[rhopf1]

Simple (short) tasked operations should be able to be combined in a single task. This will also reduce the task switching overhead. I've found updating SPI or I2C devices using background drivers creates overhead in 1msec range certainly room for other updates. Parallel I/O would be even faster.

[savaliya_ambani]

Dear Sir,

Thank you veru much your quick and relevant answers.
now one more thing is that , i have only 5 tasks. but deliberately i have set the priority of one task to Main_Prio+13. So,now when i run this code,it is not getting into any task ,only while 1 inside UserMain is running. i have set OSTimeDly(40), to get reliniqueshed. but still it is not working.

Now, can i change the constants.h file and change the max. task to 30 and set any one task to the priority of Main_Prio+25?

thank you.

[Ridgeglider]

I am not altogether sure what you are proposing. That said, and despite the fact that I once mentioned it was possible, I would dissuade you from modifying constants.h in most cases. Your post suggest a possible misconception. The constant OS_MAX_TASKS defines the maimum number of tasks that can be defined and running at one time, not the maximum priority number. The maximum priority is set to 63 and usually (always?) assigned to the IDLE task since by definition it is the least important. Including prio=0, this gives a total of 64 task slots, of which you can define (equivalent in our case to run) OS_MAX_TASKS of them. Stay away from changing OS_MAX_TASKS to 30 and trying to run a task assigned to Main_Prio + 25. The reason a maximum of ~20 tasks makes sense is that you start running out of RAM and FAST_RAM to run many more, particularly unless you allocate and definie their stacks quite carefully.

I suspect that what is happening in your case is that UserMain is running at the default prio of 50 along with (the necessary) idle task at prio=63. Now you try to define your 2nd task at Main+13, which happens to try and clobber IDLE (50+13=63 !!). When you create tasks, you can (and should) check the return argument to see if creation was successful. The OS will not let you create a task in a previously-used prio slot. Since IDLE already occcupies that prio, task creation almost certainly fails and your new task never runs. My guess.

[greengene]

"uCOS in non-preemptive and the highest priority task will own the processor unless it lets go..." - chris ruff

hmmm, a little crossed there.
uCOS is pre-emptive, i.e., a higher prioroty task that is ready to run will pre-empt a lower prioroty task that is already running. but yes, the highest priority task that is ready to run will continue to run until it lets go
or a higher-still task becomes ready.