Is it Real?

Go To Last Post
22 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys, I've designed a scheduler for embedded systems aimed squarely at mid-range 32bit systems.  Interrupts and Exceptions are never disabling by the OS and API calls can be made from within Interrupts, however they may be differed until no interrupts or exceptions are pending.  

 

It uses a composite scheduler, using priority, round robin, first-come-first-serve, co-operative. 

 

Does this meet the requirements to be a RTOS?  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Being co-operative, it is difficult to guarantee response time, thus probably not 'real time'. I think you'll find most real 'real time' os's are pre-emptive.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman, it is pre-emptive, the highest priority always runs.  

 

I found this:

All "real-time" means is that interrupt latency (time during which interrupts are disabled) is guaranteed to be less than some specified number of microseconds. In other words, the kernel guarantees that it can respond to incoming external events up to some maximum frequency (1/maxlatency). It takes a lot of careful programming and testing of all interrupt-handling paths to make this guarantee. The actual details of how this is accomplished will depend on the kernel architectur

As I said, the kernel never disables interrupts or exceptions, it uses what I term gateways

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What, you didn't like the way the other thread went off topic?  ( https://www.avrfreaks.net/forum/... )

 

Fine.  IMO, the main requirement of an RTOS it that it should be able to place a deterministic upper limit on the response time of "tasks" to "events."  (where both of those are a bit loosely defined.)

 

It uses ... co-operative

Normally you need preemption to get "real time", because otherwise response time of one "process" (task) to "becoming runnable" (an event) is at the mercy of other code being "not cooperative enough."

If your idea of "event" doesn't include "process becomes runnable", or your individual processes are very disciplined, this can work fine, and effectively be "Real Time."

 

I have this suspicion that a lot of people say that their OS is "Real Time" when what they really mean is that it is preemptive...

 

RTOS companies sometimes give examples where a UART ISR does nothing except wake up a UART task, which then runs in time to actually read the uart registers and put the data in a queue or something.  I think that's an incredibly stupid way to service a UART (spends more time context-switching than doing actual work!)

 

I had an exceptionally educational experience WRT "real time" back in the late 80s.  We made network routers, and had just finished a system that would switch about 12000 packets/second between two ethernets.   BBN, in a similar timeframe, proudly published a paper about their latest "multi-processor butterfly real time gateway that guaranteed packet processing withing 1 millisecond.  We were not impressed - that was more than 10x slower than our much smaller and cheaper box.  Some time later, a customer (and future employee!) wrote his PhD thesis, where he studied that variance of packet switching times over long timeframes.  And it turned out that while MOSTLY we switched packets at 10kpps, sometimes it would take a longer - a LOT longer - perhaps more than 100ms !  That was the difference between out (cooperative) scheduler and BBN's "RTOS."   And thus I was enlightened...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is pre-emptive, the highest priority always runs. 

What did you mean when you said "cooperative"?

Real-time usually means the tasks as well as interrupts have guarantees on their latency.

 

If you have a task like:
 

    void mytask() {
        static volatile uin32_t runcount = 0;
        runcount++;
        suspend();  // but immediately runnable again
    }

Then a true RTOS should have a maximum time bound for how long in between activations...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting, I guess a scheduler can be called whatever you want, it's the engineer that makes the system real-time using the scheduler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay guys, ignore the co-operative comment, I forgot that the round robin takes care of tasks on the same priority level.

 

But if there tasks at a lower priority then the higher priority tasks need to co-operate to allow them to execute.

 

 

Last Edited: Thu. Aug 2, 2018 - 11:05 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Be sure to consider ‘priority inversion’. If you don’t know what this is, then some Googling is in order.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have intelligent mutex's that can deal with inversion to a degree and futext, fast mutex that have priority inheritance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:

RTOS companies sometimes give examples where a UART ISR does nothing except wake up a UART task, which then runs in time to actually read the uart registers and put the data in a queue or something.  I think that's an incredibly stupid way to service a UART (spends more time context-switching than doing actual work!)

 

    It is the kernel that reads the UART data and it does not know what that data is for, so it buffers it. Another reason to buffer it is that if the data comes fast enough and you present it to the application using that peripheral byte by byte, the whole system might get congested with not much benefit. Most of the time data arrives in bursts, so it is logic to buffer it and present it to the application in chunks. I am sure you are well aware about the PUSH flag in the TCP header; same reasoning.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Somewhat of a cross post/similar question:

 

https://www.avrfreaks.net/forum/...

 

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Make sure that "ordinary" processes can't access the priority-inheriting mutexes except through some controlled interface.  Otherwise they could grab one and hold onto it forever and get all of the CPU.

 

--Mike

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

westfw wrote:
RTOS companies sometimes give examples where a UART ISR does nothing except wake up a UART task, which then runs in time to actually read the uart registers and put the data in a queue or something. I think that's an incredibly stupid way to service a UART (spends more time context-switching than doing actual work!)
Many OS have the concept of "split" interrupt handlers. Linux calls them "Top half" and "Bottom Half". Nucleus calls them "LISR" and "HISR". One is the actual vector handler and often may do little more than unlock a gate (mutex, sem4) that the next level is waiting for. That then does most of the interaction/buffering work. The HISR/Bottom Half is a scheduled task like other tasks in the system but at a higher priority than other tasks. So it gets to run very shortly after the LISR/Top Half has triggered it. It has the benefit (unlike the vector itself) that it can call OS services (things like malloc etc).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Right guys, to sum things up.  The scheduler use pre-emption, priority based scheduling with round robin and first come first serve within priority levels.  Everything seems fine about that.  However....  multiple API calls may build up in during interrupts and are batched processed when no interrupts are pending and its the last interrupt.  Would this batch processing effect the real-time-ness of the scheduler?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nope, as has been said both in this and the previous thread it's all about speed of response to interrupts. If the OS' "housekeeping" gets held up that doesn't really matter. What is key is that the guy writing the code and using the OS can be sure that if he's got some hardware event going on that is going to require service every 5us +/-0.25us or something that he's going to be able to achieve that. That is he can write code that will respond in "real time" (or as near as dammit) ad the function of the OS won't get in the way.

 

For example Windows and Linux are not "RT" because they can (and often do) "get in the way" of things needing fast response.

 

As an example I remember a project we did running Linux that has a mini PS/2 keyboard with a Holtek PS/2 keyboard controller that could asynchronously start to send a key sequence at any moment and when it did I think it pulsed out a 25kHz clock (so 40us period). We had it attached to ext-int style lines and needed to both respond to the start of the traffic but then maintain service for all the while it was "bursting" data to us. Linux got in the way. I think we even put it on the NMI and *still* had problems. We applied the "real time patches" to the Linux kernel that were supposed to make it suitable for this kind of environment but it only just worked even then. That is a case of an OS getting in the way of being able to implement a "real-time" solution to something.

 

EDIT: wonder if this helps? It's the documentation of what the real time patches to the Linux kernel try to achieve: https://wiki.archlinux.org/index...

 

EDIT2: actually, read from the top of that linked page, the first paragraph seems pretty good.

Last Edited: Fri. Aug 3, 2018 - 04:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Clawson, I wrote the kernel so that interrupts and exceptions are always active and they are not disabled at any time by the kernel so the response time is in the nano second range.  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But it's not really about the kernel. It's the interrupt handlers in drivers the user may add. Can they be guaranteed timely response at all times?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes they can Clawson, the design was to target interrupt response times with a rich set of api calls that can be made from within interrupts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

As a side note:

In these modern times it seems more logical to use multi core processors for anything that needs an RTOS.

The parallax Propellor chip was maybe one of the first, but you do not hear much from it, probably because there were no proper development tools such as C cpmilers for it.

Ti's Sittara range of processors (as used un the beagle bone boards) have 2 PRU's, which are 200MHz microcontrollers on the same die, but which run indepently from the main processor, but can still directly read from or write to the main memory.

 

Phones have at least up to 8 cores ( "ARM big Little" seems popular), and maybe 16 core processers have also already arrived in the phone market.

I do not know anything about industrial counterparts of those processors.

 

Intel makes at least 24 core processors, and a few years back I read something about 32 core ARM processors for the server market.

High end Video cards have > 2000 cores nowadays, and NVidea makes dedicated hardware for AI applications, image recognition and extreme hardware which is becoming ever more mainstream.

It's Titan V has 620 tensor cores and 5120 CUDA Cores, whatever that means.

https://www.nvidia.com/en-us/titan/titan-v/?nvid=nv-int-tnvptlh-29191

 

If you can give every process, sub process,  "old" ISR or even every I/O pin it's own processor core, I see no real benefits of the old ways of interrupts any more.

An early example of this was some "SX" processor, which was a clone of an old Microchip microcontroller, but it did not have much peripherals because it could run at 120MHz, and at that speed most uarts, SPI and other uC peripherals could be emulated in software.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I remember for many, many years running Windows first on 80286, then 80386, then 80386SX, then 80486, log before we reached Pentium (really 80586) and in all these cases the OS was happily multi-tasking, sometimes more than 100 threads or more on a single processor. So I can't help thinking that throwing multi-cores at such a thing just because you can in 2018 is an absolute necessity ?!

 

Actually (apart from CP/M on 8080 and Z80 which are not multi-tasking) I think my first experience of multi-tasking OS would probably have been OS-9 for the 6809 from around 1980. That was running multi-tasks on a CPU much lower specified than even the most basic AVR these days.

 

Interesting timeline of OS here: https://en.wikipedia.org/wiki/Ti... - even back into the 60's and 70's there were multi-tasking OS though admittedly most targetted mainframes but from mid to late 70's onwards there were a proliferation of OS for micros.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll say a couple things with assurance:

1)  Us punters here cannot answer with certainty.

1a) Any reply here made with certainty will be able to be refuted.

 

2) Surely there are many definitive resources out there that will have definitions/requirements, and discussions of each.  Many may be scholarly (horrors -- might even be in a PRINTED BOOK).

 

3)  OP apparently will not be satisfied with any list of definitions/requirements.  That said, a simple Google search "what are the requirements of an rtos" gives seemingly directly-pertinent hits on the first page:

 

https://www.multisoftvirtualacad...

An Insight Into the Types and Requirements of RTOS

 

An Insight Into the Types and Requirements of RTOS

Multisoft Virtual Academy | March 16, 2016 | Embedded Systems | No Comments

59 total views, 1 view today

Real Time Operating System (RTOS) that promises to provide some defined capabilities that are covered in the specified time frame. It also helps in predicting the unpredictable event along with processing multiple programs simultaneously.

RTOS

Types of RTOS

It comprises of two types mentioned below:

  • Hard Real Time Systems: It means that there is a hard deadline of the task and it has to be met within the specified time limit; or else the task will be declared as failed. These types of systems are used in the objects wherein safety is a critical issue. Few examples of these types of systems are trains, car, aircraft, nuclear reactors or missiles.
  • Soft Real Time Systems: It means that if the deadlines are not met within the specified time frame, some adjustments can be made and the task is not declared as failed. However, this includes the system costs, as the tasks got delayed.

RTOS Architecture

The RTOS architecture consists of the following:

  • Program Interface
  • Optional Service Modules
  • The Kernel
  • Scheduler

Requirements of a Good RTOS 

There are certain features that must be possessed by a good RTOS. Let’s get an insight about them:

Multitasking Feature: An RTOS must have...

Sure seems pertinent to me.

 

https://www.quora.com/What-is-th...

"What is the minimum system requirement to use RTOS?"

 

Isn't that the question here?

 

https://www.nasa.gov/sites/defau...

Real-Time Operating Systems (RTOS) 101

 

Richard E. Kowalski, richard.e.kowalski@ivv.nasa.gov, TASC Inc

.

NASA POC: Frank Huy, Frank.A.Huy@nasa.gov

NASA Independent

Verification and

Validation Facility

Fairmont, West

Virginia

Real

-

Time Operating Systems (RTOS) 101

Real

-

Time System Characteristics

A

real

-

time

system is a computer system which is required by

its specification to adhere to:

functional requirements

(behavior)

temporal requirements

(timing constraints, deadlines)

Specific deterministic timing (temporal ) requirements

Deterministic

" timing means that RTOS services

consume only

known and expected

amounts of

time

.

Small size (footprint)

Types of Real

-

Time Systems

A generic

real

-

time system

requires...

 

Now, if OP does a scholarly compilation of e.g. the characteristics that those and similar resources have in common, and how they differ, and wants to discuss a particular aspect -- THEN I'd be more interested.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it were me I'd simply call it "Operating System". If it happens to deliver someone's realtime requirement then count that as a serendipitous bonus. The alternative of labelling it "realtime" then being caught in a lie is surely the worse alternative?