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)