[Oberon] Oberon as (embedded) rtos.

[Frans-Pieter Vonck]

Also interesting, the JPL Rule for inter process communication.

from: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
---------------------------------------------------------------------------
Rule 6 (inter-process communication)

An IPC mechanism should be used for all task communication. Callbacks
should be avoided. No task should directly execute code or access data
that belongs to a different task. All IPC messages shall be received at 
a
single point in a task.


Communication and data exchanges between different tasks (modules) in 
the system are
best performed through a disciplined use of IPC (inter-process 
communication)
messaging. IPC messages should then contain only data, preferably no 
data pointers, and
never any function pointers. Each task or module should maintain its own 
data structures,
and not allow direct access to local data by other tasks. This style of 
software architecture
is based on principles of software modularity, data hiding, and the 
separation of concerns
that can avoid the need for the often more error-prone use of 
semaphores, interrupt
masking and data locking to achieve task synchronization
----------------------------------------------------


Found in System Oberon, message handlers!
Now the question is how this message model is implemented in C++ by JPL.
They use the rtos Vxworks for flight systems and that has a message que 
between tasks
See code below (From: 
https://www.uio.no/studier/emner/matnat/fys/FYS4220/h11/undervisningsmateriale/laboppgaver-rt/VxWorks-6.2_Application_Programmers_Guide.pdf)

/* In this example, task t1 creates the message queue and sends a 
message
* to task t2. Task t2 receives the message from the queue and simply
* displays the message.
*/
/* includes */
#include <vxWorks.h>
#include <msgQLib.h>
/* defines */
#define MAX_MSGS (10)
#define MAX_MSG_LEN (100)
MSG_Q_ID myMsgQId;

task2 (void)
{
   char msgBuf[MAX_MSG_LEN];
   /* get message from queue; if necessary wait until msg is available */
   if (msgQReceive(myMsgQId, msgBuf, MAX_MSG_LEN, WAIT_FOREVER) == ERROR)
   return (ERROR);
   /* display message */
   printf ("Message from task 1:\n%s\n", msgBuf);
}

#define MESSAGE "Greetings from Task 1"
task1 (void)
{
    /* create message queue */
    if ((myMsgQId = msgQCreate (MAX_MSGS, MAX_MSG_LEN, MSG_Q_PRIORITY))
       == NULL)
       return (ERROR);
    /* send a normal priority message, blocking if queue is full */
    if (msgQSend (myMsgQId, MESSAGE, sizeof (MESSAGE), WAIT_FOREVER,
    MSG_PRI_NORMAL) == ERROR)
    return (ERROR);
}



Paul and Chris,
Oberon in Space?
http://flightsoftware.jhuapl.edu/

Greets,
F.P.



Chris Burrows schreef op 2018-11-12 08:12:
>> -----Original Message-----
>> From: Oberon [mailto:oberon-bounces at lists.inf.ethz.ch] On Behalf Of
>> Paul Reed
>> Sent: Monday, 12 November 2018 12:26 AM
>> To: ETH Oberon and related systems
>> Subject: Re: [Oberon] Oberon as (embedded) rtos.
>> 
>> > https://en.wikipedia.org/wiki/Rate-monotonic_scheduling#cite_note-
>> 12
>> > ..."What really happened on Mars Rover Pathfinder"
>> > http://www.rvs.uni-
>> bielefeld.de/lectures/TechInf/TI2/download/19.49-1.
>> > 1.ht
>> > ml
>> > ...Some lessons learned...
>> > https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf
>> 
>> Thanks, nice reading!  It reminded me that Chris Burrows has already
>> pointed out how much you need to do of MISRA-C when writing in C,
>> which with Oberon you get out-of-the-box.
>> 
> 
> Thanks for remembering, Paul!
> 
> For those who were not fortunate enough to be able to attend Oberon Day 
> 2011
> this is a summary of my attempts to get some measure of the comparative
> reliability of C and Oberon-07 when used for embedded software 
> development.
> 
> From Wikipedia: "MISRA C is a set of software development guidelines 
> for the
> C programming language developed by MISRA (Motor Industry Software
> Reliability Association). Its aims are to facilitate code safety, 
> security,
> portability and reliability in the context of embedded systems"
> 
> I took the 142 rules of the MISRA-C:2004 "Guidelines for the use of the 
> C
> language in critical systems" and applied them to Oberon-07. I 
> discovered
> that more than 70% of the rules are NOT required when programming in
> Oberon-07. They are either already enforced by the language or are not
> applicable.
> 
> Examples of MISRA rules that are not applicable to Oberon-07:
> 
>   Rule 14.4: The goto statement shall not be used. (Oberon-07 does not 
> have
> GOTO)
> 
>   Rule 14.5: The continue statement shall not be used. (Oberon-07 does 
> not
> have CONTINUE)
> 
> Examples of MISRA rules that are enforced by the design of Oberon-07:
> 
>   Rule 14.7: A function shall have a single point of exit at the end of 
> the
> function.
> 
>   Rule 16.6: The number of arguments passed to a function shall match 
> the
> number of parameters.
> 
> The remaining 30% of MISRA rules would need to be followed if using
> Oberon-07 for critical systems. They include:
> 
>   Rule 2.4 (advisory): Sections of code should not be "commented out".
> 
>   Rule 20.4: Dynamic heap memory allocation shall not be used.
> 
> More information about MISRA and their guidelines can be found on their
> website:
> 
>   www.misra.org.uk
> 
> Regards,
> Chris Burrows
> CFB Software
> http://www.astrobe.com
> 
> 
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related 
> systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon