Jekyll2017-05-08T14:26:01+00:00https://avakar.github.io/avakar.github.ioMartin VejnárAtmel’s new USB XMEGA series2012-04-09T00:00:00+00:002012-04-09T00:00:00+00:00https://avakar.github.io/2012/04/09/atmels-new-usb-xmega-series<p>A package with Atmel’s <a href="http://www.atmel.com/devices/atxmega32a4u.aspx">atxmega32a4u</a> finally arrived on Thursday.
Although I’ve been waiting for the chip to become available for months,
I’ve only gotten to etch <a href="https://technika.junior.cz/trac/browser/demo_boards">a demo board</a> for it on Friday night
(what’s one to do on Friday night after all).</p>
<p>Anyway, I have a working board now, which I can easily program with
my <a href="http://shupito.net">Shupito programmer</a> (shameless plug). I also got to try out
a <a href="http://cz.farnell.com/jsp/search/productdetail.jsp?SKU=1568026">micro USB recepticle</a>.</p>
<p><img style="display: block; margin-left: auto; margin-right: auto" src="/images/IMG_20120409_111541.jpg" alt="atxmega32a4u demo board" width="320" height="240" /></p>
<p>A few interesting things popped out.</p>
<ul>
<li>From the programming perspective, the chip identifies itself with
the same signature as it’s cousin chip, atxmega32a4; in fact,
all atxmega32a chips identify themselves the same.</li>
<li>The micro USB connector was difficult to align. Then again, I was
probably doing it wrong – it’s an SMD component and I used tweezers
to hold it in place in the same way I would an SMD resistor. What I should
have done instead is to lay the connector on the board and use
the tweezers to carefully push it to alignment (like you would a TQFP).</li>
<li>I shouldn’t design boards in rush, I’ve completely missed
on the difference between the 5V on the USB bus and the 3.3V
maximum supply voltage of XMEGA. What a newbie mistake.
Fortunately, I realized it the next morning (well, noon,
you know, right after I woke up) before I plugged the cable in.
Cutting a trace on the board solved the problem; still, I have
to provide the supply voltage externally. There really should have been
an LDO to allows the board to be powerd from USB.</li>
<li>Trying to rotate a crimp socket on a standard (square) pinhead
to get a better contact is counter-productive. It turns out they lose
springiness very easily – to a point where you can pretty much throw
them away.</li>
<li>Putting a transparent coating on a board will prevent it from corroding.
Putting it on a pinhead will prevent electrical contact. Perhaps you can
mechanically scrape the coating off by rotating the socket?</li>
<li>Atmel provides <a href="http://www.atmel.com/Images/doc8429.pdf">a USB bootloader for XMEGA</a> with <a href="http://www.atmel.com/Images/AVR1916.zip">sources and
precompiled binaries</a>. I don’t think it was preprogrammed in the chip
though (I might have accidentally erased it, I’m not sure). You need
to download <a href="http://www.atmel.com/tools/FLIP.aspx">Atmel’s FLIP</a> software to get it running, or you can
<a href="www.atmel.com/Images/doc8457.pdf">write your own</a>.</li>
</ul>
<p>I’m thinking of implementing the FLIP protocol into
my <a href="https://technika.junior.cz/trac/wiki/avr232client">avr232client</a> or to <a href="http://tasssadar.github.com/Lorris/index.html">Lorris</a>, although neither is particularly
suited for raw USB connections.</p>
<p>I’d also like to try out the <a href="http://www.atmel.com/tools/AVRSOFTWAREFRAMEWORK.aspx">Atmel’s software framework</a>, especially
for the USB functionality (the download requires <a href="http://www.atmel.com/Images/asf-standalone-archive-3.0.1.zip">registration</a>).</p>
<p>Last but not least, I should finally port the rest of avr232client to Lorris,
but there are lots of details that need to be taken care of and I’m not sure
how much time it would take (also, it’s GPL and Qt, neighter of which
particularly motivates me).</p>Martin VejnárA package with Atmel’s atxmega32a4u finally arrived on Thursday. Although I’ve been waiting for the chip to become available for months, I’ve only gotten to etch a demo board for it on Friday night (what’s one to do on Friday night after all).Considerations for Short Distance UART Communication, Part 12011-09-19T00:00:00+00:002011-09-19T00:00:00+00:00https://avakar.github.io/2011/09/19/considerations-for-short-distance-uart-communication-part-1<p>Whenever a system consists of multiple processors, the typical question
that arises very early into the design process is that of their mutual
communication. I’ve been programming chips to communicate for years now
and went though quite a few communication protocols. Lately, I’ve been doing
a lot of thinking on communication protocol design and I’d like to share
my thoughts.</p>
<p>This is the first episode of what hopefully will become
a series of articles, in which I explain the resoning behind the protocols
that my friends and I use for communication between processors within
a single device. I’ll discuss the problems that we encountered on the way,
and how we solved them (or rather how I believe we should solve them).</p>
<p>I will make a big leap right away and state that robotics enthusiasts
put processors into their robots not because they need a lot of computing
power, but rather to control the robot’s peripherals (e.g. motors).
After all, if they needed to compute, they would just embed
a notebook into the robot. Who would want to to port their neural
networks to an embedded ARM?</p>
<p>I personally used to work with PICs and switched to AVRs shortly after.
These are 8-bit microcontrollers (MCUs) that require very few external
components to run, they are relatively cheap, and mostly they get the
job done effectively. They are, however, somewhat limited when it comes to
speed (typically around 10 to 20 MIPS) and memory (as low as 512 bytes).
The strength of these units is in the hardware peripherals they
usually come with: PWM channels, A/D converters, and—you guessed
it—communication interfaces.</p>
<p>While there are I2Cs, SPIs, CANs, USBs and other TLAs, the interface
that I believe is the most used is the UART. The advantages of
this interface are plenty.</p>
<ul>
<li>Almost every MCU has a hardware UART interface and the interface
is extremely simple to control from software (unlike I2C or,
perish the thought, USB).</li>
<li>Multiple UARTs can typically be found on an MCU (AVR XMEGA A has five),
unlike other types of interfaces (save maybe for SPI) of which
there usually is one, if any.</li>
<li>It can be connected to a PC via the RS232 port with only
a simple level adjustment (and there are dedicated chips for it,
notably MAX232).</li>
<li>There is an abundance of comm modules that can bridge UART
over to other kinds of channels, including USB, Bluetooth,
and ZigBee (making it extremely easy to communicate wirelessly).</li>
<li>You can bend UART to your needs. Turn it to a wired-AND bus
if you are limited in the number of wires, for example.</li>
</ul>
<p>Now before I continue, let me say that UART is not the best option
for long-distance communication. A while back, during the <a href="http://www.eurobot.cz/">Eurobot
Starter</a> competition, one of our teams controlled their robot
from a panel, that was connected using a 6 meter, 3 wire UART cable
(GND, TX, RX). It turned out to be a really bad idea, as the cross talk
between the wires was so strong that the two data stream simply corrupted
each other. (Actually, now that I think about it, there probably were
series resistors at the both ends of each wire to prevent an accidental
short. That certainly didn’t help either.)</p>
<p>In any case, UART is what we’ve been using forever now. I dare you to
show me a better (in terms of what I’ve written above) solution.
In the next episode, I will outline the usual requirements that
we have to put on comm protocols in embedded devices and discuss the
protocol that we’ve been using as a result of those requirements.</p>Martin VejnárWhenever a system consists of multiple processors, the typical question that arises very early into the design process is that of their mutual communication. I’ve been programming chips to communicate for years now and went though quite a few communication protocols. Lately, I’ve been doing a lot of thinking on communication protocol design and I’d like to share my thoughts.ATxmega Complete Pinouts2011-06-03T00:00:00+00:002011-06-03T00:00:00+00:00https://avakar.github.io/2011/06/03/atxmega-complete-pinouts<p>The ATxmega devices from Atmel do not have a complete pinout drawn in their datasheets. So here it is, at least for A4 and D4 devices.</p>
<div style="display: block; margin-left: auto; margin-right: auto">
<object data="/images/atxmega_a4.svg" type="image/svg+xml"></object>
<object data="/images/atxmega_d4.svg" type="image/svg+xml"></object>
</div>Martin VejnárThe ATxmega devices from Atmel do not have a complete pinout drawn in their datasheets. So here it is, at least for A4 and D4 devices.Creole Wiki Markup2010-06-26T00:00:00+00:002010-06-26T00:00:00+00:00https://avakar.github.io/2010/06/26/creole-wiki-markup<p>I’ve been using <a href="http://bitbucket.org">bitbucket</a> for some time now to host my <a href="http://bitbucket.org/avakar/hgdeps">hgdeps</a> Mercurial extension. I’ve never used any of the many features that bitbucket offers, including issue tracking and wiki hosting.</p>
<p>That changed today when I opened bitbucket and created a new repository, hoping to write down design notes regarding a software that I’m attempting to build. (I’ve made a simple “oscilloscope” – an analog converter that would sample a signal at 160kHz and send the samples through an Ethernet connection. I need a software to display and manipulate the trace. But I digress.)</p>
<p>The wiki engine on bitbucket uses <a href="http://www.wikicreole.org/wiki/Home">Creole</a> markup. Since I really hate how every wiki engine uses a different markup, I was quite pleased by the attempt at standardization, even if somewhat informal. My initial enthusiasm, however, quickly disappeared when I saw the results that the labor yielded.</p>
<p><em>Who in their right state of mind would use a double slash to indicate emphasis?</em> Actually, the so-called specification furthers its shameful act by making the double slash result in italics, thus dealing a hurtful blow to all of us that firmly believe in the semantic web. Please people, use <a href="http://en.wikipedia.org/wiki/Markdown">Markdown</a>.</p>Martin VejnárI’ve been using bitbucket for some time now to host my hgdeps Mercurial extension. I’ve never used any of the many features that bitbucket offers, including issue tracking and wiki hosting.Parameter Estimation by Model Checking for Biological Systems2010-05-20T00:00:00+00:002010-05-20T00:00:00+00:00https://avakar.github.io/2010/05/20/parameter-estimation-model-checking-biological-systems<p>During the last two semesters, I’ve been working as a member of the laboratory of systems biology on methods for estimation of parameters of biological systems. A paper is currently being written, which will hopefully appear on International Workshop on High Performance Computational Systems Biology (HiBi 2010). Though there still is work to be done, I’d like to summarize the results here in hopes that this text may also serve as a final report for the class “PA183 – Project in Systems Biology”.</p>
<h2 id="introduction">Introduction</h2>
<p>The behavior of biological systems can be described in a multitude of ways. One of the common methods – one that the rest of this article will assume – is the explicit description by a system of ordinary differential equations.</p>
<p>The state of a system is a vector of substance concentrations $\mathbf x = (x_1, x_2, \dotsc, x_n)$. For each substance there is a differential equation of the form $\dot{x_i} = f_i(\mathbf x)$. Note that we assume piecewise multi-affine systems with ramps only, i.e. $f_i(\mathbf x)$ is a sum of products of atoms, where an atom is either</p>
<ul>
<li>a constant $\kappa$,</li>
<li>the concentration of one of the substances $x_j$, or</li>
<li>a ramp function $r^+(x_j, \theta^1, \theta^2)$ or $r^-(x_j, \theta^1, \theta^2)$, as described on the <a href="http://iasi.bu.edu/~batt/rovergene/rovergene.htm">RoVerGeNe homepage</a>.</li>
</ul>
<p>An example of such model would be the following two-gene interaction also taken from the <a href="http://iasi.bu.edu/~batt/rovergene/rovergene.htm">RoVerGeNe homepage</a>.</p>
<script type="math/tex; mode=display">\dot{x_a} = \kappa_a r^-(x_b, \theta^1_b, \theta^2_b)r^-(x_a, \theta^3_a, \theta^4_a) - \gamma_a x_a,\\
\dot{x_b} = \kappa_b r^-(x_a, \theta^1_a, \theta^2_a) - \gamma_b x_b.</script>
<p>Note, that the system’s evolution is deterministic, i.e. given an initial state, there is a single unique curve in the state space of the system that describes system’s evolution in time.</p>
<p>Typically, the degradation coefficients $\gamma$ can be easily measured, as they represent the tendency of a substance to dissolve. On the other hand, the kinetic coefficients $\kappa$ are difficult to measure directly.</p>
<h2 id="parameter-estimation">Parameter estimation</h2>
<p>Instead of trying to measure the parameters directly (which as we noted may be hard), we try to estimate their value by observing the overall system behavior.</p>
<p>There are various numerical methods for determining the best parameter given a run (i.e. a sequence of snapshots of states) of the real system. For example, we could</p>
<ol>
<li>sample the parameter space,</li>
<li>run a numerical simulation for each sampled parameter value,</li>
<li>compute the distance between the simulated runs and the real run, and</li>
<li>choose the parameter value for which the simulated run is closest to the real one.</li>
</ol>
<p>Note that the distance between a simulation and a reality is a simple example of a badness function, which can be used as an input to one of the many known global minimization algorithms.</p>
<p>Our approach to parameter estimation is slightly different in that no numerical simulations are performed. Instead, the system’s behavior is described by an LTL formula, while the model of the system is abstracted to obtain its finite representation as described by Batt et al.<sup id="fnref:1"><a href="#fn:1" class="footnote">1</a></sup> Our method of parameter estimation, however, fundamentally differs from Batt’s.</p>
<h2 id="problem-reduction">Problem reduction</h2>
<p>The abstraction as described in the previous paragraph yields a structure that we call a <em>parametrized <a href="http://en.wikipedia.org/wiki/Kripke_structure">Kripke structure</a></em>. It is a graph in which verteces represent sets of states of the original system. There is an edge between two verteces if there is a run in the real system from one of the states of the source vertex to one of the states of the target vertex. (The edge existence can be determined quite efficiently.) Each edge is labeled by the set of parameter values for which it is enabled. The states are labeled by the set of atomic propositions that are satisfied for all states of the vertex.</p>
<p>Note that while all runs of the original system have a corresponding run in the abstraction, there will be additional spurious runs in the abstraction. These spurious runs may reduce the domain of parameters for which a formula is satisfied.</p>
<p>In classical LTL model checking of (non-parametrized) Kripke structures, the LTL formula is converted to a <a href="http://en.wikipedia.org/wiki/B%C3%BCchi_automaton">Buchi automaton</a> the accepting runs of which are exactly those that violate the formula. A synchronous product of the Kripke structure and the aforementioned automaton is computed; fair runs of the resulting fair parametrized Kripke structure are exactly those runs of the original structure that violate the formula.</p>
<p>The original problem is therefore reduced to the problem of determining the set of parameters for which there is no fair run in a fair parametrized Kripke structure.</p>
<h2 id="parametrized-model-checking">Parametrized model checking</h2>
<p>We define a <em>parametrized (fair) Kripe structure</em> to be a tuple $\mathcal M = (\mathcal P, S, I, F, \to, L)$, where $\mathcal P$ denotes the (possibly infinite) set of parameters, $S$ denotes the finite set of states (or vertices), $I\subseteq S$ the set of initial states, $F\subseteq S$ the set of fair states, $L\colon S\to 2^\Pi$ the labeling of states by atomic propositions (i.e. the interpretation), and $\to\subseteq S\times\mathcal P\times S$ a transition relation labeled by parameters.</p>
<p>A fair $p$-run of $\mathcal M$ is an infinite run of $p$-labeled transitions which passes through a fair state infinitely often. Our goal is to find the maximal set $P\subseteq\mathcal P$ such that there is no $p$-run for any $p\in{P}$. Similarly, we define a $p$-path and a $p$-loop.</p>
<p>If there is to be a fair $p$-run in the structure, there must be a fair state $v$, reachable from an initial state via a $p$-path and there must be a $p$-loop on $v$ consisting of at least one transition. Therefore we compute the result in two nested propagation steps.</p>
<p>A propagation will – given the set of source vertices – determine for each vertex the set of parameters $P$ such, that there is a non-trivial $p$-path from a source vertex for all $p\in P$. The final algorithm will then</p>
<ol>
<li>propagate the parameter domain from initial vertices, computing the set $P_v$ of parameters for which the vertex $v$ is reachable, and</li>
<li>for each fair vertex $v$, propagate $P_v$ from $v$. The parameter set that reaches $v$ is certainly a set of parameters for which there is a fair run.</li>
</ol>
<p>The algorithm basically performs breath-first passes through the structure and can therefore be easily parallelized.</p>
<h2 id="implementation">Implementation</h2>
<p>The above algorithm is implemented – as a part of the project – in the <a href="http://ratatanek.cz/hg/pepmc">PEPMC</a> tool. The tool expects the specification of the system and of the Buchi automaton on standard input. Examples of these specifications are stored as .bio files in the package.</p>
<p>The syntax of the .bio files is not fixed, but it is in my opinion self-explanatory (given that you’ve read and understood this article). Following is a sample run of the program.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>$ ./pmc -j 2 < cycle8.bio
0/0: 0ms
1/19683: 8650ms
2/19683: 0ms
((0, 0, 0, 0, 0, 0, 0, 0, 1), 2)<-((0, 1, 0, 0, 0, 0, 0, 0, 1), 2)
((0, 1, 0, 0, 0, 0, 0, 0, 1), 2)<-((0, 1, 0, 0, 0, 0, 1, 0, 1), 2)
((0, 1, 0, 0, 0, 0, 1, 0, 1), 2)<-((0, 1, 1, 0, 0, 0, 1, 0, 1), 1)
((0, 1, 1, 0, 0, 0, 1, 0, 1), 1)<-((0, 0, 1, 0, 0, 0, 1, 0, 1), 1)
((0, 0, 1, 0, 0, 0, 1, 0, 1), 1)<-((0, 0, 1, 0, 0, 1, 1, 0, 1), 1)
((0, 0, 1, 0, 0, 1, 1, 0, 1), 1)<-((0, 0, 1, 1, 0, 1, 1, 0, 1), 1)
((0, 0, 1, 1, 0, 1, 1, 0, 1), 1)<-((0, 0, 0, 1, 0, 1, 1, 0, 1), 1)
((0, 0, 0, 1, 0, 1, 1, 0, 1), 1)<-((0, 0, 0, 1, 1, 1, 1, 0, 1), 1)
((0, 0, 0, 1, 1, 1, 1, 0, 1), 1)<-((0, 0, 0, 0, 1, 1, 1, 0, 1), 1)
((0, 0, 0, 0, 1, 1, 1, 0, 1), 1)<-((0, 0, 0, 0, 0, 1, 1, 0, 1), 1)
((0, 0, 0, 0, 0, 1, 1, 0, 1), 1)<-((0, 0, 0, 0, 0, 0, 1, 0, 1), 1)
((0, 0, 0, 0, 0, 0, 1, 0, 1), 1)<-((0, 0, 0, 0, 0, 0, 1, 1, 1), 1)
((0, 0, 0, 0, 0, 0, 1, 1, 1), 1)<-((0, 0, 0, 0, 0, 0, 0, 1, 1), 1)
((0, 0, 0, 0, 0, 0, 0, 1, 1), 1)<-((0, 0, 0, 0, 0, 0, 0, 0, 1), 2)
[(0.1, 1.1), ((0, 1, 0, 0, 0, 0, 0, 0, 1), 2)]
</code></pre>
</div>
<p>The <code class="highlighter-rouge">-j 2</code> parameter specifies that the algorithm should run in two threads. The system in <code class="highlighter-rouge">cycle8.bio</code> contains 19683 reachable fair states (this is the system after the synchronous product is applied). The initial propagation took 8.7 seconds. The algorithm stopped after propagating from the second fair state, since all parameters were found to be violating. The last line of the output confirms this – all parameters values in range <code class="highlighter-rouge">[0.1, 1.1]</code> result in a system violating the formula; the state <code class="highlighter-rouge">((0, 1, 0, 0, 0, 0, 0, 0, 1), 2)</code> (this is the state number after discretization and synchronous product) is part of the cycle that proves it. The tool outputs the fair cycles as it finds them – you can use them to debug your system.</p>
<h2 id="conclusion">Conclusion</h2>
<p>The goals of the project – develop a tool for parameter estimation – have been met. However, the Batt’s abstraction appears to be very weak. The larger the system is, the more difficult it becomes to ignore the effect of spurious cycles.</p>
<p>Methods of spurious cycle elimination are currently being developed by other members of sybila laboratory. With these methods, PEPMC may in time become of practical use.</p>
<div class="footnotes">
<ol>
<li id="fn:1">
<p>G. Batt, C. Belta and R. Weiss. <a href="http://iasi.bu.edu/~batt/publications/batt_et_al_hscc07.pdf">Model checking genetic regulatory networks with parameter uncertainty</a>, 2006, HSCC’07. <a href="#fnref:1" class="reversefootnote">↩</a></p>
</li>
</ol>
</div>Martin VejnárDuring the last two semesters, I’ve been working as a member of the laboratory of systems biology on methods for estimation of parameters of biological systems. A paper is currently being written, which will hopefully appear on International Workshop on High Performance Computational Systems Biology (HiBi 2010). Though there still is work to be done, I’d like to summarize the results here in hopes that this text may also serve as a final report for the class “PA183 – Project in Systems Biology”.The Hardships of C++ GUI Development2010-05-19T00:00:00+00:002010-05-19T00:00:00+00:00https://avakar.github.io/2010/05/19/hardships-c-gui-development<p>This post was intended to be about the development of GUI applications with C++, but if you read forward, you’ll soon realize that it became more of rant, a monument to my frustration with existing C++ GUI toolkits (sometimes referred to as widget toolkits. Applying a bit of a self-censorship, I’ve managed to tune down the tone of the article a bit, though I had to remove a lot of “craps” from the text in the process.</p>
<p>First question to answer is why would one even want to use a GUI toolkit. As far as I’m concerned, the answer is portability – I work on both Windows and Linux systems and I want my applications to work on both. The standard C++ library provides no support for GUI development, which is actually fine with me, as I believe that such a complex functionality should not be part of any standard library. (Java, I’m looking at you. The quality of your GUIs is pathetic.) On the other hand, a good place where I would expect a GUI toolkit to appear is Boost. Unfortunately, there is no Boost.Gui at the moment and there won’t be one in the foreseeable future.</p>
<p>I’ve browsed through several <a href="http://en.wikipedia.org/wiki/List_of_widget_toolkits">publicly available libraries</a> to find one that would suit my needs. I was aware of the fact that the process would likely take a long time as the libraries are no doubt large and complicated and to evaluate their pros and cons I would have to spend a considerable amount of time on each one. My fears were further intensified by the fact that I’m not an expert in GUI development. I currently don’t do GUIs at work, and in the past I’ve only worked with an in-house GUI toolkit (we worked on a finger-touch-enabled application for Windows CE 3.0, where custom-drawn controls are more-less a must).</p>
<p>Surprisingly, the task of evaluating a GUI library is not daunting at all, even for a person with limited GUI experience. With common sense and healthy appreciation for C++, I discarded half of the listed toolkits in the very first pass, just by looking at the hello-world program on their respective home pages.</p>
<p>The problem with these toolkits in general is that while they tout themselves as being C++ libraries, their design is often not idiomatic – the language the libraries are written in could be more accurately described as “C with classes” rather than C++. Even worse are those libraries that are extremely large and framework-like, which tend to reinvent the wheel and in my opinion often end up with a square one.</p>
<p>Eventually, I was forced to declare a defeat. There seems to be no library which would satisfy all of my requirements. I’ve picked some of the libraries – those that I consider to be popular since I’ve heard of them before – and I’ll try to explain the reasons for which I consider that particular library is unsuitable.</p>
<ul>
<li><a href="http://www.gtk.org/">GTK+</a> is a C toolkit based on glib, which is a library built probably to convince C developers that it is time to switch to C++ (doing object orientation in C, though technically possible, is unnecessarily verbose, and would make a C++ developer slightly nauseous). The C developers didn’t quite get the message. Not only they happily use the library, they even base popular widget toolkits off of it. The only reason I’m including GTK+ in this list is that there are C++ bindings to it. However good the binding are though, GTK+ is a toolkit that was originally designed to work over X server and DirectFB. As a result, it paints its own controls, and those paintable rectangles of screen are the point of abstraction. Unfortunately the abstraction is set too low for Windows, as Windows offers a standard set of controls. Moreover, the design of the GTK+ main program loop, while very flexible, is completely incompatible with Windows. This is why you rarely see a Windows common dialog in GTK applications – you have to run the dialog from a separate thread and it is not exactly easy to get right.</li>
<li><a href="http://qt.nokia.com/">Qt</a> seems to work well on Windows, which is a good sign for a framework originally designed for Linux. I have two problems with it though. First, it implements its own containers (STL containers are apparently not good enough). As if that were not enough, it requires you to run the so-called MOC preprocessor on your source files before you can pass them to a C++ compiler. Note, that the preprocessor is there only to add glue for Qt’s signal/slot mechanism, a task completely unnecessary in modern C++. If Boost can do signals within the boundaries of C++, so could Qt.</li>
<li><a href="http://www.ultimatepp.org/">Ultimate++</a> is a framework (which as I explained is bad) and furthermore it is the ultimate (pardon the pun) example of how you definitely don’t want to design your containers.</li>
<li>I didn’t even want to include <a href="http://www.wxwidgets.org/">wxWidgets</a>, which, while being a popular and multiplatform framework for some reason, has managed to copy the absolutely worst qualities of ATL/WTL, requiring event maps (macros!) and other stuff which one would have hoped is now a distant and forgotten past.</li>
</ul>
<p>What I’ve done some years ago is that I’ve built <a href="http://ratatanek.cz/hg/gui">my own GUI library</a>. This is how you would use it.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>int main()
{
gui::context ctx;
gui::window wnd(ctx);
wnd.caption("title");
wnd.resizable(true);
wnd.on_close(boost::bind(&gui::context::stop, &ctx, 0));
wnd.on_resize(/*...*/);
gui::button btn(wnd);
// You'd probably do this in window's on_resize handler
btn.position(10, 10, 100, 100);
btn.text("click me");
btn.show();
wnd.show();
return ctx.run();
}
</code></pre>
</div>
<p>The code above is what I would call idiomatic; there are no macros, no unnecessary dynamic allocations, and as a bonus there are no zombie states for objects. Also note that I’m passing plain char strings, which are assumed to be utf-8 encoded.</p>
<p>The library is used in the client application for my <a href="http://technika.junior.cz/~avakar/avr232boot">tiny AVR bootloader</a>. I maintained the application for quite some time (not anymore though, not since I moved to Linux) and thus had a chance to evaluate the design of my library. I was happy with it at first of course, only with time I’ve been able to observe some disadvantages as well.</p>
<ul>
<li>It is annoying having to attach an on_close handler to windows just to stop the main loop from executing.</li>
<li>It is also annoying having to pass the parent window to every control you instantiate. It may not seem to be such a big deal in the program above, but once you make your main window into a class, you’ll find out that you have to mention every one control in your constructor’s initializer list; that is a lot of typing even when you have only one constructor.</li>
<li>You position your controls into a fixed layout, which – while typical on Windows platforms – is not recommended by GTK+ since it is difficult to get right with varying DPI and font sizes. I think it would be better to introduce an extensible mechanism for control positioning. The controls should be positioned automatically; having to write on_resize handler is a chore.</li>
<li>I’ve only implemented the toolkit for Windows, assuring myself that I can port it to Linux when necessary. Too late I’ve realized I was wrong and the port will never happen – partly due to control positioning, partly due to wrong design decisions regarding paintbox control.</li>
</ul>
<p>As my responsibilities allow, I will try to work on <a href="http://ratatanek.cz/hg/ggui">a new toolkit</a>, which for the lack of imagination on my part ended up being called “ggui”. There are some very early sketches (this time compilable on both Linux and Windows alike) in the repository, but the library is not very useful at the moment. I’ll surely blog about ggui in later posts as I think it would be beneficial to lay out the design there so as to have a reference for further development.</p>Martin VejnárThis post was intended to be about the development of GUI applications with C++, but if you read forward, you’ll soon realize that it became more of rant, a monument to my frustration with existing C++ GUI toolkits (sometimes referred to as widget toolkits. Applying a bit of a self-censorship, I’ve managed to tune down the tone of the article a bit, though I had to remove a lot of “craps” from the text in the process.Compact System Monitor Applet for Gnome2010-05-08T00:00:00+00:002010-05-08T00:00:00+00:00https://avakar.github.io/2010/05/08/compact-system-monitor-applet-gnome<p>I’ve written a super-simple panel applet for Gnome which displays current CPU load and memory consumption. The applet is supposed to be a space-conserving replacement of the default (and ugly) system monitor applet shipped with Ubuntu. Take a look at the picture of the new applet in action.</p>
<p><img src="/images/compact-sysmon-screenshot-highlight.png" alt="Compact System Monitor Appliet for Gnome" /></p>
<p>Now compare the above applet with the default one.</p>
<p><img src="/images/default-sysmon-screenshot-highlight.png" alt="Default System Monitor Appliet for Gnome" /></p>
<p>I’ve highlighted both applets so that they’re easier to spot. Notice the compactness of the new applet: it takes less than the third of the space the old applet took, while it still displays all the information I need: the CPU load per processor (the outer circle) and memory consumption (the inner one). There are actually two arcs in the inner circle, though unfortunately the separation space is only barely visible. The bars show the amount of physical memory used by applications and the physical memory dedicated to the cache.</p>
<p>The look and feel of the applet is currently hard-coded (notably the colors of arcs are set to white) so that they would match the color scheme used by the default theme of Ubuntu 10.04. It also fails to properly render its background, so it only works correctly for default panel sizes. I’ll fix these problems when I have more time. In the mean time, if you like the applet and can live with the limitations, feel free to download and use it.</p>
<p>Get the <a href="http://ratatanek.cz/hg/gnome-compact-sysmon-applet/">sources from the repository</a>. Note that on Ubuntu, you’ll need libpanel-applet2-dev to build the applet.</p>Martin VejnárI’ve written a super-simple panel applet for Gnome which displays current CPU load and memory consumption. The applet is supposed to be a space-conserving replacement of the default (and ugly) system monitor applet shipped with Ubuntu. Take a look at the picture of the new applet in action.The Remnants of an Old Friend2010-01-27T00:00:00+00:002010-01-27T00:00:00+00:00https://avakar.github.io/2010/01/27/remnants-old-friend<p>Few days ago a friend of mine, while tidying up our workroom, found remnants of a robot – Aya – which we built about 5 years ago for the <a href="http://www.eurobot.org/eng/">Eurobot challenge</a>. Ah, the memories. Back then we used Microchip’s PIC processors, specifically we were fond of PIC16F627A. It was very cheap and the aforementioned friend had had some experience with them.</p>
<p>We spent weeks fiddling with the PIC assembly, trying to get the robot to work. (There were no free C compilers available for the platform. There were free AVR compilers though. We definitely should have gone with AVRs.) Unfortunately, we didn’t get the robot working in time for the national competition.</p>
<p>The next year we started from scratch. To simplify debugging (and secondarily to make the robot easily reconfigurable), we didn’t build everything into a single processor. Instead we built several modules, each with a single well-defined purpose. This way, we could develop and test each functionality separately.</p>
<p>Although it was a great idea, the modules would need to communicate, but the basic PIC processors lacked the support for the I2C bus. They only featured the plain old USART peripheral – great for communication with a PC, but unsuitable for multi-point communication. Eventually, we ended up connecting the USART’s TX pin through a diode to a common wire, which was pulled up by a resistor. (This is basically how I2C is implemented, but of course I didn’t know that back then. I thought I was so smart, until I found out that this ingenious technique is actually used all the time.)</p>
<p>Skip a few months of programming (in assembly, of course) and you get to the point where we already had what I passionately named Aya-bus: a fully featured implementation of a communication bus based on a USART peripheral. And when I say fully featured, I mean it. I could enumerate the devices connected to the bus, I could even hot-plug new devices into a running system.</p>
<p>(To be perfectly honest, the implementation was quite buggy. It was no easy task to debug an embedded concurrent system written in assembly. I eventually maneuvered around the problems by making the bus self-repairing – the bus-master would monitor the bus and clear it in case of an error. It also generated a token if it got lost. The hot-plugging ability was a mere consequence of these “fixes”, as the bus would simply regenerate after the module was plugged in.)</p>
<p><img src="/images/P1000447.JPG" alt="main board" /></p>
<p>The picture above is the robot’s main board. You can see the two optical switches with which we used to measure the speeds of the motors. Each motor had its own processor that would measure the speed and transmit that information to the master. There are two chips missing on the board, I’m guessing the left one was a Schmitt trigger and the other was a processor that generated the control signal for servos (and motors, which were controlled by a BLDC regulator). To keep it precise, the signal was generated by a PWM peripheral and demultiplexed by the 74HCT238 chip visible at the top.</p>
<p>The chip to the right named “Rickie” was the bus-master and communicated with the computer through the barely visible MAX232-like chip at the bottom.</p>
<p><img src="/images/P1000449.JPG" alt="color sensor" /></p>
<p>There were two peripherals remotely connected to the Aya-bus: several switches – a start button and an array of switches that formed a bumper – and the device photographed above: a color sensor. (You should know that the table on which the robots competed had a chessboard pattern of yellow and brown colors with special areas painted differently. We used the color of the ground beneath for localization.)</p>
<p>The device has a photo-diode in the center. The diode was quite expensive, it is very precise and has color characteristics matching those of a human eye. Around the diode there are four pairs of LEDs, red, green, blue and ultraviolet. To determine the color of the ground, each pair of LEDs was lit and the intensity of the reflected light was measured. The ambient light was measured as well and subtracted from the color channels.</p>
<p>We ended up twelfth out of some fifty teams at the international championship in Switzerland. We had a lot of fun and I’ve learned things about programming and design I will never forget. Thank you, Aya, rest in peace.</p>Martin VejnárFew days ago a friend of mine, while tidying up our workroom, found remnants of a robot – Aya – which we built about 5 years ago for the Eurobot challenge. Ah, the memories. Back then we used Microchip’s PIC processors, specifically we were fond of PIC16F627A. It was very cheap and the aforementioned friend had had some experience with them.ZigBit ATZB-24-A2 Pinout2010-01-24T00:00:00+00:002010-01-24T00:00:00+00:00https://avakar.github.io/2010/01/24/zigbit-atzb-24-a2-pinout<p>I’ve spent the last Friday afternoon trying to get my radio controlled airplane talking to my transmitter via a ZigBee link. I’ve deemed the traditional RF connection utterly useless as I’m getting rather severe glitches as close as 15 meters away (maybe I shouldn’t have tinkered with the receiver, who knows).</p>
<p>My friend and I bought four ZigBit modules a few months ago, but I didn’t find the time to work on them until last week. The BitCloud stack provided in the SDK is surely impressive, though unsuitable for real-time control. I basically want an isochronous transfer, so I had to build the software from scratch.</p>
<p>There are two important chips inside the module, atmega1281 processor and at86rf230 ZigBit tranceiver. There is unfortunately no documentation from Atmel about how the chips are interconnected or how the module’s pads map to the processor’s pins, so I’ve had to map the pinout myself. Here it is.</p>
<p><img src="/images/zigbit_mcu_pinout_mapping_0.svg" alt="ZigBit ATZB-24-A2 Pinout" /></p>
<p>Most of the pins are either supply pins or are directly connected to the embedded atmega1281 processor. There are two notable exceptions.</p>
<ul>
<li>The RF_CLKM pin is connected to the CLKM pin of the transceiver and outputs 1MHz clock by default. It is possible to disable it or to reprogram it to output either 2, 4, or 8MHz.</li>
<li>The OSC32K is connected to the output of a 32.786kHz oscillator and is also internally connected to the processor’s TOSC1 pin (and can therefore serve as a clock source for the 8-bit asynchronous timer).</li>
</ul>
<h2 id="internal-connections">Internal connections</h2>
<p>I couldn’t map the connection between the processor and the transceiver directly, but some mapping is obvious (they communicate through the SPI lines, which means that MISO, MOSI and SCK are connected) and I’ve extracted the rest from the BitCloud sources.</p>
<table>
<thead>
<tr>
<th>atmega1281</th>
<th>at86rf230</th>
</tr>
</thead>
<tbody>
<tr>
<td>PB0</td>
<td>CS</td>
</tr>
<tr>
<td>PB1/SCK</td>
<td>SCK</td>
</tr>
<tr>
<td>PB2/MOSI</td>
<td>MOSI</td>
</tr>
<tr>
<td>PB3/MISO</td>
<td>MISO</td>
</tr>
<tr>
<td>PB4</td>
<td>SLP_TR</td>
</tr>
<tr>
<td>PA7</td>
<td>~RST</td>
</tr>
<tr>
<td>PE5/INT5</td>
<td>IRQ</td>
</tr>
</tbody>
</table>
<h2 id="in-system-programming">In-system programming</h2>
<p>As you might have noticed, the in-system programming interface (SCK, PDO, PDI, RESET) is accessible from outside. According to one of the readers (thank you, Joerg Wunsch!) the chip can indeed be programmed using the normal in-circuit programmer, so if you own one, give it a go!</p>Martin VejnárI’ve spent the last Friday afternoon trying to get my radio controlled airplane talking to my transmitter via a ZigBee link. I’ve deemed the traditional RF connection utterly useless as I’m getting rather severe glitches as close as 15 meters away (maybe I shouldn’t have tinkered with the receiver, who knows).ZigBit Bootloader2010-01-21T00:00:00+00:002010-01-21T00:00:00+00:00https://avakar.github.io/2010/01/21/zigbit-bootloader<p>I was playing with Atmel’s ZigBit ATZB-24-A2 over the last few days and wrote a command-line utility that runs on both Windows and Linux and can be used to flash programs into these modules (assuming that they have the original bootloader installed). Atmel distributes their own bootloader client as part of the BitCloud SDK, but the command-line version didn’t work for me at all and the GUI version was very unreliable.</p>
<p>The program accepts two parameters, the name of the serial port and the path to the .srec file containing the program and eeprom values to be flashed.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>zigbit_bootloader <serial-port> <srec-file-path>
</code></pre>
</div>
<p>You can pass any file as a serial port, as long as it supports your platform’s comm API (<code class="highlighter-rouge">SetCommParameters</code> and <code class="highlighter-rouge">SetCommTimeouts</code> on Windows, <code class="highlighter-rouge">tcsetattr</code> et al. on Unix). Example paths: <code class="highlighter-rouge">COM1</code> (Windows), <code class="highlighter-rouge">\\.\COM25</code> (Windows), <code class="highlighter-rouge">/dev/ttyS1</code> (Unix), <code class="highlighter-rouge">/dev/rfcomm0</code> (Unix).</p>
<p>The second parameter names a <a href="http://en.wikipedia.org/wiki/SREC_%28file_format%29">SREC file</a>. You can convert Intel’s HEX file to SREC using <code class="highlighter-rouge">objcopy</code>. Be sure to use <code class="highlighter-rouge">--srec-len=128</code> (128 is the size of a program memory page on atmega1281). Note that the program performs no integrity checking on the SREC file, make sure that the file is complete and unchanged before starting the flash procedure.</p>
<p>You must restart the device after starting this flash utility. The bootloader in the device is only active for the first 500 milliseconds. Unless activated within that time period, the control is transferred to the main program.</p>
<h2 id="the-protocol">The protocol</h2>
<p>The protocol that the Atmel’s bootloader is documented in the SDK, but beware that the documentation is very much wrong. The good news is that the sequences listed in the document are correct:</p>
<div class="highlighter-rouge"><pre class="highlight"><code>HANDSHAKE_REQ: 0xB2, 0xA5, 0x65, 0x4B
HANDSHAKE_CONF: 0x69, 0xD3, 0xD2, 0x26
ACK: 0x4D, 0x5A, 0x9A, 0xB4
NACK: 0x2D, 0x59, 0x5A, 0xB2
</code></pre>
</div>
<p>Once the device is rebooted, the bootloader runs and waits on the serial line for the <code class="highlighter-rouge">HANDSHAKE_REQ</code>. If it doesn’t receive the sequence within 500ms, the bootloader disables the serial line and transfers control to the main program. If the sequence is received in time, the device responds with <code class="highlighter-rouge">HANDSHAKE_CONF</code>.</p>
<p>The device will now accept the SREC records. Each record is processed and acknowledged by the ACK sequence. Note that especially for EEPROM records, the processing time can be quite high (up to a whole second, if not above).</p>
<p>If the next SREC record isn’t received within a few seconds of sending ACK (or HANDSHAKE_CONF in case of the first SREC record), the bootloader will start the program, i.e. there is no sequence sent to shut down the bootloader.</p>
<p>Now, the format of the binary SREC frames is documented incorrectly. Note that each SREC source line has the following format.</p>
<div class="highlighter-rouge"><pre class="highlight"><code>S <decimal digit> <even number of hex digits>
</code></pre>
</div>
<p>Each frame begins with the <code class="highlighter-rouge">S</code> and the <em>decimal</em> digit (indicating the type of the record). I cannot stress this enough: the first two characters are copied to the output frame without modification.</p>
<p>The rest of the line is then converted to binary – each pair of hex digits is turned into a single byte. Everything on the line is sent, including the final checksum.</p>
<p>For some reason, the Atmel’s Java-based bootloader client sends 256-byte frames containing the SREC record (in the above format) and padded with zeros. I do not fully understand why, the bootloader in the device does not require this. Furthermore, since the bootloader jumps to the start of the application as soon as one of the S7/S8/S9 records is received, it is the application that receives the padding zeros.</p>
<p>The version 0.1 of my client performs this padding (I wasn’t aware it wasn’t necessary), I’ve removed the padding a few commits later.</p>
<h2 id="building-and-installing">Building and installing</h2>
<p>For Windows, you can download the binary release below.</p>
<p>Otherwise you will have to build from sources. You will need a C++ compiler and the <a href="http://www.boost.org/">Boost libraries</a>. You can download the sources below. On Linux, just run <code class="highlighter-rouge">make</code>, a binary should be created. On Windows, use the Visual Studio project.</p>
<h2 id="releases">Releases</h2>
<ul>
<li>v0.2: <a href="/hg/zigbit_bootloader/archive/8808a7b61dea.tar.gz">src</a>, <a href="/files/2010-01-21-zigbit-bootloader/zigbit_bootloader-0.2.zip">win</a>, <a href="/hg/zigbit_bootloader/rev/8808a7b61dea">repo</a>
<ul>
<li>No longer sends zero-padded frames.</li>
</ul>
</li>
<li>v0.1: <a href="/hg/zigbit_bootloader/archive/de1e41b3d824.tar.gz">src</a>, <a href="/files/2010-01-21-zigbit-bootloader/zigbit_bootloader-0.1.zip">win</a>, <a href="/hg/zigbit_bootloader/rev/de1e41b3d824">repo</a>
<ul>
<li>Initial release.</li>
<li>Compilable on both Windows and Linux</li>
<li>Doesn’t check the integrity of the source .srec file.</li>
</ul>
</li>
</ul>Martin VejnárI was playing with Atmel’s ZigBit ATZB-24-A2 over the last few days and wrote a command-line utility that runs on both Windows and Linux and can be used to flash programs into these modules (assuming that they have the original bootloader installed). Atmel distributes their own bootloader client as part of the BitCloud SDK, but the command-line version didn’t work for me at all and the GUI version was very unreliable.