►
From YouTube: Rust for IOT
Description
E. Dunham
https://2019.linux.conf.au/schedule/presentation/119/
Is Rust ready for the embedded world yet? If your IOT project is on ARM or MSP430, it already has native support in the Rust compiler, and AVR and RISC-V have compiler forks available.
But architecture support is only the first challenge: If you're used to writing Rust for hosts that run an operating system, the paradigm shift of having to do everything yourself in the embedded world can be jarring.
This talk will introduce the basic techniques for writing Rust to run microcontrollers, and survey outstanding embedded rust projects already available in the ecosystem.
linux.conf.au is a conference about the Linux operating system, and all aspects of the thriving ecosystem of Free and Open Source Software that has grown up around it. Run since 1999, in a different Australian or New Zealand city each year, by a team of local volunteers, LCA invites more than 500 people to learn from the people who shape the future of Open Source. For more information on the conference see https://linux.conf.au/
#linux.conf.au #linux #foss #opensource
A
B
You
for
having
me
so
I
hope
that
you're
here
today
to
talk
about
rust
and
IOT
with
me.
If
not,
there
are
several
other
parallel
talks
that
I
would
absolutely
be
in
if
I
weren't
speaking
in
this
particular
slot,
so
I've
personally
contributed
to
the
rest
project
in
various
ways.
For
several
years
now
and
in
past
lives,
I've
built
all
kinds
of
robotics
and
embedded
projects.
B
Now
you
won't
have
heard
of
me
from
the
prominent
embedded
rust
project
or
the
fantastic
embedded
rest
book,
because
the
experts
who
work
on
those
things
know
better
than
to
try
to
fit
a
summary
into
a
45-minute
slot.
But
that's
what
I'm
going
to
try
to
do
for
you
when
I
first
proposed
this
talk
to
LCA
there
wasn't
a
central
repository
of
all
the
scattered
knowledge
about
doing,
rests
on
embedded
systems
and
between
that
time
and
right
now,
some
amazing
resources
have
been
produced.
B
At
the
end,
so
that
you
can
take
advantage
of
what
really
makes
a
conference
like
this
special,
which
is
the
other
humans
and
experts
in
the
room,
so
what
I'm
going
to
do
at
the
end,
I'll
ask
everyone
who
wants
to
connect
with
others
about
rest,
whether
that's
recruiting
for
a
project
of
your
own,
sharing,
a
project
that
you
think
is
cool
or
asking
for
a
project
to
contribute
to
to
give
me
a
quick
rundown
on
what
that
is,
and
I
will.
Thank
you
with
a
little
plush
rust
mascot
for
doing
so.
B
You
can
then
display
that,
through
the
rest
of
the
conference
and
people
that
will
know
to
talk
to
you
about
rest,
so
first
things.
First
most
of
you
probably
know
a
bit
about
the
rest
language.
It
attacks
the
apparent
dichotomies
between
human
readable
code
versus
fast
performing
code,
ergonomic
to
develop
code,
verifiable,
certified
bug-free
code
by
sweeping
a
lot
of
problems
under
the
rug
of
the
compiler.
They
then
build
a
compiler
and
associated
tool
chain.
That's
capable
of
solving
all
of
those
problems
to
write
code,
free
of
certain
classes
of
bug
in
any
language.
B
What
we
call
safe
rust
is
the
set
of
all
programs
that
you
know
are
within
this
weird
fractal
barely
defined
space
of
correct
programs,
and
that
means
that
there's
going
to
be
some
correct
programs
that
you
can't
necessarily
prove
are
free
from
bugs,
especially
when
it
comes
to
Io
any
interaction
with
the
outside
world,
and
so
for
those
cases.
When
you
need
to
write
programs
that
are
outside
of
what
you
know
it's
safe,
but
you
as
a
programmer
think
they're
inside
of
what's
correct.
B
B
So
they
get
as
close
as
possible
to
the
boundaries
of
what
the
correct
programs
free
of
memory
misuse
are,
and
so,
if
you've
come
to,
my
LCA
talks
in
the
past
I've
talked
about
how
the
new
bleeding
edge
features
that
we're
not
sure
whether
they're,
really
going
to
land
come
out
daily
in,
what's
called
the
nightly
rest
Channel,
some
of
them
graduate
to
a
beta
channel
and
then
a
stable
channel
with
the
tested
features
is
released
every
six
weeks.
That's
always
backwards.
Compatible.
B
One
thing
that's
new
since
last
year,
and
since
last,
we
talked
here
about
rust-
is
that
they've
also
added
the
concept
of
additions
and
additions
are
an
opt-in
feature,
basically
that
allow
wonderful,
new,
syntax,
wonderful
ergonomics,
increased
safety
that
might
not
be
backwards
compatible
to
the
beginning
of
time.
So
if
you
want
some
backwards
compatible
feature,
you
don't
have
to
opt
in
to
the
addition.
But
if
you
want
the
new
or
cooler
syntax
like
saying
use
the
crate
instead
of
external
crates
whatever,
then
you
can
opt
into
an
addition
with
those
features.
B
So
to
talk
about
rust
on
IOT,
we
need
to
pick
a
definition
for
what
this
buzzword
even
means.
So
IOT
is
a
bunch
of
physical
devices
with
some
kind
of
computer
in
them
and
those
devices
interface
with
the
physical
world
through
their
inputs
and
outputs
and
they
interface
with
each
other
and
often
a
server
over
the
network,
often
a
public
network.
What
could
go
wrong
in
practice?
B
So
we
need
software
on
both
sides
for
a
real
IOT
system,
both
that
server
side
and
the
embedded
devices
side,
of
course,
is
also
the
case
of
just
a
mesh
of
little
devices
talking
to
each
other
over
a
network
and
never
actually
talking
that
close
server,
but
that's
less
common
than
the
server
case
when
you
need
it
to
interact
with
humans
or
interact
with
an
app
that
a
human
is
going
to
be
working
with.
So
both
sides
of
this
equation,
the
embedded
low-level
stuff
and
the
high-level
server
stuff
can
be
written
in
rust.
B
So
most
programmers
find
working
directly
on
the
hardware
to
be
much
less
familiar
and
more
challenging
than
writing
code.
That
runs
basically
as
a
server
that
central
server
or
database
in
most
IOT
design
patterns
is
actually
super
familiar
if
you've
done
web
development
at
ocation
development,
atop
an
operating
system,
and
that
makes
them
a
great
place
to
start.
If
you're
learning
a
new
programming
language
for
the
first
time,
there's
often
more
mentors
and
resources
for
running
a
program.
B
Atop
an
operating
system
then-
and
it's
easier
to
reproduce
for
someone
else
to
reproduce
the
error
you're
getting.
Then,
if
you're
going
directly
on
hardware
plus
writing
atop
the
operating
system
lets
you
avoid
thinking
about
a
lot
of
hardware
problems
that
the
operating
system
just
solves
for
you
before
you
even
notice
them.
B
So
you
can
get
a
working
IOT
project
doing
minimal
if
any
development
on
the
hardware
to
start
with
so
the
Mozilla
things
project
has
a
rest
example
where
you
can
write
the
server
in
rust.
There
example
shows
how
to
use
the
web
think
rate
to
talk
to
a
dimmable
light
bulb
and
a
humidity
sensor
that
expose
the
web
thing
API,
and
you
can
talk
to
anything
talk
to
that
API,
which
you
can
find
in
the
wiki
list
of
supported.
B
B
B
If
you
can
get
away
with
it,
because
that
standard
library
has
been
well
tested
for
years
and
years
on
a
ver
of
platforms
as
a
rule
of
thumb,
if
a
piece
of
hardware
that
you're
considering
is
used
to
run
a
Linux
derivative,
you
can
probably
write
rest
with
the
standard
library
for
targeted
a
great
example
of
this,
and
probably
in
the
room
here.
Right
now
is
wesley
moore's
ePaper
badge
for
this
conference,
whose
code
is
written
in
rust
with
the
source
at
that
github
link
right
there.
B
B
So
what
about
the
embedded
case?
What
about
the
tiny
little
chips,
the
ones
with
the
power
size
or
price
constraints
that
rule
out
the
possibility
of
running
an
operating
system
to
run
your
program
on
writing
software?
For
these?
Like
writing.
The
operating
systems
themselves
is
called
embedded
programming
when
you
don't
have
an
operating
system,
exposing
those
multi-threading,
those
I/o
primitives
to
your
standard
library.
You
obviously
can't
use
a
standard
library
and
instead
you
have
to
be
much
more
explicit
about
how
you
want
your
program
to
perform
those
tasks
so
micromanaging.
B
Fortunately,
rust
provides
support
out
of
the
box
for
quite
a
few
different
architectures,
so
rust
categorizes
its
support
for
different
families
of
chips
in
what
it
calls
tears,
so
the
tier
one
is
guaranteed
to
work.
So
every
change
to
rust
runs
tests.
They
build
the
code,
they
test
the
code
on
that
architecture
and
if
it
fails,
then
they
go
back
and
fix
it
before
pushing
that
change.
B
Tier
to
is
guaranteed
to
build
they'll
build
the
code
for
that
architecture
and
if
it
builds
good
enough,
they
don't
necessarily
have
the
hardware
available
to
test
the
code
on
that
architecture
and
tier
3
is
basically
this
might
work,
but
we
don't
really
make
any
promises,
because
there's
not
the
resources
available
to
do
that
continuous
building
for
it
and
continuous
testing
on
it
that
tiers,
1,
&
2
may
have
so.
Those
different
levels
of
testing
basically
correlate
to
whether
you're
likely
to
be
the
first
one
to
find
some
bug
that
a
test
might
have
caught.
B
If
you
want
a
full
list
of
all
of
the
supported,
architectures
and
platforms,
you
can
check
out
the
rest
Forge.
They
have
a
wonderful
list
with
the
cargo
support
and
all
of
the
details
on
there.
So
what
happens?
If
you
want
the
target,
a
platform
that
isn't
supported
yet
you
can
add
support,
but
the
difficulty
of
doing
that
will
vary
based
on
whether
the
tools
that
rust
uses
are
already
ported
to
that
platform
or
not
so
to
understand
the
different
processes
you
can
use
to
address,
support
to
some
other
architecture
that
doesn't
have
it.
Yet.
B
Let's
quickly
recap
what
a
rust
program
goes
through
as
it's
being
compiled.
So
when
you
compile
rust
code,
it
goes
through
a
series
of
steps.
First,
the
compiler
makes
what's
called
Mir,
which
is
an
intermediate
representation
of
that
code
within
rust.
That
mirror
is
what
your
IDE
can
use
to
expose
any
errors
in
your
code
as
you're.
Writing
it
and
relatedly.
B
If
you're,
not
using
it
rust
integration
with
your
IDE,
yet
I
would
strongly
recommend
checking
out
our
we
IDE
yet
comm,
which
will
tell
you
exactly
what
the
status
is
and
where
to
get
that
integration.
So
after
Mir
they
make
LLVM,
which
is
the
low-level
Virtual,
Machines,
intermediate
representation,
so
the
LLVM
ir,
and
that
goes
to
a
big
old
utility,
the
LLVM
that
does
optimization
on
it
to
optimize
away
any
code.
That's
irrelevant
to
the
final
outcome
of
your
programs,
behavior
and
the
LLVM
converts
the
ir
into
a
runnable
program.
B
So
if
you
want
to
see
what
your
code
looks
like
at
each
of
these
steps,
which
is
really
interesting
to
see,
where
did
those
abstractions
go
away?
When
did
they
go
away?
You
can
either
use
the
emit
flag
to
rest
sea
to
tell
it
emit
Azzam
emit
LLVM
IR
emit
Mir
emit
LLVM
byte
code,
whatever
it
is
that
you
want
to
see,
or
if
you're,
not
depending
on
a
lot
of
other
crates
and
you're
just
curious.
B
You
can
hop
into
the
rest
play
pin
at
play,
trust,
Lang,
org
and
under
the
little
run
button
up
in
the
corner.
You
can
ask
it
to
show
assembly
or
show
IR
for
that
particular
program
that
you've
pasted
it
in
so
to
figure
out
whether
you're
embedded
device
is
supported
or
can
be
supported
by
rest.
You
first
check
whether
its
architecture
appears
as
a
target
in
that
platform
support
list
that
I
linked
earlier.
If
it's
not,
there
have
a
search
around
the
web
to
see
whether
LLVM
can
target
it.
B
B
So
if
you
want
to
write
rust
to
add
support,
it's
a
good
place
to
look
and
regardless
of
which
code
generator
you
prefer,
if
you
want
to
add
a
new
target
to
rest,
you
do
have
to
add
it
to
some
code
generator
and
that's
a
bunch
of
work.
There's
one
other
workaround
that
you
can
consider.
So
if
you
don't
have,
if
you
do
have
a
platform
that
you
can
write
C
for,
but
you
can't
generate
rest
code
for
that
platform
through
either
of
the
code
generators.
B
You
can
try
turning
your
rust
into
C
and
then
compiling
that
C
through
whatever
methods
you
anyways
I.
Tenma
Sanchez
did
this
to
get
rest
running
on
the
esp8266
by
compiling
rust
in
to
see
with
the
M
rest,
C
compiler
and
then
putting
that
C
through
the
usual
tool
train
to
target
that
board.
You
can
see
his
project
and
scripts
at
that
github
link
that
I've
got
on
the
screen.
The
drawback
of
using
M
rust
see
is
that
on
its
own
it
doesn't
do
the
same
Baro
checking
and
validation
that
regular
rust
C
does
so.
B
B
Finally,
you
might
find
yourself
in
a
situation
where
you
want
to
use
some
C
code
alongside
some
rust
code
or
a
little
bit
of
rust
code
alongside
some
C
code
in
an
embedded
context,
and
if
that's
the
case,
the
embedded
rust
book
goes
into
great
detail
on
how
to
impure
operate
between
embedded,
rust
and
embedded
C.
If
you
want
to
take
advantage
of
existing
C
code
in
this
kind
of
way
check
out
the
embedded
rest
book
at
that
link.
Additionally,
if
you're
integrating
between
C
and
rust,
you'll,
probably
find
yourself
spending
a
lot
of
time.
B
Writing
foreign
function
interface
bindings
between
the
two.
Some
of
that
binding
writing
challenge
can
be
automated
using
the
crate
called
bind
gen,
but
you
can
find
on
crates
at
I/o.
So
if
you're
working
without
the
standard
library,
where
do
the
primitive
types
and
the
methods
come
from,
so
even
when
you
opt
out
of
the
standard
library,
most
rust
programs
will
have
the
cork
rake
available.
B
It
doesn't
help
you
with
IO
and
multi-threading
in
the
same
way
that
the
standard
library
does,
but
it
still
exposes
a
bunch
of
the
primitives
and
the
macros
that
you're
used
to
having
you
can
find
all
of
the
core
crate
docks
and
compare
them
to
a
standard
library
docks
there
on
the
rest
side.
So,
if
you're
on
a
chip,
that's
more
powerful
and
you
think
it
could
run
something
kind
of
like
the
standard
library,
but
that
won't
work
for
some
reason.
B
You
may
find
yourself
wanting
to
make
a
custom
standard
Prairie,
and
this
is
a
workflow.
That's
also
supported
the
tool
you
want
in
that
case
is
called
zargo.
It's
like
cargo,
but
with
an
X
instead
of
a
say
for
cross
compiling.
If
you're
watching
this
talk
on
the
recording
after
2019
Durga's
sister
root,
building
features
may
very
well
have
finished,
integrating
into
cargo
so
check
its
wiki
and
if
it
says
yay
will
ended
in
cargo
now
just
use
the
cargo
features
instead.
B
So
after
all
that,
let's
hope
that
you've
found
a
device
with
a
story
for
targeting
it
with
rust,
maybe
that
story's
LLVM,
maybe
that
story
is
used.
Crane
left,
maybe
that
story
is
work
through
with
see
tool
chain.
So
next
check
out
the
awesome
embedded
rust
repo
link
there,
which
is
another
new
thing
since
I
initially
proposed.
This
talk
to
find
what
support
crates,
and
example,
code
are
available
for
your
platform,
so
many
popular
embedded
platforms
have
several
support.
B
Crates
that
are
already
written
for
them
remember
to
check
the
rest
versions
that
they
use
and
have
a
look
at
the
activity.
The
recent
activity
for
the
repository
of
the
project
when
evaluating
whether
it's
still
active
or
whether
this
was
someone's
weekend
project
several
years
ago
and
may
require
a
bit
more
effort
than
you
thought
to
get
it
up
to
date.
B
So
if
you've
only
been
doing
regular
rests,
atop
an
operating
system
so
far,
you'll
be
almost
overwhelmed
by
all
of
the
new
words
and
concepts
that
pop
up,
when
you
jump
into
embedded
development,
and
many
of
these
concepts
are
just
common
to
all
embedded
development
everywhere.
But
these
kind
of
seems
scary
when
they
all
come
at
you
at
once.
So
I'd
like
to
go
through
a
few
of
the
first
things
that
you'll
need
to
be
acquainted
with
when
writing
rest
target
and
embedded
system.
B
First
you'll
see
a
bunch
of
references
to
hell
the
hardware
abstraction
layer,
not
the
2001
musical
machine,
so
this
expresses
the
way
that
those
standard
functions
that
you
normally
get
through.
The
operating
system
should
be
performed
on
a
particular
CPU
family.
So
how
crates
for
a
given
board
that
you're
working
on
are
a
great
place
to
find
example,
code
as
well,
since
the
person
who
wrote
the
hell
crate
usually
did
it
as
a
side-effect
of
trying
to
get
some
other
more
compelling
project.
B
Working
on
that
hardware,
for
instance,
the
Tomo,
that's
Tom's,
open
micro,
USB
device
was
developed
by
members
of
our
own
LCA
community
and
it's
helped
create
linked
right.
There
includes
some
wonderful
examples
of
how
to
blink
the
LED
and
how
to
boot
it
up
just
to
get
the
user
started
with
doing
anything
with
that
crate.
B
So,
while
an
embedded
board
is
really
good
at
interfacing
with
the
inputs
and
outputs
in
the
environment,
the
sensors,
the
lights,
the
motors,
whatever
that
might
be
they're
generally
really
lacking
in
the
human
readable
output
Department.
If
your
program
fails
in
some
way,
while
it's
running
on
the
board,
maybe
it
can
blink
an
LED
at
you
and
that's
generally
about
it,
so
in
order
to
get
actual
useful,
debug
information
off
of
a
program,
while
it's
running
on
an
embedded
system,
you're
going
to
probably
want
a
technique
known
as
semi
hosting.
B
So
this
is
where
the
code
is
connected
to
the
host
machine,
probably
your
development
environment
and
it
can
put
its
errors
and
panics
back
to
your
console
and
log
them
out
for
you
to
analyze
later
on.
So
just
basically
look
for
a
semi
hosting
crate
for
your
platform
or
family
of
platforms,
and
then
you
can
log
messages
from
your
chip
as
it
has
them
back
to
your
host
machine.
There
is
a
fantastic
example
of
semi
hosting
in
the
embedded
rest
book
for
the
cortex-m
that
they're
using
in
their
examples.
So
definitely
look
for
that.
B
If
you
want
I
owe
in
a
useful
feedback
kind
of
sense,
another
challenge
of
designing
embedded
rest
programs
is
another
site
of
the
I/o
heavy
nature
of
all
of
the
IOT
stuff.
Although
the
compiler
can
check
the
logic
in
your
program,
it
doesn't
know
enough
about
what
the
peripheral
devices
attached
to
your
board
might
do
to
make
any
guarantees
about
them,
but
the
principles
behind
writing
memory.
Safe
code
still
apply
to
writing
safe
interfaces
to
your
peripherals.
For
anything
that
we
can
read
or
write.
B
The
alternative
to
using
the
singleton
pattern
would
be
to
use
mutable
global
state
to
store
that
code.
That
represents
the
peripheral,
but
that's
guaranteed
to
be
unsafe,
because
you
can't
make
any
promises
about
whether
the
other
parts
of
your
program
may
try
to
write
it
while
you're
trying
to
read
it
or
vice
versa,
at
any
point
in
time.
B
So
another
way
to
improve
the
compilers
ability
to
reason
about
your
peripherals
is
to
model
them
as
state
machines.
A
state
machine
is
just
a
representation
of
which
of
several
valid
conditions.
The
peripheral
can
transition
between.
From
which
other
ones
like
if
I
was
in
the
state
of
waiting
to
give
my
talk,
then
I
had
to
get
on
stage.
Give
the
intro
give
the
talk
and
then
take
questions.
It
would
be
illegal
to
go
directly
from
waiting
to
speak
to
taking
questions
it
just
wouldn't
make
sense.
B
It'll
never
be
needed
at
runtime,
so
you
can
get
the
benefit
of
having
the
logic
expressed
by
these
empty
abstractions
without
the
cost
of
having
them
alter
the
code
that's
produced
at
the
end.
That's
the
zero
cost,
abstraction
that
restorations
go
on
about,
and
it's
when
you
get
basically
the
best
of
both
worlds.
Another
challenge
in
writing.
Embedded
software
is
concurrency.
B
If
you
take
no
special
precautions
around
concurrency,
it's
possible
that
you
might
be
halfway
through
doing
something
that
you
really
don't
want
to
get
interrupted
with
like
reading
or
writing
something
and
then
an
interrupt
fires
and
changes
the
state
of
that
thing
you
were
working
with
and
then
who
knows
what's
going
to
happen
afterwards,
you
get
undefined
behavior
and
that's
what
we're
trying
to
avoid.
So
instead
there's
three
ways
you
can
tackle
concurrency
in
your
code.
B
The
first
way
to
handle
concurrency
is
to
avoid
it
don't
handle,
interrupts
and
if
you
need
to
get
the
state
of
something
around,
you
just
pull
it
when
you
have
time
to
for
some
devices,
especially
those
that
upload
data
every
so
often
or
toggle,
their
output
upon
detecting
some
condition.
That
persists
over
time.
This
can
actually
be
a
perfectly
viable
solution
and
avoiding
concurrency.
All
together
makes
programs
easier
to
write
and
easier
to
reason
about
in
debug,
but
it's
often
not
possible.
B
So
instead,
when
you
need
to
handle
concurrency
on
a
board
that
supports
it,
you
can
use
atomic
operations
that
are
provided
by
the
instruction
set
of
the
device
that
you're
targeting,
for
instance,
if
you're
using
a
cortex,
m3
you'll,
have
atomic
operations
for
reads
and
writes
that
will
just
retry
until
they're
successful.
If
something
that
can't
be
interrupted
was
going
on
when
they
first
tried
to
happen
for
earlier
cortex,
as
though
you
won't
have
those.
B
So
if
your
board
and
your
Howell
create
support
Atomics,
they
can
let
you
do
important
operations
without
the
risk
of
them
getting
interrupted
or
ever
getting
forgotten
to
get.
But
what,
if
you
don't
have
them?
The
final
approach?
If
you've
got
to
have
concurrency-
and
you
can't
do
Atomics
is
you
can
just
temporarily
disable
interrupts
while
the
important
pieces
of
code
are
executed,
but
leave
them
on
the
rest
of
the
time
when
the
less
critical
code
is
going
on.
B
So
those
areas
where
there's
no
interrupts
allowed
are
called
critical
sections
and
the
syntax
for
them
will
vary
based
on
the
crates
that
you're
using
to
target
your
particular
architecture.
So
they
do
have
the
drawback
that,
if
an
interrupt
just
gets
ignored,
then
you
have
to
figure
out
what's
going
to
happen,
but
that's
less
problematic
than
getting
the
undefined
behavior
of
interrupting
at
the
wrong
time.
So,
finally,
one
of
the
parts
of
CPU
behavior
that
you're
gonna
have
to
micromanage.
Well,
you
don't
have
an
OS
helping.
You
is
telling
it
what
all
the
registers
do.
B
The
registers
are
just
little
spaces
in
memory
where
the
processor
stores
little
specific
pieces
of
information.
Each
one
has
an
address
and
some
of
them
store
special
information
where
the
CPU
will
always
look
to
that
place
for
that
fact,
and
others
can
hold
whatever
you
want
them
to
so
using
the
right
specialized
registers.
Matters
a
lot
because
an
instruction
might
read
from
a
particular
register
and
if
you
have
the
wrong
thing
there,
nothing
is
going
to
work
as
expected.
B
B
So,
if
you're
interested
in
learning
more
about,
embedded
or
low-level
rest
by
reading
it.
The
many
operating
systems
that
are
written
in
rust
can
be
a
great
place
to
see
it
really
pushing
the
boundaries.
So
a
few
of
those,
the
red
ox
OS,
is
probably
the
most
famous
of
those,
and
it
runs
on
the
nightly
rust
that
has
all
of
the
cool
new
features.
There
are
others,
though
Robo
Galia
is
trying
to
improve
the
rest
ecosystem
around
the
SEL
for
microkernel.
B
So
another
thing
to
call
out,
especially
since
we're
talking
about
IOT
today,
is
that
there's
the
top
operating
system
and
project
they're
at
Taco,
S
org.
That
offers
a
couple
of
open
hardware
boards
and
is
customized
for
them.
That's
focused
on
improving
the
IOT
ecosystem.
So
if
open
hardware
is
a
big
deal
to
you
and
you
want
to
go,
buy
a
board
or
produce
a
board
that
has
a
huge
amount
of
rust
support,
seriously,
consider
their
hail
and
I
mix
products.
B
So,
as
I
mentioned
at
the
start
of
this
talk,
rusts
embedded
resources
have
expanded
so
much
even
just
in
the
ten
months
since
I
proposed
this
talk
to
fill
what
felt
at
the
time
like
a
gap
in
their
documentation.
So
there's
now
an
embedded
working
group
with
an
IRC
channel
and
the
handle
rest
embedded
on
Twitter.
So
you
can
absolutely
join
them.
Ask
them
questions.
They
are
the
experts
there's
a
couple
of
books
out
the
embedded
nomicon
and
the
debugger
nomicon.
B
This
is
a
common
naming
convention
for
how
to
write
unsafe
rest
is
just
always
the
nomicon.
If
you
would
like
to
go
into
more
detail
and
the
working
groups
repository
has
a
bunch
of
things,
including
they're,
working
at
the
moment
on
a
repository
and
a
website
of
showcasing
a
bunch
of
cool
embedded
projects.
That's
not
ready
yet,
but
pretty
soon,
we'll
be
ready
for
polls
proposing
your
own
rust,
embedded
projects
to
be
showcased
there
and,
if
you're,
just
getting
started
in
embedded
development.
B
B
The
way
that
I
would
like
this
to
work
is
I'd
like
to
hear
from
those
of
you
who
have
ruffs
IOT
projects
or
just
rest
projects
or
want
to
start
one
so
put
up
your
hand
we'll
come
around
with
a
mic
and
tell
us
basically
these
questions:
what's
your
favorite
rest,
IOT
project
or
the
project
you
contribute
to
or
that
you're
looking
for
what
kind
of
help
and
feedback
does
it
need?
What
should
people
search
to
find
it
online
and
for
everybody
that
shares
a
project
up
until
I
run
out?
B
So
if
you
have
questions,
we
can
take
questions
in
the
end
at
the
end
outside,
but
I
would
recommend
talking
to
the
experts
who
are
using
and
doing
these
projects,
because
so
many
questions
our
value,
judgments
and
matters
of
experience
and
opinion
that
you
will
get
a
better
answer
from
polling.
Several
people
who've
tried
it
at
different
times
than
from
asking
any
one
speaker
so
with
that,
let's
start
going
around
to
for
people
to
share
their
IOT
rust,
stuff,
mm-hmm
hi.
C
C
B
D
Hi
I'm
Kate,
Stewart
and
I'm
with
the
Zephyr
project,
and
so
one
of
the
things
were
interested
in
and
obviously
is
running
on,
OS,
very
lightweight,
OS
and
so
I'm
sort
of
curious.
Is
there
any
work
being
done
on
having
a
rust
port
rust
standard
library
port
into
Zephyr
to
be
running
with
it?
Do
you
know
of
I'm.
B
Not
I'm
not
personally
aware
of
as
eff
report
off
the
top
of
my
head,
but
there
could
very
well
be
one
quietly
being
discussed
or
worked
on
online.
That
I
just
don't
happen
to
have
seen
yet
because
I
haven't
looked
for
it.
So
I
would
strongly
recommend
both
searching
it
and
asking
the
embedded
working
group
in
their
channel
and
asking
around
the
Zephyr
community,
because
things
are
often
just
quietly
not
quite
open
yet
because
people
aren't
quite
happy
with
them
yet
for
quite
some
time
before
they
become
really
public
and
easy
to
find
Thanks.
E
E
B
Absolutely
so
I
would
say
that
the
core
team
is
your
best
point
of
contact
there,
and
if
you
go
to
the
core
team
and
ask
for
their
feedback
on
your
current
engagement
with
the
community,
then
they
can
probably
point
you
exactly
where
you
can
help
best.
There
is
a
bit
of
a
concern
in
that
rest
is
a
fully
volunteer
project.
B
Some
people
are
paid
to
work
on
rest,
but
that's
generally
rest
for
their
particular
company's
needs,
and
so
there's
there's
some
ambiguity
in
your
comment
about
whether
or
not
you're
expecting
here's
some
hardware,
please
implement
all
of
the
things
for
us.
If
that's
the
case,
then
making
sure
that
there
is
something
in
it
for
the
people
doing,
the
implementation
can
help
a
lot.
If
that's,
if
that's
not
the
case,
just
I
think
working
working
directly
with
the
core
team
working
with
the
infrastructure
team.
B
If
you're
concerned
about
the
test
story,
for
instance,
if
you're
like,
why
aren't
you,
why
isn't
this
tier
1?
Why
aren't
you
testing,
building
and
testing
everything
on
it?
Maybe
it's!
We
don't
have
the
hardware,
because
no
one
has
provided
us
with
hardware
and/or.
No
one's
running
the
hardware
or
whatever
that
might
be,
and
whatever
that
answer
is
to
the
question:
what
can
we
do
to
get
this
to
a
higher
support
tier
and
to
contribute
better?
B
They
will
be
able
to
point
to
you
in
the
best
direction
for
that
engagement,
and
we
could
brainstorm
later
on
about
community
involvement
strategies
about
basically
marketing
your
project,
maybe
have
a
bet
about
better
publicizing.
What
can
be
done
with
it?
But
let's
continue
for
now.
I
would
be
delighted
to
talk
to
you,
after
about
just
ideas,
for
how
to
make
it
better
known.
B
F
Great
talk,
I
just
wanted
to
mention
a
big
part
of
IOT
is
obviously
the
mobile
applications
to
interact
with
those
we've
recently
started,
using
rust
for
iOS
and
Android
in
production,
and
we've
found
it
to
be
brilliant,
like
the
Android
bindings
and
I
had
the
iOS
bindings
just
a
so.
If
you
are
making
an
IIT
device
consider
using
rust,
because
then
you
can
use
rust
for
your
device
itself
and
also
for
the
core
parts
of
iOS
and
Android
might
save
you
some
time.
Fantastic.
G
H
It's
partially
overlapping
with
his
question,
but
what's
the
debug
story
right
now,
because
I
used
rust
about
one
year
ago
for
us,
Jas,
stuff
and
I
got
stuck
into
debugging
is
really
really
hard.
Awesome
Jes
is
also
kind
of
new
platform.
So
it's
not
just
rust
being
immature.
But
what
about
you
know
embedded
programming.
B
So
yeah
debugging
is
absolutely
hard.
I,
don't
know
of
a
language
in
which
you've
been
embedded.
Debugging
is
necessarily
easy.
If
there's
a
language
in
which
it's
radically
easier
and
they
have
a
tooling
story
that
makes
it
radically
easier,
I'm,
pretty
sure
that
the
developers
and
myself
would
love
to
hear
about
how
we
could
adopt
that
the
debug
story
I
mean
you
want
I.
Is
that
an
answer
up
there?
Yes,
what
is
your
possible
answer?
I
will
sorry
I'm
really
giving
my
volunteers
their
exercise
so.
F
On
embedded,
I've
used
a
product
called
black
magic
Pro
before
which
is
basically,
it
gives
you
a
serial
port
to
a
JTAG
interface
and
I've
actually
messed
around
a
bit
with
using
rust
on
that,
and
you
do
get
call
stacks
and
you
can
put
breakpoints
and
stuff
like
that
on
and
you
don't
have
to
worry
too
much
about
LOD,
be
talking
to
your
device
and
stuff.
So
I
can
recommend
if
you're,
using
your
cortex,
m0
or
cortex
m3
check
out
a
black
magic
probe.
F
B
I
Hi
I'm
Wes
I
run
a
little
project
called
read
rust,
which
collects
blog
posts
from
the
Ross
community,
and
it's
a
bit
of
a
future
call
for
the
participation
but
currently
working
on
a
version
2.
That
would
let
me
recruit
other
people
to
help
post
the
the
articles
and
approve
them.
So
if
anyone's
keen
to
get
involved,
I'm
also
working
on
this
new
version
being
based
on
it
already
uses
the
bunch
of
rust
tools,
but
the
new
version
is
going
to
be
built.
I
J
I
guess
you,
the
inspiration
here
so
I've
been
using
these
Nordic
based
embedded
sheets,
which
is
a
Bluetooth,
low-energy
chipset
with
an
arm
m4,
embedded
and
I
was
interested
to
look
at
the
rust
IOT,
so
I
thought
well.
Maybe
I
can
print
it,
but
I
looked
and
there's
actually
a
seemingly
relatively
mature
project
for
it
already
so
I
guess
what
I'm
excited
to
see
is:
there's
actually
quite
some
mature
ecosystem
around
rust,
embedded,
so
yeah
I'm
gonna,
try
it
out
and
I
guess.
J
B
K
Particularly
IOT
related
but
I'm
in
the
middle
of
writing.
Some
rust
code
for
graph
algorithms,
a
port
of
an
earlier
C
module,
with
a
particular
emphasis
on
the
fact
that
lots
of
problems
involve
standard
graph
algorithms.
But
you
don't
usually
want
to
change
all
your
data
structures
into
the
form
that
most
graph
libraries
want
them
in
order
to
do
that.
So,
if
anyone
wants
to
assist
with
that,
particularly
if
they
know
the
sort
of
rustic
idiom
ways
of
doing
things,
then
that
would
be
most
appreciated.
L
All
right
not
quite
an
IOT
projects,
but
it
is
embedded.
If
anyone
doesn't
know
these
Sony
cameras
actually
can
run
Android.
So
what
started
out
as
an
attempt
at
porting
over
the
Google
HDR
app
to
try
and
get
amazing
photos
out
of
it
and
then
installing
Instagram
on
that
which
I
can
post
directly
to
anyone.
B
L
B
Right
well,
it
looks
like
we're
just
about
at
time.
Thank
you,
everybody
for
your
feedback
and
your
publication
of
your
various
rest
and
rest
IRT
projects.
So
you
can
get
these
slides
and
notes
at
that
link.
You
can
find
me
on
Twitter
or
on
IRC
and
I
will
be
around.
We
can
do
a
rest-pause
later
if
anyone
wants
a
rest,
buff
just
postal,
a
chat
list.