As the last few days of 2015 pass, I’d like to reflect on the recent past but also look forward to things to come. For one, the JeeLabs weblog is now thriving again: the new weekly post-plus-articles format has turned out to suit me well. It keeps me going, it’s oodles of fun to do, and it avoids that previous trap of getting forced into too-frequent daily commitments.

Apart from a summer break, every week in 2015 has been an opportunity to explore and experiment with physical computing topics, several ARM µCs, and various software ideas.

Here are the last two articles for 2015:

• Preparing for a new weblog – Wed
• My New Year’s resolutions – Thu

I’d like to close off 2015 with a deeply worrisome but nevertheless hopeful note. While this is a totally technology-focused weblog, it has not escaped me that we live in very troubling times. Never in history have so many people been on the run, fleeing home and country for the most basic of all human needs: a safe place to live. We’ve all seen Aryan Kurdi’s fate:

An innocent three-year old boy, born in the wrong place at the wrong time, trying to escape from armed conflict. He could have been me, he could have been you. His tragic fate and that of many others could have been avoided. Europe offers a peaceful and prosperous home for half a billion people – accommodating one percent more is the least we can do.

I’m proud to see countries rise to the occasion, and put humanity and the planet first. Let’s cherish our compassion as well as our passion, our understanding as well as our creativity. For 2016, I wish you and yours a very open, respectful, and empathy-rich planet.

(For comments, visit the forum area)

As the end of 2015 is approaching and now that the new server setup has been completed, it’s time to clean up some remaining loose ends. Spring cleaning is early, here at JeeLabs!

Next week will be a good time for reflection and my new year’s resolutions. For now, I just want to go into some topics which didn’t seem to fit anywhere else. In daily doses, as usual:

• Getting the most out of rsync – Wed
• Temporary post-HouseMon script – Thu
• Great visibility, no cloud in sight – Fri

I’m pleased with the new Odroid XU4 server so far. The Mac Mini is being re-purposed as Liesbeth’s new Mac – a nice SSD-based setup with 8 GB of RAM. Its Core 2 Duo @ 2.66 GHz will be a step up from the 5-year old 1.4 GHz MacBook Air’s she’s been working on.

Which frees up that 11″ MBA for my own portable use again – it’s a fantastic little laptop!

(For comments, visit the forum area)

As you may know, the various websites here at JeeLabs are served locally. Houten offers very fast Fiber-To-The-Home connections, my ISP (XS4ALL) is excellent, and I don’t see the point of putting everything in the cloud. Sure, it’s a bit more work to keep going, but this way I can delude myself into thinking that I am “the master of my own universe” …

This Mac Mini server has been doing all the work for several years now:

But for various reasons it’s now time to revisit that setup and simplify things further:

• VMs are OUT, Odroid is IN – Wed
• Effortless fallback server – Thu
• Why doesn’t this dream setup exist? – Fri

As you’ll see, I’m jettisoning a lot of dead weight. The resulting server is much cheaper, consumes far less energy, is more robust, has fewer moving parts, is easier to manage, and handles page requests much faster than before. What is there not to like about this, eh?

(For comments, visit the forum area)

Last week’s exploration of “processing with limited computing power” a few decades ago has led me into another direction which turned out to be mesmerising and addictive…

All due to a chip called a Field Programmable Logic Array, which usually looks like this:

That’s a lot of pins – large FPGA’s can have over 1,000 pins, in fact!

What are they? What’s the point? Why are they so hard to use? Can we play with them?

Read on to find out, as usual there will be articles coming this week to explore the “field”:

• Move over, John von Neumann – Wed
• Building a MultiComp-based Z80 – Thu
• The language(s) of FPGAs – Fri
• TFoC – A wide performance range – Sat

Once again, there is an awful lot of ground to cover this week, but with a bit of luck, it’ll end up being a decent bird’s eye view of what this FPGA (and CPLD) stuff is all about…

(For comments, visit the forum area)

Small microcontroller chips, modern laptops/desktops – the range of computing power is enormous nowadays. So enormous, that it can be pretty hard to grasp the magnitude.

This week, I’m going to do some explorations, using a HY-Tiny board with an STM32F103 on it. Or to be put it differently: a fairly low-end but popular 32-bit ARM Cortex M3 µC, running at 72 MHz, with 128 KB flash and 20 KB RAM. It draws up to 40 mA at 3.3V.

Let’s find out what this little gadget is capable of:

• Tiny Basic with room to spare – Wed
• Creating a virtual 6502 chip – Thu
• Altair BASIC via 8080 emulation – Fri
• JavaScript in a 128 KB µC – Sat
• TFoC – The Fabric of Computing – Sun

So there you have it: a µC the size of a fingernail, vastly outperforming the Apollo Guidance Computer used to put man on the moon, less than half a century ago. You’ve got to wonder: would we still be able to perform this feat, using just an STM32F103? – I have my doubts…

(For comments, visit the forum area)

There are many ways to experiment with embedded development, which is what the Arduino IDE really is all about. But before diving more into using the Arduino IDE with STM32 µCs, I’d like to mention another option, based on a Raspberry Pi (A+, B+, or 2):

It’s called the ARMinARM board, by a company called OnAndOffables: a board with an STM103RE, sitting on top of the RasPi, with lots of connections to communicate through.

I’ll briefly touch on alternatives, but I like this setup because of how these two boards work together. Unlike a Win/Mac/Lin setup, this combo has everything-in-one for development.

So here goes for this week’s episode of articles, dished out in small daily doses:

• ARMinARM can set you free! – Wed
• A plethora of tools on the Pi – Thu
• Developing in C/C++ for STM32 – Fri
• Developing in Lua for STM32 – Sat
• Developing in JavaScript for STM32 – Sun

As you will see, there’s quite a bit of potential in this little 7x6x3 cm package!

(For comments, visit the forum area)

To follow up on last week’s upload articles, I’m going to turn a couple of these boards into Black Magic Probe programmers:

From left to right: an STM Nucleo F103RB (any Nucleo will do, though), a board from eBay (many vendors, search for “STM32F103C8T6 board”), and Haoyu’s HY-TinySTM103T.

And let’s do it right, with a couple of custom PCB’s – here are three versions (the first one will keep its original firmware, actually). Each does have slightly different usage properties:

• Use any STM Nucleo as programmer – Wed
• From eBay “C8” µC to BMP tool – Thu
• The HY-Tiny can also act as BMP – Fri

Each of these supports uploading, serial “pass-through” connection, and h/w debugging. Building one of these, or getting a pre-built & pre-loaded one, is a really good investment.

(For comments, visit the forum area)

When dealing with ARM µCs and boards based on them, there’s always one big elephant in the room: how to upload software to them, and how to talk to them via serial or USB.

The available options, choices, trade-offs, and even just their properties can be staggering. This week’s article series is about what the problem is, an overview of the many different ways to address them, and how to get started with the minimal fuss and/or minimal cost.

On the menu for this week are four dishes, served on a daily basis:

• Most bare µCs are clueless – Wed
• Lots of chickens and eggs – Thu
• Bootstrapping a boot loader – Fri
• Making a Black Magic Probe – Sat

Fortunately, we’ll need very little to get going. We can pull ourselves up by our bootstraps!

(For comments, visit the forum area)

As announced last week, I’ll be switching (pouring?) my efforts into a new series of µC’s for a while, so there’s quite a bit of work ahead to get going, and I really don’t want to dwell too much on the basics. The whole point is to get further, not redo everything and get nowhere!

So for this week, there will be a whole slew of posts. As usual, each next post will be ready on successive days, as I figure it all out and try to stay ahead of the game :)

• STM32F1’s and all that jazz – Wed
• Details of the STM32F103 – Thu
• So many boards, so many µCs – Fri
• The Arduino IDE with STM32 – Sat
• A few simple sketches for ARM – Sun
• Meet the RF Node Watcher – Mon

Here is a sneak preview of the main character in this exciting new adventure:

(For comments, visit the forum area)

During my tinkering over the past two weeks, I hit a snag while trying to hook up the LPC824 µC to the Arduino IDE. Nothing spectacular or insurmountable, but still…

This week, I have two articles for you, explaining what this is all about:

• Serial uploads vs flow control – Wed
• Revisiting existing chips and code – Thu

Warning: there are going to be some changes w.r.t. where I’ll be going next…

(For comments, visit the forum area)

Let’s get that upload going. Remember, this is about adding a “hardware platform” to the Arduino IDE so it can compile and upload files to a Tinker Pico, based on the LPC824 µC.

There are two parts to this: 1) getting all the IDE setup files right so that it knows how to compile & upload, and 2) implementing pinMode(), digitalWrite(), etc. so they can be used with LPC824 microcontrollers in the same way as with ATmega’s and other µC’s.

So let’s tackle these issues one by one, shall we?

• Compile and upload the bare minimum – Wed
• Using an LPC824 the Arduino way – Thu

Here’s my very first compile and upload to a Tinker Pico:

(For comments, visit the forum area)

What will it take to support the LPC824 µC, i.e. the Tinker Pico, from the Arduino IDE?

As the Arduino IDE has been evolving and growing over the years, more and more µC platforms have been added – both officially and unofficially – after the initial ATmega µC’s. One of the earlier ones was Energia, which was created as a fork to support TI’s MSP430 chips, but as the IDE matured, it has become easier to support several other architectures in the mainstream build as a simple add-on, such as ESP8266 and STM32.

Sooo… let’s try and find out how hard it would be to include our LPC824 µC into the mix:

• Adding a new Arduino platform – Wed
• Extending the “ide-hardware” project – Thu

Update: the following two articles are postponed to next week. Sorry for the bad planning:

• A quick hack to make it compile – Fri
• Uploading via the IDE – Sat

So far, this is merely an exploration, as I said. A complete port will take considerably more effort. I’m also considering moving a bit beyond the digitalRead/Write conventions…

(For comments, visit the forum area)

It’s time to get some new hardware out the door, which I’ve been doodling with here at JeeLabs for quite some time, and which some of you might like to tinker with as well.

The first new board is the Tinker Pico, which was already pre-announced a while ago. Here’s the final PCB, which is being sent off to production now, soon to appear in the shop:

As before, each week consists of one announcement like this, and one or more articles with further details, ready for release on successive days of the week – three in this case:

• Tinker Pico v1 – Wed
• How to upload over FTDI – Thu
• Writing code for the Tinker Pico – Fri

This is merely a first step, running pretty basic demo code. Stay tuned for more options…

(For comments, visit the forum area)

Time to try something different – this week, the JeeLabs blog and articles will be written by Thorsten von Eicken, as guest author. I’m very excited by the project he has created and will gladly step aside to let him introduce it all -jcw

Has it ever happened to you that you put together a nice JeeNode or Arduino project, test it all out on your bench, then mount it “in the field” and … it doesn’t quite work right? Or the next day it malfunctions? Well, to me it happens all the time. Or I want to add another feature to my greenhouse controller or my weather station but I don’t want to bring it back to my bench for a few days for a full rework and re-test. Instead I’d love to troubleshoot or tune the code remotely, sitting comfortably at home in the evening while my project is mounted somewhere out there.

My first attempt at solving this situation was to deploy a BeagleBone Black with a WiFi dongle and a serial cable (a RaspberryPi or Odroid could work just as well):

Essentially I turned a $55 BBB plus a little $10 WiFi dongle into a remote FTDI widget. In the first moment I was in heaven: it’s an inexpensive solution in the grand scheme of things and it worked great. But then I became addicted and one BBB was insufficient: I wanted to hook more than one remote JeeNode up! Well, suddenly the prospect of buying 3-4 such set-ups didn’t look so inexpensive anymore!

That’s when the esp8266 WiFi modules caught my eye at a cost under $5. Here is a WiFi module with a processor and a UART and, most importantly, an SDK (software development kit). The SDK suggested that I could implement the key functions to remotely watch debug output of a JeeNode as well as reprogram it, just like I was doing with the BBB. My mind started racing: what could I make it do? What would a complete hardware solution cost? How much power would it use? What is its WiFi range?

At that point I chatted with JC about my little project, which I called “esp-bridge”, and got a cautiously interested response with ingredients ranging from “sounds very cool!” to “it’s gonna use way too much power”. Not to be easily deterred I thought it would take me about a week to write some code. That was 4 months ago, and while I have a day job I have spent a lot of time on the esp-bridge project since. In the end, I hope you will benefit from all this because through this week’s episode of the JeeLabs blog you will indeed be able to complete the journey in one week! The plan for the week is as follows:

• Meet the esp8266 – Wed
• The esp-bridge circuit – Thu
• Serial bridge – Fri
• Web server software – Sat
• Over-The-Air update – Sun
• Putting it all together – Mon

As the week develops (and beyond) I would love to hear your feedback and questions. The last post will be written just-in-time so I can try to answer anything that comes up before then. For general discussion, please use the esp-link thread on the ESP8266.com site or open a new thread in the same forum. If you download the software from GitHub to put your own esp-bridge together and run into bugs or mis-features please post to the GitHub issues tracker.

Quick clarifications about names: esp-bridge refers to the hardware & software gadget described in this blog series while esp-link is the name of the software itself.

(For comments, visit the forum area)

All the posts and articles so far have been about staying “close to the silicon” on ARM µCs. Direct access to I/O registers to control and read out pins, and to activate the built-in hardware interfaces. It gets tedious after a while, and worst of all: very repetitive.

I’ve been coding for the LPC8xx chips in C/C++ with virtually no runtime library support. The reason was to expose all the raw stuff that happens as a µC starts up, very dumb, and needs to be told how to get a notion of time (SysTick), how to read/set/clear/toggle pins, how to sleep in various low-power modes, how to talk to the serial interface, yada, yada…

Figuring out how things work at the lowest level is a fascinating adventure. It’s no more than an indirect jump on reset, a run-time stack, and processing machine code – forever. But let’s not deal with these details all the time. Let’s think about sensors, conditions, decisions, actions – let’s define the behaviour of a system, not just deal with technicalities.

There are numerous ways to move up in abstraction level on embedded µCs. This week’s episode is about the bigger picture and the three broad categories of these approaches:

• So many abstractions to choose from – Wed
• A µC is just a small computer – Thu
• No wait, it’s a language runtime – Fri
• Or is it a data-driven engine, perhaps? – Sat

Warning: there are no conclusions at the end. I’m still exploring and evaluating. I’ve been on many long and winding roads already. I’m not too impressed by most of them. Treating a µC (any board) as the centre of a project feels wrong, particularly in the context of multi-node home monitoring and automation – which is still, after all, the focus of this weblog.

We really need to look at the bigger picture. How to evolve and manage the designs we create over a longer period of time. Old stuff needs to fit in, but it shouldn’t prevent us from finding a broader view. Adding and managing single nodes should not be the main focus.

(For comments, visit the forum area)

Putting a chip on a board, as with the Tinker Pico, is one thing. Getting it to do something is quite another matter. We’ll want to develop tons of software for it and upload the code.

The uploading bit has already been solved by using a modified FTDI board, with some exciting new options coming up in the next few months. How’s that for a teaser, eh?

This week’s episode is about the software side of things. Toolchains, runtimes, build tools, IDE’s, that sort of thing. Brought to you – as usual – in a series of daily bite-sized articles:

• Exploring LPC824 peripherals – Wed
• Using MBED as toolchain – Thu
• LPCOpen and LPCXpresso – Fri
• Using the Eclipse IDE on Windows – Sat

I’m having a hard time making up my mind on which path to choose as future code base. The curse of having too many choices, each with their own trade-offs and compromises.

(For comments, visit the forum area)

There are more chips in NXP’s LPC8xx ARM µC family. We’ve seen the delightful 8-DIP LPC810, which packs a lot of power and is an interesting way to get started with ARM, and we’ve seen the LPC812 which is available in a tiny TSSOP-16 package, yet has 4 times the flash and RAM memory of the LPC810.

But there’s one more interesting member in this family: the LPC824, which can easily compare (and exceed) the specification of that workhorse of the Arduino world, the venerable ATmega328. This week’s episode is about getting familiar with the LPC824:

• Meet the LPC824 – Wed
• More LPC824 peripherals – Thu
• Tinker Pico LPC824 board – Fri

The LPC824 could make a really nice foundation for remote sensor nodes: loads of modern hardware peripherals, ultra-low sleep mode power consumption, and plenty of I/O pins.

I’m really excited about this chip. As with all the LPC8xx chips, there’s a “switch matrix” to connect (nearly) any h/w function to any pin. This means that you don’t really have to care much about pinouts and figuring out up front which pins to use for which tasks. This offers a lot of flexibility when designing general-purpose boards with a bunch of headers on them.

(For comments, visit the forum area)

Now that we have the RFM69 working on Raspberry Pi and Odroid C1, we’ve got all the pieces to create a Wireless Sensor Network for home monitoring, automation, IoT, etc.

But I absolutely don’t want to leave the current range of JeeNodes behind. Moving to newer hardware should not be about making existing hardware obsolete, in my book!

The JeeNode v6 with its on-board RFM12 wireless radio module, Arduino and IDE compatibility, JeePorts, and ultra-low power consumption has been serving me well for many years, and continues to do so – with some two dozen nodes installed here at JeeLabs, each monitoring power consumption, house temperatures, room occupancy, and more. It has spawned numerous other products and DIY installations, and the open-source JeeLib library code has opened up the world of low-cost wireless signalling for many years. There are many thousands of JeeNodes out there by now.

There’s no point breaking what works. The world wastes enough technology as it is.

Which is why, long ago a special RF69-based “compatibility mode” driver was added to JeeLib, allowing the newer RFM69 modules to interoperate with the older RFM12B’s. All you have to do, is to add the following line of code to your Arduino Sketches:

#define RF69_COMPAT 1

… and the RFM69 will automagically behave like a (less featureful) RFM12.

This week is about doing the same, but in reverse: adapting JeeLib’s existing RF12 driver, which uses a specific packet format, to make an RFM12 work as if it were an RFM69:

• Classic vs native packets – Wed
• RF compatibility options – Thu
• RF69 native on ATmega’s – Fri
• Using RFM12’s with RFM69 native – Sat

As I’ve said, I really don’t like to break what works well. These articles will show you that there is no need. You can continue to use the RFM12 modules, and you can mix them with RFM69 modules. You can continue to use and add Arduino-compatible JeeNodes, etc. in your setup, without limiting your options to explore some of the new ARM-based designs.

Let me be clear: there are incompatibilites, and they do matter at times. Some flashy new features will not be available on older hardware. I don’t plan to implement everything on every combination, in fact I’ve been focusing more and more on ARM µC’s with RFM69 wireless, and will most likely continue to do so, simply to manage my limited time.

Long live forward compatibility, i.e. letting old hardware inter-operate with the new…

With the Micro Power Snitch sending out packets, it’d be nice to be able to receive them!

This week is about turning a Raspberry Pi, or a similar board such as an Odroid-C1, into a Linux-based central node for what could become a home-based Wireless Sensor Network.

All it takes is an RFM69 radio module and a little soldering:

On the menu for this week’s episode:

• A super simple “RasPi RF” setup – Wed
• Using WiringPi with RasPi RF – Thu
• RasPi RF schematic and PCB – Fri
• Hooking RasPi RF into MQTT – Sat

And before you know it, you’ll be smack in the middle of this century’s IoT craze…

(For comments, visit the forum area)

We’ve come to the eighth and final episode of the Micro Power Snitch story: it’s working! The circuit is transmitting wireless packets through the RFM69 radio module running on nothing but harvested electromagnetic energy. Install once, run forever!

But there are still several little details, optimisations, and edge cases we need to take care of – which is what this week’s articles are all about. As always, one article per day:

• The MPS really works – Wed
• Should we send, or not? – Thu
• MPS component improvements – Fri
• Final MPS schematic and PCB – Sat

The MPS triggers on any appliance drawing ≥ 500W (on 230 VAC, or 250W for 115 VAC):

As always on the JeeLabs weblog: everything is open source – you are welcome to build and adapt this circuit for your own purposes. If you do, please consider sharing your suggestions/findings/improvements on the forum, for others to learn and benefit as well.

(For comments, visit the forum area)

The two problems with projects powered by harvested energy, are: 1) running out of juice, and 2) falling into a state of limbo and not (or not consistently) getting out of it again.

Here is an example of both happening – a successful µC startup and then a radio failure:

In the case of the Micro Power Snitch, the energy coming in may vary greatly, since it will be proportional to the current drawn by the appliance being monitored by our MPS.

We’re going to have to tread carefully in this week’s episode:

• Let’s switch to a better MOSFET – Wed
• Anatomy of a power-up – Thu
• Power through I/O pins? – Fri
• Taming the radio startup current – Sat

As usual, each of the above articles will be ready on successive days.

Planned for next week: a few more loose ends, and then my closing notes.

(For comments, visit the forum area)

And you thought the MPS was finished, or perhaps abandoned, eh?

This week resumes the development of a little LPC810-/RFM69-powered setup which runs on parasitic power, harvested from either phase of a current-carrying AC mains wire.

To summarise, the last step in the project I went through a few weeks ago, was to create a PCB for it. Here were some builds, with all the hacks and hooks added to try things out:

As it turns out, I had made so many mistakes, one after the other, that it really set me back, irritated me to no end, and kept me busy with complete silliness… but all is well again now.

The articles in this week’s “back in business” MPS episode are:

• The PCB that got everything wrong – Wed
• Back on track – now the hard part – Thu

And with a bit of luck, by next week I’ll have figured out how to send out brief RF packets on an ridiculously minimal energy budget. Because that’s what “The Snitch” is all about!

(For comments, visit the forum area)

… for an important announcement from our sponsor:

Just kidding, of course!

But it got your attention, right? Good. That’s what this week’s episode is about: taking care of something unexpected, i.e. processing tasks without planning them ahead all the time.

On the menu for the coming days:

• Interrupts on ARM – Wed
• Masking interrupts – or not – Thu
• Interrupt service times – Fri
• Serial port interrupts – Sat
• Pin changes, levels, and edges – Sun

Interrupts – when handled properly – are extremely powerful and can deal with “stuff” in the background. But there are a lot of tricky cases and hard-to-debug failure modes. It’s worth getting to grips with them really well if you want to avoid – unexpected – failures.

(For comments, visit the forum area)

One of the things I’m going to need at some point is additional flash memory. Since the simplest way these days to add more memory is probably via SPI, that’s what I’ll use.

This week’s episode is about connecting an SPI chip, implementing a simple driver, code re-use, the hidden dangers of solderless breadboards, and point-to-point soldering:

• Hooking up a dataflash chip – Wed
• Accessing SPI memory – Thu
• Too much capacitance is bad – Fri
• Soldering one-off SMD circuits – Sat

The end result is several megabytes of extra storage, using only 4 I/O pins. Data logger? Serial port audit? Storage for audio, video, images? Your next novel? It’s all up to you!

(For comments, visit the forum area)

Digital chips can’t do analog directly – you need an A/D converter for that, right?

Not so fast. Just as pulse-width modulation (PWM) can be used to turn a purely digital signal into a varying analog voltage, there are tricks to measure analog values as well.

All you need is the proper software, a simple analog comparator, and these components:

This week’s episode examines delta-sigma modulation and shows you how it’s done:

• Measuring voltage without ADC – Wed
• 10-bit ADC on LPC810 and 812 – Thu

There’s in fact a little gem hidden inside those LPC8xx chips which allows implementing this without bogging down the µC. Just one interrupt whenever a measurement is ready. But the basic idea is applicable to any microcontroller with a built-in analog comparator.

(For comments, visit the forum area)

The LPC8xx series has no EEPROM memory. This type of Electrically Erasable memory is very useful to store configuration settings which need to be retained across power cycles:

But we can emulate it with flash memory, despite the somewhat different properties.

Here’s the why’s, what’s, and how’s of this software trick – in this week’s article series:

• Permanent variables – Wed
• Emulating EEPROM with flash – Thu
• A bag of C++ tricks – Fri

There’s quite a bit of detail involved to get this right, as you will see.

(For comments, visit the forum area)

No, I haven’t abandoned the Micro Power Snitch!

But some projects are trickier than others, and this one didn’t want to play along when I tried it again on my new PCB design. I fixed one glaring wiring mistake so far, but there’s more going on. Since Mr. Murphy seems to be enjoying himself again, I’m going to let him enjoy his little “victory” for a while and come back to the MPS at a (slightly) later date.

Instead, let’s move up the ladder a little and experiment with another ARM µC:

On the right: four times as much memory (both flash and RAM) and twice as many pins.

• Meet the LPC812 – Wed
• It runs the same firmware – Thu
• Soldering a TSSOP chip by hand – Fri
• Adding an RFM69 radio – Sat

As you can see, packaging is everything – and bigger is not always more…

(For comments, visit the forum area)

In this concluding part (for now) about the Micro Power Snitch, which feeds off the magnetic field around an AC mains power cable when in use, I’ll look into how the whole circuit behaves when it comes to actually sending out wireless radio packets.

The daily articles in this week’s final MPS episode are:

• CT’s and burden resistors – Wed
• Inductive spikes and safety – Thu

Update – With apologies (again!), I’m going to postpone the following posts:

• Sending out MPS packets – Fri
• Construction and final notes – Sat

It’s a huge challenge to manage the incoming energy so that everything keeps going!

(For comments, visit the forum area)

At the end of the day, the Micro Power Snitch (MPS) is really about powering up and down robustly under all circumstances. There will be times when there is no energy coming from the Current Transformer, and there will be times when energy levels hover around the go/no-go point of the circuit. That’s the hard part: being (very) decisive at all times!

This week’s episode looks at an improved circuit with a dozen individual components or so. As you will see, it has excellent snap-action behaviour, and does the right thing on the “up” ramp as well as on the “down” ramp, regardless of how slowly those voltage levels change.

Here is the daily sequence for this week:

• A revised, complete MPS – Wed
• Extremely slow ramps – Thu
• Next MPS challenge: the radio – Fri
• The MPS as prototype PCB – Sat

With a complete MPS circuit design worked out, we’re finally getting somewhere.

(For comments, visit the forum area)

There’s trouble ahead for the MPS: it’s not reliable enough yet, and can enter a “zombie mode” whereby the µC won’t have enough voltage to start up, while drawing so much current (relatively speaking) that the energy source isn’t able to raise the voltage further.

Leading to some beautiful pictures, but nevertheless totally undesired behaviour:

The daily articles in this week’s episode are:

• Pretty picture, ugly effect – Wed
• An improved MPS circuit – Thu
• It’s all about the startup “hump” – Fri
• Investigating the voltage doubler – Sat

So far, it looks like this second MPS design solves the problems of the first. Progress!

(For comments, visit the forum area)

So far, there’s an idea, a circuit to collect energy, and sample code to make an LPC810 come alive every so often, briefly. It’s time to tie things together and see what happens!

As usual, one article per day in this week’s episode:

• Setting up a test power source – Wed
• The first MPS circuit – Thu
• Yes, the MPS lives, but… – Fri
• Adding a voltage monitor – Sat

As you will see in Saturday’s article, this first MPS design is indeed able to power an LPC810 µC after some modifications, and keep it alive “under certain conditions”.

But there’s a very nasty skeleton in the closet – stay tuned!

(For comments, visit the forum area)

It’s time to tackle a fairly ambitious challenge: let’s try to make an LPC810 run off “harvested” energy and use it to periodically send out a wireless packet.

This week will be a short intro into the matter, with more to follow later:

• Picking up magnetic energy – Wed
• Collecting energy into a reservoir – Thu
• First goal: just some blips – Fri

To lift the veil a bit, here’s the energy I’m going to try to harvest:

This is the voltage from a Current Transformer (CT), when unloaded. Such a CT needs to be “clamped” around one of the wires in an AC mains cable, and will then generate a voltage which is proportional to the amount of current flowing in that wire.

Well, maybe, sort of…

(For comments, visit the forum area)

This week is about uploading firmware over a serial communication link, and interacting with the uploaded firmware.

First a quick recap on how it all works, then a little diagnostic tool, and then a little utility with some new powers. Your Odroids and Raspberries will never be the same again!

The article schedule for the coming days is as follows:

• Re-flashing an ARM chip – Wed
• Let’s find out what’s going on – Thu
• Uploading via a USB interface – Fri
• Uploading (just about) anywhere – Sat

The goal: freedom from having lots of USB cables all over the desk – at last…

(For comments, visit the forum area)

By popular request…

Several people have mentioned these topics to me recently, as being something they’d like to know more about. All of it is available from various textbooks of course, but it’s often buried deeply in more elaborate chapters. It seems like a good idea to single these out, especially if you’re quite fluent in programming a higher-level language other than C/C++.

Interestingly, all these topics turn out to be related in some way to memory maps, such as this somewhat arbitrary example from Wikipedia:

Low level programming is all about wrestling with such details, very “close to the silicon”.

The other topics which tend to trip people up coming from JavaScript, Python, PHP, Java, etc. are about how bits, bytes, and words can be manipulated, how to deal with memory areas for arrays and buffers, how types work in C/C++, and how a CPU copes with urgency:

• Low-level programming – Wed
• Lots of bits and pieces – Thu
• Pointer addressing – Fri
• Casting types in C/C++ – Sat
• We interrupt this program – Sun

I’ll keep the articles concise and only touch on the aspects relevant to embedded programs.

… but feel free to take a week off from reading this weblog if you already know all this!

(For comments, visit the forum area)

Let’s revisit the LPC810 and the RFM69. Things are starting to come together at last.

I’ll pick up where I left off three weeks ago, making two LPC810’s talk to each other via RFM69’s and then picking up the results on a Raspberry Pi over I2C. Hang in there!

• Debugging the RF link – Wed
• Picking up a signal – Thu
• Debugging the I2C bridge – Fri
• Keeping track of the milli’s – Sat

You know the drill by now: one article per day, as things become ready for publication.

(For comments, visit the forum area)

There is a lot more to go into w.r.t. the LPC810 µC and the RasPi/Odroid Linux boards, but since surprisingly many design decisions are related to that main driving force of electricity called “voltage”, this is a good opportunity to first cover those basics in a bit more detail.

Here is the list of upcoming articles, one per day:

• The water analogy – Now
• Heat versus momentum – Thu
• Voltage sources – Fri
• Level translation – Sat

Here’s a nice diagram from Wikipedia with all the rechargeable battery technologies:

Quite a variety, and all of them with different trade-offs. Read the articles to find out why it matters, when to stack ’em up, how to avoid problems, and what buck & boost is about.

(For comments, visit the forum area)

The “LPC810 meets RFM69” series, is being postponed a bit longer than anticipated, the relevant pieces are simply not ready and stable enough yet to present as working code. With my apologies for this change of plans. I’ll definitely get back to this – count on it!

For now, let’s start exploring another piece of the puzzle, when it comes to setting up a wireless network, and in particular a wireless sensor network (WSN)

• Pies, Bones, and Droids – Now
• Ian started it all with Debra – Thu
• Linux, pins, volts, and ports – Fri
• Meet Raspie and Quadie – Sat

As usual, each of the above articles will be ready on subsequent days.

If you’ve always wanted to try out Linux without messing with your computer – here’s a gentle introduction to the world of physical computing, from a Linux board’s perspective!

(For comments, visit the forum area)

The code presented last week – or should I say last year? – was unfinished. In fact, it wasn’t even tested, just designed and written in a way which “should” work, eventually…

The thing with communication is that you’ve got two pieces which need to work together, but they are running on different bits of hardware, which makes it harder to see the big picture and reason about what’s going on. Getting to that first data exchange can be tricky.

In this case, we’ve also got an I2C link in there, so there are in fact three systems involved, and in addition, we’re going to need a way to re-program those two LPC810 µC’s:

Let’s get on with it and figure out how to make this stuff work:

• One step at a time – Now
• Decoding incoming data in Go – Thu

Update – With apologies, I’m going to postpone the following three posts a bit longer. Too many distractions here, keeping me from working on this with proper concentration:

• Debugging the I2C bridge – Wed
• Debugging the RF link – Thu
• Keeping track of the milli’s – Fri

Lots of pesky little details to deal with and quite a few bugs to squash, as you’ll see…

(For comments, visit the forum area)

This week, as we jump from 2014 into 2015, I’d like to start on an exploration which is dear and near to me: ultra low-power wireless sensor nodes for use in and around the house.

The LPC810 µC has 4 free I/O pins, when connected via a serial port or I2C. And as it so happens, it’s also quite feasible to drive an RFM69 wireless module with just 4 pins, i.e. using just an SPI bus connection, without any interrupt pins hooked up.

So why not try to combine the two, eh?

The following articles introduce a brand new “RF69” driver, using native packet mode:

• Radio blips from an LPC810 – Now
• From RFM69 to RasPi via I2C – Thu

This concludes this year’s refreshed weblog series, but I’m really looking forward to the year ahead. The new weekly format is working out nicely for me – I hope you also like it.

To close off the year and fulfil another goal I had set for myself, the recent material on this weblog has now been added to the The Jee Book. It’s just a start to let you download the entire set of articles published so far – in a range of e-book formats, including PDF.

I hope you had a great 2014 and wish you a very Guten Rutsch into 2015. May it bring you and yours much happiness, creativity, and inspiration – with respect and tolerance for all.

Happy hacking,
Jean-Claude Wippler

(For comments, visit the forum area)

Physical computing is about hooking things up. Sure, there’s also low-power and wireless in the mix, but in the end you need to tie into the real world, and that means connecting sensors, indicators, actuators, and what-have-you-not. It’s a big varied world out there!

The computing side is all about information. From a µC’s perspective, we need to direct information from sensors to us, and from us back out to indicators and actuators.

The more data you need to shuttle across (or the more frequently), the harder it becomes in terms of engineering. But sometimes all you need is to send or receive a few bytes of data, perhaps just a few times per second. That’s where I2C comes in, created over 30 years ago.

Or, more accurately: the I²C bus, which stands for the “Inter-Integrated Circuit” bus.

So the upcoming article series is about this wickedly clever “eye squared see” invention:

• Let’s take the bus – Now
• Masters and slaves – Thu
• I2C on the Raspberry Pi – Fri
• Re-flashing an LPC810 on the RPi – Sat

As before, one article per day. And while we’re at it, I’ll also use the Raspberry Pi single-board computer as an example of how to use I2C under Linux. As you’ll see, it’s really easy!

(For comments, visit the forum area)

The past several weeks were about hacking stuff together: electrically connecting chips and some other components together, and making the resulting circuit + software do fun stuff.

This week is about turning an experiment into a more formal design.

In some cases, such as the mains distribution panel at JeeLabs, clear wiring is not a luxury:

Those colour codes are not for making a pretty picture – the are required by law. And even though most mains distribution panels end up being unique one-offs, the formal “notation” is essential to make each design well-documented and understandable for decades to come.

With low-power experiments, we have a lot more freedom to just hack around, fortunately!

But although breadboards are great for trying out ideas by letting you “edit” the electronic circuit, at some point you will probably want to make it more permanent, or smaller, or more robust – or even all those at once. Or perhaps you simply want to make it repeatable, so more “instances” of your experiment can be produced – whether for fun or for profit, and perhaps even not for yourself but for others to replicate with minimal effort.

Tinkering is fun. Repeatedly solving the same puzzle or falling into the same trap is not.

Here are this week’s articles, as planned for the coming days at 0:00 CET:

• Circuits and schematics – Now
• The magic of copper and solder – Thu
• Laying out and routing a PCB – Fri

Please note that these articles are not a how-to guide for the entire process, just a first introduction to all the steps involved in going from an idea to a reproducible design.

Getting to know the ARM architecture and the LPC810 is a wonderful adventure. It’s also almost impossible to figure out where to start. So let’s just dip our toes in the water, eh?

This week’s articles all highlight a different aspect of the LPC810 (of the entire LPC8xx series, in fact), by exploring a variety of uses and figuring out how to implement them.

Each of the following examples includes a minimal circuit to demonstrate their use:

• Serial output from a DIP – Now
• Number crunching on a DIP – Thu
• Atomic clock via a DIP – Fri
• LEDs racing around a DIP – Sat
• Motion out of a DIP – Sun

All of them can also be built on a breadboard, but soldering up a little circuit with an 8-DIP chip (or socket) in them is a lot more fun. It really shows the versatility of such little µC’s:

Who knows, you might even have an immediate use for some of these examples. With a bit of extra work, any of them could be turned into a self-contained I2C slave to add to your own project. Instead of complicating your own project code with the hard timing requirements of pulsed LEDs or servos, why not simply “off-load” to a dedicated LPC810?

The sky is the limit. Eh, wait, strike that, it isn’t anymore…

(For comments, visit the forum area)

This next article series is about setting up a practical project for use around the house. It’s small enough to be covered in a few articles, and simple enough to be constructed entirely on a breadboard with no soldering involved. It’s time to start making things!

I’ll take you through the problem definition, the way to pick a solution, and the many trade-offs involved in getting everything working as intended. As you will see, getting this thing to run off batteries poses some challenges, but is nevertheless feasible.

Here are this week’s articles, as planned for the coming days at 0:00 CET:

• Let’s build a GPA – Now
• Hardware design choices – Thu
• Measuring distances – Fri
• Reducing power consumption – Sat
• Squeezing a bit more – Sun
• In-System Programming – Mon

The GPA has all the properties you’d expect in a physical computing project: a sensor, a readout, a microcontroller, and a power source. You may not have a garage (or a car), or you may have a car with this functionality built-in, but there’s probably something to glean from this design process for your own use – and maybe some parts will be useful in other ways. It’s all “loosely coupled” after all, with a breadboard to build any variations you like:

Speaking of parts – Martyn & Co have produced a kit for the JeeLabs shop if you’d like to get going fast, with everything needed to create this little parking aid gimmick.

(For comments, visit the forum area)

As you may have noticed, the publication date of these posts has been shifting a bit. Well, no longer: from now on, all posts will be scheduled to go out on … Weekly Wednesday!

As before, each post will mention one or more new articles, released on successive days.

This “Getting Started” series has been about exploring ARM µC’s, in particular the 8-pin LPC810 shown above, and there’s one important topic left to cover so you can compile your own code and explore what’s possible in this virtually infinite playground.

Here goes, the concluding articles of the Getting Started series:

• Setting up a toolchain
• More tools for your tool belt
• The need for speed
• Relax and live longer

If you’re eager to start tinkering with the LPC810 chip: have a look at the JeeLabs shop, where Martyn Judd & Co from Digital Smarties have created two very practical packages to get you started: the Bare ARM Blinker kit which has everything needed to replicate and extend the recent explorations on this weblog, and the ARM duo- and 6-pack, i.e. a supply of bare LPC810 chips to experiment with. Note that there’s no soldering involved.

Be warned, though: it’s pretty addictive stuff! – and we’re only just getting started…

(For comments, visit the forum area)

The idea of starting out with the 8-DIP LPC810 ARM µC occurred to me not very long ago, when I discovered a simple upload mechanism based on the modified FTDI interface. It’s quite an intriguing idea that you can put some pretty advanced decision and timing logic into such a small chip and do so entirely through free open source tools, with all the details fully exposed.

Making an LPC810 do stuff feels like creating our own custom chips: we can upload any software of our own design into the chip, then place it in a project as “control centre” to do fun stuff. Protocol decoders / encoders / converters, LED drivers (e.g. the WS2812 “neopixel”), even a small interpreter or a wireless radio driver, these are all feasible – despite having just 4 KB of flash memory.

Small programmable chips such as the LPC810 demand a relentless drive for simplicity, which is an excellent skill to develop IMO – for whatever physical computing projects you may have in mind.

Anyway. The hardware side is now completely done, with something like this ready to go:

Unfortunately, that’s only half of the story. We still need to address uploads + compilation.

Check out the next set of articles, to be published from Wednesday through Saturday:

• Uploading from Mac OSX
• Uploading from Linux
• Uploading from Windows
• Life after uploads

With this out of the way, we can make an LED blink or fade. Trivial stuff, but note that we’re setting up the infrastructure for embedded software development on ARM chips.

Oh, and if this is too basic for you, see if you can figure out this JeePuzzle … any takers?

(For comments, check the forum area)

The articles this week continue on the path just started, hooking up a bare ARM chip, and making it do something silly. No soldering and (almost) no software installation involved.

As before, keep in mind that only the first of the following articles is available right away – the others will be published one at a time, a day apart:

• Long live the breadboard
• Minimal code, the basics
• The upload conundrum
• Modifying the USB BUB

A thought occurred to me recently, and it got stuck in my head:

We can send an autonomous vehicle to Mars using a mighty/majestic Saturn V rocket, or we can launch a fragile/fickle weather balloon and enjoy the view on earth from above.

I’m a guy who prefers the latter. Simple, clean, quiet, and with a journey which is at least as interesting as the result. Which is why you’ll find many posts on this weblog which do things differently, and even repeatedly. Not to be different, but because life is as much about going someplace as it is about getting there.

And yes, I’d love to figure out how to launch a weather balloon some day. There’s probably also a point to be made about the difference in energy consumption…

(for comments, please use the weblog section of the jeelabs.net discussion forum)

Ok, here’s the deal: once a week there will be a post like this one, with links to one or more “articles”. These articles will cover some common topic, in small doses. There will be weeks with just one article, and there will be weeks with more than one – depending on the topic, energy levels, complexity, moon phases, and of course the generosity of the muses.

On the day when a post is published, only the first article listed will be available. Each day after that, the next one will be ready. This keeps each daily post nicely limited to a short, and hopefully enjoyable and informative experience.

This first episode contains entries for today, Saturday, and Sunday, just to get started:

• Brutally Bare Basics
• Welcome to ’32
• Just an ARM and a LED

If everything works out, all the articles will add up to form chapters, and the chapters will join forces to produce a book. But that’s for the future to tell, for now the articles will only exist on this weblog (and stay there forever, BTW).

These weekly posts will rarely change once published. Articles on the other hand, can and will most likely get updated, extended, and even rearranged from time to time – to fix errors and omissions, or to include any relevant new information.

For comments, please use the new weblog section of the forum at https://jeelabs.net/.

Enjoy,
-jcw