mirror of
https://salsa.debian.org/gnuk-team/gnuk/gnuk.git
synced 2024-09-21 19:30:08 +00:00
92 lines
5.1 KiB
HTML
92 lines
5.1 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
<html><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
|
||
|
<title>ChibiOS/RT: Designing an embedded application</title>
|
||
|
<link href="custom.css" rel="stylesheet" type="text/css">
|
||
|
<link href="tabs.css" rel="stylesheet" type="text/css">
|
||
|
</head><body>
|
||
|
<table style="text-align: center; width: 100%;" border="0"
|
||
|
cellpadding="2" cellspacing="2">
|
||
|
<tbody>
|
||
|
<tr>
|
||
|
<td style="width: 80px;"><img alt="ChibiOS/RT Logo" src="logo_small.png"></td>
|
||
|
<td><big><big>ChibiOS/RT</big></big><br><br>Architecture - Reference Manual - Guides</td>
|
||
|
<td style="width: 80px;"></td>
|
||
|
</tr>
|
||
|
</tbody>
|
||
|
</table>
|
||
|
<hr size="1">
|
||
|
<!-- Generated by Doxygen 1.6.3 -->
|
||
|
<div class="navigation" id="top">
|
||
|
<div class="tabs">
|
||
|
<ul>
|
||
|
<li><a href="main.html"><span>Main Page</span></a></li>
|
||
|
<li><a href="modules.html"><span>Modules</span></a></li>
|
||
|
<li><a href="annotated.html"><span>Data Structures</span></a></li>
|
||
|
<li><a href="files.html"><span>Files</span></a></li>
|
||
|
</ul>
|
||
|
</div>
|
||
|
<div class="navpath"><a class="el" href="main.html">ChibiOS/RT</a> » <a class="el" href="articles.html">Articles and Code Samples</a> » <a class="el" href="page__kb.html">Knowledge Base</a>
|
||
|
</div>
|
||
|
</div>
|
||
|
<div class="contents">
|
||
|
|
||
|
|
||
|
<h1><a class="anchor" id="article_design">Designing an embedded application </a></h1><p>ChibiOS/RT offers a variety of mechanisms and primitives, often it is better to focus on a single approach for the system design and use only part of the available subsystems.<br/>
|
||
|
When designing your application you may choose among several design alternatives:</p>
|
||
|
<ul>
|
||
|
<li><a class="el" href="article__design.html#nothreads">Single threaded superloop</a></li>
|
||
|
<li><a class="el" href="article__design.html#messpass">Message Passing</a></li>
|
||
|
<li><a class="el" href="article__design.html#thdshared">Threads sharing data</a></li>
|
||
|
<li><a class="el" href="article__design.html#thdmixed">Mixed</a></li>
|
||
|
</ul>
|
||
|
<h2><a class="anchor" id="nothreads">
|
||
|
Single threaded superloop</a></h2>
|
||
|
<p>Correct, single thread, it is not mandatory to use the multithreading features of the OS. You may choose to implements everything as a complex state machine handled in the main thread alone. In this scenario the OS still offers a variety of useful mechanisms:</p>
|
||
|
<ul>
|
||
|
<li>Interrupt handling.</li>
|
||
|
<li>Virtual Timers, very useful in state machines in order to handle time triggered state transitions.</li>
|
||
|
<li>Power management.</li>
|
||
|
<li>Event Flags and/or Semaphores as communication mechanism between interrupt handlers and the main.</li>
|
||
|
<li>I/O queues.</li>
|
||
|
<li>Memory allocation.</li>
|
||
|
<li>System time.</li>
|
||
|
</ul>
|
||
|
<p>In this configuration the kernel size is really minimal, everything else is disabled and takes no space. You always have the option to use more threads at a later time in order to perform separate tasks.</p>
|
||
|
<h2><a class="anchor" id="messpass">
|
||
|
Message Passing</a></h2>
|
||
|
<p>In this scenario there are multiple threads in the system that never share data, everything is done by exchanging messages. Each thread represents a service, the other threads can request the service by sending a message.<br/>
|
||
|
In this scenario the following subsystems can be used:</p>
|
||
|
<ul>
|
||
|
<li>Synchronous Messages.</li>
|
||
|
<li>Mailboxes (asynchronous message queues).</li>
|
||
|
</ul>
|
||
|
<p>The advantage of this approach is to not have to deal with mutual exclusion, each functionality is encapsulated into a server thread that sequentially serves all the requests. As example, you can have the following scenario:</p>
|
||
|
<ul>
|
||
|
<li>A buffers allocator server.</li>
|
||
|
<li>A disk driver server.</li>
|
||
|
<li>A file system server.</li>
|
||
|
<li>One or more client threads.</li>
|
||
|
</ul>
|
||
|
<p>Example: <br/>
|
||
|
<br/>
|
||
|
</p>
|
||
|
<div align="center">
|
||
|
<img src="inline_dotgraph_10.dot.png" alt="inline_dotgraph_10.dot" border="0" usemap="#inline_dotgraph_10.dot.map">
|
||
|
<map name="inline_dotgraph_10.dot.map" id="inline_dotgraph_10.dot.map"></map>
|
||
|
</div>
|
||
|
<p> <br/>
|
||
|
<br/>
|
||
|
Note that the threads should not exchange complex messages but just pointers to data structures in order to optimize the performance. Also note that a thread can be both client and server at the same time, the FS service in the previous scenario as example.</p>
|
||
|
<h2><a class="anchor" id="thdshared">
|
||
|
Threads sharing data</a></h2>
|
||
|
<p>This is the most common scenario, several threads have access to both their private data and shared data. Synchronization happens with one of the mechanisms described in the <a class="el" href="article__mutual__exclusion.html">Mutual Exclusion guide</a> article.<br/>
|
||
|
</p>
|
||
|
<h2><a class="anchor" id="thdmixed">
|
||
|
Mixed</a></h2>
|
||
|
<p>All the above approaches can be freely mixed in a single application but usually I prefer to choose a way and consistently design the system around it. The OS is a toolbox that offers a lot of tools but you don't have to use them all necessarily. </p>
|
||
|
</div>
|
||
|
<hr size="1"><address style="text-align: right;"><small>
|
||
|
Generated on Sun Jul 11 13:13:09 2010 for ChibiOS/RT by <a href="http://www.doxygen.org/index.html"><img src="doxygen.png" alt="doxygen" align="middle" border="0"></a> 1.6.3</small></address>
|
||
|
</body>
|
||
|
</html>
|