COSTS VERSUS EASE OF PROTOTYPING:

Although familiarity with a platform may be attractive in terms of ease of prototyping, it is also
worth considering the relationship between the costs (of prototyping and mass producing) of a
platform against the development effort that the platform demands. This trade-off is not hard and
fast, but it is beneficial if you can choose a prototyping platform in a performance/ capabilities
bracket similar to a final production solution. That way, you will be less likely to encounter any
surprises over the cost, or even the wholesale viability of your project, down the line. For example,
the cheapest possible way of creating an electronic device might currently be an AVR
microcontroller chip, which you can purchase from a component supplier for about £3. This
amount is just for the chip, so you would have to sweat the details of how to connect the pins to
other components and how to flash the chip with new code. For many people, this platform would
not be viable for an initial prototype.

Stepping upwards to the approximately £20 mark, you could look at an Arduino or similar. It
would have exactly the same chip, but it would be laid out on a board with labelled headers to help
you wire up components more easily, have a USB port where you could plug in a computer, and
have a well-supported IDE to help make programming it easier. But, of course, you are still
programming in C++, for reasons of performance and memory.

For more money again, approximately £30, you could look at the BeagleBone, which runs Linux
and has enough processing power and RAM to be able to run a high-level programming language:
libraries are provided within the concurrent programming toolkit Node.js for JavaScript to
manipulate the input/output pins of the board.

If you choose not to use an embedded platform, you could think about using a smartphone instead.
Smartphones might cost about £300, and although they are a very different beast, they have many
of the same features that make the cheaper platforms attractive: connection to the Internet (usually
by wireless or 3G phone connection rather than Ethernet), input capabilities (touchscreen, button
presses, camera, rather than electronics components), and output capabilities (sound, screen
display, vibration). You can often program them in a choice of languages of high or low level,
from Objective C and Java, to Python or HTML and JavaScript.

Finally, a common or garden PC might be an option for a prototype. These PCs cost from £100 to
£1000 and again have a host of Internet connection and I/O possibilities. You can program them
in whatever language you already know how to use. Most importantly, you probably already have
one lying around.

For the first prototype, the cost is probably not the most important issue: the smartphone or
computer options are particularly convenient if you already have one available, at which point they
are effectively zero-cost. Although prototyping a “thing” using a piece of general computing
equipment might seem like a sideways step, depending on your circumstances, it may be exactly
the right thing to do to show whether the concept works and get people interested in the project, to
collaborate on it, or to fund it.
At this stage, you can readily argue that doing the easiest thing that could possibly work is entirely
sensible. The most powerful platform that you can afford might make sense for now.

Of course, if your device has physical interactions (blowing bubbles, turning a clock’s hands,
taking input from a dial), you will find that a PC is not optimized for this kind of work. It doesn’t
expose GPIO pins (although people have previously kludged this using parallel ports). An
electronics prototyping board, unsurprisingly, is better suited to this kind of work. We come back
to combining both of these options shortly.

An important factor to be aware of is that the hardware and programming choices you make will
depend on your skill set, which leads us to the obvious criticism of the idea of “ease of
prototyping”, namely “ease... for whom?”

For many beginners to hardware development, the Arduino toolkit is a surprisingly good choice.
Yes, the input/output choices are basic and require an ability to follow wiring diagrams and,
ideally, a basic knowledge of electronics. Yet the interaction from a programming point of view is
essentially simple—writing and reading values to and from the GPIO pins. Yes, the language is
C++, which in the early twenty-first century is few people’s idea of the best language for beginners.
Yet the Arduino toolkit abstracts the calls you make into a setup() function and a loop() function.
Even more importantly, the IDE pushes the compiled code onto the device where it just runs,
automatically, until you unplug it. The lack of capabilities of the board presents an advantage in
the fact that the interaction with it is also streamlined.

Compare this with developing using a computer: if you already know how to develop an
application in C#, in Python, or in JavaScript, you have a great place to start. But if you don’t
know, you first have to evaluate and choose a language and then work out how to write it, get it
going, and make it start automatically. Any one of these tasks may be, strictly speaking, easier
than any of the more opaque interactions with an odd-looking circuit board, but the freedom of
choice adds its own complexities. Another option is to marry the capabilities of a microcontroller
to connect to low-level components such as dials, LEDs, and motors while running the hard
processing on a computer or phone. A kit such as an Arduino easily connects to a computer via
USB, and you can speak to it via the serial port in a standard way in any programming language.

Some phones also have this capability. However, because phones, like an Arduino, are “devices”,
in theory they can’t act as the computer “host” to control the Arduino. (The side of the USB
connection usually in charge of things.) The interesting hack used by the Android development kit
(ADK), for example, is for the Arduino to have a USB host shield—that is, it pretends to be the
computer end of the connection and so in theory controls the phone. In reality, the phone does the
complicated processing and communication with the Internet and so on.

As always, there is no single “right answer” but a set of trade-offs. Don’t let this put you off starting
a prototype, though. There are really no “wrong answers” either for that; the prototype is something
that will get you started, and the experience of making it will teach you much more about the final
best platform for your device than any book, even this one, can.
PROTOTYPES AND PRODUCTION:

Although ease of prototyping is a major factor, perhaps the biggest obstacle to getting a project
started—scaling up to building more than one device, perhaps many thousands of them—brings a
whole new set of challenges and questions.

CHANGING EMBEDDED PLATFORM:

When you scale up, you may well have to think about moving to a different platform, for cost or
size reasons. If you’ve started with a free-form, powerful programming platform, you may find
that porting the code to a more restricted, cheaper, and smaller device will bring many challenges.
This issue is something to be aware of. If the first prototype you built on a PC, iPhone, BeagleBone,
or whatever has helped you get investment or collaborators, you may be well placed to go about
replicating that compelling functionality on your final target.

Of course, if you’ve used a constrained platform in prototyping, you may find that you have to
make choices and limitations in your code. Dynamic memory allocation on the 2K that the Arduino
provides may not be especially efficient, so how should that make you think about using strings or
complex data structures? If you port to a more powerful platform, you may be able to rewrite your
code in a more modern, high-level way or simply take advantage of faster processor speed and
more RAM. But will the new platform have the same I/O capabilities? And you have to consider
the ramping-up time to learn new technologies and languages.

In practice, you will often find that you don’t need to change platforms. Instead, you might look
at, for example, replacing an Arduino prototyping microcontroller with an AVR chip (the same
chip that powers the Arduino) and just those components that you actually need, connected on a
custom PCB.

PHYSICAL PROTOTYPES AND MASS PERSONALISATION:

Chances are that the production techniques that you use for the physical side of your device won’t
translate directly to mass production. However, while the technique might change—injection
moulding in place of 3D printing, for example—in most cases, it won’t change what is possible.
An aspect that may be of interest is in the way that digital fabrication tools can allow each item to
be slightly different, letting you personalise each device in some way. There are challenges in
scaling this to production, as you will need to keep producing the changeable parts in quantities of
one, but mass personalisation, as the approach is called, means you can offer something unique
with the accompanying potential to charge a premium.

CLIMBING INTO THE CLOUD:

The server software is the easiest component to take from prototype into production. As we saw
earlier, it might involve switching from a basic web framework to something more involved
(particularly if you need to add user accounts and the like), but you will be able to find an
equivalent for whichever language you have chosen. That means most of the business logic will
move across with minimal changes. Beyond that, scaling up in the early days will involve buying
a more powerful server. If you are running on a cloud computing platform, such as Amazon Web
Services, you can even have the service dynamically expand and contract, as demand dictates.