Reply by misterhershel●November 30, 20122012-11-30
--- In l..., dave@... wrote: >
> 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.
> > +
> At some point, if you're going to do a lot of time sensitive stuff,
it's good to look at the hardware assets that are available.
We have discovered the immense power of the DMA and timer subsystems on these
chips, and the advantages of being able to time stuff to a single processor
clock.
Once you get the small number of time critical challenges taken care of, you can
just get a RTOS running, and forget about all that hard stuff.
>
> So, now I thin it is clear what I am searching for. So what you are implying is that software can meet the REAL TIME"
requirement.
This is far from clear.
don
Reply by Donald H●November 29, 20122012-11-29
--- In l..., "M. Manca" wrote:
> I personally used hard RTOS in the past but there is
no port for
Please share the specifics about this system.
Which RTOS, what processor, what speed, amount of memory, etc, etc.
The classes I took sooo many years ago, stated that "Hard Real Time" was not
possible.
It's a marketing term.
"Best Real Time" with what you have, is more like it.
Hard Real Time maybe just fine with a PIC16 in one application.
But a 3GHZ XXYYZZ processor will not cut it in another application.
Its the design of the system that gives you " Hard Real Time" response.
Not a single piece of software (RTOS) or single piece of silicon (CPU) can give
you that.
don
Reply by Gregory Nutt●November 29, 20122012-11-29
> > is there anyone using or that used in the past a
hard real time OS with
> > LPC series of microcontrollers?
> > Regards,
>
> If I were to answer your question as literally as you have stated it I
> would just say "yes", and leave it at that. >
> I assume however you are asking for an as yet unstated reason, so to
try > and guess your next questions [I spend a lot of time
on technical
> support guessing things] I suggest looking at the following link for
> several FreeRTOS on LPC projects:
>
> http://www.lpcware.com/
There are many other RTOSs available for the LPC family that do not appear in
that list. For example, ChibiOS supports many LPC parts but does not appear in
the list: http://www.chibios.org/dokuwiki/doku.php?id=chibios:architectures. My
RTOS, NuttX, also supports several members of the LPC family:
http://www.nuttx.org and is not in the list.
Greg
Reply by "M. Manca"●November 29, 20122012-11-29
Il 29/11/2012 13:07, Chris ha scritto: >
>
> >> 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.
> I suppose to be experienced at least as much engineers answered until
now.
And I think to be a little bit more expert then engineers not knowing
the difference between a soft RTOS and a hard RTOS.
And much more expert then engineers not knowing that hard RTOS exists,
are used and that their use is mandatory in some application areas in
fields of military, space and transport systems.
So, don't tell me what I don't need to hear, I normally design
applications using or not soft RTOS, some times I need hard RTOS and I
use them.
This time the problem is to know if is there anyone that used before a
hard RTOS with LPC ARM and Cortex microcontrollers because those I
quickly tested until now are not so good (too complex then necessary or
without required tools and so on) or too much expensive for my customer.
Hard RTOS aren't only "theoretically" possible, they exists and are
normally used and they work pretty well. Writing sw using a hard RTOS is
also different then writing sw for s soft RTOS because you have to know
and define constraints and calculate (using some tools) if the
application is schedulable within its constraints.
So, many thanks to everyone but there is no space to change the
requirement about using a hard RTOS because not only is mandatory but
have to be certified that is really a hard RTOS. > 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 FreeRTOS Info●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.
>> 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.
Reply by "M. Manca"●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.
>
>
Reply by Paul Curtis●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... :-)
>> 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)
:-)
