OSDev.org

Hi guys

I'm a newer of this site. I'm a Master student of Computer engineering. I like OS dev very much. Now I'm trying to write a RTOS kernel. I have back ground of computer architecture, OS and some linux kernel development. I have transplanted a RTOS to a embedded board that has a STM32 ARM Cortex M3 processor. STM32 processor provides many library and boot code, which means I don't need care about so much details of hardware stuff. So I can focus OS part. Also I'm hacking the RTOS kernel that is uCOS ii for 1 and half months. I think I have figure out most part of that RTOS kernel. But I still don't know how to eat this big cake. Or where I can start. So I hope you guys can give me some suggestions. Because I think you are all professional and pretty like this area

Well, whereas in a PC the distinction between the OS and applications is fairly clear cut, in the embedded world it seems to me somewhat less so.

So, I imagine that the first thing you would need to clarify in your mind is why an operating system would be a useful thing to have. Also, would there be multiple processes running, or only one. In the latter case you wouldn't need any kind of process management and I/o would be too system specific for it to be part of a generic OS.

That leaves memory management, and maybe a file system if flash memory is available. Other than that, there might be a rag Bach of utilities to save people writing them for themselves. Any way, once you have decided what your OS is going to do, you would need to decide what the data structures would have to look like to enable it to do it, and then write the code to maintain those data structures. In the case of a file system, how would you keep track of which parts of flash memory are available, which parts have been allocated, and how do you prevent it from becoming hopelessly fragmented. Similar questions would doubtless arise with a memory manager.

Another thing might be exception handlers, to handle the situation if some piece of hardware went wonky, but that also might be too system specific for a generic OS.

Thank your comment The reason why I want to write a RTOS kernel is when I was in OS class. The professor said that RTOS is so different than regular OS. And then I did some research about that. So I'm interested in that stuff. I think my RTOS should be based on tasks. Each task should have a priority. This RTOS kernel should solve the priority inversion situation.

The problem for me is I don't know if I need write some basic functions and then add other features. Or I need figure out any details of this kernel. I don't know the process of kernel development. So that is why I come here to ask you guys. But now, I think I may be implement some basic function first. Such as init() deinit() etc. And when I meet some new problems I can come here to ask your again.

Thanks your advices.

mathematician wrote:Well, whereas in a PC the distinction between the OS and applications is fairly clear cut, in the embedded world it seems to me somewhat less so.

So, I imagine that the first thing you would need to clarify in your mind is why an operating system would be a useful thing to have. Also, would there be multiple processes running, or only one. In the latter case you wouldn't need any kind of process management and I/o would be too system specific for it to be part of a generic OS.

That leaves memory management, and maybe a file system if flash memory is available. Other than that, there might be a rag Bach of utilities to save people writing them for themselves. Any way, once you have decided what your OS is going to do, you would need to decide what the data structures would have to look like to enable it to do it, and then write the code to maintain those data structures. In the case of a file system, how would you keep track of which parts of flash memory are available, which parts have been allocated, and how do you prevent it from becoming hopelessly fragmented. Similar questions would doubtless arise with a memory manager.

Another thing might be exception handlers, to handle the situation if some piece of hardware went wonky, but that also might be too system specific for a generic OS.

wzf1943 wrote:Thank your comment The reason why I want to write a RTOS kernel is when I was in OS class. The professor said that RTOS is so different than regular OS. And then I did some research about that. So I'm interested in that stuff. I think my RTOS should be based on tasks. Each task should have a priority. This RTOS kernel should solve the priority inversion situation.

The problem for me is I don't know if I need write some basic functions and then add other features. Or I need figure out any details of this kernel. I don't know the process of kernel development. So that is why I come here to ask you guys. But now, I think I may be implement some basic function first. Such as init() deinit() etc. And when I meet some new problems I can come here to ask your again.

Thanks your advices.

mathematician wrote:Well, whereas in a PC the distinction between the OS and applications is fairly clear cut, in the embedded world it seems to me somewhat less so.

So, I imagine that the first thing you would need to clarify in your mind is why an operating system would be a useful thing to have. Also, would there be multiple processes running, or only one. In the latter case you wouldn't need any kind of process management and I/o would be too system specific for it to be part of a generic OS.

That leaves memory management, and maybe a file system if flash memory is available. Other than that, there might be a rag Bach of utilities to save people writing them for themselves. Any way, once you have decided what your OS is going to do, you would need to decide what the data structures would have to look like to enable it to do it, and then write the code to maintain those data structures. In the case of a file system, how would you keep track of which parts of flash memory are available, which parts have been allocated, and how do you prevent it from becoming hopelessly fragmented. Similar questions would doubtless arise with a memory manager.

Another thing might be exception handlers, to handle the situation if some piece of hardware went wonky, but that also might be too system specific for a generic OS.

Well here's my two cents. Kernel development for me is the same as Os development. They are one in the same, however with that being said they are very different. When you write an Os you rely on a Kernel for a lot of hardware related tasks, in Kernel development your writing around hardware. The Os relies on the Kernel, the Kernel relies on pretty much only hardware. So they aren't really that much different if you think about it. Maybe I am explaining this wrong. But Kernel's are highly complex, however so can an Os.

Good luck with your project! - Matt

Thanks Matt
I know kernel is manage both hardware and software. And that is why kernel is that hard. For me, of course I wanna do a whole kernel by myself. But I don't have that much time now. What I'm doing now is building a tiny kernel. I don't know if I can finish. But I just hope I can learn some real stuff.
Thank your comment again!

PearOs wrote:

wzf1943 wrote:Thank your comment The reason why I want to write a RTOS kernel is when I was in OS class. The professor said that RTOS is so different than regular OS. And then I did some research about that. So I'm interested in that stuff. I think my RTOS should be based on tasks. Each task should have a priority. This RTOS kernel should solve the priority inversion situation.

The problem for me is I don't know if I need write some basic functions and then add other features. Or I need figure out any details of this kernel. I don't know the process of kernel development. So that is why I come here to ask you guys. But now, I think I may be implement some basic function first. Such as init() deinit() etc. And when I meet some new problems I can come here to ask your again.

Thanks your advices.

mathematician wrote:Well, whereas in a PC the distinction between the OS and applications is fairly clear cut, in the embedded world it seems to me somewhat less so.

So, I imagine that the first thing you would need to clarify in your mind is why an operating system would be a useful thing to have. Also, would there be multiple processes running, or only one. In the latter case you wouldn't need any kind of process management and I/o would be too system specific for it to be part of a generic OS.

That leaves memory management, and maybe a file system if flash memory is available. Other than that, there might be a rag Bach of utilities to save people writing them for themselves. Any way, once you have decided what your OS is going to do, you would need to decide what the data structures would have to look like to enable it to do it, and then write the code to maintain those data structures. In the case of a file system, how would you keep track of which parts of flash memory are available, which parts have been allocated, and how do you prevent it from becoming hopelessly fragmented. Similar questions would doubtless arise with a memory manager.

Another thing might be exception handlers, to handle the situation if some piece of hardware went wonky, but that also might be too system specific for a generic OS.

Well here's my two cents. Kernel development for me is the same as Os development. They are one in the same, however with that being said they are very different. When you write an Os you rely on a Kernel for a lot of hardware related tasks, in Kernel development your writing around hardware. The Os relies on the Kernel, the Kernel relies on pretty much only hardware. So they aren't really that much different if you think about it. Maybe I am explaining this wrong. But Kernel's are highly complex, however so can an Os.

Good luck with your project! - Matt

wzf1943, your very welcome. Starting off small is good. I have been working on my kernel "iPear" for about five years now. It's been a long self learning process, but I am finally achieving my goals. I write my code in my free time however, but my recommendation is. Start small, and keep it simple and work your way up to more complex area's. But what I found to work well it to tackle what needs to be implemented and the things that aren't insanely hard, get those working first and make sure they are flawless, then work your way up to something harder like Multitasking, or a USB driver for example. I don't really see Kernel development hard anymore since I'm so used to it and I when I think about it I cant even really imagine how I got this far but its fun and you'll learn a lot. Whether you write a Os, or a Kernel or both your going to learn a lot.

But keep in mind, Osdev is your friend! Don't spend countless days and days trying to solve something, spend maybe a day and then ask here, because some of these guys like Brenden or James Molly have some really good tips and ideas.

- Matt

Oh shoot, I just realized I've been spending the last five years writing a RTOS kernel...

A description of the design and implementation of a really simple hard real-time kernel can be found here:http://barrywatson.se/#articles
It's designed to be so simple anybody could pick it up, port it, and improve it.

The priority inversion problem is solved with the SRP algorithm for resource access, and you've also got non-blocking communication between jobs (processes/tasks). It implements either the deadline monotonic or earliest deadline first scheduling algorithms. It comes with all source code and a small bootstrap loader so you can boot it up on 32-bit PCs. If you don't want to install it on hardware then you can run it as a process in UNIX but obviously that's not very "hard real-time".

There is also a small book (circa 70 pages) that describes the implementation and how to perform feasibility analyses for the scheduling algorithms.

Hi wzf1943,

Don't do a RTOS.

These are specialized operating systems with a particular specialized purpose and considerable constraints. You have neither purpose or constraints here - simply a desire to learn and play with kernel development, which is more than sufficient reason to try osdev.

There's plenty of avenues for fun doing a `regular operating system', or just whatever you want. If you haven't already, check out the Bare Bones turorial. That gets you started with a very minimal example. Where you go from there is entirely up to you, you don't even need to have a goal. If you are more interested in process magament and scheduling than filesystems, you can simply focus on that. I respect the part where you set small, reasonable goals and meet those. I originally just wanted to be able to play Pong on my custom OS, with a basic VGA text mode driver and a keyboard driver. When I finished that goal, I just kept having fun and added Snake and Game of Life and things improve a few orders of magnitude from that.

Thanks PearOS I like your OS's name haha. It's geeks' humor. I definitely agree your opinion. What I'm doing now is build a framework first. This skeleton has no functions at fist. But it can transplant to a processor at least. Then I decided to implement scheduler that has one task and add multi tasks later etc. I think the most interesting prat of OS dev is you can learn many stuff. And that's is why it's so hard. I think this place is so friendly and professional

PearOs wrote:wzf1943, your very welcome. Starting off small is good. I have been working on my kernel "iPear" for about five years now. It's been a long self learning process, but I am finally achieving my goals. I write my code in my free time however, but my recommendation is. Start small, and keep it simple and work your way up to more complex area's. But what I found to work well it to tackle what needs to be implemented and the things that aren't insanely hard, get those working first and make sure they are flawless, then work your way up to something harder like Multitasking, or a USB driver for example. I don't really see Kernel development hard anymore since I'm so used to it and I when I think about it I cant even really imagine how I got this far but its fun and you'll learn a lot. Whether you write a Os, or a Kernel or both your going to learn a lot.

But keep in mind, Osdev is your friend! Don't spend countless days and days trying to solve something, spend maybe a day and then ask here, because some of these guys like Brenden or James Molly have some really good tips and ideas.

- Matt

Oh shoot, I just realized I've been spending the last five years writing a RTOS kernel...

Thanks bwat I'll read this book carefully. It must helps me a lot.

bwat wrote:A description of the design and implementation of a really simple hard real-time kernel can be found here:http://barrywatson.se/#articles
It's designed to be so simple anybody could pick it up, port it, and improve it.

The priority inversion problem is solved with the SRP algorithm for resource access, and you've also got non-blocking communication between jobs (processes/tasks). It implements either the deadline monotonic or earliest deadline first scheduling algorithms. It comes with all source code and a small bootstrap loader so you can boot it up on 32-bit PCs. If you don't want to install it on hardware then you can run it as a process in UNIX but obviously that's not very "hard real-time".

There is also a small book (circa 70 pages) that describes the implementation and how to perform feasibility analyses for the scheduling algorithms.

wzf1943 wrote:Thanks PearOS I like your OS's name haha. It's geeks' humor. I definitely agree your opinion. What I'm doing now is build a framework first. This skeleton has no functions at fist. But it can transplant to a processor at least. Then I decided to implement scheduler that has one task and add multi tasks later etc. I think the most interesting prat of OS dev is you can learn many stuff. And that's is why it's so hard. I think this place is so friendly and professional

PearOs wrote:wzf1943, your very welcome. Starting off small is good. I have been working on my kernel "iPear" for about five years now. It's been a long self learning process, but I am finally achieving my goals. I write my code in my free time however, but my recommendation is. Start small, and keep it simple and work your way up to more complex area's. But what I found to work well it to tackle what needs to be implemented and the things that aren't insanely hard, get those working first and make sure they are flawless, then work your way up to something harder like Multitasking, or a USB driver for example. I don't really see Kernel development hard anymore since I'm so used to it and I when I think about it I cant even really imagine how I got this far but its fun and you'll learn a lot. Whether you write a Os, or a Kernel or both your going to learn a lot.

But keep in mind, Osdev is your friend! Don't spend countless days and days trying to solve something, spend maybe a day and then ask here, because some of these guys like Brenden or James Molly have some really good tips and ideas.

- Matt

Oh shoot, I just realized I've been spending the last five years writing a RTOS kernel...

Anytime! I like the name too, though I sometimes feel like its more a Windows mock than an Apple one, as my Os runs some Windows programs now.... But either way I like the name so that's all that matters