Never working is better than working sometimes

After trawling the mBed forum and trying out lots of different HTTP client type examples, I was shocked earlier today to actually see some HTML appear in a terminal window. Success!

The mBed successfully talked to the router, got an IP address via DHCP and made a request to my own server (I've set up a web page to broadcast messages when a username/password combination is sent).

Unlike previous attempts, I used the Twitter example which uses HTTP POST instead of HTTP GET to retrieve a response from a web server (it actually posts data to the server too, but I'm not interested in that side of things yet).



I was utterly amazed to see a response from the server appear in the terminal window. Finally, something was working and I could concentrate on building my web-enabled device. True, it was still a niggling concern that previous examples hadn't worked, but by now I just wanted a working solution (see how this whole library-based approach to development just makes you abandon understanding for the sake of getting something to work?!)

I was so thrilled, I wanted to see my web page contents appear again, so I pressed the reset button on the board and waited for it to get the data again.
Nothing.

It was assigned an IP address, then just sat there.
Very much like the previous attempts - it got to the HTTP POST command and just locked up!

I reset the board again.
Nothing.

Then again.



This time, some HTML appeared in the terminal window.
What the......
Exactly the same code running on exactly the same hardware, calling exactly the same web page (nothing changes between attempts) sometimes works and sometimes doesn't. A more frustrating scenario I can't imagine just at this time!

After repeating the experiment, I now have a sort-of-working HTTP client which can return data from a website, but only once every six or seven attempts.
Straight away, I thought hardware - dodgy soldering and loose wires - after all, if the software/firmware doesn't change between it working and not working, it must be something else.

I replaced my home-made RJ45 socket (which still works with other development boards, so I'm convinced it's not the problem, but just to be sure) with a pre-built breakout board, with all the connectors in place.



The result was the same. Resetting the device (or removing power from it completely) resulted in more locking up and occasionally a response written to screen.
All in all, a really frustrating week - I feel it would have been better spent building an ethernet device to connect to a PIC-based project myself! At least then, when it didn't work properly, I'd at least have some understanding about what was going on and maybe even why it wasn't working.

I've never been a fan of plug-n-play type development, as it discourages full understanding. And my experiences with the mBed development system haven't done much to change that view just yet!

First mBed development

As a PIC developer, and member of BuildBrighton, I often get a bit of stick from the others who are avid Arduino fans. The very reason most people love Arduino is mostly the reason why I don't get along with it - it's not the C-based language or abstraction (both of which I already use quite extensively when writing Actionscript for Flash) but what really bothers me is the over-reliance on libraries.

When I write PIC code, I tend to pore over reams and reams of boring (and confusing) datasheets, try to understand what is going on inside that little black box of magic, and write code to make it do exactly what I want.

Arduino has become successful because of the massive community of people who write code for it and post the results as "libraries" that other users can simply download and include in their projects. That's great provided the code is well written in the first place. There are a lot of people successfully using Arduino for their projects who don't really understand a single line of code! But by plugging together a few different libraries, you can get a working prototype up and running fairly quickly.

Despite my prejudices towards library-based coding, the lure of an ARM7 processor with built-in ethernet was just too much! The mBed development kit I was sent seems perfect for building quick and easy prototypes with very little knowledge of the underlying hardware. I've never built an ethernet stack, nor would I know where to start, but the mBed website provides a number of libraries and examples showing how to build a working HTTP client (some code that runs on the microcontroller and retrieves web pages from a URL is all I was after!)

Now the gripe - it's been over a week since this little thing arrived through my letterbox and I set to working immediately on ideas to try out it's hardware features. Since I'd already got access to most of it's peripherals through the PIC 18F series, I concentrated on the one thing it trumped a PIC with - ethernet support.

Yet nearly a week later, and despite the supposedly simple copy-and-paste approach to coding with the mBed system, I've yet to make a working HTTP client!

I have the 2368 series board (which has an 60Mhz ARM7 onboard, later versions such as the 1768 have a Cortex-M3 CPU running at 100Mhz) but not one of the HTTP client examples from the mBed website works.
Some of the other guys at BuildBrighton use the 1768 type mBed kits and the code works first time for them - but on my board, it just keeps locking up. (Some of the other guys at BuildBrighton just laugh and say I need to get an Arduino with an ethernet shield, but pfffft.)

I've used the same RJ45 sockets as the others, tried to communicate over the same networks, connecting to the same routers/hubs and while their boards all return HTML data almost instantly, whenever my board hits a HTTP GET type command, it just locks up!

And so the point of this grumble - it's still relatively early days for the mBed system. Which means the community is still pretty small - and the support just isn't there yet. I've been posting to forums asking for assistance, but haven't yet had any reply that has proved useful (whenever anyone at the Skiff has an Arduino-type problem, they can post a question and expect half a dozen answers within a few hours!). And the major problem - for me at least - is that I have no idea of what is going on inside those libraries to get to the bottom of why it's not working: which is mostly due to the way a library-based development system works. With a PIC, you work at almost byte and bit level - you can see every register and find out what is going on at the tiniest level. With the mBed system (and similarly, Arduino) all the clever, tricky, brain-hurting stuff is hidden away inside a few APIs supposedly making these things really easy to work with. Which is fine, when the libraries are well written and work all the time. But when they don't and there's no support, there's nowhere left to turn. Except, perhaps, back to my PICs.....

Farnell/element14 supporting new development

As a member of BuildBrighton, I've been taking part in some exciting competitions run by Farnell/element14. I've been a long-time customer of Farnell and bought most of my equipment through them (long gone are the days when you could pop into a local Maplin store and speak with someone knowledgeable about components and get help with your homebrew project!). They've always offered excellent service, a really comprehensive catalogue of components, and next day delivery even if your order doesn't go in until late into the evening!



I know a lot of people use RS Components and Rapid and even I still scour eBay for job-lot bargains, but mostly, when it comes to sourcing electronics components, there's only one website on my Google Chrome regularly visited list - and it's Farnell. In short, I think Farnell are great!

And now there's even more reason to rave about Farnell - because their recently re-branded element14 department has been running a number of projects to encourage interaction with the developer community. Not only did they organise the Worldwide HackerSpace Challenge, but they also gave away free cash (yes, real, genuine cash to spend anywhere, not just on their webstore) to provide the community maker groups with a budget to develop their own ideas!

As well as this, Farnell are actively encouraging developers to submit their ideas and helping by providing equipment and development kits: all completely free of charge! There are no caveats or conditions - if one of their guys likes what you're doing, look out for an email asking what you'd like to play with from their massive catalogue of components and look out for some freebies in the post!

We got an mBed development kit completely free. In fact we were offered anything from the Farnell products catalogue to try out and review, but we headed straight for the NXP storefront (http://uk.farnell.com/nxp) to check out the latest ARM7 development kits - although PICs are great, we're looking to step up to something bigger and beefier soon, and the NXP mBed system looks like a nice easy introduction to ARM7.

We're kicking a few ideas around to see what we can do with it, but already have a steer on what we can use it for. More details will be posted here as they're finalised.....

mBedded is embedded

A lovely surprise this morning here at Nerd Towers - after an afternoon on the beach, I returned home to find an evaluation kit sitting on the doormat, from the guys at Farnell.
After publishing a number of project ideas at BuildBrighton, and posting some ideas on an earlier blog, Geektar (a guitar for geeks), we were thrilled to be invited to evaluate the mBed development board and to "blog" about the findings here.

So the first thing to do was to have a look what we'd been sent.
The contents seemed a little sparse - a dev board, a usb cable, a plastic credit card showing the pinout and a single sheet of A5 basically saying "go to the website and learn more"



In fact, the credit card proved to be more interesting than we first thought.
It shows all the cool stuff that the processor supports - and it's a pretty impressive list of stuff! The mBed system is based on an ARM7 processor and it has some pretty cool features. It's a 40-pin microcontroller (similar to the PIC18F4550) and has lots of hardware features you'd expect to find on a higher-end 'controller:

2 x hardware SPI interfaces
2 x hardware serial/USART interfaces
2 x hardware I2C interfaces
6 x analogue-to-digital input pins
1 x digital-to-analogue output pin
6 x hardware PWM pins
USB support
CAN interface (home automation CANBUS?)
1 x ethernet/networking interface

Most of these functions are either available on the PIC18F series of chips, or can be recreated in software (see our 20-channel servo controller project for examples of how multiple PWM output pins can be generated using software) but being a 32-bit processor and supporting much faster speeds (PIC 18F runs at up to 48Mhz, ARM7 up to 72Mhz) the mBed controller is perfect for processor intensive tasks like driving displays, multi-processing and so on.



But what sets this chip apart from other chips we've worked with is the exciting introduction of onboard ethernet. Until now, most of our microcontroller projects have been USB-based, requiring a host PC. Most of the time, this is more than adequate, as the functionality of the device can be greatly enhanced through the use of some custom-built software.

But the mBed dev board suddenly makes "real" embedded systems a possibility:
the introduction of the ethernet interface means we can create devices which talk to our home internet connection and control (or be controlled by) commands send so/from the 'net.

The mBed system couldn't be easier to use: the device itself appears, when connected to a PC, as a removable drive. Code is compiled into .bin files and you don't need a programmer or any special hardware to "burn code" - just copy and paste the .bin file to the device, press the reset button and the mBed device restarts, running your code! It's that easy!

The examples on the mBed website are pretty impressive too - it uses a number of pre-built libraries, similar to the approach used by Arduino, and abstracts all the complicated low-level stuff, allowing you to concentrate on just getting your stuff working. Code is written using an online editor and saved to the "cloud", so it's always accessible wherever you are. This makes it ideal for cross-platform development and sharing code, whether you're on Windows, Linux or Mac. There's no software to install or complicated folder paths to set up. In fact, to re-program the device you simply plug it in and download a new file to the removable device.



One of the first ethernet examples on the mBed website shows how an RFID tag can generate tweets, to show who has arrived over the course of the day. As we're looking to make a stand-alone device that will communicate over the internet (without the need for a host controller) these examples will form the basis of most of our learning in the coming days.....