Teaching Real Time System using Single Board Computer and GNULinux

1
Teaching Real Time System using Single Board
Computer and GNU/Linux

• Presented By PM Dr R Badlishah Ahmad
• Prepared By Zahereel Ishwar Abdul Khalib

2
Presentation Outline

• Defining Real Time system
• Linux as a Real Time OS ?
• The POSIX standard
• Brief theoretical topics covered in teaching the
  subject
• Brief Practical Laboratory exercise
• Project

3
Real Time Def

• A Real Time system is a system which correctness
  depends on ( 2 aspects)
• Output produce
• The time it takes to produce the output (Response
  Time).

4
Soft Real Time System

• A system is considered as soft real time if it is
  built to react to stimuli as quickly as it can
  best effort.
• However, if the system loses events or fails to
  process them in time, there is no catastrophic
  consequence on its operation. There is just a
  degradation in quality.
• Typical examples
• Audio
• Video
• Voice over IP

5
Hard Real Time

• A system is considered as a hard real time if it
  can answer to an internal or external stimulus
  within a given maximum amount of time.
• Guaranteed worst case Deterministic
  Predictable
• Hard real time systems are used wherever failing
  to react in time can cause a system failure or
  damage, or put its users/others in danger.
• Typical examples
• Industrial process control
• Transportation
• Medicine (pacemakers, etc.)

6
Typical Real Time System

• Most Real Time System are Embedded System

7
Linux a Real Time OS ?

• The Linux kernel 2.4 cannot be considered as a
  real time operating system
• Like Unix, it is a time sharing (General Purpose)
  operating system designed to maximize throughput
  not to optimize real time performance.
• Non deterministic timing behavior of some kernel
  services
• memory allocation, system calls ( built in kernel
  function)...
• By default, processes are not pre-emptible
  (cannot be stopped) when they execute system
  calls.

8
Linux a Real Time OS ?

• Main Linux kernel 2.6. enhancement
• Improved responsiveness (but still NOT
  deterministic)
• A PREEMPTIBLE KERNEL
• AN EFFICIENT SCHEDULER
• SYNCHRONIZATION

9
Compare 2.4 vs 2.6 Performance
10
The POSIX standard

• (Portable Operating System Interface ) POSIX
• It define standards interface that allows code
  written for a POSIX conformance OS to be portable
  to another POSIX conformance OS with zero
  changes.

11
Brief on POSIX

• POSIX.1 POSIX core services
• (the feature set usually found in UNIX
  operating systems)
• POSIX.1b real-time extensions
• POSIX.1c thread extensions

12
Details of POSIX Std
13
Is Linux POSIX conformance ?

• Linux is 90 percent or more POSIX-compliant.
  Meaning that it has implemented more than 90 of
  the characteristic defined in POSIX
• (Note POSIX does not defined performance but it
  defines interface characteristic).
• Thus, the time and effort spent developing an
  embedded application on Linux can be leveraged
  into the real-time space with the choice of
  another, POSIX- conformant RTOS.
• POSIX conformance enables open standards-based
  Solaris, Linux, HP-RT, HPUX, and UNIX
  applications, for example, to be easily migrated
  to other POSIX conformant systems.

14
Thus, Linux 2.6 is a Real Time Kernelsoft real
time

• In short, code written on Linux 2.6 kernel can
  always be ported to other Real Time OS like
  LynxOS, eCOS should Hard Real Time performance is
  required.
• .but, if whats required is Soft Real Time, than
  Linux 2.6 will do the job.

15
Theoretical topics Covered in Teaching

• Educate the students to write concurrent and
  synchronize code based on POSIX.1 POSIX.1b
  standard.
• these includes
• Techniques of creating and executing multiple
  process.
• Signal Programming (interrupt like mechanism)
• Inter process communication techniques
• Shared Memory
• Message Passing
• Semaphores
• Pipe, named pipe
• Real Time Signals
• Priority Scheduling
• Clock and Timers

16
Laboratory Practice

• Configure the hardware running a Linux Kernel
  2.6.16 for a specific purpose (networking,
  performance, etc).

17
. Lab Practice

• Write concurrent and synchronize application
  using Linux system calls ( kernel
  function) which exhibit some real time
  application.
• Cross compile code and porting the code to the
  hardware platform.

18
Project

• Implement a soft real time system on the target
  board which interacts with external sensors.
  (Specific title changes over the semester) The
  challenge in the project is achieving peak
  performance, which shall be made true by
• Tweaking the kernel options
• Scheduling / Concurrent / Sycnhronization process
  manipulation

19
ANYTHING to CLARIFY ?
20
AN EFFICIENT SCHEDULER

• The new 2.6 kernel has a new process scheduler
  that replaces the slow algorithms of earlier
  kernels. Previously, to decide which task should
  run next, the scheduler had to look at each ready
  task and score its relative importance.

21
Pre-emptible

• Linux has always been similar to most
  general-purpose operating systems in that its
  process scheduler is prohibited from running when
  a process is executing.
• This has meant that once a task is in a system
  call, the task controls the processor until the
  system call returns, no matter how long that
  might take. While this design is simple to
  implement, it can delay more important tasks.
• The new Linux 2.6 kernel is now preemptible to
  some degree, making it more responsive and giving
  designers better control over the timing of
  events.
• While 2.6 still cannot be considered a true RTOS,
  but preemption points have been inserted to
  enable the scheduler to run and possibly block a
  current process so that a higher priority process
  can be scheduled.

22
Synchronization

• Oftentimes, multiprocessing applications need to
  share resources, such as shared memory or shared
  devices. Software designers are able to avoid
  race conditions by using a mutex to ensure that
  only one task is using the resource at a time.
  Until now, the Linux implementation of mutex has
  always involved a system call to the kernel to
  determine whether to block the thread or allow it
  to continue. The timeconsuming system call was
  often unwarranted and unnecessary.
• The new implementation in Linux 2.6 supports fast
  user-space mutexes, which check user space to see
  if blocking is necessary and only perform a
  system call when blocking the thread is required.
  When blocking isn't required, avoiding the
  unneeded system call saves time. The user space
  functions also use scheduling priority to
  determine which thread is allowed to execute in
  the case of a conflict.