DESIGNING FOR THE IOT CONNECTED PRODUCTS
www.newelectronics.co.uk 9 March 2021 19
karepa_summer/stock.adobe.com
Author details:
Jonathan Pallant
is senior
embedded
systems
consultant at
42 Technology
connectivity, either with LTE-M or
NB-IoT, a device like the Nordic
nRF9160 is a compelling package of
CPU, RAM, Flash, GPS and Modem.
But, if you can afford the PCB space,
you might prefer the exibility of a
“standard” microcontroller and a
separate LTE module. A similar story
applies to wireless standards like
Wi-Fi and Bluetooth, where there are
microcontrollers available with the
radio built-in, and also stand-alone
modem modules.
Of course, IoT devices don’t just
run on basic microcontrollers. There
are plenty of examples where the
power and technical ability of a full
Linux Kernel-based system was the
right choice, even with the knock-on
effects on power consumption, space
and software support burden.
The Core Course
This stage involves bringing in
pre-existing software (essentially
“third-party IP”) including: the
Operating System (or Real-Time
Operating System) kernel; the
chipset drivers; and the board
support package (BSP) which
customises those drivers for your
particular PCB design.
Chipset vendors often provide
a free Software Development Kit
(SDK) containing all of this. But
it is worth remembering that this
SDK may not work with anyone
else’s silicon, limiting your ability to
change supplier in the future. If that
matters, perhaps consider a vendorneutral
offering such as Amazon
FreeRTOS or Microsoft’s ThreadX.
Linux-based systems have
similar options too – often with
a free “distribution” to get you
started. But you may prefer to rollyour
own or to use a more generic
off-the-shelf Linux distribution,
such as Ubuntu Smart Start or
Fedora IoT. It all depends on your
security requirements, development
timescales and any system
limitations on power consumption
and storage space.
The Code Course
Of course, you can’t just install
embedded Linux on your device,
or ash on an RTOS, and call it a
day. You’ll need to add the “secret
sauce” by writing code to customise
this system to your needs. That
could be as simple as specifying the
endpoints and keys to upload sensor
readings, or as complex as running
multiple bespoke protocol stacks
and sophisticated AI processing at
the edge for good measure. Either
way, the language and tools you
use will have a huge impact on your
up-front development programme,
as well as for on-going support and
maintenance.
The C programming language
has been the default for almost
40 years now, but maybe there’s
value in trying a memory-safe
systems language, like Rust or even
something like MicroPython. But if
you nd your Chipset or Core can’t
handle your preferred choice here,
you may need to go back and rethink.
The Cloud Course
Most connected device
developments involve the gathering
of data for later analysis, and the
issuing of commands to control
devices “in the eld”. It makes
sense almost universally to ofoad
this computing requirement to one
of the pre-built IoT management and
data storage offerings available from
the big “cloud” providers, rather than
using on-premises systems.
Whichever cloud platform
you choose though, you’ll need
to balance the up-front costs of
integration against on-going support
and maintenance. And remember,
you’re going to need support from
your cloud, chipset and connectivity
providers for the entire lifetime of
your product in the eld.
And finally…the Comms Course
The default Communications
protocol your Code will use to talk
to your Cloud provider will usually
be text-based (such as JSON or
XML) running over an encrypted
connection-oriented HTTP link.
Whilst this sort of stack is
ubiquitous (it’s how most current
websites are built), its plain-text
nature increases both bandwidth
requirements on your connectivity
and chipset resources, and the
connection-oriented nature can
interact badly with some highlatency
wireless services. For
example, if you are designing an
ultra-low power monitoring system
using NB-IoT, you might be better
with a binary connection-less
protocol like CoAP.
Also, being able to rely on a
well-used, real-world-tested protocol
stack (such as the one that comes
with your Core software) is almost
certainly going to be better than
trying to spin one yourself.
It’s worth remembering
There are few absolutes in
technology and there will always
be a range of solutions to meet
your requirements. What works
best will depend on your budgets,
timescales and the skills you have
available in-house, from an external
development partner or through any
existing relationships with hardware,
software or network providers. But,
even the best technical solution
will never become a winner unless
it gets to market on time and with
the right combination of price,
specication, and availability too.
Below: Deciding what
to prioritise is not
always easy when
developing new
connected products
/www.newelectronics.co.uk
/stock.adobe.com