For more information about this bug, visit
A comment was added:
------- Comment #2 from peter [dot] soetens [..] ... 2007-04-17 17:02

(In reply to comment #1)
>
> Doesn't this result (for some applications) in more threads, and hence (unless
> you explicitly decrease the default stack size of the thread) an increased
> memory footprint?

There are two issues here:
1. What is the 'correct' thing to do when 'scheduling' activities
2. What is the smallest footprint for that method.

For point 1., it is correct to only group activities if the frequency and
priority match. Because if an activity has a freq. of, say, 1Hz, it may assume
that it has about 1 sec. to complete its task. In case this activity is grouped
with and activity of 1000Hz, running at the same priority, the latter will miss
a lot of deadlines. Thus the correct thing to do is to assign a thread for each
frequency/priority combo in use and let the RTOS scheduler do the preemption.

For point 2., given that such threads are created, what consumes the least
memory ? A lightweight RTT class for each such thread.

If you *do* want to schedule activities of different frequencies in the same
thread, use the SlaveActivity in combination with a PeriodicActivity in which
you manage the order and timing of the slaves.

For more information about this bug, visit
A comment was added:
------- Comment #1 from klaas [dot] gadeyne [..] ... 2007-04-17 16:20

(In reply to comment #0)
> The PeriodicActivity, TimerThread and TimerInterface/TimerOneShot classes were
> designed to run multiple activities (of the same priority) sequentially in the
> same thread. It also allowed to run lower frequency activities in a higher
> frequency thread. This 'concept' was abandoned before RTT 1.0 and now
> activities are only 'grouped' in a thread if they have the same frequency and
> priority. This decision made the TimerInterface redundant and it could be
> completely replaced by smaller code in the TimerThread class, which calls the
> PeriodicActivities directly, eliminating a virtual function call and freeing up
> some heap memory.

Doesn't this result (for some applications) in more threads, and hence (unless
you explicitly decrease the default stack size of the thread) an increased
memory footprint?