OSDev.org

Hello all,

I guess this is the right place to announce a new OS

My team has created an open-source RTOS designed for critical systems (https://sourceforge.net/projects/rtospharos/). It is licensed under Apache 2.0.

Down to the features:
- fixed-priority preemptive scheduler (256 priority levels)
- partitions (each partition contains a set of threads)
- native support for periodic, sporadic and aperiodic threads
- Memory protection (partitions)
- Time protection (a thread is not allowed to execute for more time than it is configured to)
- Set of intra-partition objects (semaphores, events, message queue, timers, futures)
- Set of inter-partition objects (message queue, channel for zero-copy transfer, resource)
- Inter-partition filter - application defined methods that allow/reject communication between partitions (operate on a separate stack, on the memory area of the callee partition but on the time window of the caller thread)
- support for a wide variety of ARM CPUs

It is relatively a new OS, more or less one year since its first release. For each release there is a quite extensive User Manual with working examples (see the latest release in https://sourceforge.net/projects/rtospharos/files/).

You are quite welcome to make comments, ask questions, request new features, etc

We believe it is well commented so it could be a learning experience for newcomers to this area, but could also be for more experienced OS developers (we hope so).

Please enjoy it,
Pedro

Since you mention it is real time, is it soft or hard real time? And what guarantees can it make?

Hi,

Thanks for your question.

If you are asking if it is possible to use Pharos on a critical system, let me just something about critical systems (that you may already know). There is normally a criticality level associated with system standards (e.g DAL level, SIL, etc). Pharos is quite new and we haven't (yet) demonstrated to which criticality level Pharos is certified to.

If you asking about it's time properties, pharos has a O(1) algorithmic complexity for most of the cases and O(log(N)) in some specific cases (e.g. at a clock tick).

Regarding the guarantees, pharos always places the highest priority ready thread on the executing state (it has a preemptive scheduler). Also it supports nesting interrupts. The blocking queues (e.g. on a semaphore) are also priority based. The interrupt critical sections are minimized (a system call only disables interrupts when it needs to).

Does this answer your question?

Thanks again,
Pedro

Anything about deadlock detection?
Anything about priority inversion?

pharos wrote:Hi,

Thanks for your question.

If you are asking if it is possible to use Pharos on a critical system, let me just something about critical systems (that you may already know). There is normally a criticality level associated with system standards (e.g DAL level, SIL, etc). Pharos is quite new and we haven't (yet) demonstrated to which criticality level Pharos is certified to.

With all due respect, I doubt that even the more experienced members here (except possibly rdos) knows enough about RTOS certification to follow that explanation. A simpler (if not necessarily as accurate) answer such as, 'it is for soft real time only' or 'it is meant to be usable for hard real time, but it is still undergoing vetting and certification' would be more appropriate in a group where even the more ambitious members are mostly amateurs and hobbyists (in the sense that they are neither making money at it - AFAIK, the only one here who is selling an OS product is rdos - nor working on formal research and/or organized FOSS development projects in this field).

Indeed, it would be difficult to say if your reply even made sense, rather than being a load of doublespeak. I not at all convinced it did, in fact, though my knowledge of formal RTOS standards is virtually nonexistent so I can only assume that I am simply unfamiliar with what you refer to. This rather speaks to my main point though, that your answer isn't going to make sense to most of the regulars here, never mind the novices.

TL;DR - even if your answer makes sense, if it doesn't make sense to your audience, it is indistinguishable from a lie. Just sayin'.

@alexfru

We did not implement a deadlock detection mechanism. As far as we know, there is no O(1) or O(log(N)) deadlock detection mechanism. If you know one, we will be more than happy to implement it!
We do implement a semaphore ceiling which, if used correctly, can prevent deadlocks (note that there are some conditions required for deadlocks to be prevented when using ceiling semaphores).
We also allow a partition to obtain a "resource" from another partition for access in mutual exclusion. This resource is controlled also via a semaphore ceiling but, when inside the resource:
- the thread stack is changed to a special stack
- the memory permissions changed to the memory permissions of the resource owner partition
- the access to the resource is only allowed if the executing thread has a big enough time window to successfully complete the resource (each resource has a configurable WCET) without exhausting its time window -> this is to ensure that once a thread has access to a resource it can complete it without other lower priority threads preempting it

Do you have an application in mind for pharos?


@Schol-R-LEA

Thanks for giving your point of view. I had not think about this hard/soft issue from that perspective. Nevertheless, I think that even if the audience is not familiar with some concepts, one could transmit the knowledge so that an understanding could be reached, hopefully.

There is a well defined difference between hard/firm/soft real time based on the "utility" of the system as time goes by. I guess this well documented and one can google it can find hundreds of explanations for this so I cannot add anything new.
But in the "real world" this definition is...not used at all (at least I never encountered it). Typically what is done is:
- there is a standard that defines the level of criticality of your system based on what could happen if the system does not operate correctly (e.g. lives are lost, equipment is damaged, a person could feel uncomfortable, a person was not see any behavior at all). This is quite similar to the utility function, but normally the standards define more levels (than the 3 hard/firm/soft)
- based on the critical level, the standard defines which "proofs" you must produce to certify your system to that level (e.g. coding standard, tests, etc)

When reading the question of whether pharos is for hard/soft real time I was in doubt if the question was related to this "criticality" definition or was related to the API provided or whatever. So, to try to answer again to the question, pharos:
- has an API design for hard real time systems
- the source code was written so that the certification proofs would be easier to provide (if the opportunity arises for this)
- pharos is NOT certified today to any standard

I hope to have clarified any doubt related to this issue. But your answer has proven to me that are multiple ways to see the same subject, so if this answer did not satisfy you (or anyone else) please let me know

Thanks,
Pedro

Continuing from my earlier question, since you are indicating it is hard realtime, i have two follow up questions:

To what load percentage does the system guarantee deadlines?
How does it degenerate after that point (no guarantees? or will it (try to) minimize overruns? does it/can it drop tasks?)

Hi

It is, as you stated, it is the system that is schedulable (or not). The operating system itself (any operating system) cannot give guaranteed percentage unless it very specific (e.g. your system only has periodic and/or sporadic threads, priorities are well defined by RMS or EDF, no mutual exclusions areas, etc). It is up to the system as a whole to check if it is schedulable or not. Pharos has a fixed priority preemptive scheduler. That means that the priorities are fixed so EDF is not possible (at least for now). This means that RMS is possible if the application defines the threads priorities according to the RMS conditions.

But you could also use RTA to determine if a system is schedulable (this does not calculate with percentages but gives you some information).

I'm glad you asked the second point since I forgot to mention it before. Pharos has, for periodic and sporadic threads, deadline detection. Once the application has been notified that a deadline was missed, it can do all sorts of things, including suspending the "offending" thread.

If you have more questions, I'll be glad to answer them. Also, feel free to check this presentation about Pharos:

https://www.slideshare.net/RTOSPharos/pharos-105989016

Regards
Pedro

Hi all,

Just to announce that a new release has been made (1.4.0) with support for the raspberry pi3.

Regards,
Pedro

Hi all,

Just to announce that several other releases are available. Plenty of new features have been added:

- multi-core with communication (channels and heavy weight queue between partitions of different cores)
- aperiodic threads have now also time protection (that is, they won't execute for more time than they are supposed to)
- support for STM32 board

And several bugs have been fixed.

Regards,
Pedro

Hi all,

Just announce that release 3.1.0 has just been issued.

The main change is support for RISC-V 64 bit.

Best regards
Pharos team