I have to create scheduler for RTOS. How should I start?
What OS is good for writing scheduler? What operating systems should I chose?
How can I test scheduler, debug code?
If you are willing to learn something by writing a real time scheduler, then you should start with reading this. Through this, you can learn different kinds of scheduler design and their applications. You can start with writing a small co-operative scheduler.
I will recommend you to use freeRTOS(as it is free and simple) first before jumping to write your own scheduler. There are user manual available online for free. Download them and go through them. Then, you can develop a application using freeRTOS APIs. Through this, you will understand the necessity of features provided by a RTOS (like process synchronization, priority of tasks, inter-process communication) and it's scheduler.
You may need to buy a development board support by freeRTOS or there is also windows port available online. Then, you can start writing your own scheduler implementation. The freeRTOS source code which is available online for free can be used to aid your development. FreeRTOS is designed to be small and simple. The kernel itself consists of only three C files. To make the code readable, easy to port, and maintainable, it is written mostly in C, but there are a few assembly functions included where needed (mostly in architecture-specific scheduler routines).
Also, POSIX C library can also be used to understand RTOS and features required by any real time system. You can develop application using POSIX library to understand RTOS. Later, you can switch to any other RTOS.
Related
I come from an embedded background, where hard real-time is taken quite seriously. For me (fast) real time is tricky on Linux, and ludicrous on Windows, jet video games seem to be doing just fine.
Obviously, since it's only soft real time, and the frequency is (relatively) low with 60+ Hz, the simple solution is to render as fast as possible and hope for the best. But are there any advanced techniques in use that further enhance the responsiveness on Windows?
Some concrete questions:
Is there a way to handle Windows pre-empting at unfavourable moments? How do you share work on multiple cores when some of them are doing something else?
Is IO-latency in Windows deterministic? Can (should) you pressure the scheduler to context switch ASAP?
How common are scheduling techniques like Earliest Deadline First / Rate Monotonic Scheduling (or others)? (build on top of the existing one of course)
Any insight would be welcome!
Edit:
I've looked through a few resources and have added my conclusions:
1.
Q: What happens when a time critical calculation gets pre-empted?
A: The thread should have higher priority so pre-emption is rare, and when it happens, the interruption should be brief (short interrupts or IO-operations).
Windows has the capability to move threads to other cores, thou it is recommended to keep them locked ( -> Thread Affinity).
2.
Q: Should IO-operations have a higher priority than the render loop?
A: Yes, Naughty Dog's engine gives IO-operation higher priority.
Q: What kind of scheduling is used?
A: In the presentation, a job system is used (similar to reactive programming).
It uses three priorities that are non-preemptive.
I recommend you read Modern Operating System from Ph.D Andrew Tanenbaum if you haven't read it. His book also have Unix and Windows architecture.
One most major thing: Game programming is different than Embedded programming
I had worked with Windows and Android (Unix-like). Not only Windows but also Android very hard rendering too meet hard real-time. One of our tricks to reduce CPU, GPU latency is using lower feature driver support for the visual effect (which mean if hardware not support good this new graphic API, we will use older API so this will make object less shape and less beauty) or if device is not support the feature and effect is not important, just remove this effect for that device. It will push FPS (frames per second) better.
Game engine is also difference between many graphic APIs, use Vulkan or DX12 (Windows) or Metal (Apple devices) is make more FPS but require newer hardware, because they are low-level APIs. It will give you better performance, more beautiful than OpenGL or DX11, but old APIs is support on older devices.
And 3 your questions, I will answer with my knowledge (may be there is a better answer from other):
I also have a small question: Why don't you use thread, atomic, mutex C++ 11 APIs for share tasks with multi-core CPU? It easier for thread programming, cross-platform and no need to schedule anything.
Windows has classic Win32 thread APIs SetThreadPriority for set the relative priority of a thread. This API isn't recommended for Windows Runtime (Modern Windows concept from Microsoft for Windows 8 and later) which recommended using thread-pool concept instead (use modern API will automation parallel tasks with multi-core, which is better than manually config use classic API).
In Game engine, there is a presentation of Christian Gyrling from Naughty Dog talking concept Parallel and Sergey Makeev from Roblox implement open source TaskScheduler base this concept in Win32 APIs and Pthread APIs. Jeff Preshing from Ubisoft also have a presentation using C++ 11.
What did you mean about IO-latency? Keyboard, mouse or Disk IO? I will edit answer if you edit your question more clear
I can't find a document or anything similar Earliest Deadline First / Rate Monotonic Scheduling on Windows. May be this is limited by prevent kernel mode scheduling from Microsoft.
From my research I cannot find what kernel type is being used in eCos, such as monolithic or micro-kernel. All I could find from my research is that the kernel is a real-time one or websites just describe it as the eCos kernel, does this mean it is a custom made kernel?
What I know about eCos is that it is a hard RTOS although is somewhat vulnerable in terms of security, uses priority, queue based scheduling.
A micro-kernel is:
... the near-minimum amount of software that can provide the mechanisms
needed to implement an operating system (OS). These mechanisms include
low-level address space management, thread management, and
inter-process communication (IPC).
(Wikipedia 11 Dec 2018)
The eCos kernel is described in its Reference Manual thus:
It provides the core functionality needed for developing
multi-threaded applications:
The ability to create new threads in the system, either during startup
or when the system is already running.
Control over the various threads in the system, for example
manipulating their priorities.
A choice of schedulers, determining which thread should currently be
running.
A range of synchronization primitives, allowing threads to interact
and share data safely.
Integration with the system's support for interrupts and exceptions.
It is quite clearly by comparison of these descriptions a micro-kernel. Other services provided by eCos such as file-systems, networking and device drivers are external and separable from the kernel. That is to say, you can deploy the kernel alone without such services and it remains viable.
In a monolithic kernel, these services are difficult or impossible to separate as they are an intrinsic part of the whole. Unlike eCos mand most other RTOS they do not scale well to small hardware platforms common in embedded systems. Monolithic kernels are suited to desktop and general purpose computing platforms, because the platforms themselves are monolithinc - a PC without a filesystem, display, keyboard etc, is not really viable, whereas in an embedded system that is not the case.
While Linux, and even Windows are used in embedded systems, a micro-kernel is deployable on platforms with a few tens of kilo-bytes of memory, whereas a minimal embedded Linux for example requires several mega-bytes and will include a great deal of code that your application may never use.
Ultimately the distinction is perhaps irrelevant, as is the terminology. It is what it is. You do not choose your kernel or OS on this criteria, but rather whether it provides the services you require, runs on your target, and fits in the available resource.
I think it is a monolithic kernel. If you review this page: http://ecos.sourceware.org/getstart.html
It is used instead of linux kernel and linux kernel support monolithic kernels. In addition, if it was a micro kernel , they would highlight the kernel type like QNX Kernel type which is micro kernel
Although I have implemented many projects in C, I am completely new to operating systems. I tried real time linux on Discovery board (STM32) and got the correct results for blinking LED but I didn't really understand the whole process since I just followed the steps and could not find whole description for each step on the internet.
I want to implement scheduling on real time linux. What is the best way to start? Any sites, books, tutorials available?
Complete RTLinux process description will be appreciated.
Thanks in adv.
The transition from "bare metal" to OS based programming is something that I experienced in reverse. I started out a complete software guy, totally into the OS side of things and over time I have moved to the opposite of that (even designing circuits in VHDL!). My advice would be to start simple. Linux is pretty complex, and everywhere you look there are many layers of things all working together to deliver the final product. If you are dead set on a real time linux extension, I'd be happy to suggest https://xenomai.org/ which is a real time extension for linux.
However, to more specifically address your question about implementing scheduling in Linux, you can, but it will be a large amount of work and can be very complicated. The OS uses a completely fair scheduling process ( http://en.wikipedia.org/wiki/Completely_Fair_Scheduler ) and whenever you spin up a thread, it simply gets added to the list to run. This can differ slightly if you implement your code in kernel space as a driver, rely on hardware interrupts, etc., but in general, this is how Linux works. Real time generally means that it has the ability to assign threads one of several different priorities and utilize thread preemption fully at any given time which are concepts that aren't really a part of vanilla Linux. It has some notion of this, but it has limitations that can cause problems when you are looking for real time behavior from Linux.
What may be helpful to you is an RTOS. If you are looking for a full on Real Time Operating System, check out FreeRTOS http://www.freertos.org/ . It has a large community and supports a lot of different devices out of the box with a large amount of example code. They even support your specific board with an example package, so you can give it a shot with nothing to lose! http://www.freertos.org/FreeRTOS-for-Cortex-M3-STM32-STM32F100-Discovery.html . It gives you access to many OS ish constructs like network APIs, memory management, and threading without the overhead and latency of a huge OS. With an RTOS, you create tasks and assign them priorities so you become the scheduler and are no longer at the mercy of the OS. You run the OS, not the OS runs you (if that makes sense). Plus, the constructs offered within an RTOS will feel much like bare metal code and thus will be much easier to follow, understand, and fully learn. It is a more simple world to learn the base building blocks of a full blown OS such as Linux or Windows. If this option sounds good, I would suggest looking through the supported devices on FreeRTOS website and picking one you would like to experiment with and then go for it. I would highly recommend this as a way to learn about scheduling and OS constructs in general as it is as simple as you can get and open source. Once you have the basics of an RTOS down, buying a book about Linux specifically wouldn't be a bad idea. Although there are many free resources on the web related to learning about Linux, they are commonly contradictory, and can be misleading. Pile on learning Linux specific knowledge along with OS in general, and it can feel overwhelming. Starting simpler will help keep you from getting burnt out and minimize the amount of time you spend feeling lost. Linux is definitely a learning process, but like with any learning process, start simple, keep your ultimate goal in mind, make a plan, and take small, manageable steps along that plan until you look up and find yourself exactly where you want to be. Then go tackle the next mountain!
The real-time Linux landscape is quite confusing. 99.99% of the information out there is just plain obsolete.
First, there are lots of "microkernels" that run Linux as one task. (Such as the defunct RTLinux). The problem is that you must write your real-time task to a different API, and can't depend on anything in Linux, because Linux will be frozen in the background while your task runs. So unless your task is dead-simple ("stop the motors when I press this button"), this approach will cause more pain than gain.
Next, there is the realtime Linux patch set. This hasn't been doing so well. because of the next item:
Lastly, the current Linux kernel has gotten rid of the problems that caused people to need realtime in the past. You can even turn off Linux on one of your processors to have full control of the CPU. See also this paper.
To answer your question: I see two different paths you could take:
1) Start with a normal 3.xx Linux kernel and explore the various APIs and realtime techniques (i.e. realtime priorities, memory pinning, etc.) This can get you "close enough" for 99% of what people want "realtime" for. If it's good enough for high frequency trading, it's probably good enough for you.
2) If you have a hard realtime requirement and you are worried that Linux won't cut it, then (as Nick mentioned above), just go buy a processor and write your realtime code with no OS. By splitting up your "realtime" and "non-realtime" code onto different CPUs, you will make the whole system simpler and much more robust.
If you want to learn real-time operating systems then I suggest that you get an FPGA, for example the Altera DE2, and experiment with your own operating system and ucos. You can read a good text about embedded RTOS here.
You could also get a Linux Raspberry and write your own operating system for that.
I wish to write a very basic RTOS which can just switch between two tasks. Its not for any professional usage. Its just for fun
Most references say about how to use an RTOS and not about how to write one.
Refering an opensource RTOS like FreeRTOS will not make us understand the base concept.
One reference i found is Simple Real Time Operating Sysytems
I would wish to know if there is any other source which can be a kickstarter for those who wish to write an RTOS from scratch.
Jean Labrosse's book MicroC/OS-II:The Real Time Kernel describes the implementation of a simple RTOS in minute detail. There is a new edition for MicroC/OS-III, with architecture specific editions (but I've no experience of the new edition, and MicroC/OS-III is has slightly more complex/sophisticated scheduler).
Although now a commercial RTOS in its own right MicroC/OS was originally presented by this book (and its µC/OS predecessor) as a reference on RTOS kernel/scheduler implementation. Its principles can be applied more broadly to implement your own RTOS (though you need to respect any licences and copyrights of course).
I'm taking an introductory course (3 months) about real time systems design, but any implementation.
I would like to build something that let me understand better what I'll learn in theory, but since I have never done any real time system I can't estimate how long will take any project. It would be a concept proof project, or something like that, given my available time and knowledge.
Please, could you give me some idea? Thank you in advance.
I programm in TSQL, Delphi and C#, but I'll not have any problem in learning another language.
Suggest you consider exploring the Real-Time Specification for Java (RTSJ). While it is not a traditional environment for constructing real-time software, it is an up-and-coming technology with a lot of interest. Even better, you can witness some of the ongoing debate about what matters and what doesn't in real-time systems.
Sun's JavaRTS is freely available for download, and has some interesting demonstrations available to show deterministic behavior, and show off their RT garbage collector.
In terms of a specific project, I suggest you start simple: 1) Build a work-generator that you can tune to consume a given amount of CPU time; 2) Put this into a framework that can produce a distribution of work-generator tasks (as threads, or as chunks of work executed in a thread) and a mechanism for logging the work produced; 3) Produce charts of the execution time, sojourn time, deadline, slack/overrun of these tasks versus their priority; 4) demonstrate that tasks running in the context of real-time threads (vice timesharing) behave differently.
Bonus points if you can measure the overhead in the scheduler by determining at what supplied load (total CPU time produced by your work generator tasks divided by wall-clock time) your tasks begin missing deadlines.
Try to think of real-time tasks that are time-critical, for instance video-playing, which fails if tasks are not finished (e.g. calculating the next frame) in time.
You can also think of some industrial solutions, but they are probably more difficult to study in your local environment.
You should definitely consider building your system using a hardware development board equipped with a small processor (ARM, PIC, AVR, any one will do). This really helped remove my fear of the low-level when I started developing. You'll have to use C or C++ though.
You will then have two alternatives : either go bare-metal, or use a real-time OS.
Going bare-metal, you can learn :
How to initalize your processor from scratch and most importantly how to use interrupts, which are the fastest way you have to respond to an externel event
How to implement lightweight threads with fast context switching, something every real-time OS implements
In order to ease this a bit, look for a dev kit which comes with lots of documentation and source code. I used Embedded Artists ARM boards and they give you a lot of material.
Going with the RT OS :
You'll fast-track your project, and will be able to learn how to fine-tune a RT OS
You may try your hand at an open-source OS, such as Linux or the BSDs, and learn a lot from the source code
Either choice is good, you will get a really cool hands-on project to show off and hopefully better understand your course material. Good luck!
As most realtime systems are still implemented in C or C++ it may be good to brush up your knowledge of these programming languages. Many realtime systems are also embedded systems, so you might want to play around with a cheap open source one like BeagleBoard (http://beagleboard.org/). This will also give you a chance to learn about cross compiling etc.