Surprising Combinations

After reading the report of the European Mars Lander Crash investigation (and growing frustration with C as an embedded programming language), I started to look into Ada about a year ago. The Make With Ada contest, the availability of runtimes and drivers for embedded systems, and the promise of a standardised framework for real-time programming made this a very interesting journey.

Unfortunately, my go-to MCU (STM32F051, cheap, easily available, good development boards) is very low end, and the tasking part of the AdaCore runtimes are not yet fully working on Cortex M0 MCUs: My remote sensor program would run into an error of a nested lock operation because of missing hardware spin lock support on M0 cores.

Fortunately, a solution which first seemed overly complex but which turned out to be very elegant turned up, a of the higher level Ada runtime to FreeRTOS. FreeRTOS has very wide platform support, and runs without problem on the STM32F051.

Moving my existing code to Simon Wright's work was surprisingly simple (proving the advantage of standardising real time concepts in the language level), only the stack sizes for the tasks had to be adjusted. After years of pointer arithmetic, buffer overflows, and casting, Ada is a refreshing change!

Warm and fuzzy feelings

You have to hand it to the Newton Community, even twenty years after the Newton was canceled, it can still generate that warm and fuzzy feeling. Hats off to Noah Leon for creating a lovely movie which captures the spirit of this group! And it is of course a great honor to be part of it, it is not very often that you get the chance to appear alongside of one of Apple's past CEOs ;)

The thumbulator

I now pushed the thumbulator branch as the new master branch for CoreForth. The idea behind thumbulator is to have just enough of a host based virtual environment to compile Forth source, and dump the resulting binary which can then be flashed. The .elf file is therefore now just an intermediate file, it could be flashed, but contains only the core part. However, if thumbulator fails to run or produce a binary, it will silently still create a garbage binary, which won't flash properly. I guess I need to make that part more robust :)

When writing CoreForth, I got quite far with the assembly based pseudo code approach, but at some point, I wanted to switch to high level code. Metacompilation is probably the right approach but I felt it would require a rewrite of the whole system. Same with a tethered Forth. I also was using qemu for experimenting without hardware, and the 1.0 branch of CoreForth was just converting the Forth byte code into assembly sources for later compilation via an assembler.

qemu seemed a bit heavy though, and with thumbulator I found a lightweight way to have a host based environment to produce a target binary. This works as long as there are no fancy hardware dependencies at compile time, but usually, there aren't any ;) And if something is desperately needed, it is pretty easy to extend thumbulator.

Just checking ...

Call me a pessimist (or long term thinker), but the other day, I just had to check if my Pismo PowerBook G3 still boots, and if I can still compile the Newton Y2010 patch. The way things are going, it looks like I'll still be using my MessagePad when the next iteration of the Y2010 patch is due (around 2026).

Si4012 and CC1101

Something completely different for a change: I recently designed a simple sensor network, and wanted to keep the cost of the sensor nodes down while using the 434MHz band for range reasons. The Silicon Labs Si4012 transmitter fit the bill very nicely, but I was already happily using a Texas Instruments CC1101 radio as the receiver.

Below are the settings for the CC1101 and Si4012, the modulation is 2-FSK and the bit rate is 38.4kpbs. First the CC1101 register settings:

static constexpr uint8_t cc110x_default_init_values[][2] = {
        {CC1101_IOCFG0,      0x2F},
        {CC1101_IOCFG1,      0x2F},
        {CC1101_IOCFG2,      0x06},
        {CC1101_FIFOTHR,     0x47}, // RX attenuation 6dB, 33/32 byte threshold
        {CC1101_PKTLEN,      0x3D}, // 62 bytes max packet length
        {CC1101_PKTCTRL1,    0x0C}, // CRC autoflush, status append
        {CC1101_PKTCTRL0,    0x05}, // TX/RX CRC enabled, variable packet length
        {CC1101_FSCTRL1,     0x06}, // 152kHz IF frequency
        {CC1101_FREQ2,       0x10}, // 434 MHz carrier frequency
        {CC1101_FREQ1,       0xB1},
        {CC1101_FREQ0,       0x3B},
        {CC1101_MDMCFG4,     0xFA}, // 135kHz channel bandwidth
        {CC1101_MDMCFG3,     0x83}, // 38.4kbps symbol rate
        {CC1101_MDMCFG2,     0x06}, // 2-FSK, 16/16 sync word detection, carrier sense
        {CC1101_MDMCFG1,     0x42}, // 8 bytes preamble
        {CC1101_DEVIATN,     0x27}, // 11.9kHz FSK deviation
        {CC1101_MCSM1,       0x3c},
        {CC1101_MCSM0,       0x18},
        {CC1101_FOCCFG,      0x16},
        {CC1101_WORCTRL,     0xFB},
        {CC1101_FSCAL3,      0xE9},
        {CC1101_FSCAL2,      0x2A},
        {CC1101_FSCAL1,      0x00},
        {CC1101_FSCAL0,      0x1F},
        {CC1101_TEST2,       0x81},
        {CC1101_TEST1,       0x35},
        {CC1101_TEST0,       0x09},

And this is the Si4012 configuration (these are properties, to be set via the SET_PROPERTY command:

static constexpr uint8_t pa_config[7] = {0x60, 0x01, 0x71, 0x00, 0x19, 0x7d, 0xff};
static constexpr uint8_t tx_freq[5] = {0x40, 0x19, 0xde, 0x7f, 0x60};
static constexpr uint8_t modulation_fskdev[3] = {0x20, 0x01, 0x0b};
static constexpr uint8_t bitrate_config[4] = {0x31, 0x01, 0x80, 0x04};
static constexpr uint8_t chip_config[2] = {0x10, 0x00};

When sending from the Si4012, the preamble (8 x 0xaa), the sync word (0xd391) and the CRC need to be added manually to the packet.

Slightly strange combination

Continuing the praise for the J-Link SWD/JTAG adapter, it works well in even slighly odd situations. The new Intel Quark D1000 is debugged via JTAG, but uses an IO voltage of 1.8V. My old Olimex ARM-USB-TINY-H adapter doesn't go as low, but using the J-Link with OpenOCD worked like a charm!

Things which Just Work

It's about time to praise two tools which I'm using very frequently and which have saved my day time and again: The Saleae Logic Analyzer and the J-Link SWD/JTAG adapter.

Both tools "just work" without any fuzz, and on my development platforms Mac OS X, Linux and Windows. The Saleae comes with very easy to use software, has nicely engineered hardware, extensibility and awesome support (three years warranty!). The J-Link is maybe not as sexy, but it handles the key task of debugging, flashing and interfacing with GDB without hiccups.

For both tools, cheap clones do exist, but it is a no brainer to spend a little more money to reward the excellent work that went into them.

PS: Yes, the Apple Newton also falls into this category, but I don't think that needs to be explicitly pointed out ;)

Little motes here and there

Since the internet of things is all the rage, I wanted to do some learning by doing, and set up an own small network to experiment a little. It seems that there are a lot of technologies to chose from, and that on all layers: Different radio technologies, different processors, different protocols and so on. I settled for now on SWAP as the protocol since it's easy enough, but I'm using the widely available NRF24L01+ chips for the radio layer. The CPUs are a mix of MSP430's, LPC1114's and STM32F0's, running either a bare metal program (MSP430 and STM32F0) or mbed (LPC1114).

It has been a very interesting experience so far, and in good hacker manner, doing things from first principle gives a lot of insights: How to get power consumption to the micro ampere level? How to build small and simple hardware designs? What are good antenna designs? What about quality of service, packet loss, etc? How to visualise data and use it in smart ways?

The biggest problem is however a very common one: What to actually build with all that stuff :)?

A Subjective Classification of MCUs

  • MSP430 (the smaller x2 series): Like a trusted friend or cosy small home. Limited, but things work as expected.
  • ATmega328: Crufty and rusty. Glad there are abstraction layers to hide that.
  • STM32: Shiny weapon of choice (with some rough edges here and there).

Newton Projects in Modern Times

I really like GitHub for easy hosting and version control of software project sources, but it is just not that easy to use for Newton NTK projects. Mark Mason's story of how he open sourced Dashboard is a great read about how he mastered the challenges of resource forks, lost sources, ancient version control systems and so on to get Dashboard onto GitHub. Even more, the stuff under the obsolete files folder is pretty hilarious ;)

tntk avoids these issues by being text based, but this comes at the loss of a graphical UI builder. I'm not too bothered by this, but it appears that the easiest way to go back in time and create Newton apps the way they were intended to be implemented is to get a fast and reliable PPC based Mac, install Classic, and head back to the future ;) - and don't forget to back up frequently!