+<h2 id="irc">IRC processing</h2>
+<p>
+The IRC signal processing is the most demanding part of our solution
+since the frequency of the IRC signal can go up to 21 kHz,
+when maximal voltage is applied to the motor. To achieve reasonable
+performance, a kernel driver has been implemented for this purpose.
+It uses four GPIO pins — two for each IRC channel.
+One of these two pins is configured to generate interrupts for
+rising edges and the other for falling edges. Motor position is
+derived from the order of interrupts and applications can read it via
+<tt>/dev/irc0</tt>.
+</p>
+<p>
+This solution has an interesting property that it works even when the
+processing of one (or few more) interrupt(s) is delayed due to other
+activities in the system. In preempt_rt, the interrupt handlers run
+in dedicated threads, which can be preempted by threads with higher
+priority. Thanks to the fact that the scheduler run queue is a FIFO
+queue, the IRQ threads are activated in the same order as the original
+interrupts and our position calculation works even in the case of
+a delay. The alternative approach, where the position is calculated from
+the actual IRC signal levels read in the interrupt handler would fail,
+because the level read in a delayed handler might be different from
+the level at the time when the corresponding IRQ was generated.
+</p>
+<p>
+Even better performance could be probably achieved by processing the
+IRC signals in ARM's fast interrupt requests (FIQ), but this solutions
+would not be portable to other architectures. Other option is to
+design more sophisticated hardware but minimal HW solution is
+excellent for teaching.
+</p>
+
+<h2 id="model">Simulink model</h2>
+<p>
+Simulink model of the motor controller is depicted in Figure.
+The
+<a href="https://github.com/ppisa/rpi-rt-control/blob/master/simulink/sfIRCInput.c" target="_blank"><em>IRC0</em></a>
+and
+<a href="https://github.com/ppisa/rpi-rt-control/blob/master/simulink/sfPWMwDir.c" target="_blank"><em>PWMwDir</em></a>
+blocks are so called C MEX S-functions. The former reads the motor position
+from <tt>/dev/irc0</tt>, the latter controls the PWM and DIR signals
+by directly accessing the GPIO registers via <tt>mmap()</tt>ed <tt>/dev/mem</tt>.
+The actual motor control is performed by a proportional-sum-derivative (PSD)
+controller enhanced with an anti-windup technique. Setpoint <em>w</em>
+is generated either manually or by a simple trajectory generator.
+Sampling period of the whole model was set to 1 ms. The source code
+of the S-functions as well as the model are available from
+<a href="https://github.com/ppisa/rpi-rt-control" target="_blank">Github</a> repository.
+</p>
+<p>
+The <em>ert_linux</em> target was configured to use an ARM C cross-compiler.
+The generated binary was copied to the target RPi board by the
+<tt>scp</tt> command and ran there. Simulink <em>external mode</em> was
+used to tune certain model parameters on-line as well as to see the
+actual signal values in the scope windows.
+</p>
+
+<h2 id="evaluation">Performance evaluation</h2>
+<p>
+The Linux kernel used for our experiments was the official
+Raspberry Pi rpi-3.12.y Linux kernel version 3.12.28 patched with Steven
+Rostedt's stable preempt_rt patch (patch-3.12.26-rt40) and with Junjiro R.
+Okajima's aufs3.12.x 20140512. The latencies measured by the <tt>cyclictest</tt>
+tool when the system was loaded by TCP communication and SD card accesses are as
+follows. The maximal latency was 170 μs, average about 40 μs. When
+graphical desktop was run the maximal latencies increased to 280 μs
+(probably caused by contention on the system bus generated by the
+VideoCore GPU). This observation is in same range as
+more serious examination and long term performance monitoring
+on better tuned RT-kernel kernel executed by
+<a href="https://www.osadl.org/" target="_blank">Open Source Automation Development Lab</a>
+and documented in their
+<a href="https://www.osadl.org/Profile-of-system-in-rack-7-slot-3.qa-profile-r7s3.0.html" target="_blank">Quality assurance Farm</a>.
+</p>
+<p>
+System load caused by running an unoptimized (soft-float only) model
+was about 2%. The USB connected Ethernet controller (a part of RPi) generated
+load of about 10%. The highest load was generated by the software IRC
+signal processing — up to 95%, i.e. the limit for RT tasks. This
+happened during fast motor rotation (e.g. when maximal input voltage
+was applied) and the interrupt frequency was 8 kHz per each channel
+(32 kHz in total). As can be seen, processing of the IRC signal at
+full speed (21 kHz) is above capabilities of the Linux kernel on this
+hardware. As mentioned above, the use of FIQ (or raw interrupts) could
+help here. For lower speeds, our simple solution works flawlessly and
+can be used as a great tool for control education and experiments.
+</p>
+
+<h2 id="links">Links</h2>
+<dl>
+ <dt>Bachelor thesis of Radek Mečiar: Motor control with Raspberry Pi board and Linux (Czech language only), 2014</dt>
+ <dd>Available <a href="https://support.dce.felk.cvut.cz/mediawiki/images/1/10/Bp_2014_meciar_radek.pdf" target="_blank">online in PDF format</a>
+ </dd>
+ <dt>Michal Sojka, Pavel Píša: Usable Simulink Embedded Coder Target for Linux at 16th Real Time Linux Workshop, 20+4</dt>
+ <dd><a href="https://www.osadl.org/?id=2018" target="_blank">Paper abstract</a> at <a href="https://www.osadl.org/RTLWS-2014.rtlws-2014.0.html" target="_blank">16th Real Time Linux Workshop</a> site.
+ </dd>
+ <dt>RPi RT Control Support</dt>
+ <dd><a href="https://github.com/ppisa/rpi-rt-control" target="_blank">https://github.com/ppisa/rpi-rt-control</a>
+ <br>GitHub Repository with RPi IRC kernel module and Simulink model and RPi blocks sources.
+ </dd>
+ <dt>Fully preemptive kernel sources for RPi (kernel-3.12.28-rt40+)</dt>
+ <dd><a href="https://github.com/ppisa/linux-rpi/tree/rpi-3.12.y-aufs-rt-ppisa" target="_blank">https://github.com/ppisa/linux-rpi</a>
+ <br>GitHub repository with branch rpi-3.12.y-aufs-rt-ppisa containing Linux kernel sources
+ with Steven Rostedt's stable preempt_rt (patch-3.12.26-rt40) and with Junjiro R. Okajima's aufs3.12.x 20140512
+ patches applied.
+ </dd>
+ <dt>Simulink Embedded Coder target for Linux</dt>
+ <dd><a href="http://rtime.felk.cvut.cz/gitweb/ert_linux.git" target="_blank">http://rtime.felk.cvut.cz/gitweb/ert_linux.git</a>
+ <br>Repository with core templates for Linux hosted, Linux cross architecture targetted
+ Simulink code generation templates and configuration.
+ </dd>
+ <dt>Auxiliary utilities for Raspberry Pi</dt>
+ <dd><a href="https://github.com/ppisa/rpi-utils" target="_blank">https://github.com/ppisa/rpi-utils</a>
+ <br>The repository includes RAM based root overlay support to protect SDcard against wearing and tearing
+ and keep root filesystem intact when experiments are download and run on system or even crash it.
+ </dd>
+</dl>
+