On 28/11/2012 18:52, 42Bastian wrote:
>
>
> Hi
>
>> In my understanding FreeRTOS doesn't meet, it should be a soft RTOS
>> because it doesn't assure to deterministically meet deadlines.
>> My question is just if there is someone using a hard RTOS with LPC2xxx
>> or LPC1xxx families of microcontrollers, what is and why choosed that
> RTOS.
>
> What you want is an RTOS with an deadline scheduler, that is one, that
> modifies the priorities of tasks according their deadline (earliest
> deadline first).
>
> Most RTOSs around use a pre-emptive priority based scheduler which can be
> used to mimic a DL-scheduler by the application.
>
> Actually, I don't know of any DL-scheduler RTOS. I know OSE had one on
top
> of its normal scheduling some years ago.
Yes - there are lots of scheduling algorithms used in academia that are
not used in the commercial world. They are two different worlds. People
on one side of that fence understand that, and people on the other
don't. I will leave it up to you to decide which is which ;o)
Complex scheduling algorithms are not normally appropriate in the
microcontroller space in any case because they take up valuable flash
space and even more valuable run time.
A priorities pre-emptive scheduler does, in my opinion (it is my
opinion, I'm not going to engage in an argument about it, I leave that
to the academics, see comments above) allow hard real time behaviour,
assuming the worst cases have been analysed and it is proven to be true.
Of course, you cannot change the laws of physics, and of course there
are occasions when it cannot be achieved without changing the scheduling
algorithm or getting a faster processor.
The same is true for a deadline scheduler. Just because it is a
deadline scheduler does not mean it will meet its deadlines if to do so
would require a warm in the time space continuum.
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.
Hard real time RTOS
Started by ●November 28, 2012
Reply by ●November 28, 20122012-11-28
Reply by ●November 28, 20122012-11-28
Besides meeting a deadline, there are certain things that need to be done
synchronously. For example, taking measurements at equally spaced
intervals, or clocking steps to a stepper motor. Jitter in either of
those processes has ill effects.
I don't know what task managers are available commercially because I've
always used my one, first written in 1978.
DaveS
> Hi
>
>> In my understanding FreeRTOS doesn't meet, it should be a soft RTOS
>> because it doesn't assure to deterministically meet deadlines.
>> My question is just if there is someone using a hard RTOS with LPC2xxx
>> or LPC1xxx families of microcontrollers, what is and why choosed that
>> RTOS.
>
> What you want is an RTOS with an deadline scheduler, that is one, that
> modifies the priorities of tasks according their deadline (earliest
> deadline first).
>
> Most RTOSs around use a pre-emptive priority based scheduler which can be
> used to mimic a DL-scheduler by the application.
>
> Actually, I don't know of any DL-scheduler RTOS. I know OSE had one on top
> of its normal scheduling some years ago.
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
synchronously. For example, taking measurements at equally spaced
intervals, or clocking steps to a stepper motor. Jitter in either of
those processes has ill effects.
I don't know what task managers are available commercially because I've
always used my one, first written in 1978.
DaveS
> Hi
>
>> In my understanding FreeRTOS doesn't meet, it should be a soft RTOS
>> because it doesn't assure to deterministically meet deadlines.
>> My question is just if there is someone using a hard RTOS with LPC2xxx
>> or LPC1xxx families of microcontrollers, what is and why choosed that
>> RTOS.
>
> What you want is an RTOS with an deadline scheduler, that is one, that
> modifies the priorities of tasks according their deadline (earliest
> deadline first).
>
> Most RTOSs around use a pre-emptive priority based scheduler which can be
> used to mimic a DL-scheduler by the application.
>
> Actually, I don't know of any DL-scheduler RTOS. I know OSE had one on top
> of its normal scheduling some years ago.
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
Reply by ●November 28, 20122012-11-28
IMHO there is no such thing as an RTOS that guarantees “hard real
time” constraints,
It’s generally up to the overall system design to determine if these can bet met, not a task solely for the RTOS since no RTOS can guarantee that you will have the resources available to meet the demands of all asynchronous events.
There are a few pre-requisites for a system to be able to meet these that are RTOS dependant, mainly the ability to prioritize tasks, to pre-empt lower priority tasks, and to be deterministic in task switching overhead.
For hard real time constraints you need to guarantee that no process can disable interrupts indefinitely, which is generally outside the control of the RTOS on many processor architectures
But to make a “hard real time” system you need to understand the peak CPU load under all conditions, including the effect of any other bus masters in the system, and the effect of the cache, bus, and memory architectures on latency.
Given that these system level constraints can be met then most available RTOS’s can be used in a “Hard Real Time” system.
Phil.
From: l... [mailto:l...] On Behalf Of d...@maildr.us
Sent: 28 November 2012 19:06
To: l...
Subject: Re: [lpc2000] Hard real time RTOS
Besides meeting a deadline, there are certain things that need to be done
synchronously. For example, taking measurements at equally spaced
intervals, or clocking steps to a stepper motor. Jitter in either of
those processes has ill effects.
I don't know what task managers are available commercially because I've
always used my one, first written in 1978.
DaveS
> Hi
>
>> In my understanding FreeRTOS doesn't meet, it should be a soft RTOS
>> because it doesn't assure to deterministically meet deadlines.
>> My question is just if there is someone using a hard RTOS with LPC2xxx
>> or LPC1xxx families of microcontrollers, what is and why choosed that
>> RTOS.
>
> What you want is an RTOS with an deadline scheduler, that is one, that
> modifies the priorities of tasks according their deadline (earliest
> deadline first).
>
> Most RTOSs around use a pre-emptive priority based scheduler which can be
> used to mimic a DL-scheduler by the application.
>
> Actually, I don't know of any DL-scheduler RTOS. I know OSE had one on top
> of its normal scheduling some years ago.
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
It’s generally up to the overall system design to determine if these can bet met, not a task solely for the RTOS since no RTOS can guarantee that you will have the resources available to meet the demands of all asynchronous events.
There are a few pre-requisites for a system to be able to meet these that are RTOS dependant, mainly the ability to prioritize tasks, to pre-empt lower priority tasks, and to be deterministic in task switching overhead.
For hard real time constraints you need to guarantee that no process can disable interrupts indefinitely, which is generally outside the control of the RTOS on many processor architectures
But to make a “hard real time” system you need to understand the peak CPU load under all conditions, including the effect of any other bus masters in the system, and the effect of the cache, bus, and memory architectures on latency.
Given that these system level constraints can be met then most available RTOS’s can be used in a “Hard Real Time” system.
Phil.
From: l... [mailto:l...] On Behalf Of d...@maildr.us
Sent: 28 November 2012 19:06
To: l...
Subject: Re: [lpc2000] Hard real time RTOS
Besides meeting a deadline, there are certain things that need to be done
synchronously. For example, taking measurements at equally spaced
intervals, or clocking steps to a stepper motor. Jitter in either of
those processes has ill effects.
I don't know what task managers are available commercially because I've
always used my one, first written in 1978.
DaveS
> Hi
>
>> In my understanding FreeRTOS doesn't meet, it should be a soft RTOS
>> because it doesn't assure to deterministically meet deadlines.
>> My question is just if there is someone using a hard RTOS with LPC2xxx
>> or LPC1xxx families of microcontrollers, what is and why choosed that
>> RTOS.
>
> What you want is an RTOS with an deadline scheduler, that is one, that
> modifies the priorities of tasks according their deadline (earliest
> deadline first).
>
> Most RTOSs around use a pre-emptive priority based scheduler which can be
> used to mimic a DL-scheduler by the application.
>
> Actually, I don't know of any DL-scheduler RTOS. I know OSE had one on top
> of its normal scheduling some years ago.
>
> --
> 42Bastian
> +
> | http://www.sciopta.com
> | Fastest direct message passing kernel.
> | IEC61508 certified.
> +
>
Reply by ●November 28, 20122012-11-28
On 28 Nov 2012, at 22:15, "Phil Young" wrote:
> IMHO there is no such thing as an RTOS that guarantees hard real time constraints,
From the Green Hills Marketing Manual for velOSity:
"...but the absolute worst case response time is extremely fast, statically known and guaranteed." They don't disable interrupts during an OS call, which is cute.
I always found GHS software to be expensive and clunky, but their claims are grounded in fact.
I used SPOX on a multiprocessor DSP project (a MAW). I think that was, perhaps, the most over-rated "operating system" that I ever did see.
What's a hard real time system? One that, if it fails, is a catastrophic failure. Most "real time" systems deal with processing data in real time but are soft or firm because it doesn't really matter if things clog up or need a reboot, it's just a fact of life that we have grown accustomed to with PCs. Having dealt with broadcast systems before, that had real time constraints, but if we didn't fill a scan line, it wasn't the end of the world, we knew we'd have another fresh set of scan lines to fill in the next frame.
I can't remember where I read it now, but there was a really great passage about what a "hard real time" system meant in a data acquisition situation. The passage ended with a guy explaining what hard real time meant to him when he needed to acquire and transmit the data from nuclear detonations with a real hard limit: his device was going to die, and they needed the data acquired and transmitted before it did. If anybody else can remember where this recollection comes from (doubt it), please pipe up because I have a huge library of tech reference books and I can't remember where I read it.
-- Paul.
> IMHO there is no such thing as an RTOS that guarantees hard real time constraints,
From the Green Hills Marketing Manual for velOSity:
"...but the absolute worst case response time is extremely fast, statically known and guaranteed." They don't disable interrupts during an OS call, which is cute.
I always found GHS software to be expensive and clunky, but their claims are grounded in fact.
I used SPOX on a multiprocessor DSP project (a MAW). I think that was, perhaps, the most over-rated "operating system" that I ever did see.
What's a hard real time system? One that, if it fails, is a catastrophic failure. Most "real time" systems deal with processing data in real time but are soft or firm because it doesn't really matter if things clog up or need a reboot, it's just a fact of life that we have grown accustomed to with PCs. Having dealt with broadcast systems before, that had real time constraints, but if we didn't fill a scan line, it wasn't the end of the world, we knew we'd have another fresh set of scan lines to fill in the next frame.
I can't remember where I read it now, but there was a really great passage about what a "hard real time" system meant in a data acquisition situation. The passage ended with a guy explaining what hard real time meant to him when he needed to acquire and transmit the data from nuclear detonations with a real hard limit: his device was going to die, and they needed the data acquired and transmitted before it did. If anybody else can remember where this recollection comes from (doubt it), please pipe up because I have a huge library of tech reference books and I can't remember where I read it.
-- Paul.
Reply by ●November 29, 20122012-11-29
Hi
>> Means, you have to specify your environment first. Than you can check if a
>> certain RTOS can handle it.
>>
> As I said it isn't a speed problem, it is an deterministically assurance
> problem.
I checked Wikipedia. According the article on Rate Monotonic Scheduling
(that's what we are talking about), the "assurance" can only be given up
to an overall load of around 70%.
So it is very much important what jobs are running in the system and what
relation is between the constraints and the CPU.
So if the RTOS needs n cycles to change from task to task, it will always
need n cycles no matter if you run on 1MHz or 1GHz (with maybe a little
jitter due to cache, bus effects).
And as Phil stated, it is the whole system to look at!
So again, first check your needs, then choose a CPU and then an RTOS
(pre-emptive) that suits _you_ best.
Cheers
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
>> Means, you have to specify your environment first. Than you can check if a
>> certain RTOS can handle it.
>>
> As I said it isn't a speed problem, it is an deterministically assurance
> problem.
I checked Wikipedia. According the article on Rate Monotonic Scheduling
(that's what we are talking about), the "assurance" can only be given up
to an overall load of around 70%.
So it is very much important what jobs are running in the system and what
relation is between the constraints and the CPU.
So if the RTOS needs n cycles to change from task to task, it will always
need n cycles no matter if you run on 1MHz or 1GHz (with maybe a little
jitter due to cache, bus effects).
And as Phil stated, it is the whole system to look at!
So again, first check your needs, then choose a CPU and then an RTOS
(pre-emptive) that suits _you_ best.
Cheers
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●November 29, 20122012-11-29
>> From the Green Hills Marketing Manual for
velOSity:
>
> "...but the absolute worst case response time is extremely fast,
> statically known and guaranteed." They don't disable interrupts during
> an OS call, which is cute.
But only works, if interrupts are not interfering with the remaining system.
Anyway, there are other RTOS around that claim the same.
When I worked for another RTOS company they claimed for their MC68000 port
the very same. In the end I learned, that they just keep interrupt locking
shorter than the longest instruction (movem.l d0-d7/a0-a6,-(sp)).
> I can't remember where I read it now, but there was a really great
> passage about what a "hard real time" system meant in a data
> acquisition situation. The passage ended with a guy explaining what
> hard real time meant to him when he needed to acquire and transmit the
> data from nuclear detonations with a real hard limit: his device was
> going to die, and they needed the data acquired and transmitted before
> it did.
Now that's what I call a deadline (from the original meaning of the word) :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
>
> "...but the absolute worst case response time is extremely fast,
> statically known and guaranteed." They don't disable interrupts during
> an OS call, which is cute.
But only works, if interrupts are not interfering with the remaining system.
Anyway, there are other RTOS around that claim the same.
When I worked for another RTOS company they claimed for their MC68000 port
the very same. In the end I learned, that they just keep interrupt locking
shorter than the longest instruction (movem.l d0-d7/a0-a6,-(sp)).
> I can't remember where I read it now, but there was a really great
> passage about what a "hard real time" system meant in a data
> acquisition situation. The passage ended with a guy explaining what
> hard real time meant to him when he needed to acquire and transmit the
> data from nuclear detonations with a real hard limit: his device was
> going to die, and they needed the data acquired and transmitted before
> it did.
Now that's what I call a deadline (from the original meaning of the word) :-)
--
42Bastian
+
| http://www.sciopta.com
| Fastest direct message passing kernel.
| IEC61508 certified.
+
Reply by ●November 29, 20122012-11-29
Hi,
> When I worked for another RTOS company they claimed for their MC68000 port
> the very same. In the end I learned, that they just keep interrupt locking
> shorter than the longest instruction (movem.l d0-d7/a0-a6,-(sp)).
After working with the 68k in a multi-processor environment, it was a real
shock to look at the primitive interrupt controllers kludged onto the side
of 8086, the original ARM, and many other micros over the years. The whole
m68k line was just well designed. The 68020 was fantastic, and only now
with the Cortex-M3 and NVIC are ARM catching up to a processor that had such
stuff in the core some 20+ years ago. Auto-vectored interrupts, interrupt
priorities, peripherals providing vectors over the bus, bus locking using
TAS, CAS, and CAS2 over VMEbus, and the 020's master, interrupt, user, and
supervisor stack pointers...
On one broadcast system we had a dual VMEbus setup, using 8 FORCE cards for
intelligent serial I/O and packetization of 48 feeds, two terrestrial
broadcast network insertion drivers, and a 68020 card for user interface.
It worked amazingly well. I wrote the low-level code that the ISIO cards
ran and the broadcast network inserter code running on a CPU20/CPU30;
somebody else wrote all the user interface and control code. The dual
VMEbus system provided a hot spare for switchover when the watchdog decided
that the data it requested to be inserted into the network didn't actually
get inserted. The wonders of small teams... :-)
Sorry--off topic.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
> When I worked for another RTOS company they claimed for their MC68000 port
> the very same. In the end I learned, that they just keep interrupt locking
> shorter than the longest instruction (movem.l d0-d7/a0-a6,-(sp)).
After working with the 68k in a multi-processor environment, it was a real
shock to look at the primitive interrupt controllers kludged onto the side
of 8086, the original ARM, and many other micros over the years. The whole
m68k line was just well designed. The 68020 was fantastic, and only now
with the Cortex-M3 and NVIC are ARM catching up to a processor that had such
stuff in the core some 20+ years ago. Auto-vectored interrupts, interrupt
priorities, peripherals providing vectors over the bus, bus locking using
TAS, CAS, and CAS2 over VMEbus, and the 020's master, interrupt, user, and
supervisor stack pointers...
On one broadcast system we had a dual VMEbus setup, using 8 FORCE cards for
intelligent serial I/O and packetization of 48 feeds, two terrestrial
broadcast network insertion drivers, and a 68020 card for user interface.
It worked amazingly well. I wrote the low-level code that the ISIO cards
ran and the broadcast network inserter code running on a CPU20/CPU30;
somebody else wrote all the user interface and control code. The dual
VMEbus system provided a hot spare for switchover when the watchdog decided
that the data it requested to be inserted into the network didn't actually
get inserted. The wonders of small teams... :-)
Sorry--off topic.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com
Reply by ●November 29, 20122012-11-29
Il 28/11/2012 23:47, Paul Curtis ha scritto:
The point is that the customer ask to have a hard RTOS and a Cortex-M or
Cortex-R class microcontroller.
I personally used hard RTOS in the past but there is no port for
Cortex-M or Cortex-R families of microcontrollers so I asked here if is
there anyone using a hard RTOS wiht LPC2xxx and LPC1xxx families.
The alternative should be to modify a soft RTOS introducing a deadline
scheduler and modifying interrupt management that is not exactly a
trivial job.
> On 28 Nov 2012, at 22:15, "Phil Young" wrote:
>
>> IMHO there is no such thing as an RTOS that guarantees hard real time constraints,
> >From the Green Hills Marketing Manual for velOSity:
>
> "...but the absolute worst case response time is extremely fast, statically known and guaranteed." They don't disable interrupts during an OS call, which is cute.
>
> I always found GHS software to be expensive and clunky, but their claims are grounded in fact.
>
> I used SPOX on a multiprocessor DSP project (a MAW). I think that was, perhaps, the most over-rated "operating system" that I ever did see.
>
> What's a hard real time system? One that, if it fails, is a catastrophic failure. Most "real time" systems deal with processing data in real time but are soft or firm because it doesn't really matter if things clog up or need a reboot, it's just a fact of life that we have grown accustomed to with PCs. Having dealt with broadcast systems before, that had real time constraints, but if we didn't fill a scan line, it wasn't the end of the world, we knew we'd have another fresh set of scan lines to fill in the next frame.
>
> I can't remember where I read it now, but there was a really great passage about what a "hard real time" system meant in a data acquisition situation. The passage ended with a guy explaining what hard real time meant to him when he needed to acquire and transmit the data from nuclear detonations with a real hard limit: his device was going to die, and they needed the data acquired and transmitted before it did. If anybody else can remember where this recollection comes from (doubt it), please pipe up because I have a huge library of tech reference books and I can't remember where I read it.
>
> -- Paul.
>
>
The point is that the customer ask to have a hard RTOS and a Cortex-M or
Cortex-R class microcontroller.
I personally used hard RTOS in the past but there is no port for
Cortex-M or Cortex-R families of microcontrollers so I asked here if is
there anyone using a hard RTOS wiht LPC2xxx and LPC1xxx families.
The alternative should be to modify a soft RTOS introducing a deadline
scheduler and modifying interrupt management that is not exactly a
trivial job.
> On 28 Nov 2012, at 22:15, "Phil Young" wrote:
>
>> IMHO there is no such thing as an RTOS that guarantees hard real time constraints,
> >From the Green Hills Marketing Manual for velOSity:
>
> "...but the absolute worst case response time is extremely fast, statically known and guaranteed." They don't disable interrupts during an OS call, which is cute.
>
> I always found GHS software to be expensive and clunky, but their claims are grounded in fact.
>
> I used SPOX on a multiprocessor DSP project (a MAW). I think that was, perhaps, the most over-rated "operating system" that I ever did see.
>
> What's a hard real time system? One that, if it fails, is a catastrophic failure. Most "real time" systems deal with processing data in real time but are soft or firm because it doesn't really matter if things clog up or need a reboot, it's just a fact of life that we have grown accustomed to with PCs. Having dealt with broadcast systems before, that had real time constraints, but if we didn't fill a scan line, it wasn't the end of the world, we knew we'd have another fresh set of scan lines to fill in the next frame.
>
> I can't remember where I read it now, but there was a really great passage about what a "hard real time" system meant in a data acquisition situation. The passage ended with a guy explaining what hard real time meant to him when he needed to acquire and transmit the data from nuclear detonations with a real hard limit: his device was going to die, and they needed the data acquired and transmitted before it did. If anybody else can remember where this recollection comes from (doubt it), please pipe up because I have a huge library of tech reference books and I can't remember where I read it.
>
> -- Paul.
>
>
Reply by ●November 29, 20122012-11-29
>> A hard real time OS is an OS that guarantees to meet
a deadline deterministically.
>> A soft real time OS (usually called RTOS) usually or generally meet a deadline.
I would echo the comments of all the other experienced programmers here.
These kinds of definitions are "idealistic" and you are trying to "over simplify"
and paint a complex subject as a "Black&White" picture,
when in reality it is all "Shades of Gray". Far more complex than you describe.
I have used FreeRTOS for many projects now with LPC MCUs.
It's a high quality RTOS, it does what an RTOS should do.
I can write good code for it, and get everything done "deterministically" the way I want.
I can also write crappy bad code that does not handle timing and has problems.
So what do either of those results have to do with the RTOS? Nothing. It is your code.
Any RTOS is nothing more than a tool kit: Threads, Mutexes, INTs, etc.
What you do with those tools and how you use them is up to you.
The RTOS cannot make those choices for you. Every project has different needs.
When you talk about high reliability systems, well you can have multiple MCUs running
in parallel with independent RTOS's, and have a voting election between them for all decisions.
Nice idea, but even those systems fail. Just ask NASA.
Chris.
>> A soft real time OS (usually called RTOS) usually or generally meet a deadline.
I would echo the comments of all the other experienced programmers here.
These kinds of definitions are "idealistic" and you are trying to "over simplify"
and paint a complex subject as a "Black&White" picture,
when in reality it is all "Shades of Gray". Far more complex than you describe.
I have used FreeRTOS for many projects now with LPC MCUs.
It's a high quality RTOS, it does what an RTOS should do.
I can write good code for it, and get everything done "deterministically" the way I want.
I can also write crappy bad code that does not handle timing and has problems.
So what do either of those results have to do with the RTOS? Nothing. It is your code.
Any RTOS is nothing more than a tool kit: Threads, Mutexes, INTs, etc.
What you do with those tools and how you use them is up to you.
The RTOS cannot make those choices for you. Every project has different needs.
When you talk about high reliability systems, well you can have multiple MCUs running
in parallel with independent RTOS's, and have a voting election between them for all decisions.
Nice idea, but even those systems fail. Just ask NASA.
Chris.
Reply by ●November 29, 20122012-11-29
> When you talk about high reliability systems, well
you can have multiple
> MCUs running
> in parallel with independent RTOS's, and have a voting election between
> them for all decisions.
> Nice idea, but even those systems fail. Just ask NASA.
The high reliability paradox. Aspiring to increase time between
failures with the addition of dis-similar components means you have more
code from more sources, and therefore unquestionably also means you have
more bugs in your system. Mitigate this risk through complex voting
systems means you have a lot more code and data paths and....you have
more bugs in your system (but hopefully you can recover from them
gracefully).
Now I am getting of topic.
With regards to the original question. As I said in my first reply, a
literal answer to the question is a simple "yes". I have also implied
that the original poster (OP) was making life hard for him/her self by
writing obtuse questions with no hint as to what information they
actually wanted. The OP has since made it clear that their opinion on
what qualifies as hard real time is somewhat adjacent to the industry
accepted definition (leave it!) but has not yet provided an example of
an available product that *does* meet their requirements. If the
product exists, the question could become easy to answer, such as "has
somebody ported a system with XYZ style scheduling algorithm such as
product ABC to the LPCnnn microcontroller".
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.
> MCUs running
> in parallel with independent RTOS's, and have a voting election between
> them for all decisions.
> Nice idea, but even those systems fail. Just ask NASA.
The high reliability paradox. Aspiring to increase time between
failures with the addition of dis-similar components means you have more
code from more sources, and therefore unquestionably also means you have
more bugs in your system. Mitigate this risk through complex voting
systems means you have a lot more code and data paths and....you have
more bugs in your system (but hopefully you can recover from them
gracefully).
Now I am getting of topic.
With regards to the original question. As I said in my first reply, a
literal answer to the question is a simple "yes". I have also implied
that the original poster (OP) was making life hard for him/her self by
writing obtuse questions with no hint as to what information they
actually wanted. The OP has since made it clear that their opinion on
what qualifies as hard real time is somewhat adjacent to the industry
accepted definition (leave it!) but has not yet provided an example of
an available product that *does* meet their requirements. If the
product exists, the question could become easy to answer, such as "has
somebody ported a system with XYZ style scheduling algorithm such as
product ABC to the LPCnnn microcontroller".
Regards,
Richard.
+ http://www.FreeRTOS.org
Designed for microcontrollers. More than 7000 downloads per month.
+ http://www.FreeRTOS.org/trace
15 interconnected trace views. An indispensable productivity tool.
