Software Architechture comparison, comments and sugestions...

I was thnking with myself today and i remembered an old software
architecture for embedded systems division:

1. Round-robin
2. Round-robin with interrupts
3. Function-queue-scheduling
4. Real-time Operating Syste

IHMO the first one is just a subset of the second so i will just
ignore it.

I was thinking on what kind of architecture i usually use on my
projects (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI
C2000) and i concluded that i probably use something between 2 and 3.
Teh architecture that i use is basically inspired on a mechanism used
on the Fnet stack. It poll a list of tasks continuously. What i did is
to create several different handlers that can carry different tasks
and use a void pointer as an argument. So in general i got a handler
for timed tasks and a handler for async tasks. And i keep registering
and unregistering services on both handlers. I must follow some rules
to do not get a bad code, like never use an unpredictable while, or
lock my code with nops, but that works most of the cases and is very
portable. In order to improve the portability, most of the system is
described by structures, and all the hardware dependent functions are
separeted and abstractared by theses structures. So in general all the
logic is reusable and all i must change is the hardware specific code,
that is not that much.

However today using RTOS is a real trend and i could hear of good
implementations of Function-queue-scheduling (however i got no
example). Could you guys describe your experience with the software
architecture you use? Comments on the benefits/drawbacks of each one?
In special related to performance, scalability and reliability?

Thank you!

On 22/02/2012 03:26, Sink0 wrote:
> I was thnking with myself today and i remembered an old software
> architecture for embedded systems division:
> 
> 1. Round-robin
> 2. Round-robin with interrupts
> 3. Function-queue-scheduling
> 4. Real-time Operating Syste
> 
> IHMO the first one is just a subset of the second so i will just
> ignore it.
> 
> I was thinking on what kind of architecture i usually use on my
> projects (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI
> C2000) and i concluded that i probably use something between 2 and 3.
> Teh architecture that i use is basically inspired on a mechanism used
> on the Fnet stack. It poll a list of tasks continuously. What i did is
> to create several different handlers that can carry different tasks
> and use a void pointer as an argument. So in general i got a handler
> for timed tasks and a handler for async tasks. And i keep registering
> and unregistering services on both handlers. I must follow some rules
> to do not get a bad code, like never use an unpredictable while, or
> lock my code with nops, but that works most of the cases and is very
> portable. In order to improve the portability, most of the system is
> described by structures, and all the hardware dependent functions are
> separeted and abstractared by theses structures. So in general all the
> logic is reusable and all i must change is the hardware specific code,
> that is not that much.
> 
> However today using RTOS is a real trend and i could hear of good
> implementations of Function-queue-scheduling (however i got no
> example). Could you guys describe your experience with the software
> architecture you use? Comments on the benefits/drawbacks of each one?
> In special related to performance, scalability and reliability?
> 
> Thank you!


This is one of those fundamental questions that is asked so many times
in so many different places, and (one of the) conversation(s) that I
hate getting involved in [he says and then immediately gets involved].

The best solution for a software architecture is completely dependent on
the application being implemented - and even then completely open to
subjective opinion.  The best way to learn different architectures is to
read one of the many different books on the subject, try things out, get
experience (no book is a replacement for experience), learn from your peers.

As an opener, which will get shot down in flames I'm sure, there are
some reasons why an RTOS *might* be a good solution in *some* situations
here:

http://www.freertos.org/FAQWhat.html#WhyUseRTOS

...note the comments at the top of the section linked to though.

Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.

On Fri, 24 Feb 2012 11:26:04 +0000, FreeRTOS info wrote:

> On 22/02/2012 03:26, Sink0 wrote:
>> I was thnking with myself today and i remembered an old software
>> architecture for embedded systems division:
>> 
>> 1. Round-robin
>> 2. Round-robin with interrupts
>> 3. Function-queue-scheduling
>> 4. Real-time Operating Syste
>> 
>> IHMO the first one is just a subset of the second so i will just ignore
>> it.
>> 
>> I was thinking on what kind of architecture i usually use on my
>> projects (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI
>> C2000) and i concluded that i probably use something between 2 and 3.
>> Teh architecture that i use is basically inspired on a mechanism used
>> on the Fnet stack. It poll a list of tasks continuously. What i did is
>> to create several different handlers that can carry different tasks and
>> use a void pointer as an argument. So in general i got a handler for
>> timed tasks and a handler for async tasks. And i keep registering and
>> unregistering services on both handlers. I must follow some rules to do
>> not get a bad code, like never use an unpredictable while, or lock my
>> code with nops, but that works most of the cases and is very portable.
>> In order to improve the portability, most of the system is described by
>> structures, and all the hardware dependent functions are separeted and
>> abstractared by theses structures. So in general all the logic is
>> reusable and all i must change is the hardware specific code, that is
>> not that much.
>> 
>> However today using RTOS is a real trend and i could hear of good
>> implementations of Function-queue-scheduling (however i got no
>> example). Could you guys describe your experience with the software
>> architecture you use? Comments on the benefits/drawbacks of each one?
>> In special related to performance, scalability and reliability?
>> 
>> Thank you!
> 
> 
> This is one of those fundamental questions that is asked so many times
> in so many different places, and (one of the) conversation(s) that I
> hate getting involved in [he says and then immediately gets involved].
> 
> The best solution for a software architecture is completely dependent on
> the application being implemented - and even then completely open to
> subjective opinion.  The best way to learn different architectures is to
> read one of the many different books on the subject, try things out, get
> experience (no book is a replacement for experience), learn from your
> peers.
> 
> As an opener, which will get shot down in flames I'm sure, there are
> some reasons why an RTOS *might* be a good solution in *some* situations
> here:
> 
> http://www.freertos.org/FAQWhat.html#WhyUseRTOS
> 
> ...note the comments at the top of the section linked to though.

I'm going to quote the first line of your page, because I think it just 
about sums it up:

"You do not need to use an RTOS to write good embedded software. At some 
point though, as your application grows in size or complexity, the 
services of an RTOS might become beneficial..."

I've found that a simple half-RTOS (i.e., a non-preemptive 'function 
caller') works well for the size of applications that I have been writing 
here.  These are all one-man applications, so they only have a handful of 
separate 'tasks' to perform, and there's only one guy to assign 
priorities, and that guy understands that the slowest task can bog down 
the fastest (because it's non-preemptive).

I've also found that an RTOS makes a huge (beneficial) difference in 
development and maintenance effort when you've got an application big 
enough that you need more than one developer.  Once you get the task 
priorities straightened out (by cooperation, or by a strong software 
lead), and once you've smacked anyone who turns off interrupts for more 
than a few clock cycles, you can spin the less demanding tasks off to 
less skilled designers; any mistakes they make (either outright bugs or 
simple lack of optimal performance) are confined to the work that they 
do, while the better developers can pursue the really challenging work 
without having to constantly worry that "Joe Slow" is going to muck up 
the whole thing by putting 1ms of unbroken processing time into a human 
interface task.

I've also stood by watching in horror (or had to adopt software and fix 
it) as an application was written by software leads that completely 
strangled the "real-timliness" of an RTOS, by putting in seemingly-clever 
mechanisms that allowed slow tasks to block high priority tasks.

So an RTOS doesn't mean that _everyone_ on the team can be a "Joe Slow", 
and it _does_ mean that if the software lead is one then the whole effort 
is bound to fail.

But anything that's not preemptive pretty much guarantees that _everyone_ 
on the team _must not_ be a "Joe Slow", which makes it harder to assemble 
a team, and means more work for everyone during development.

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

 > > This is one of those fundamental questions that is asked so many
times
> > in so many different places, and (one of the) conversation(s) that I
> > hate getting involved in [he says and then immediately gets involved].
>
> > The best solution for a software architecture is completely dependent o=
n
> > the application being implemented - and even then completely open to
> > subjective opinion. =A0The best way to learn different architectures is=
 to
> > read one of the many different books on the subject, try things out, ge=
t
> > experience (no book is a replacement for experience), learn from your
> > peers.
>
> > As an opener, which will get shot down in flames I'm sure, there are
> > some reasons why an RTOS *might* be a good solution in *some* situation=
s
> > here:
>
> >http://www.freertos.org/FAQWhat.html#WhyUseRTOS
>
> > ...note the comments at the top of the section linked to though.
>
> I'm going to quote the first line of your page, because I think it just
> about sums it up:
>
> "You do not need to use an RTOS to write good embedded software. At some
> point though, as your application grows in size or complexity, the
> services of an RTOS might become beneficial..."
>
> I've found that a simple half-RTOS (i.e., a non-preemptive 'function
> caller') works well for the size of applications that I have been writing
> here. =A0These are all one-man applications, so they only have a handful =
of
> separate 'tasks' to perform, and there's only one guy to assign
> priorities, and that guy understands that the slowest task can bog down
> the fastest (because it's non-preemptive).
>
> I've also found that an RTOS makes a huge (beneficial) difference in
> development and maintenance effort when you've got an application big
> enough that you need more than one developer. =A0Once you get the task
> priorities straightened out (by cooperation, or by a strong software
> lead), and once you've smacked anyone who turns off interrupts for more
> than a few clock cycles, you can spin the less demanding tasks off to
> less skilled designers; any mistakes they make (either outright bugs or
> simple lack of optimal performance) are confined to the work that they
> do, while the better developers can pursue the really challenging work
> without having to constantly worry that "Joe Slow" is going to muck up
> the whole thing by putting 1ms of unbroken processing time into a human
> interface task.
>
> I've also stood by watching in horror (or had to adopt software and fix
> it) as an application was written by software leads that completely
> strangled the "real-timliness" of an RTOS, by putting in seemingly-clever
> mechanisms that allowed slow tasks to block high priority tasks.
>
> So an RTOS doesn't mean that _everyone_ on the team can be a "Joe Slow",
> and it _does_ mean that if the software lead is one then the whole effort
> is bound to fail.
>
> But anything that's not preemptive pretty much guarantees that _everyone_
> on the team _must not_ be a "Joe Slow", which makes it harder to assemble
> a team, and means more work for everyone during development.
>
> --
> My liberal friends think I'm a conservative kook.
> My conservative friends think I'm a liberal kook.
> Why am I not happy that they have found common ground?
>
> Tim Wescott, Communications, Control, Circuits & Softwarehttp://www.wesco=
ttdesign.com

Tim, thats pretty much one of the reasons i am thinking on trying
RTOS. I pretty much can handle to have a very good RT behavior when i
am programming alone. But with a team is much more complicated.

But still, i belive RTOS are good for projects with a reasonable
complexity. Others might be the best choice for small-medium
complexity.

Any way, do you guys have any good example of some projects you would
chose between Round-robin and Function-queue-scheduling?

Richard, i am going to make a try on FreeRTOS. I am a Code Sourcery.
Any good linker example for Code Sourcery with LPC17xx example I could
find others comercial GCCs but they seems to use different linker
file.

Also, i use Eclipse as my IDE. How should i build my project includes/
liked folders? I tried to link the whole Source folder but it does not
work as there are many different ASM files for different archs. Should
i just copy and paste al the files on my project?

Thank you! Any other comment about the original question is
apreciated.

In article <ji7s46$p17$1@dont-email.me>, noemail@given.com says...
> 
> On 22/02/2012 03:26, Sink0 wrote:
> > I was thnking with myself today and i remembered an old software
> > architecture for embedded systems division:
> > 
> > 1. Round-robin
> > 2. Round-robin with interrupts
> > 3. Function-queue-scheduling
> > 4. Real-time Operating Syste

The thing I see that was missed in above is other operating system 
architectures like pre-emptive, fault-tolerant, fallover, then the
categoreies such as sigle/multi-processor/multi-core. Then we could
consider Real Time versions of them.

Whether it is realtime or not depends on the application e.g. a 
temperature monitor using a loop of 3 jumped to tasks can be deemed real 
time if it ALWAYS responds within its SPECIFIED response time.

> > IHMO the first one is just a subset of the second so i will just
> > ignore it.
> > 
> > I was thinking on what kind of architecture i usually use on my
> > projects (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI
> > C2000) and i concluded that i probably use something between 2 and 3.
> > Teh architecture that i use is basically inspired on a mechanism used
> > on the Fnet stack. It poll a list of tasks continuously. What i did is
> > to create several different handlers that can carry different tasks
> > and use a void pointer as an argument. So in general i got a handler
> > for timed tasks and a handler for async tasks. And i keep registering
> > and unregistering services on both handlers. I must follow some rules
> > to do not get a bad code, like never use an unpredictable while, or
> > lock my code with nops, but that works most of the cases and is very
> > portable. In order to improve the portability, most of the system is
> > described by structures, and all the hardware dependent functions are
> > separeted and abstractared by theses structures. So in general all the
> > logic is reusable and all i must change is the hardware specific code,
> > that is not that much.

What are the applications and industry sectors, will the product be 
reused at all (e.g. set top box/router/mobile phone) and have version
upgrades.

Having written code for one off designs used for many years, one I had 
to look at software upgrade after 6 years but will never be used in 
another project for various reasons. Mainly processor core it was based 
on is not really going to be available within a few years and the 
application will have reached product life cycle end before then.

> > However today using RTOS is a real trend and i could hear of good
> > implementations of Function-queue-scheduling (however i got no
> > example). Could you guys describe your experience with the software
> > architecture you use? Comments on the benefits/drawbacks of each one?
> > In special related to performance, scalability and reliability?
> > 
> > Thank you!
> 
> 
> This is one of those fundamental questions that is asked so many times
> in so many different places, and (one of the) conversation(s) that I
> hate getting involved in [he says and then immediately gets involved].
> 
> The best solution for a software architecture is completely dependent on
> the application being implemented - and even then completely open to
> subjective opinion.  The best way to learn different architectures is to
> read one of the many different books on the subject, try things out, get
> experience (no book is a replacement for experience), learn from your peers.
> 
> As an opener, which will get shot down in flames I'm sure, there are
> some reasons why an RTOS *might* be a good solution in *some* situations
> here:

Like everything else break down what the application is doing, what are 
the repsonse times accuracy and resolution required and how many people 
will work on the project before even thinking what type of task 
scheduling is required. There is no one OS or type to suit all 
applications, some OS have requirements that realistically could be
pointless and too costly for some applications. A bit like loading
a full desktop OS including GUI onto an alarm sensor.
 
> http://www.freertos.org/FAQWhat.html#WhyUseRTOS
> 
> ...note the comments at the top of the section linked to though.
> 
> Regards,
> Richard.
> 
> + http://www.FreeRTOS.org
> Designed for Microcontrollers.
> More than 7000 downloads per month.



-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

On Tue, 21 Feb 2012 19:26:51 -0800, Sink0 wrote:

> I was thnking with myself today and i remembered an old software
> architecture for embedded systems division:
> 
> 1. Round-robin
> 2. Round-robin with interrupts
> 3. Function-queue-scheduling
> 4. Real-time Operating Syste
> 
> IHMO the first one is just a subset of the second so i will just ignore
> it.
> 
> I was thinking on what kind of architecture i usually use on my projects
> (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI C2000) and
> i concluded that i probably use something between 2 and 3. Teh
> architecture that i use is basically inspired on a mechanism used on the
> Fnet stack. It poll a list of tasks continuously. What i did is to
> create several different handlers that can carry different tasks and use
> a void pointer as an argument. So in general i got a handler for timed
> tasks and a handler for async tasks. And i keep registering and
> unregistering services on both handlers. I must follow some rules to do
> not get a bad code, like never use an unpredictable while, or lock my
> code with nops, but that works most of the cases and is very portable.
> In order to improve the portability, most of the system is described by
> structures, and all the hardware dependent functions are separeted and
> abstractared by theses structures. So in general all the logic is
> reusable and all i must change is the hardware specific code, that is
> not that much.
> 
> However today using RTOS is a real trend and i could hear of good
> implementations of Function-queue-scheduling (however i got no example).
> Could you guys describe your experience with the software architecture
> you use? Comments on the benefits/drawbacks of each one? In special
> related to performance, scalability and reliability?

Well, I haven't answered this because I'm not quite sure just what you 
mean by your first three definitions.

The other sort of solution that I'm used to are called "task loops": you 
have a loop (often in main), and you have external events (either pins or 
interrupt routines) that set flags.  The task loop loops through a bunch 
of code that basically tests a flag then does or does not execute the 
corresponding code, tests the next flag then does or does not execute the 
corresponding code, etc.

Most of the ones that I worked with were just gargantuan if-then chains, 
or case statements.  Every once and a while someone will make a more 
structured one, where all the tasks live in a structure and ISRs set the 
flags, then the main loop just queries each run flag in turn (or does so 
in order of priority, if someone's getting fancy).

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

On Fri, 24 Feb 2012 15:59:12 -0800 (PST), Sink0 <sink00@gmail.com>
wrote:

>Tim, thats pretty much one of the reasons i am thinking on trying
>RTOS. I pretty much can handle to have a very good RT behavior when i
>am programming alone. But with a team is much more complicated.
>
>But still, i belive RTOS are good for projects with a reasonable
>complexity. Others might be the best choice for small-medium
>complexity.
>
>Any way, do you guys have any good example of some projects you would
>chose between Round-robin and Function-queue-scheduling?

When building embedded systems, you usually have full control what is
running on the hardware, so I do not understand why bother e.g. with
round robin. The situation might be different, if the end user can
launch unspecified programs at their own will, in which case round
robin might make sense.

Since the 1970's, I have used quite a few simply priority based
operating systems and I have never needed any fancy scheduling
algorithms.

A few rules of thumb:

1.) Do as little as possible in a high priority task.
2.) Always ask, if the priority of a certain task can be _lowered_,
never ask if something task priority can be increased.

The RT extensions typically use their own environment for normal RT
activities and when there  is nothing valuable to do, the OS will run
the null task, which might contain eg. the windows or Linux OS and
their applications (but these are uninteresting from the RTOS point of
view).

In article <fb7hk7hmdjaimq7jp5fm5pstjcldfscbdd@4ax.com>, 
upsidedown@downunder.com says...
> 
> On Fri, 24 Feb 2012 15:59:12 -0800 (PST), Sink0 <sink00@gmail.com>
> wrote:
> 
> >Tim, thats pretty much one of the reasons i am thinking on trying
> >RTOS. I pretty much can handle to have a very good RT behavior when i
> >am programming alone. But with a team is much more complicated.
> >
> >But still, i belive RTOS are good for projects with a reasonable
> >complexity. Others might be the best choice for small-medium
> >complexity.
> >
> >Any way, do you guys have any good example of some projects you would
> >chose between Round-robin and Function-queue-scheduling?
> 
> When building embedded systems, you usually have full control what is
> running on the hardware, so I do not understand why bother e.g. with
> round robin. The situation might be different, if the end user can
> launch unspecified programs at their own will, in which case round
> robin might make sense.

Well in the most simplest of implememtations nearly all scheduling
schemes are round robin in the respect that they have a list of tasks
(or functions or routines) to perform, the list is gone through and
then scanned from the beginning again.
 
> Since the 1970's, I have used quite a few simply priority based
> operating systems and I have never needed any fancy scheduling
> algorithms.
> 
> A few rules of thumb:
> 
> 1.) Do as little as possible in a high priority task.
> 2.) Always ask, if the priority of a certain task can be _lowered_,
> never ask if something task priority can be increased.
> 
> The RT extensions typically use their own environment for normal RT
> activities and when there  is nothing valuable to do, the OS will run
> the null task, which might contain eg. the windows or Linux OS and
> their applications (but these are uninteresting from the RTOS point of
> view).

I normally break tsks down so that they operate in small portion of time 
and are called again at another time slice, if necessary each task has
it its own state machine, init, stop, start functions. Often they make
'OS' calls to reschedule their next time point.

Depends on what the application is doing as to what is appropriate.

Even with outside comms and potential time hogs it is easier if you
break down the processes as much as possible first before even looking
at scheduling.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.pcserviceselectronics.co.uk/fonts/> Timing Diagram Font
<http://www.gnuh8.org.uk/>  GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
<http://www.badweb.org.uk/> For those web sites you hate

Sink0 wrote:

> I was thnking with myself today and i remembered an old software
> architecture for embedded systems division:
> 
> 1. Round-robin
> 2. Round-robin with interrupts
> 3. Function-queue-scheduling
> 4. Real-time Operating Syste
> 
> IHMO the first one is just a subset of the second so i will just
> ignore it.

Come to think of it, there's also

0. Interrupts without round-robin.

Some of the simplest applications can be done entirely in interrupt 
handlers, and the main loop, if any, is just a pro-forma thing to make sure 
the processor stays in sleep mode.

2. could be considered separate in cases where the interrupt handlers do 
non-trivial processing, beyond setting flags for the round-robin loop to 
poll.

	Mel.

Sink0 wrote:
> I was thnking with myself today and i remembered an old software
> architecture for embedded systems division:
>
> 1. Round-robin
> 2. Round-robin with interrupts
> 3. Function-queue-scheduling
> 4. Real-time Operating Syste
>
> IHMO the first one is just a subset of the second so i will just
> ignore it.
>
> I was thinking on what kind of architecture i usually use on my
> projects (that usually range beween  a PIC16F/MSP430 to a ARM CM4/ TI
> C2000) and i concluded that i probably use something between 2 and 3.
> Teh architecture that i use is basically inspired on a mechanism used
> on the Fnet stack. It poll a list of tasks continuously. What i did is
> to create several different handlers that can carry different tasks
> and use a void pointer as an argument. So in general i got a handler
> for timed tasks and a handler for async tasks. And i keep registering
> and unregistering services on both handlers. I must follow some rules
> to do not get a bad code, like never use an unpredictable while, or
> lock my code with nops, but that works most of the cases and is very
> portable. In order to improve the portability, most of the system is
> described by structures, and all the hardware dependent functions are
> separeted and abstractared by theses structures. So in general all the
> logic is reusable and all i must change is the hardware specific code,
> that is not that much.
>
> However today using RTOS is a real trend and i could hear of good
> implementations of Function-queue-scheduling (however i got no
> example). Could you guys describe your experience with the software
> architecture you use? Comments on the benefits/drawbacks of each one?
> In special related to performance, scalability and reliability?
>
> Thank you!


There's no good general answer. Pick one and live with it. Most of
what's the right answer depends on the services your app needs.

I've seen round-robin used with an IP stack, so ....

--
Les Cargill