tag:blogger.com,1999:blog-51156041905369541032024-03-13T13:11:29.456+00:00Geeky Rantsgeohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-5115604190536954103.post-27833775587517895752016-05-15T00:26:00.000+01:002016-05-15T01:49:39.237+01:00How ECC-SHA-llent!About a year ago, shortly after TI released the CC26xx family of chips, I published <a href="http://blog.spd.gr/2015/04/to-cc-or-not-to-cc.html">a rant</a> about the differences between those chips and the CC2538. Among the things I discussed was the fact that TI have apparently removed advanced cryptographic hardware acceleration from the CC26xx (and subsequently CC13xx) products.<br />
<br />
No SHA2, no ECC, only good-old AES...<br />
<br />
It was not making sense! Why remove such a desirable feature???<br />
<br />
<h3>
CC26xxware to the rescue</h3>
<br />
At roughly the same time as the first CC26xx chips were released, TI also released a set of supporting libraries code-named <a href="http://processors.wiki.ti.com/index.php/CC26xxware">CC26xxware</a>. The Contiki OS has supported CC26xx-based boards since pretty-much day one and it pulls CC26xxware in as a git sub-module. At the time of release, CC26xxware was at revision 2.21.01.15600.<br />
<br />
Come CC26xxware version 2.21.03.15980 and suddenly two new files appear: <span style="font-family: "courier new" , "courier" , monospace;">rom_crypto.h</span> and <span style="font-family: "courier new" , "courier" , monospace;">rom_crypto.c</span>. Uh-oh...<br />
<br />
For the CC13xx family of chips, the respective support bundle is called CC13xxware and it features the same two files. TI originally distributed CC26xxware and CC13xxware as stand-alone downloads, but at some point they decided to stop doing so and they are now bundling them inside TI-RTOS.<br />
<br />
Both xxwares are distributed under the terms of the 3-clause BSD license, which is an excellent choice!<br />
<br />
Back to the point: So perhaps the chips do have crypto capability, only TI is not very forthcoming about it.<br />
<br />
Let's have a closer look!<br />
<br />
<h3>
The ROM crypto API</h3>
<br />
If we look inside <span style="font-family: "courier new" , "courier" , monospace;">rom_crypto.h</span>, we see the following function prototypes (Taken from CC26xxware version 2.23.01.16780, distributed with TI RTOS 2.16.00.08 - 25 Feb 2016):<br />
<br />
<pre class="brush: cpp">extern void AES_ECB_EncryptData(uint8_t *text, uint16_t textLen, uint8_t *aesKey);
extern void AES_ECB_DecryptData(uint8_t *text, uint16_t textLen, uint8_t *aesKey);
extern int8_t AES_CCM_EncryptData(uint8_t encryptFlag, uint8_t MACLen, uint8_t *nonce,
uint8_t *plainText, uint16_t textLen,
uint8_t *addDataBuf, uint16_t addBufLen,
uint8_t *aesKey, uint8_t *MAC, uint8_t ccmLVal);
extern int8_t AES_CCM_DecryptData(uint8_t decryptFlag, uint8_t MACLen, uint8_t *nonce,
uint8_t *cipherText, uint16_t textLen,
uint8_t *addDataBuf, uint16_t addBufLen,
uint8_t *aesKey, uint8_t *MAC, uint8_t ccmLVal);
extern uint8_t AES_CTR_EncryptData(uint8_t *plainText, uint16_t textLen,
uint8_t *aesKey, uint8_t *nonce,
uint8_t *initVector);
extern uint8_t AES_CTR_DecryptData(uint8_t *cipherText, uint16_t textLen,
uint8_t *aesKey, uint8_t *nonce,
uint8_t *initVector);
extern void ECC_initialize(uint32_t *pWorkzone);
extern uint8_t ECC_generateKey(uint32_t *randString, uint32_t *privateKey,
extern uint8_t ECC_ECDSA_sign(uint32_t *secretKey, uint32_t *text, uint32_t *randString,
uint32_t *sign1, uint32_t *sign2);
extern uint8_t ECC_ECDSA_verify(uint32_t *publicKey_x, uint32_t *publicKey_y,
uint32_t *text, uint32_t *sign1, uint32_t *sign2);
extern uint8_t ECC_ECDH_computeSharedSecret(uint32_t *privateKey,
uint32_t *publicKey_x,
uint32_t *publicKey_y,
uint32_t *sharedSecret_x,
uint32_t *sharedSecret_y);
extern uint8_t SHA256_runFullAlgorithm(SHA256_memory_t *memory, uint8_t *pBufIn,
uint32_t bufLen, uint8_t *pBufOut);
extern uint8_t SHA256_initialize(SHA256_memory_t *workZone);
extern uint8_t SHA256_execute(SHA256_memory_t *config, uint8_t *pBufIn,
uint32_t bufLen);
extern uint8_t SHA256_output(SHA256_memory_t *memory, uint8_t *pBufOut);</pre>
<br />
<h3>
So, what can these things do? </h3>
<br />
We can safely draw some conclusions here now, can't we? The chips can do:<br />
<ul>
<li>SHA 256 </li>
<li>ECDSA sign/verify </li>
<li>ECDH </li>
<li>AES CTR, ECB, CCM</li>
</ul>
But this is a ROM API. If you look at the corresponding .c file, you will see things in the lines of this (excerpt from the same TI-RTOS version):<br />
<br />
<pre class="brush: cpp">typedef uint8_t(*ecdsa_sign_t)(uint32_t *, uint32_t *,uint32_t *, uint32_t *, uint32_t *);
ecdsa_sign_t ecc_ecdsa_sign = (ecdsa_sign_t)(0x10017969);
uint8_t
ECC_ECDSA_sign(uint32_t *secretKey, uint32_t *text, uint32_t *randString,
uint32_t *sign1, uint32_t *sign2)
{
return (uint8_t)ecc_ecdsa_sign((uint32_t*)secretKey, (uint32_t*)text, (uint32_t*)randString,
(uint32_t*)sign1, (uint32_t*)sign2);
}
</pre>
<br />
Thus, a call to <span style="font-family: "courier new" , "courier" , monospace;">ECC_ECDSA_sign()</span> is fundamentally a jump to a pre-determined address in ROM through a function pointer. The same applies for ECDH and SHA functions. What we cannot know for certain until TI decides to tell us is what exactly happens under the hood at these addresses on ROM. Nothing stopping us from guessing though, and I can imagine two scenarios:<br />
<ul>
<li>Either that address on ROM hosts a fully software-based implementation of ECDSA (or ECDH or SHA and so on)</li>
<li>Or that address in ROM hosts a driver for some undocumented hardware crypto engine.</li>
</ul>
If we look at the addresses on ROM a little more closely:<br />
<br />
<pre class="brush: cpp">ecdsa_sign_t ecc_ecdsa_sign = (ecdsa_sign_t)(0x10017969);
ecdsa_verify_t ecc_ecdsa_verify = (ecdsa_verify_t)(0x10017b01);
</pre>
<br />
Ergo, there is a gap of <span style="font-family: "courier new" , "courier" , monospace;">0x10017b01 - 0x10017969 = 408</span> bytes there available for <span style="font-family: "courier new" , "courier" , monospace;">ecc_ecdsa_sign</span>. Draw your own conclusions if you fancy doing so.<br />
<br />
What we can also do is actually try to use those functions and benchmark them; this could provide more hints about whether we are looking at a hardware crypto engine. <br />
<br />
<h3>
A brief note about RNGs</h3>
<br />
In the CC26xx Technical Reference Manual [1], TI have boldly stated:<br />
<blockquote class="tr_bq">
"<i>The true random number generator (TRNG) module provides a true, nondeterministic noise source for the purpose of generating keys, initialization vectors (IVs), and other random number requirements. The TRNG is built on 24 ring oscillators that create unpredictable output to feed a complex nonlinear combinatorial circuit. That post-processing of the output data is required to obtain cryptographically secure random data.</i>"</blockquote>
TI don't normally make such claims lightly. For instance, the CC2538 User Guide [2] clearly classifies the respective RNG as a Pseudo-RNG and does not suggest that the module is suitable for crypto. In fact the document contains statements like:<br />
<blockquote class="tr_bq">
"<i>Randomness tests show good results for this module. However, a slight DC component exists.</i>"</blockquote>
and<br />
<blockquote class="tr_bq">
"<i>To fully qualify the random generator as true random, much more elaborate tests are required. Software packages that may be useful in this respect are available on the internet.</i>"</blockquote>
This is something I personally interpret as, "<i>If you want to do crypto using this thing, do so at your own risk"</i>.<br />
<br />
<h3>
Final thoughts </h3>
<br />
During a recent e-mail exchange, a colleague of mine whom I respect immensely wrote to me something in the lines of "Why does the chip with all the crypto capability lack a cryptographically suitable RNG, whereas the chip that does have a cryptographically secure RNG has limited crypto capability?".<br />
<br />
That was a very valid point and I suspect we have not heard the entire story yet.<br />
<br />
What I have not yet had time to do is search around for more information on the hardware in places such as TI's E2E forum as well as on the wider internet. What I also want to do is have a closer look at TI-RTOS' sources and see how (and if) it uses those ROM functions. Doing so may reveal further hints...<br />
<br />
<h3>
References</h3>
<div style="padding-left: 22px; text-indent: -22px;">
[1] "<i>CC26xx SimpleLink<sup>TM</sup> Wireless MCU Technical Reference Manual</i>", SWCU117D, February 2015 - Revised September 2015, [ <a href="http://www.ti.com/lit/pdf/swcu117">pdf</a> ]</div>
<div style="padding-left: 22px; text-indent: -22px;">
[2] "<i>CC2538 System-on-Chip Solution for 2.4-GHz IEEE 802.15.4 and ZigBee®/ZigBee IP® Applications"</i>, SWRU319C, April 2012 - Revised May 2013, [ <a href="http://www.ti.com/lit/pdf/swru319">pdf</a> ]</div>
geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-80046105729910865552015-04-16T04:00:00.002+01:002016-04-06T15:05:53.910+01:00To CC or not to CC<span id="goog_1113713031"></span><a href="https://www.blogger.com/"></a><span id="goog_1113713032"></span>Earlier this year TI announced a new generation of wireless MCUs code-named CC26xx. This is a family of CM3-powered <abbr title="System-on-Chip">SoC</abbr>s with varying 2.4GHz RF capabilities:<br />
<ul>
<li>CC2630: IEEE 802.15.4</li>
<li>CC2640: <abbr title="Bluetooth Low Energy">BLE</abbr></li>
<li>CC2650: BLE and IEEE 802.15.4 </li>
</ul>
If you read around the web, you may also get glimpses of a CC2610 and a CC2620.<br />
<br />
The CC2650 is basically a superset of the CC2630 and the CC2640.<br />
<br />
On the same day as the hardware announcement, TI also released a <a href="https://github.com/contiki-os/contiki/pull/974">port of the Contiki OS</a> for two CC2650-based boards:<br />
<ul>
<li>SmartRF 06 Evaluation Board + <a href="http://www.ti.com/tool/cc2650emk">CC2650 Evaluation Module</a></li>
<li>The <a href="http://www.ti.com/tool/cc2650stk">CC2650 Sensortag</a></li>
</ul>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-L9Z4rk2kdTA/VS_VltmagnI/AAAAAAAAAKo/E5aQl2Amq_U/s1600/desktop.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="200" src="https://1.bp.blogspot.com/-L9Z4rk2kdTA/VS_VltmagnI/AAAAAAAAAKo/E5aQl2Amq_U/s1600/desktop.jpg" width="320" /></a></div>
<br />
This port supports all the cool stuff one can do with Contiki, but it also provides a first glimpse of BLE, which is not officially supported by the OS.<br />
<br />
<h3>
</h3>
<h3>
But... What about the CC2538?</h3>
<br />
One might think that this is a little too early, less than 2 years from the release of the CC2538. But are the two chips really competitors? Is the CC26xx meant to replace the CC2538? What are the key differences? These are the questions I'm pondering in this post, and I shall try to answer them by taking a deeper look at some of the features of the CC26xx and putting them side-by-side with its predecessor.<br />
<br />
Oh and by the way, since we live in a capitalist, { disclaimer , indemnity }-fueled world, I must say that: "Naturally, this is just an overview, so if you want more details you should read the respective specs. Especially so if you are trying to choose between those two parts for a product."<br />
<br />
Moving swiftly on... <br />
<br />
<h3>
Power management</h3>
<br />
A quick look at the two datasheets [1, 2] immediately reveals the ultra low-power nature of the CC26xx. Let's have a quick look side-by-side:<br />
<br />
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg .tg-wr85{font-weight:bold;background-color:#efefef;text-align:center}
.tg .tg-hgcj{font-weight:bold;text-align:center}
.tg .tg-2sfh{font-weight:bold;background-color:#efefef}
.tg .tg-34fq{font-weight:bold;text-align:right}
.tg .tg-y0hu{font-size:small;background-color:#efefef}
.tg .tg-0ge8{font-size:small;background-color:#efefef;text-align:center}
.tg .tg-en76{font-size:small;text-align:center}
.tg .tg-ghao{font-size:small}
.tg .tg-40fp{font-size:small;text-align:right}
</style> <br />
<table class="tg"><tbody>
<tr> <th class="tg-wr85" colspan="2">CC26xx</th> <th class="tg-hgcj" colspan="3">CC2538</th> </tr>
<tr> <td class="tg-2sfh">Test Condition</td> <td class="tg-wr85">Typ</td> <td class="tg-hgcj">Typ</td> <td class="tg-hgcj">Max</td> <td class="tg-34fq">Test Condition</td> </tr>
<tr> <td class="tg-y0hu">Standby.<br />
With RTC, CPU, RAM and (partial) register retention.<br />
RCOSC_LF </td> <td class="tg-0ge8">1μA</td> <td class="tg-en76">1.3μA</td> <td class="tg-ghao">2μA</td> <td class="tg-40fp">Power mode 2.<br />
Digital regulator off<br />
16-MHz RCOSC and 32-MHz crystal oscillator off<br />
32.768-kHz XOSC, POR, and sleep timer active<br />
RAM and register retention</td> </tr>
<tr> <td class="tg-y0hu">Active.<br />
Core running CoreMark (Peripherals inactive)</td> <td class="tg-0ge8">1.45 mA + 31 μA/MHz<br />
( = 1.946mA at a theoretical 16MHz)</td> <td class="tg-en76" colspan="2">7mA</td> <td class="tg-40fp">Digital regulator on<br />
16-MHz RCOSC running<br />
No radio, crystals, or peripherals active.<br />
CPU running at 16-MHz with flash access</td> </tr>
</tbody></table>
<br />
Now those test conditions are obviously not identical, but they can still help us move forward. We see a difference under low power operation, we see a big difference while running. In fact, even configuring the CC26xx to fire on all cylinders (48MHz), its active consumption will be lower (2.938mA) than those 7mAs on the CC2538.<br />
<br />
I've always been taking those datasheet values with a pinch of salt, since it's often difficult to understand the exact test conditions in terms of what was running and what was not.<br />
<br />
What happens under the hood?<br />
<br />
<h4>
Power management, old style</h4>
<br />
Up to the CC2538 inclusive, TI's chips traditionally had preset "power modes" (I like calling them profiles). Those were built into the chip. For example, in the table above, we see that the datasheet mentions "Power Mode 2". In a nutshell, to enter a low power mode, one would roughly follow the steps below:<br />
<ol>
<li>Shut down / configure board peripherals (LEDs, sensors, etc)</li>
<li>Select one of the <i>pre-defined</i> power modes by writing some hardware register</li>
<li>Configure the chip for this power mode (e.g. wakeup sources)</li>
<li>Enter this power mode</li>
</ol>
Let me emphasise this: The CC2538's PM2 is built into the chip itself, and so are the remaining power profiles (active, sleep, PM[0..3]).<br />
<br />
Now this is very very simple to write software for, but it does have a problem: Imagine that you want to enter low-power operation and that you need some functionality X while operating in this low-power mode. You have a quick look at the device datasheet and you see that PM2 turns off feature X. Feature X is only available in PM1, which will result in a higher consumption. However, you do in fact <i>really</i> need feature X, so you are stuck with PM1. You are also stuck with all the other things that run (and draw current) while in PM1, even those that you couldn't care less about.<br />
<br />
<h4>
Power management, CC26xx-style</h4>
<br />
The CC26xx re-writes the textbook: It does <i>not</i> have pre-defined power modes. In the table above, we see the term "Standby", but this is <i>not</i> built into the chip, it is just a software-defined profile in TI-RTOS. The reality with the chip itself is a lot more flexible, which also makes it a lot more complex to write software for. Let's have an introductory look.<br />
<br />
First things first, in typical CM3 fashion, at any give point in time the micro on the CC26xx can be in one of three states:<br />
<ol>
<li>Active / Running</li>
<li>Sleeping</li>
<li>Deep Sleeping</li>
</ol>
The CC26xx digital power system is partitioned:<br />
<ul>
<li>The CC26xx has two separate <abbr title="Voltage Domain">VDs</abbr>: MCU and <abbr title="Always ON">AON</abbr>. The MCU VD can be turned off when we want to fully shut the chip down, but it will otherwise be on. AON is... well... AON.</li>
<li>Each VD is further partitioned into Power Domains (<abbr title="Power Domain">PD</abbr>s). For example, the MCU VD has the following PDs:</li>
<ul>
<li>MCU AON: This is in fact AON and cannot be turned off by software, except by turning off the entire MCU VD.</li>
<li>CPU</li>
<li>SYSBUS</li>
<li><abbr title="Versatile Instruction Memory System">VIMS</abbr></li>
<li>RFCORE</li>
<li>PERIPH</li>
<li>SERIAL</li>
</ul>
<li>Each PD contains digital modules. </li>
<ul>
<li>VIMS: Flash, cache and ROM</li>
<li>PERIPH: Supplies the DMA controller, Crypto engine, the <abbr title="True Random Number Generator">TRNG</abbr>, <abbr title="General-Purpose Timer">GPT</abbr>s [3:0], GPIO, <abbr title="Synchronous Serial Interface">SSI</abbr>1 and the <abbr title="Integrated Interchip Sound">I2S</abbr> module</li>
<li>SERIAL: Supplies the UART, SSI0, I<sup>2</sup>C</li>
</ul>
<li>Some of the modules have retention which can be enabled/disabled by software </li>
<li>Additionally, each of the peripherals / modules has a clock gate and of course the module itself can also be enabled / disabled by software, as usual.</li>
<li>RAM is partitioned in 4 blocks, and each block can have its retention enabled or disabled</li>
</ul>
This drawing tries to capture the VD / PD / Module / Clock Gate logical structure: <br />
<ul></ul>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-ypkE5UFvi0I/VS-8kS9lfCI/AAAAAAAAAKU/RSHixuKG0vo/s1600/cc26xx-power-partitioning.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="176" src="https://1.bp.blogspot.com/-ypkE5UFvi0I/VS-8kS9lfCI/AAAAAAAAAKU/RSHixuKG0vo/s1600/cc26xx-power-partitioning.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
The SERIAL and PERIPH PDs can be turned on/off by software on demand. For the CPU domain, we can request it to be off, but this will only happen when the CM3 drops to deep sleep. We can also request VIMS / SYSBUS on or off, but their behaviour depends on some additional factors and, generally speaking, we cannot explicitly force them on or off. For instance, SYSBUS will only actually turn off if neither the micro nor the RF are requesting access to it.<br />
<br />
While active, the chip can be supplied by a DC-DC or a Global LDO. When we drop to deep sleep, we can request a switch to a micro-LDO (uLDO), to reduce leakage.<br />
<br />
This system is very flexible and we can do various shenanigans. For example, we can do the following:<br />
<ul>
<li>Configure the SSI0 clock to run while the CM3 is active, as well as during sleep and deep sleep. </li>
<li>Keep the SERIAL PD on (it's where SSI0 sits).</li>
<li>Disable all clocks under sleep and deep sleep for the remaining modules within SERIAL (e.g. for the UART). </li>
<li>Turn off PERIPH and RFCORE (this will turn off the RF as well as all modules within the PERIPH PD).</li>
<li>Request SYSBUS, VIMS and CPU PDs off. RFCORE is off, so SYSBUS will turn off when the MCU drops to deep sleep.</li>
<li>Request retention to be disabled for a part of our RAM (we have made sure there's nothing we need in there).</li>
<li>Disable VIMS and RFCORE retention.</li>
<li>Turn off the AUX PD within the AON VD (The AUX being a secondary, 16-bit sensor controller).</li>
<li>Drop to deep sleep.</li>
<li>Wait for SSI0 trigger to wake-up.</li>
</ul>
This is merely an example. If we chose to do so, we can even leave RFCORE running and turn off everything else. We can pretty-much configure any combination we like (within some loose constraints of course).<br />
<br />
Unlike TI-RTOS, Contiki does not attempt to pre-define power profiles. Instead, it provides a set of helper functions that control the power down/up sequence and aim to help developers configure the state of the chip under low-power operation. In my humble opinion, CC26xx power mode support is the most mature power-related system among those present in the official Contiki source code repository.<br />
<br />
The CC26xx's power management features are described in greater detail in the CC26xx TRM [3].<br />
<br />
I love the CC2538, but - despite the complexity - the CC26xx wins.<br />
<br />
<h3>
One RF to rule them all</h3>
<br />
It only makes sense to compare the CC2538 with the CC2630 and the CC2650. The key difference here is that the CC2650 radio can operate in IEEE 802.15.4 as well as in BLE mode. Therefore, if for whatever reason you need to support both a 6LoWPAN / ZigBee and a BLE stack, you can do so without having to spin a dual-RF board. The CC2650 can do both with a single radio, albeit not simultaneously. The switching can be done on-demand and it is controlled by software.<br />
<br />
<h4>
Controlling the Radio</h4>
<br />
The CC2538 adopts a standard approach whereby the RF is controlled exclusively by hardware registers (In the region of ~70 documented in the user guide). The only thing that's perhaps worthy of a comment is that, even though the MCU is a 32bit one, the registers are 8bit-wide, with bits 31..8 being reserved. Makes me think that this radio has been used in a product powered by an 8bit micro in the past...<br />
<br />
The CC26xx adopts an entirely different approach. Reading the TRM, one can count fewer than 15 RF-related hardware registers, with another few power-related ones.<br />
<br />
The RF is a CM0-powered chip (also called a <abbr title="Command and Packet Engine">CPE</abbr>), which communicates with the CM3 using a shared memory interface. The two chips can raise interrupts to one another. Software running on the CM3 passes commands to the CPE through a single register, called <code>CMDR</code>. The module responsible for the communication between the CM3 and the CPE is called "Radio Doorbell" (RFC_DBELL).<br />
<br />
Each command from the CM3 to the CPE can be of one among three types:<br />
<ul>
<li>Direct Command</li>
<li>Immediate command</li>
<li>Radio Operation command</li>
</ul>
Direct commands are very straightforward: The CM3 writes the command and its parameters directly to <code>CMDR</code>. The 16 high bits [31..16] represent the command ID, the following 14 bits [15..2] represent optional parameters, whereas the 2 least significant bits must be 01. An example of a direct command is <code>CMD_ABORT</code>, which will signal the CPE to abort any current ongoing operations immediately.<br />
<br />
Immediate commands and Radio Ops are more complicated. The command itself is represented by a data structure stored in the CM3's RAM, <strike>the chip's flash</strike> or the radio's RAM. The value written to <code>CMDR</code> is merely a pointer to this data structure. The CPE can tell that a command is an Immediate one or a Radio OP by inspecting the 2 least significant bits of <code>CMDR</code>, which for those commands must be clear. Therefore, the data structure representing those commands must be aligned on a 4-byte boundary.<br />
<br />
Immediate commands change or inspect the status of the radio and can be issued at any time, although some of them are only relevant when the radio is actually doing something. An example of an Immediate command is <code>CMD_IEEE_CCA_REQ</code>, which requests <abbr title="Clear Channel Assessment">CCA</abbr> and <abbr title="Received Signal Strength indication">RSSI</abbr> information.<br />
<br />
Radio Ops will access the actual radio hardware, to perform operations such as enter RX mode or TX a frame.<br />
<br />
Direct commands are basically Immediate commands that either don't need parameters at all, or that need parameters which can be accommodated within the space available in <code>CMDR</code>.<br />
<br />
A second hardware register, called <code>CMDSTA</code>, is used so that the CPE can communicate to the CM3 the status of the most recent command written to <code>CMDR</code>. The 8 least significant bits of <code>CMDSTA</code> represent the command's result, while the 24 most significant bits may contain command-specific signalling.<br />
<br />
Specifically for Radio Ops, the data structure representing the command has a status field, which is used by the CPE to inform about command execution status and is used in addition to the signalling via <code>CMDSTA</code>. Normally, <code>CMDSTA</code> will be updated immediately upon command reception (e.g. the command was successfully submitted for execution, or an error occurred), while the command's status field will keep getting updated over time as the command is being executed (e.g. "not started yet", "running", "done / complete" or "done / aborted").<br />
<br />
It certainly took me a while to get my head around this new way of working. From the CM3 developer's perspective, the CPE is a bit of a black box. You send commands to it and it does things. It's easy to tell what you think you asked the CPE to do. It's not always easy to tell what the CPE is actually doing. The API is very thorough in terms of sending commands to the CPE, but I find it lacking in terms of requesting status information. <code>CMDSTA</code> and the status field of Immediate commands and Radio Ops provides some information, but this information only relates to the most recent command sent (<code>CMDSTA</code>) or the respective Immediate command or Radio Op (command's status field). Thus, if you send a "Enter IEEE RX" command, you can then inspect the status field and see if the command is currently running. But if you do not send a command, then you have no way of knowing what the CPE is up to. For example, if you configure it to send ACKs for frames that pass frame filtering, it will every now and then interrupt RX mode, switch to TX, send the ACK, go back to RX. This happens without any commands sent from the CM3, so there is no status field to inspect. The API does not provide a "Are you currently in TX?" command, nor a "Have you started receiving a frame?" or "What is your current state?". Some (but not all) of those questions can be answered by inspecting interrupt flags, but the ability to directly enquire about those and other similar status updates would be nice to have in the API.<br />
<br />
<h3>
Hardware crypto</h3>
<br />
TI seem to have taken a step backwards on this front. The CC26xx only has an <abbr title="Advanced Encryption Standard">AES</abbr> crypto engine (that can only do 128-bit AES). Nothing to write home about, this feature has been around since the CC2420 / CC2430 days.<br />
<br />
Conversely, the CC2538 provides hardware acceleration for AES-128 as well as 256, but it also provides acceleration for <abbr title="Secure Hash Algorithm">SHA</abbr>2 and, optionally, <abbr title="Public Key Acceleration">PKA</abbr> for <abbr title="Elliptic Curve Cryptography">ECC</abbr>-128/256 and <abbr title="Rivest-Shamir-Adleman">RSA</abbr>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-lF2H_gGEyHg/VS-udTNRK6I/AAAAAAAAAJ8/TgDAsMaaalA/s1600/zenital.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img alt="" border="0" height="319" src="https://4.bp.blogspot.com/-lF2H_gGEyHg/VS-udTNRK6I/AAAAAAAAAJ8/TgDAsMaaalA/s1600/zenital.png" title="" width="320" /></a></div>
As IoT applications are gaining traction, hardware manufacturers, product developers, regulators, end-users and, generally speaking, all stakeholders are becoming more interested in security. The devices we are discussing here are very constrained and they cannot run the latest and greatest security-related technological advances. The <a href="https://ict-rerum.eu/">RERUM</a> EC-funded R&D project aims to tackle some of the security- and privacy-related challenges for Smart City applications. During the course of RERUM, <a href="http://zolertia.io/">Zolertia</a> (one of the twelve consortium partners) developed the Re-Mote, a new hardware platform, which was designed by the requirements of the Use-Cases considered by the project. Zolertia, in collaboration with RERUM consortium partners, chose the CC2538 SoC to power the Re-Mote, partly due to its cryptography-related capability.<br />
<br />
I am sure TI had their reasons for taking this decision, and time will tell whether they were right or not.<br />
<br />
For the time being, the CC2538 wins. Hands down.<br />
<br />
<h3>
USB</h3>
<br />
The CC2430 was what got me involved with Contiki in the first place. The CC2530 and <a href="http://blog.spd.gr/2014/04/upstream-contiki-goes-multicast-more-or.html">multicast support</a> were the main reasons why I was invited to join the Contiki team of maintainers. Naturally, I feel emotionally attached with the CC2530, especially so with the almighty <a href="http://www.ti.com/tool/cc2531emk">CC2531 USB dongle</a>!<br />
<br />
The CC2530s are powered by 8051-based, 8-bit micros. I still think that the CC2530 is a great chip, but it does have two problems:<br />
<ul>
<li>Harvard-based architecture: Very very simply speaking, this means our toolchain is not GCC-based. We use <abbr title="Small Device C Compiler">SDCC</abbr> to build images, which is not a bad thing at all in itself, but SDCC does have a much smaller community. This means it doesn't evolve as quickly as GCC-based toolchains and the code optimisations it can do are nowhere near as sophisticated.</li>
<li>As I have said in various places, at various times (on occasion kicking and screaming), the 8051's stack is limited to 256 bytes, when building with SDCC at least. This is a big big problem. This renders the chip plain and simple unsuitable for Contiki and <abbr title="IPv6 over Low power Wireless Personal Area Networks">6LoWPAN</abbr>-networked applications. It would be possible to develop all those things in an 8051-friendly way, but when writing software for this chip one should implement some things in a different way than the way one would use for Von Neumann-based machines. Contiki is standards-compliant and cross-platform, therefore it is impossible to adopt 8051-friendly software design decisions for platform-independent code.</li>
</ul>
Back on topic: Despite all of the above, the CC2531 does have this amazing feature: A USB controller. But for the limitations listed above, I would consider the USB dongle to be the perfect solution for 6LoWPAN border routers and dummy radios (SLIP radios using Contiki nomenclature). With Contiki, this functionality has been traditionally been achieved by UART-based solutions, and the interface between the border router and its host has always been a bottleneck.<br />
<br />
The CC2538 also has native USB support, but it doesn't suffer from any of the CC2530's limitations. It is high-time we replaced the CC2531 dongle by something newer, and I am hoping that someone will soon produce a CC2538-powered USB stick!<br />
<br />
In fact, I heard it through the grapevine that one is around the corner... It has a smaller form factor than the CC2531; I believe that the curved part at the right hand-side has cut lines and can be taken off. Button on the side seems like a great idea and it also has an epic LED that can turn pink!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://3.bp.blogspot.com/-gIRbFRc57z4/VTEkjjAUfaI/AAAAAAAAAK0/coKTPEtYxcQ/s1600/20150409_154350.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="192" src="https://3.bp.blogspot.com/-gIRbFRc57z4/VTEkjjAUfaI/AAAAAAAAAK0/coKTPEtYxcQ/s1600/20150409_154350.jpg" width="320" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Reproduced with Zolertia's express permission</td></tr>
</tbody></table>
<br />
The CC26xx does not feature a USB controller. This is probably not a huge deal for wireless applications. Depending on what one is trying to achieve, one can see the CC2538's USB as a useful feature, or one can see it as an unnecessary burden.<br />
<br />
<h3>
Other noteworthy differences</h3>
<br />
In the previous sections, I focused on the features that I consider to be key differentiating factors between the two chips. However, the CC2538 and the CC26xx have additional subtle (or not quite as subtle) differences. I am going to try to summarise them in the table below.<br />
<style type="text/css">
.tg {border-collapse:collapse;border-spacing:0;}
.tg td{font-family:Arial, sans-serif;font-size:14px;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg th{font-family:Arial, sans-serif;font-size:14px;font-weight:normal;padding:10px 5px;border-style:solid;border-width:1px;overflow:hidden;word-break:normal;}
.tg .tg-poza{font-size:large;background-color:#efefef}
.tg .tg-83r5{font-weight:bold;background-color:#efefef;color:#333333;text-align:center}
.tg .tg-cs79{font-weight:bold;background-color:#efefef}
.tg .tg-4uy2{font-weight:bold;background-color:#efefef;text-align:right}
.tg .tg-ghao{font-size:small}
.tg .tg-en76{font-size:small;text-align:center}
.tg .tg-yeb6{font-weight:bold;background-color:#efefef;text-align:right}
.tg .tg-s6z2{text-align:center}
.tg .tg-6wos{text-align:center}
</style> <br />
<table class="tg"><tbody>
<tr> <th class="tg-poza"></th> <th class="tg-83r5">CC26xx</th> <th class="tg-83r5">CC2538</th> </tr>
<tr> <td class="tg-cs79" colspan="3">Key features</td> </tr>
<tr> <td class="tg-4uy2">Power management</td> <td class="tg-ghao">Advanced<br />
Flexible, but complex to harness</td> <td class="tg-ghao">Standard<br />
Not very flexible, but simple to implement</td> </tr>
<tr> <td class="tg-4uy2">RF</td> <td class="tg-ghao"><ul>
<li>CC2630: 2.4GHz IEEE 802.15.4</li>
<li>CC2640: BLE</li>
<li>CC2650: 2.4GHz IEEE 802.15.4 and BLE</li>
</ul>
Very few hardware registers<br />
Most operations use a new API</td> <td class="tg-ghao">2.4GHz IEEE 802.15.4<br />
Traditional approach based on H/W registers</td> </tr>
<tr> <td class="tg-4uy2">Crypto</td> <td class="tg-en76">128-bit AES</td> <td class="tg-ghao"><ul>
<li>128- and 256-bit AES</li>
<li>SHA2</li>
</ul>
Optionally: <br />
<ul>
<li>ECC 128/256</li>
<li>RSA</li>
</ul>
</td> </tr>
<tr> <td class="tg-4uy2">USB Controller</td> <td class="tg-en76">Nay</td> <td class="tg-en76">Yay</td> </tr>
<tr> <td class="tg-yeb6">OS Support</td> <td class="tg-s6z2" colspan="2">Both very-well supported by Contiki</td> </tr>
<tr> <td class="tg-cs79" colspan="3">Features not discussed extensively</td> </tr>
<tr> <td class="tg-4uy2">MCU Speed</td> <td class="tg-6wos">Up to 48MHz</td> <td class="tg-6wos">Up to 32MHz</td> </tr>
<tr> <td class="tg-4uy2">RAM</td> <td class="tg-6wos">20KB, all capable of retention<br />
(+8KB VIMS Cache +2KB on the AUX)</td> <td class="tg-6wos">16 or 32KB<br />
(16KB with retention in all PMs)</td> </tr>
<tr> <td class="tg-4uy2">Flash</td> <td class="tg-6wos">128 KB</td> <td class="tg-6wos">128, 256 or 512 KB</td> </tr>
<tr> <td class="tg-4uy2">UARTs</td> <td class="tg-6wos">1</td> <td class="tg-6wos">2</td> </tr>
<tr> <td class="tg-4uy2">SSIs</td> <td class="tg-6wos">2</td> <td class="tg-6wos">2</td> </tr>
<tr> <td class="tg-4uy2">I2Cs</td> <td class="tg-6wos">1</td> <td class="tg-6wos">1</td> </tr>
<tr> <td class="tg-4uy2">AUX</td> <td class="tg-6wos">16-bit sensor controller with 2KB SRAM</td> <td class="tg-6wos">Nay</td> </tr>
<tr> <td class="tg-4uy2">RNG</td> <td class="tg-6wos"><abbr title="True Random Number Generator">TRNG [1]</abbr></td> <td class="tg-6wos"><abbr title="Pseudo-Random Number Generator">PRNG</abbr></td> </tr>
<tr> <td class="tg-4uy2">I2S</td> <td class="tg-6wos">Yay</td> <td class="tg-6wos">Nay</td> </tr>
<tr> <td class="tg-4uy2">Can iron your shirts</td> <td class="tg-6wos">Nay</td> <td class="tg-6wos">Nay</td> </tr>
</tbody></table>
<br />
<h3>
References</h3>
<div style="padding-left: 22px; text-indent: -22px;">
[1] "<i>CC2650 SimpleLink<sup>TM</sup> Multistandard Wireless MCU</i>", SWRS158, February 2015, [ <a href="http://www.ti.com/lit/gpn/cc2650">pdf</a> ]</div>
<div style="padding-left: 22px; text-indent: -22px;">
[2] "<i>CC2538 Powerful Wireless Microcontroller System-On-Chip for 2.4-GHz IEEE 802.15.4, 6LoWPAN, and ZigBee® Applications"</i>, SWRS096D, December 2012 - Revised April 2015, [ <a href="http://www.ti.com/lit/gpn/cc2538">pdf</a> ]</div>
<div style="padding-left: 22px; text-indent: -22px;">
[3] "CC26xx SimpleLink<sup>TM</sup> Wireless MCU Technical Reference Manual", SWCU117A, February 2015 - Revised March 2015, [ <a href="http://www.ti.com/lit/pdf/swcu117">pdf</a> ]</div>
geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-90813402220307303752014-06-07T23:54:00.000+01:002014-06-07T23:56:36.074+01:00Anathema for my earsThis post is not geeky and definitely not a rant. Far from!<br />
<br />
I have been a long standing fan of <a href="http://anathema.ws/">Anathema</a>'s. I remember listening to the Eternity album in a bar in Athens shortly after its release. I remember the guys sitting at the table next to me ranting "blergh, this is rubbish, they've gone too soft". I remember thinking "What the devil are these chaps talking about? This is brilliant! What's this band called???". I swiftly spent my hard-earned pocket money to buy Eternity on the very same day.<br />
<br />
Anathema then released "Alternative 4", but what really did it for me was when I saw them live at the Rodon Club in Athens shortly before the release of "Judgment". Surely, they played all the great stuff that they had already released, but they also gave us a sneak-peak of their upcoming release, by performing "Deep" and "Judgement".<br />
<br />
That was it. Helplessly, hopelessly and irrevocably in love with them.<br />
<br />
Fast forward 15 years, their style has changed a fair bit, but I'm still a huge fan and I've had the opportunity to see them live at Donington during the Download Festival 2010. I just found out about the upcoming release of their new "Distant Satellites" album. I pre-ordered it before I even <a href="http://www.independent.co.uk/arts-entertainment/music/anathema-exclusive-album-stream-get-a-first-listen-to-the-bands-new-record-distant-satellites-9487235.html">listened to samples</a>, which is exactly what I'm doing as I'm writing this post.<br />
<br />
First track starts playing, and ten seconds in I felt an irresistible urge to write this and to scream out loud that this is another bloody great piece of work. Now if you know me, you know that I am passionate about music, but never before have I been so excited by a new release to blog about it.<br />
<br />
If you like Anathema, do yourself a favour and buy Distant Satellites. If you've not heard of them before, do yourself a favour and listen to this.<br />
<br />
And I thought "Weather Systems" was great...geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-84023562426617114032014-04-13T00:06:00.002+01:002014-04-13T00:06:45.281+01:00IPv6-in-IPv6 + HBHO Extension Headers: The answer to the ultimate question of RFC compliance, the universe, and everythingSo there is this person with whom I've been discussing Contiki/6LoWPAN-related topics for ages. However, due to the fact that he's based in the other side of the Atlantic, we'd not had a chance to meet in person before. <abbr title="Internet Engineering Task Force">IETF</abbr> 89 took place in London this year, he was attending, it was an excellent opportunity to meet in person and I jumped on a train without hesitation.<br />
<br />
Himself, a bunch of other (IETF) IoT / Contiki enthusiasts and I met after the IETF and we went for dinner and a few drinks. Among them, a key player in IETF's <abbr title="Routing Over Low power and Lossy networks">ROLL</abbr> <abbr title="Working Group">WG</abbr>. Naturally, lots of the conversation was on Contiki-related topics, and at some point we started discussing ROLL's protocols.<br />
<br />
Among other topics, we spoke about <abbr title="IPv6 Routing Protocol for Low-Power and Lossy Networks">RPL</abbr> (some pronounce it 'ripple') and <abbr title="Multicast Protocol for Low power and Lossy Networks">MPL</abbr> (some pronounce it 'mipple'). I emphatically recommended that, for obvious pronunciation-related reasons, they should refrain from using the acronym NPL for any of their subsequent protocols...<br />
<br />
Moving swiftly on...<br />
<br />
<h3>
A little background</h3>
<br />
Now that Contiki features its <a href="http://blog.spd.gr/2014/04/upstream-contiki-goes-multicast-more-or.html">shiny support for 6LoWPAN multicast</a>, I've been spending some of my spare time implementing the most recent version of the <a href="http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast">MPL</a> <abbr title="Internet Draft">ID</abbr> (currently <a href="http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-08">v08</a>).<br />
<br />
Simple scenario: A 6LoWPAN connected to the rest of the Internet. For
simplicity's (and my own sanity's) sake, let's for a second assume that
the world suddenly woke up one day and IPv6 had been deployed globally. A host somewhere in the Internet sends a multicast datagram to a Global-Scope IPv6 address, and some nodes inside the 6LoWPAN are interested in this multicast group. Shimples!<br />
<br />
Or maybe it's not that simple. You see, MPL defines an IPv6 <abbr title="Hop-by-Hop Options">HBHO</abbr>
header, called the 'MPL Option', present in all MPL Data Messages. Why is that a problem? Well, it's a
problem cause MPL only operates inside the 6LoWPAN, so if a multicast
datagram originates from somewhere outside it, it won't have an MPL Option.<br />
<br />
Let's try to visualise this from a network layer perspective (omitting layer 2 and UDP headers for clarity). Observe how a multicast datagram originating at an Internet host will <i>not</i> have an MPL Option extension header in it (right). However, inside the 6LoWPAN, the MPL Option must be there (left).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-r-qaH13glYU/U0m1lpL5NUI/AAAAAAAAAII/FNABlBJuxfM/s1600/mpl-opt.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://2.bp.blogspot.com/-r-qaH13glYU/U0m1lpL5NUI/AAAAAAAAAII/FNABlBJuxfM/s1600/mpl-opt.png" height="230" width="400" /></a></div>
<br />
<br />
In the MPL draft, there is also a discussion about the Realm-Local multicast scope. This is a new scope, currently emerging as part of <a href="http://tools.ietf.org/html/draft-ietf-6man-multicast-scopes-04">draft-ietf-6man-multicast-scopes</a> (currently at v04). The relevance of the Realm-Local scope is not immediately obvious. Please bear with me...<br />
<br />
<h3>
An example of a perfectly smooth conversation</h3>
<br />
So there we were, eating dinner and generally having a blast, till I
decided to mention the Realm-Local scope, which was when then things
started going south... The conversation below was predominantly between
myself and a person very active within IETF's ROLL WG. Let's call him
"Him", to preserve anonymity, privacy etc.<br />
<br />
<span style="color: blue;">Me</span>: <i>Is Realm-Local moving forward? I'm planning to add support for it in Contiki since MPL uses it.</i><br />
<span style="color: #990000;">Him</span>: <i>Yes, it's moving forward.</i><br />
<span style="color: blue;">Me</span>: <i>In practical terms, what's the difference between Realm-Local and... <blah blah>?</i><br />
<span style="color: #990000;">Him</span>: <i><Explanation></i><br />
<br />
(so far so good)...<br />
<br />
<h3>
An example of a conversation NOT to continue, cause it stops being perfectly smooth...</h3>
<br />
<span style="color: #990000;">Him (continues)</span>: <i>Thus, when a multicast datagram enters the 6LoWPAN, the LBR is going to send it as Realm-Local.</i><br />
<i><span style="color: blue;">Me</span> (dazed and confused)</i>:<i> Do you mean a datagram with a Global-Scope destination?</i><br />
<span style="color: #990000;">Him</span>:<i> Yes.</i><br />
<span style="color: blue;">Me</span> (dazed and confused): <i>Eeeerm. What? Why would we change the destination address? Why not just forward it inside the 6LoWPAN with the same destination?</i><br />
<span style="color: #990000;">Him</span>: <i>No no, you're not changing it. But the datagram doesn't have an MPL option.</i><br />
<br />
(Remember the image earlier. No MPL Option in the original datagram)<i> </i><br />
<br />
<span style="color: blue;">Me</span>: <i>Why not just add the MPL option? </i>(I should have known the answer but I didn't)<br />
<span style="color: #990000;">Him</span>: <i>NO! You may not add extension headers en-route!</i><br />
<span style="color: blue;">Me</span>: <i>OK. Then what?</i><br />
<span style="color: #990000;">Him</span>: <i>You encapsulate with IPv6-in-IPv6. The inner header stays as-is, the outer one uses Realm-Local destination.</i> <br />
<br />
That was shock number one. Now to give credit where credit's due, the MPL ID is quite explicit about this scenario: "<i>IPv6-in-IPv6 encapsulation MUST be used</i>, hence the "I should have known" comment above. <br />
<br />
Let's try to expand the previous diagram to explain what I was thinking (top structure of network headers) and what "Him" was explaining (bottom).<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-ZX22he-Doy0/U0m4rcyOFrI/AAAAAAAAAIY/eu3ZjLD7N_Q/s1600/6-in-6.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-ZX22he-Doy0/U0m4rcyOFrI/AAAAAAAAAIY/eu3ZjLD7N_Q/s1600/6-in-6.png" height="263" width="400" /></a></div>
<br />
Fair enough, at the end of the day, as discussed in a previous post, <a href="http://blog.spd.gr/2014/04/upstream-contiki-goes-multicast-more-or.html">Contiki currently doesn't implement either</a>, so if we're gonna do it, we can always do it correctly right from the start... Or can we?<br />
<br />
But then I just had this Eureka moment: Haaaang on a minute. Wait wait wait. RPL also defines its own HBHO [<a href="http://tools.ietf.org/html/rfc6553">RFC 6553</a>] and the situation with incoming unicast datagrams is identical: They are not carrying the RPL HBHO.<br />
<br />
<h3>
Therefore, I simply <i>had</i> to insist</h3>
<br />
<span style="color: blue;">Me</span>: <i>Let's totally forget about multicast for a moment. Plain old unicast datagram sent from the internet. When the datagram is entering the 6LoWPAN, it needs the RPL HBHO and the border router adds it.</i><br />
<span style="color: #990000;">Him</span>: <i>Noooope. You must do IPv6-in-IPv6</i><br />
<br />
<h3>
Houston, we have a problem! </h3>
<br />
Simply put, "Him" just told me we're not RFC-compliant... Once again, let's have a look at the usual diagram, this time modified for a unicast datagram entering the RPL network. Observe how I've replaced the MPL Option with the RPL Option.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-SpiZJ-qtXQA/U0m7v2REehI/AAAAAAAAAIk/7ho73PS2KyQ/s1600/6-in-6-rpl.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-SpiZJ-qtXQA/U0m7v2REehI/AAAAAAAAAIk/7ho73PS2KyQ/s1600/6-in-6-rpl.png" height="263" width="400" /></a></div>
<br />
<br />
Despite the comedy value of the conversation, this last bit is an even more serious problem than the situation with MPL's HBHO. You see, we (Contiki) don't currently support incoming multicast datagrams, but we sure as hell support unicasts entering a RPL network. In a sense, it's better to not support a spec, than to support it in a non-compliant fashion. I like to think of Contiki as THE operating system for the IoT. Due to the embedded, super optimized way its TCP/IP stack has been implemented, I fear it would take a very considerable effort to implement IPv6-in-IPv6. Not to mention the code size and complexity increase.<br />
<br />
<span style="color: blue;">Me</span>: <i>Well, sorry, but IPv6-in-IPv6 with Contiki ain't gonna happen any time soon.</i><br />
<br />
I know that the people I was talking to can't be wrong about those things. Originally, I was hoping that they misunderstood the use-case I was trying to describe, or that I misunderstood what they were trying to explain to me.<br />
<br />
Nevertheless, the discussion prompted me to re-visit <a href="http://tools.ietf.org/html/rfc6553">RFC 6553</a> (RPL Option), as well as <a href="http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-08">draft-ietf-roll-trickle-mcast-08</a> (MPL's spec, including MPL Option). Having done so, it appears, dear reader, that they understood the question perfectly well and that I understood the answer perfectly well too...<br />
<br />
In other words, we just found out that Contiki is not as RFC Compliant as we might have liked it to be. If that's the case, we should probably open a bug in the issue tracker...<br />
<br />
Now blogs are about personal opinions are they not? Well, I know that this one is. Well, even though I'm a lot wiser now (thanks, "Him"), my personal opinion is not a lot different to what I said during the dinner in question:<br />
<br />
<div style="text-align: center;">
<span style="color: blue;">Me</span>: <i>Well, sorry, but IPv6-in-IPv6 with Contiki ain't gonna happen any time soon.</i></div>
<br />
The entire situation is a little bit of a mess. I can see why the RPL Option is useful. What I can't see is the need to over-complicate a spec that targets constrained environments, therefore also constrained nodes. RPL is becoming the de-facto standard for 6LoWPANs, and it's already complex enough. What I can't see is the need to harm it by introducing serious implications to its implementability for something that's no huge benefit.<br />
<br />
Happy coding!geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-23371439499303668792014-04-12T22:24:00.002+01:002014-04-17T23:34:07.784+01:00Upstream Contiki goes multicast... More or less...After a fair bit of patience, my 6LoWPAN multicast implementation for Contiki has now been merged upstream. This is super cool, and I must admit I'm well chuffed!<br />
<br />
This means that now you can have a Contiki node join an IPv6 multicast group. You can then send a datagram to this multicast address from somewhere in the Internet, and the Contiki node will receive it. Right? Well, I'm afraid the answer is "No, not quite".<br />
<br />
You see, as I documented right from the start in Contiki's <a href="https://github.com/contiki-os/contiki/pull/364">Pull Request #364</a>, we currently only support multicast for traffic originating inside a 6LoWPAN and with a destination in <i>the same</i> 6LoWPAN. Multicast traffic cannot traverse the network's boundary in either direction.<br />
<br />
Within the 6LoWPAN, we currently have two options:<br />
<ul>
</ul>
<ol>
<li>Multicast group management with RPL in MOP3. Forwarding with <abbr title="Stateless Multicast RPL Forwarding">SMRF</abbr> (pronounced "Smurf"!) [1, 2]</li>
<li>All multicast functionality with Trickle Multicast [3] (there is no group management as such). This is currently based on an old version of the <abbr title="Multicast Protocol for Low power and Lossy Networks">MPL</abbr> Internet Draft, which is why I'm intentionally using the name "Trickle Multicast" and not MPL.</li>
</ol>
<ul>
</ul>
Thus, things inside the 6LoWPAN are pretty much sorted out. In order to be able to extend this functionality across the 6LoWPAN's boundary, we need a couple more components:<br />
<ol>
</ol>
<ul>
<li>Some sort of mechanism to notify the outside world about group subscriptions of nodes inside the LoWPAN. This, in my humble opinion, can and should be done with <abbr title="Multicast Listener Discovery">MLD</abbr>. As a Contiki contributor <a href="https://github.com/contiki-os/contiki/pull/574">demonstrated</a> recently, an embedded implementation of MLD won't be trouble in terms of code size and complexity.</li>
<li>The network's border router should be able to forward multicast traffic from the outside world to the 6LoWPAN and vice-versa. For reasons that I'm explaining in a <a href="http://blog.spd.gr/2014/04/ipv6-in-ipv6-hbho-extension-headers.html">separate post</a>, this is not as straightforward as it may initially sound, and it's certainly more complex than simply forwarding an IPv6 datagram.</li>
<li>The network's border router should be able to conduct multicast routing on its internet-facing interfaces (in other words, outside the 6LoWPAN). The discussion of what protocols and mechanisms could be used for that is a wider topic on IPv6 multicasting and therefore out of scope of this post.</li>
</ul>
<ol>
</ol>
I'll try to visualise this. Everything inside the dashed 6LoWPAN box is what we already have (points 1 and 2 above). We need more functionality on the BR in order to achieve the right-hand side of the figure, plus functionality to cross the 6LoWPANs boundary.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="http://2.bp.blogspot.com/-RWYMfUrhPn0/U0mtMGXz6II/AAAAAAAAAH4/vXXENi0vYw8/s1600/mcast.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="http://2.bp.blogspot.com/-RWYMfUrhPn0/U0mtMGXz6II/AAAAAAAAAH4/vXXENi0vYw8/s1600/mcast.png" height="201" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">R: A router somewhere in the Internet. BR: Our border router</td></tr>
</tbody></table>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<br />
Naturally, all of the above is under the assumption of an IPv6-enabled Internet. But let's not discuss this right now.<br />
<br />
Thus, milestone achieved, but not quite there yet. Next up (in no particular order):<br />
<ul>
<li><abbr title="Multicast Protocol for Low power and Lossy Networks">MPL</abbr> implementation. This will update and eventually obsolete the current "Trickle Multicast" implementation.</li>
<li>Better forwarding in RPL MOP3 instances (I'm planning to publish this, so I'm not telling you how!)</li>
<li>MLD support</li>
</ul>
Stay tuned<br />
<br />
<h3>
References</h3>
<p>
<div style="padding-left: 22px; text-indent: -22px;">
[1] G. Oikonomou, I. Phillips, T. Tryfonas, "<i>IPv6 Multicast Forwarding in RPL-Based Wireless Sensor Networks</i>", Wireless Personal Communications, Springer US, 73(3), pp. 1089-1116, 2013 [ <a href="http://dx.doi.org/10.1007/s11277-013-1250-5">doi</a> ]
</div>
<div style="padding-left: 22px; text-indent: -22px;">
[2] G. Oikonomou, I. Phillips, "Stateless Multicast Forwarding with RPL in 6LoWPAN Sensor Networks", in <i>Proc. 2012 IEEE International Conference on Pervasive Computing and Communications Workshops (PERCOM Workshops)</i>, Lugano, Switzerland, pp. 272-277, 2012 [ <a href="http://dx.doi.org/10.1109/PerComW.2012.6197494">doi</a> ]
</div>
<div style="padding-left: 22px; text-indent: -22px;">
[3] J. Hui, R. Kelsey, "Multicast Forwarding Using Trickle", IETF Internet Draft (version 01) [ <a href="http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-01">url</a> ]
</div>
</p>
geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-49003420027301598812012-11-04T20:28:00.001+00:002012-11-04T20:39:16.181+00:00Contiki for the cc2531 USB Stick: At long last...As of a couple of days ago, the <a href="http://www.contiki-os.org/">Contiki</a> embedded Operating System for the Internet of Things will now run on TI's excellent <a href="http://www.ti.com/tool/cc2531emk">cc2531 USB dongles</a> (and by '<i>run</i>' I mean '<i>properly, with USB support</i>'). Currently, we can put the USB dongle in CDC-ACM mode but, with the backbone of the driver in place, I am hoping that support for other device classes will start appearing soon (I've already heard people mentioning HID and ECM).<br />
<br />
I successfully ran a <a href="https://github.com/g-oikonomou/contiki-sensinode/tree/cc-ports/examples/cc2530dk/border-router">6LoWPAN border router</a> on one of these little things and it's bloody fast, compared to standard UART-based approaches (e.g. a Sensinode n601 or a cc2530 EM on a SmartRF). <u>Extremely unscientific tests</u> show an average 30% RTT reduction when communicating (IPv6 ping) between the linux host and the USB stick. I'm sure I've saved those benchmarks somewhere...<br />
<br />
I also successfully ran a <a href="https://github.com/g-oikonomou/contiki-sensinode/tree/cc-ports/examples/cc2530dk/sniffer">.15.4 sniffer</a> on a USB stick. More on that in a future blog post, stay tuned!<br />
<br />
The USB code is largely based on a USB framework for ARM CPUs which pre-existed in the contiki source tree. Philippe Rétornaz (EPFL) made a bunch of adjustments to it so that it would play nicely with the cc2531. He also wrote the low level USB driver. I took all that and did a series of contikifications.<br />
<br />
The framework, driver etc are hosted in branch <span style="font-family: "Courier New",Courier,monospace;">master</span> of contiki's <a href="https://github.com/contiki-os/contiki">official github repo</a>. If you are interested in further gory details, have a look at <a href="https://github.com/contiki-os/contiki/pull/18">pull request #18</a> or commits <span style="font-family: "Courier New",Courier,monospace;"><a href="https://github.com/contiki-os/contiki/commit/0e55eb09479c2247b920d8b1db44988f8e621701">0e55eb0947</a>..<a href="https://github.com/contiki-os/contiki/commit/79cffa030fe8417295a96dfbc778f628b0f147d7">79cffa030f</a></span>. As ever, in order to get proper 6LoWPAN functionality on those things without a gazillion crashes, you will need to use the <span style="font-family: "Courier New",Courier,monospace;">cc-ports</span> branch on <a href="https://github.com/g-oikonomou/contiki-sensinode">contiki-sensinode</a>.<br />
<br />
Some more information can be found on the contiki wiki, in the <a href="https://github.com/contiki-os/contiki/wiki/8051-Based-Platforms">8051-related pages</a> (which I've only recently moved to the GitHub wiki over from the old location) <br />
<br />
As ever, feedback is invited and would be extremely appreciated.geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBristol, UK51.454513 -2.5879151.375358999999996 -2.7458385 51.533667 -2.4299815tag:blogger.com,1999:blog-5115604190536954103.post-68056258405562588922012-04-09T01:44:00.001+01:002012-04-09T02:44:24.430+01:00bibtexbrowser... Music for Publication Lists (Part II)<h4 style="font-weight: normal;">
<i><span style="font-size: large;">
Embed bibtexbrowser in your web page</span></i></h4>
<br />
<a href="http://blog.spd.gr/2012/04/bibtexbrowser-music-for-publication.html">« Part I - A journey through the realms of boredom...</a><br />
<br />
In Part I of this post I shared my thoughts on personal publication lists and I documented my reasons for using <span class="bibauthor">Martin Monperrus' </span><a href="http://www.monperrus.net/martin/bibtexbrowser/">bibtexbrowser</a> in my web page.<br />
<br />
The script is very simple to install and works off-the-shelf. However, with a bit of tweaking we can achieve better integration with the rest of our site. In this part, I shall share my experiences from customising it, hoping that it might help others who decide to use it.<br />
<br />
<h3>
Modes</h3>
We can run bibtexbrowser in 3 modes:<br />
<ul>
<li>Stand Alone: When you directly invoke <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.php</span> and let it generate an entire page. This will <a href="http://www.monperrus.net/martin/bibtexbrowser.php?bib=metrics.bib&all">look like this</a> or <a href="http://www.monperrus.net/martin/bibtexbrowser.php?frameset&bib=monperrus.bib">like this</a> (frameset display).</li>
<li>Embedded: When you use it inside your own page and you get it to generate a section. A page like that can be <a href="http://www.monperrus.net/martin/publications">seen here</a>.</li>
<li>As a library: In this mode, it parses your bib DB and populates its data structures but it doesn't generate any HTML until you ask it to do so at a later stage. More on that later.</li>
</ul>
<br />
<h3>
Basic Configuration</h3>
<span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.php</span> includes <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.local.php</span>. This is your chance to override the default configuration and make local changes. So for example if you want to turn off Javascript progressive enhancement, you'd add the line below to your <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.local.php</span>:
<br />
<pre class="brush: php">define('BIBTEXBROWSER_USE_PROGRESSIVE_ENHANCEMENT',false);
</pre>
It's documented quite well <a href="http://www.monperrus.net/martin/bibtexbrowser/#Bycreatingabibtexbrowserlocalphp">here</a>, so not a lot to say. It's being mentioned here cause we'll use it plenty later on.<br />
<br />
<h3>
Embedded Mode </h3>
This is also <a href="http://www.monperrus.net/martin/bibtexbrowser/#Howtoembedyourpublicationlistinyourhomepage">well documented in bibtexbrowser's page</a>. Let's assume that you have a php script called <span style="font-family: "Courier New",Courier,monospace;">pubs.php</span> and you want to embed your publications list. You will do something like this:<br />
<pre class="brush: php"><?php
$_GET['bib']='mybib.bib';
$_GET['author']='Your Name';
include( 'bibtexbrowser.php' );
?>
</pre>
That's it. The only thing to do afterwards is write CSS styles to make the generated output looks like the rest of your page.<br />
<br />
<h3>
Library Mode</h3>
<i>But in frameset mode there are great and handy authors, years, types and other menus on the left. Why can't I have them in embedded mode?</i><br />
<br />
If you browse through bibtexbrowser's code, you will see something about a '<i>New undocumented feature</i>' (in version v20111211 this is near line 1746). In your embedding <span style="font-family: "Courier New",Courier,monospace;">pubs.php</span> script where you include bibtexbrowser, you can do this (notice line 1):
<br />
<pre class="brush: php">$_GET['library']=1;
$_GET['bib']='mybib.bib';
$_GET['all']=1;
include( 'bibtexbrowser.php' );
/* We have included bibtexbrowser but it's not generated anything yet */
setDB(); /* Read the bibliography and populate data structures */
new IndependentYearMenu(); /* Generate the years menu */
/* Do more stuff */
new Dispatcher(); /* Generate bibtexbrowser HTML */
</pre>
This <span style="font-family: "Courier New",Courier,monospace;">IndependentYearMenu()</span> function generates the HTML for the year menu (it does, honest!). Remember, your <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.local.php</span> is your friend. You can copy this function over from <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.php</span> and modify it as you please. This is how I'm generating my custom authors menu:<br />
<pre class="brush: php"><?php
class CustomAuthorsMenu {
function CustomAuthorsMenu() {
if (!isset($_GET[Q_DB])) {die('Did you forget to call setDB() before instantiating this class?');}
$authorIndex = $_GET[Q_DB]->authorIndex();
?>
<div id="authormenu" class="filterbox toolbox">
<div class="filterprop">
<a href="#authormenu" title="Expand/Collapse" onclick="toggle_toolbox('authorlist'); return false;">±</a>
</div>
<span class="this">Authors:</span>
<div class="filterlist" id="authorlist">
<?php
echo '<span><a '.makeHref(array(Q_AUTHOR=>'.*')).'>All</a></span>'."\n";
foreach($authorIndex as $author) {
echo '<span><a '.makeHref(array(Q_AUTHOR=>$author)).'>'.$author.'</a></span>'."\n";
}
?>
</div>
</div>
<?php
}
}
?>
</pre>
Between <span style="font-family: "Courier New",Courier,monospace;">setDB()</span> and <span style="font-family: "Courier New",Courier,monospace;">new Dispatcher()</span> you can do whatever you like. So this is how I'm loading bibtexbrowser (in my <span style="font-family: "Courier New",Courier,monospace;">pubs.php</span>):<br />
<pre class="brush: php"><?php
$_GET['library']=1;
$_GET['bib']='geo.bib;authors.bib';
$_GET['all']=1;
include('bibtexbrowser.php');
setDB();
new CustomAuthorsMenu();
new CustomYearMenu();
?>
<div id="bodyText">
<?php
include('Template/conditions.php');
new Dispatcher();
?>
</div> </pre>
The process is similar for the years menu. The outcome can be <a href="http://www.spd.gr/pubs.php?Academic">seen here</a>. Check out the author and year menus on the left.<br />
<br />
<h3>
But, what about the search form?</h3>
The form is generated by function <span style="font-family: "Courier New",Courier,monospace;">searchView()</span>, which doesn't get called in embedded mode. Similar process, we can copy it over to our <span style="font-family: "Courier New",Courier,monospace;">pubs.php</span> and modify it.
<br />
<pre class="brush: html"><form action="?Academic" method="get">
<div class="sortbox toolbox">
<a href="#" onclick="toggle();return false;">Raw List / Grouped<br /></a>
<a href="?Academic">By Type<br /></a>
<a href="?Year">By Year<br /></a>
<div class="search">
<input type="text" name="search" class="input_box" id="searchtext"/>
<input type="hidden" name="bib" value="geo.bib"/>
<input type="submit" value="search" class="input_box"/>
</div>
</div>
</form>
</pre>
Those of you who are observant will have noticed that, compared to the original:<br />
<ul>
<li>I've replaced bibtexbrower's constants with hard-coded values. This is because I'm generating the form at the wrong position in the script, we can do it after including <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.php</span> and keep the constants. I'll be changing that soon...</li>
<li>I'm putting the entire <span style="font-family: "Courier New",Courier,monospace;"><div></span> inside the <span style="font-family: "Courier New",Courier,monospace;"><form></span> and not the other way round. This is for XHTML 1.1 compliance. More on that later.</li>
</ul>
<br />
<h3>
Individual Publication Pages</h3>
bibtexbrowser can also display an individual page for a publication, such as for example <a href="http://www.monperrus.net/martin/bibtexbrowser.php?bib=monperrus.bib&key=monperrus08d">this one</a>. If you look at this page's source, you will notice many lines like these:<br />
<pre class="brush: html"><meta name="DC.Title" content="A Model-driven Measurement Approach"/>
<meta name="citation_title" content="A Model-driven Measurement Approach"/>
</pre>
These lines are my favorite bibtexbrowser feature: bibliographic metadata. The first one is Dublin Core, the second is google scholar metadata. The problem here is that if you run bibtexbrowser embedded, the script that generates the page's head is the embedding script, not bibtexbrowser.
Bottom line, I advise against running individual pages embedded.<br />
<br />
An idea that I'm planning to have a stab at is to change the bibtexbrowser script so that when it encounters the argument <span style="font-family: "Courier New",Courier,monospace;">key</span><span style="font-family: inherit;">,</span> it will generate the metadata headers and COinS before bailing out. Then, the embedding script can call suitable methods, retrieve the values and add them to the generated page's head.<br />
<br />
<h3>
XHTML 1.1</h3>
bibtexbrowser generates valid XHTML 1.0 Transitional. That's great but that rest of my site is XHTML 1.1. If we try to validate the page as 1.1, we get the following error:<br />
<br />
Line X, Column Y: there is no attribute "name"
<br />
<span style="font-family: "Courier New",Courier,monospace;"><td class="bibref"><a name= <span style="color: red;">" </span>2"></span><br />
<br />
The workaround to this one is simple, just change <span style="font-family: "Courier New",Courier,monospace;">name="foo"</span> to <span style="font-family: "Courier New",Courier,monospace;">id="foo"</span>, like so:
<br />
<pre class="brush: diff">--- /Users/cexgo/Documents/spd.gr/bibtexbrowser.php.txt 2012-04-05 14:23:24.000000000 +0100
+++ bibtexbrowser.php 2012-04-09 00:54:01.000000000 +0100
@@ -1336,28 +1338,41 @@ class BibEntry {
*/
function toTR() {
echo '<tr class="bibline">';
- echo '<td class="bibref"><a name="'.$this->getId().'"></a>['.$this->getAbbrv().']</td> ';
+ echo '<td class="bibref"><a id="id'.$this->getId().'"></a>['.$this->getAbbrv().']</td> ';
echo '<td class="bibitem">';
echo bib2html($this);
</pre>
We're not done yet. Even if the markup is valid XHTML 1.1, we need to make sure that page is served as such. When running in embedded more, things are easy since the headers are generated by our own script. In stand-alone mode though, this is what the server sends:
<br />
<pre class="brush: html"><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
</pre>
We need to change the <span style="font-family: "Courier New",Courier,monospace;">DOCTYPE</span> and a few other bits and bobs. Although technically <span style="font-family: "Courier New",Courier,monospace;">Content-type:text/html</span> will work, according to the specs it may not be used and should be replaced by <span style="font-family: "Courier New",Courier,monospace;">application/xhtml+xml</span>. Here's how I've patched <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.php</span>:
<br />
<pre class="brush: patch">--- /Users/cexgo/Documents/spd.gr/bibtexbrowser.php.txt 2012-04-05 14:23:24.000000000 +0100
+++ bibtexbrowser.php 2012-04-09 00:54:01.000000000 +0100
@@ -2878,13 +2916,13 @@ function HTMLWrapper(&$content,$metatags=array()/* an array name=>value*/) {
// when we load a page with AJAX
// the HTTP header is taken into account, not the <meta http-equiv>
-header('Content-type: text/html; charset='.ENCODING);
-echo '<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">'."\n";
-
+ header ("Content-Type:application/xhtml+xml; charset=utf-8");
+ echo '<?xml version="1.0" encoding="UTF-8"?>'."\n"
?>
-<html xmlns="http://www.w3.org/1999/xhtml">
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
-<meta http-equiv="Content-Type" content="text/html; charset=<?php echo ENCODING ?>"/>
+<meta http-equiv="Content-Type" application/xhtml+xml; charset=UTF-8"/>
<meta name="generator" content="bibtexbrowser v20111211" />
<?php if ($content->getRSS()!='') echo '<link rel="alternate" type="application/rss+xml" title="RSS" href="'.$content->getRSS().'&amp;rss" />'; ?>
<?php
</pre>
A few more things to keep in mind. By default bibtexbrowser opens individual pages in the same window/tab. If you prefer using a new tab, you can override the default by adding this to your <span style="font-family: "Courier New",Courier,monospace;">bibtexbrowser.local.php</span><span style="font-family: inherit;">:</span>
<br />
<pre class="brush: php">define('BIBTEXBROWSER_BIB_IN_NEW_WINDOW',true);
</pre>
If you do that, you will find that some <span style="font-family: "Courier New",Courier,monospace;">target="foo"</span> will creep in the generated markup. The page will not validate against XHTML 1.1 with errors like this:<br />
<br />
Line X, Column Y: there is no attribute "target"<br />
<div style="font-family: "Courier New",Courier,monospace;">
…an</a>, George Oikonomou, "<a target= <span style="color: red;">"</span> _blank" </div>
<br />
I don't have a workaround for the <span style="font-family: "Courier New",Courier,monospace;">target="_blank"</span> thing since it's a feature that I'm never going to use, I just had to point it out since I noticed it. Lastly, keep in mind that the frameset version will not validate either, due
to the differences in framing methods between XHTML 1.0 and 1.1. If you try to solve this, you are probably looking at quite a beast.<br />
<br />
<h3>
Summary</h3>
<h3>
</h3>
In order to better integrate <a href="http://www.monperrus.net/martin/bibtexbrowser/">bibtexbrowser</a> with my publication list <a href="http://www.spd.gr/pubs.php">here</a>, I made a few modifications and tweaks. I believe that bibtexbrowser is an excellent script. In this post I am sharing my observations, hoping to help those of you who want to exploit some of its cool features and who are curious enough to want to take things a few steps further than a vanilla
installation.<br />
<br />
<a href="http://blog.spd.gr/2012/04/bibtexbrowser-music-for-publication.html">« Part I - A journey through the realms of boredom...</a>geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBristol, UK51.454513 -2.5879151.375358 -2.7458385 51.533668 -2.4299815tag:blogger.com,1999:blog-5115604190536954103.post-47042437963500266922012-04-08T18:42:00.000+01:002012-04-09T03:19:37.100+01:00bibtexbrowser... Music for Publication Lists (Part I)<span style="font-size: large;"><i>A journey through the realms of boredom...</i></span><br />
<div style="text-align: right;">
<br />
<a href="http://blog.spd.gr/2012/04/bibtexbrowser-music-for-publication_09.html">Part II - Embed bibtexbrowser in your web page »</a></div>
<br />
If your job involves writing academic papers, you have no real option but to maintain a publications list on your web page.<br />
<br />
<div style="font-family: "Courier New",Courier,monospace;">
<rant></div>
<blockquote class="tr_bq">
To make things worse, in addition to an author's personal page, there is the institutional page which also needs kept up-to-date. </blockquote>
<blockquote class="tr_bq">
Some are still stuck with good old <span style="font-family: "Courier New",Courier,monospace;">~geo/public_html</span> pages and manual updates. Most organisations have taken a step forward and have implemented their own bespoke publication management systems ('<i>institutional repositories</i>'). Those systems usually share some common characteristics: i) a poor attempt at a catchy "<span style="font-family: "Courier New",Courier,monospace;">SOME-ACRO</span>" name, ii) they cost $£¥€ to develop and iii) they are quite <i>rubbish</i>... </blockquote>
<blockquote class="tr_bq">
I mean seriously people, <i>import from bibtex</i> <u>must</u> be the <u>first</u> feature to implement, yet whenever I've landed a new job I've had to spend hours in front of some appalling, counter-intuitive, pointy pointy clicky clicky web-based interface, manually data-entering my (short) publication list. And then the management complains if the list is not being kept updated. </blockquote>
<blockquote class="tr_bq">
I can't even begin to imagine life for people with very long lists, (although I suspect they also have the option to delegate the task). Sometimes I wonder if this is why the term '<i>Selected Papers</i>' was invented in the first place...</blockquote>
<div style="font-family: "Courier New",Courier,monospace;">
</rant></div>
<br />
But back to our personal web page. Doing everything manually is obviously not an option; it's tedious,
boring, error-prone and deprives you of all the features that you could
get if you were to generate the page dynamically (sort, search etc).<br />
<br />
<i>I simply could not possibly be bothered...</i><br />
<br />
<h3>
First Paradigm: Generate offline, serve statically </h3>
One can write a set of scripts to generate <u>static</u> HTML content from bibliographic data. Whenever the data are updated, content must be re-generated. This however does not necessarily have to be triggered manually by the user. It can be, for example, a cron job which runs every few hours. This is a lot less burden on your back-end than generating a page on the fly every time it's accessed. This is actually a very good approach, since the frequency of updates to a publication list is very low compared to the frequency at which it's being accessed.<br />
<br />
This relies on having scripts which can write directly to the file system hosting the content. If your personal page is hosted in your own box or on some company or university server, this is often not a problem. However, if you are using some commercial hosting company this approach is probably not an option.<br />
<br />
<h3>
Dynamic Generation, Take One</h3>
(or <i>'How to make your own life harder than it needs to be'</i>)<br />
<br />
As discussed earlier, I skipped the manual update business altogether. I would have gone for the approach above but when I mentioned the words <i>shell</i>, <i>cron job</i>, <i>script</i> and <i>make</i> to my hosting provider techies (who happen to be mates), they laughed at me with passion and said "<i>Just generate it dynamically</i>". That was a couple of years ago (or four).<br />
<br />
I then had a quick look around the internet. What I was looking for was a system that would read from bibtex files, generate a page and add various links to each entry (DOI, publisher URL, pre-print pdf if available etc). Unfortunately, I couldn't quite find what I was looking for. Most solutions were either overkill or lacked features, so I ended up knocking together my own php-based system. At that time I was having my first go at php so, being rather clueless, I feared it would take me ages to write a bibtex parser.<br />
<br />
I ended up with an intermediate solution. Here is how it worked, briefly:<br />
<ul>
<li>As a starting point, I kept each paper in its own bibtex.</li>
<li>Using the <a href="http://sourceforge.net/p/bibutils/home/Bibutils/">bibutils suite</a>, I would generate bibliographic data in <a href="http://www.loc.gov/standards/mods/">MODS</a> format - one MODS file from each bibtex file. This was done offline with GNU make. Remember: no shell access to the hosting machine, so this would take place in my own box.</li>
<li>The same build system would collate all individual .bib files to a single bibtex DB.</li>
<li>I would then upload the updated .bib and MODS files to my server. The MODS format is XML so it was very easy to parse in PHP and generate the pages.</li>
</ul>
At the start I thought this was really cool but I quickly started stumbling. Every time I had to make a change, no matter how minor, I had to:<br />
<ul>
<li>Run make</li>
<li>Identify which bib and MODS files were affected by the change and re-upload them to the server. I'd also have to upload the integrated bib DB (which I would often forget).</li>
</ul>
A small typo or encoding error in the bib: make and upload. Paper got accepted: make and upload. Paper went live in ieeexplore and got a doi: make and upload. To make matters even worse, my web hosting uses a point and click upload interface so I couldn't even script the upload. I <u>had</u> to do it by hand but it was still a lot better than manually maintained static pages.<br />
<br />
It only took a couple of new <span style="font-size: small;">papers</span>, a few dozen typos and a few thousand clicks to realise that:<br />
<br />
<span style="font-size: small;"><i>I </i></span><span style="font-size: small;"><i>simply </i></span><span style="font-size: small;"><i>could no longer be bothered...</i></span><br />
<br />
<h3>
Next Attempt at Dynamic Generation: bibtexbrowser</h3>
(or <i>'I wish I'd spotted this earlier'...</i>)<br />
<br />
Thursday the 5th April 2012 was a day of revelation. That time came again when I had to update my publications list but I'd had enough of make/upload cycles. I googled "bibtex php parser" and I came across <a href="http://www.monperrus.net/martin/bibtexbrowser/">Martin Monperrus' bibtexbrowser</a>. This excellent php script does exactly what I needed but hadn't found previously: The user uploads a bibtex file to the hosting box, the script generates the publication list on the fly.<br />
<br />
The paradigm is the same as my previous system: '<i>php reads bibliography DB, php generates page</i>'. However, it does so straight from the bibtex file without the need of an intermediate format, thus reducing maintenance overhead from '<i>annoying</i>' to '<i>ridiculously trivial</i>'.<br />
<br />
It also has a few features that give it even further added value:<br />
<ul>
<li>It can be used standalone, embedded in your own page or as a library. The library functionality is rather awesome but undocumented at the
moment, I only found out about it by reading a bunch of comments inside
the script.</li>
<li>It is very easy to customise.</li>
<li>It adds google scholar meta-data to your pages (and eprints and Dublin Core, if you want).</li>
<li>It generates <a href="http://ocoins.info/">COinS</a> metadata so that software like zotero or mendeley can directly import from your page.</li>
</ul>
I played around with it over the last couple of days. Not only did it make me put the previous system swiftly in the bin, but it also made me want to tell the world how good it is.<br />
<br />
In the next part of this post, I am going to share my experiences from customising it.<br />
<br />
<div style="text-align: right;">
<a href="http://blog.spd.gr/2012/04/bibtexbrowser-music-for-publication_09.html">Part II - Embed bibtexbrowser in your web page »</a></div>geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBristol, UK51.454513 -2.5879151.375358 -2.7458385 51.533668 -2.4299815tag:blogger.com,1999:blog-5115604190536954103.post-86151409004031666322012-04-08T03:43:00.000+01:002012-04-13T15:14:21.836+01:00Multicast Support for 6LoWPANs with the Contiki OSA few months ago I started work on adding IPv6 multicast support to the <a href="http://www.contiki-os.org/">Contiki</a> Operating System. This effort has resulted in extensions to Contiki's core networking code and its RPL implementation. Additionally, I have implemented two multcast forwarding algorithms:<br />
<ul>
<li><b>Multicast Forwarding with Trickle</b>: This implements the multicast algorithm described in <a href="http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast">this internet draft</a>. </li>
<li><b>Stateless Multicast RPL Forwarding (SMRF)</b>: The RPL routing protocol enters Mode of Operation (MOP) 3 and handles multicast group management as per the RPL documents. SMRF is a lightweight engine which handles datagram forwarding.</li>
</ul>
SMRF is described in detail <a href="http://www.spd.gr/pubs.php?key=Oikonomou-2012-1-persens&bib=geo.bib%253Bauthors.bib">in this paper</a>, alongside a thorough comparison between the two algorithms in terms of performance, datagram loss rates and energy consumption.<br />
<br />
The implementation is currently under review by the core Contiki developer team, awaiting their approval before I can push it upstream. Until that day, it is <a href="https://github.com/g-oikonomou/contiki-sensinode/tree/mcast-forward">hosted on github</a> (branch '<span style="font-family: "Courier New",Courier,monospace;">mcast-forward</span>'), as a fork of the Contiki OS.<br />
<br />
I have tested things with the Cooja simulator (msp430-gcc) as well as with cc2530/cc2430 devices (sdcc). I am especially interested in success/failure reports on devices relying on other toolchains, such as AVR-based nodes or econotags, since I don't have access to the hardware.<br />
<br />
Feel free to have a stab!geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBristol, UK51.454513 -2.5879151.375358 -2.7458385 51.533668 -2.4299815tag:blogger.com,1999:blog-5115604190536954103.post-86083268707560944002012-04-05T14:02:00.002+01:002012-04-05T14:02:59.181+01:00Contiki's cc2x30 ports are now upstream<a href="http://www.contiki-os.org/">Contiki</a>'s ports for TI's cc2530 Development Kit and Sensinode/cc2430 devices have been merged back upstream and I shall be maintaining them actively.<br />
<br />
Users who wish to use them, should first read the guides listed <a href="http://www.sics.se/contiki/wiki/index.php/8051_Based_Platforms">here</a>. Examples can be found in <span style="font-family: "Courier New",Courier,monospace;">$CONTIKI/examples/cc2530dk</span> and <span style="font-family: "Courier New",Courier,monospace;">examples/sensinode</span>. With a correct <a href="http://sdcc.sourceforge.net/">SDCC</a> installation, you can expect examples from these directories in Contiki's <span style="font-family: "Courier New",Courier,monospace;">master</span> branch to compile cleanly.<br />
<br />
Examples demonstrating basic functionality (non-uIPv6) should work off the shelf. If they don't, you are possibly looking at a bug so feel free to shout on the <a href="http://lists.sourceforge.net/lists/listinfo/contiki-developers">contiki-developers mailing list</a>.<br />
<br />
For more advanced examples (uIPv6), we need a set of patches to Contiki's core, aiming to reduce stack depth during code execution and prevent overflows. These patches not very suitable for other Contiki platforms so they are highly unlikely to ever be merged upstream. They are currently being hosted on GitHub, on a <a href="https://github.com/g-oikonomou/contiki-sensinode">fork of the Contiki git repo</a> (branch <span style="font-family: "Courier New",Courier,monospace;">cc-ports</span>). More techy details, whys and hows can be found <a href="http://www.sics.se/contiki/wiki/index.php/8051_Memory_Spaces">here</a>.<br />
<br />
Enjoy!geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comBristol, UK51.454513 -2.5879151.375358 -2.7458385 51.533668 -2.4299815tag:blogger.com,1999:blog-5115604190536954103.post-80647273043121561162011-12-21T21:33:00.000+00:002011-12-21T21:33:48.688+00:00Good paper... must... reject...A colleague and I recently received the review outcome for one of our conference papers. This is an excerpt of the feedback from one of the reviewers: <br />
<blockquote class="tr_bq">
<b>*** Reasons to accept: Please give the main reasons for accepting the paper.</b><br />
<i>(this was actually blank)</i><br />
<br />
<b>*** Reasons to reject: Please give the main reasons for rejecting the paper.</b><br />
This article is very well written. The contribution is interesting and the results are encouraging.
</blockquote>
The final outcome was "accept" :Dgeohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-70720016527136034532011-12-21T21:09:00.000+00:002011-12-21T21:11:32.037+00:00Guesticide!I was browsing through a recent issue of the <a href="http://www.timeshighereducation.co.uk/">Times Higher Education</a> today and I stumbled across a very fascinating article. It is entitled "<a href="http://www.timeshighereducation.co.uk/story.asp?storycode=418055">Research Intelligence - Phantom and parasitical menaces</a>" and is dated November the 10<sup>th</sup> 2011.<br />
<br />
The article is a report on a survey published by the British Medical Journal, on the phenomena of <i>guest</i> and <i>ghost</i> authors on academic publications. The survey's title is "Honorary and ghost authorship in high impact biomedical journals: a cross sectional survey". The original survey (<cite><abbr class="slug-jnl-abbrev" title="bmj.com">BMJ</abbr>
<span class="slug-pop-date">2011;</span><span class="pop-slug">343:d6128) </span></cite>was aired in October 2011, with a subsequent correction (<cite><abbr class="slug-jnl-abbrev" title="bmj.com">BMJ</abbr>
<span class="slug-pop-date">2011;</span><span class="pop-slug">343:d7677) </span></cite>published in November 2011.<br />
<br />
This is a link to the publication: <a href="http://www.bmj.com/content/343/bmj.d6128.full">http://www.bmj.com/content/343/bmj.d6128.full</a><cite></cite><br />
The correction can be found here: <a href="http://www.bmj.com/content/343/bmj.d7677">http://www.bmj.com/content/343/bmj.d7677</a><cite></cite><br />
<br />
In my humble opinion, the interesting part is not the discussion on the phenomena themselves. Rather, it is the discussion on methods to decrease their occurrence. THE's article lists various recommendations, from various sources. Among them are ghost/guest explicit prohibition; signed contribution statements from authors; publications bans; more rigid institutional monitoring; legal action. Some may seem a tad bureaucratic or unrealistic but, to me, this is an indication that the community acknowledges the situation as a problem that needs solved.<br />
<br />
Being outside the biomedical field myself, I will refrain from commenting on the <i>ghost</i> part. When it comes to <i>guests</i> though, I shall point you to the first reader comment (the one on November the 10<sup>th</sup>) below THE's article. Read the third paragraph, the one starting with "On reason for this...".<br />
<br />
Having read this comment, I have nothing further to say...geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-66604025563821052682011-12-15T21:17:00.004+00:002011-12-21T19:52:47.271+00:00Contiki for cc2530 with uIPv6/RPL supportI recently finished porting the <a href="http://www.contiki-os.org/">Contiki Embedded Operating System</a> for <a href="http://www.ti.com/product/cc2530">Texas Instruments cc2530</a> devices.<br />
<br />
The port can be found on github:<br />
<a href="https://github.com/g-oikonomou/contiki-sensinode/wiki">https://github.com/g-oikonomou/contiki-sensinode/wiki</a><br />
<br />
As part of my work for Loughborough University, I have also ported <a href="http://nets-www.lboro.ac.uk/george/contiki-sensinode/index.htm">Contiki for Sensinode/cc2430 </a>devices. Due to hardware similarities, it made sense to co-host the two ports on the same repo.<br />
<br />
Both ports use the <a href="http://sdcc.sourceforge.net/">Small Device C Compiler</a> and have full banking support, which means that we can build working images up to 256 KB (for cc2530-F256) or up to 128KB for Sensinode/cc2430.<br />
<br />
Still a couple of drivers to implement (SmartRF LCD, joystick), but the interesting functionality is all there: IPv6/6LoWPAN support with RPL, UDP and ICMPv6. TCP is currently disabled but I am hoping to enable and test it as soon as I get a chance.<br />
<br />
The cc2530 porting effort would have been impossible without the direct
support from TI, who kindly donated development/testing kit. Many thanks to them!geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comtag:blogger.com,1999:blog-5115604190536954103.post-52567532438896314732011-10-30T22:40:00.000+00:002011-10-30T22:40:23.133+00:00A Tribute to bkarak and to humanity, in generalMy mate <a href="http://bkarak.wizhut.com/blog">bkarak</a> and I share a very complex relationship. Since the dawn of our acquaintance, he has been telling me what I should be doing, often with a very obnoxious, tactless attitude.<br />
<br />
"<i>If you don't move to the UK, I'll start launching pies towards your face</i>", "<i>What are you waiting for? Move it!!!</i>" ... you get the idea.<br />
<br />
History often repeats itself. What usually happens is, I ignore him (on occasion invoking pathetic excuses) till he picks a new topic to pester me about. I usually wait, very patiently, for things to settle down. More often than not, once they have I then go ahead and do what he had been telling me to do all along, claiming that it was my infinite wisdom that guided my decision. The dreaded "<i>I told you so!</i>" is often a significant part of our conversations.<br />
<br />
The flavor of the past couple of weeks has been "<i>You should put your work on a blog and get some visibility</i> <+ obnoxious emphasis>". Faithful to tradition and after having brushed him off for long enough, I now start populating this blog with an entry dedicated to his infinite kara-wisdom. <br />
<br />
Despite his astounding "<i>finesse"</i>, bkarak is a very efficient rationalist when it comes to advising other people on a course of action. Sadly, he's not equally perceptive when it comes to following his own advice. That is to say, as opposed to other human beings (self included), who always practice what they preach.<br />
<br />
... or do they?geohttp://www.blogger.com/profile/15197214201151847712noreply@blogger.comLoughborough, Leicestershire, UK52.7707741 -1.204346752.7323476 -1.2833107000000001 52.8092006 -1.1253827