+ Current
+Version 0.4.2
+-
+ Project on SourceForge
+ Documentation
+ Downloads Wiki Forum
+ Contact me
+-
+ History
+ Description Current ports
+ Design Performance and Size
+ Future
+-
+ Credits
+
+ ![SourceForge.net Logo](http://sflogo.sourceforge.net/sflogo.php?group_id=205897&type=4)
+
+ |
+
+ History
+This kernel is something I wrote back in 1990 for use on boards
+equipped
+with M68K processors, the development was made on an Atari ST. The OS
+worked well for its intended purpose, Internet was not
+widespread at that time so the system had a limited use.
+Recently I decided to release this system, formerly known as mkRTOS, as Free
+Software. I cleaned up the code, improved the documentation, made a
+port on a more modern architecture (ARM) and it is finally ready.
+While ChibiOS/RT is a new product it is based on a proven system so the
+alpha/beta phases should not last long, the project was started as an
+alpha
+version mainly to be able to incorporate the feedback into the
+product easily.
+ Description
+ChibiOS/RT is designed for embedded applications and it is meant to be
+linked with the application code. The design philosophy is to make it
+easy to use so I hope that all the APIs are meaningful, easy to
+understand and with the parameters you would expect from them. The
+system offers threads, semaphores, messages, events, virtual timers,
+queues, I/O channels with timeout capability and much more.
+ Current
+ports
+Currently the ChibiOS/RT is ported to the following architectures:
+
+ - ARM7TDMI-LPC214x, the port to other LPC2000 chips
+should be trivial, port to other ARM families should be easy too. Both
+ARM and THUMB modes are supported.
- Atmel AVR, the port is almost complete but untested because I broke my JTAG probe...
- x86 as a Win32 process, this port allows to write
+your application on the PC without the need of a development
+board/simulator/emulator. Communication ports are simulated over
+sockets, you can telnet on the simulator ports for the debug. I am
+considering to create a similar simulator into a Linux process.
+ - M68K, this was the original target but it is
+currently removed from the source tree because currently I have no way
+to test it, my old Atari ST is long dead. It should be very easy to
+revive the port to the M68K or Coldfire CPUs.
+
+In general the port is very easy on architectures that can handle well
+linked lists, the kernel is entirely reliant on lists so this
+is a
+very important efficiency factor. 16 and 32 bits architectures are
+always fine, 8 bit architectures should be evaluated case by case but
+are not ruled out, something like an H8 would not have problems. You
+could port it
+to a Z80/Z180 (I considered that too, and made tests using the SDCC
+compiler) but the
+resulting code is not much efficient because the instruction set is
+missing the indirect addressing for 16 bits values that is important
+for efficient linked lists traversal.
+ Design
+The system was designed to be stable and avoid trouble as much as
+possible so some rules were set:
+
+ - No arrays or tables, I don't like to have to
+configure limits
+for data structures, only use lists or other dynamic data structures.
+See
+the Documentation and
+the demos.
+ - No memory allocation inside the kernel, an allocator
+can be
+troublesome for RT applications. All the data structures are declared
+in the application code and not allocated from a shared system heap.
+This does not prevent the application code to use an allocator if
+needed, it is just the kernel that does not require it.
+ - No weird macros in the user code, everything should
+look
+and feel like normal C code with a normal main() function. I don't like
+to bring someone else weird programming habits in my code and I think
+this is true for everybody.
+ - Encapsulate all the things that need changes while
+porting
+the OS to new architectures in few template files, fill the code into
+the templates and the port is done.
Performance and SizeChibiOS/RT
+has a wide set of APIs but all the subsystems can be included or
+removed from the memory image by editing the kernel configuration file
+chconf.h. On ARM processors, the kernel size starts at just
+1.5KiB depending on the included subsystems and the choosen
+compiler optimizations. As reference, a kernel configured with...
- System startup code
- Chip initialization code
- Multithreading APIs
- Virtual Timer APIs
- Semaphore APIs
- System time + Sleep API
- Suspend/Resume APIs
- Small main() program with flashing LEDs demo and 3 threads
...just takes 2.11KiB of program space when compiled using THUMB code and space optimizations. Note that this is quite a typical configuration
+not a minimal one. A kernel configured with all the options and
+optimized for speed takes about 8KiB. See the documentation about the
+many available subsystems.
About performance, on a 48MHz LPC
+ARM7 processor the kernel is capable of context switch time ranging
+from 3 to 6 microseconds depending on the code type (ARM/THUMB) and the
+choosen complier/kernel optimizations. In the distribution is included
+a spreadsheet with the exact values and the various space/time trade
+offs. The context switch time is *measured* using 2 threads
+exchanging messages and doing *real* work, it is not a calculated peak
+value. See the demo code, it includes the benchmark.
+ Future
+Expect:
+
+ - Documentation improvements.
+
+ - Ports to more architectures/boards when I am able to
+put my hands on new hardware/tools.
+ - More demos.
+ - Creation of new subsystems.
+ - Integration with
+existing other free projects like: TCP/IP stacks, File Systems etc.
+
+ Credits
+ChibiOS/RT was created using:
+
+ |
+
+