►
From YouTube: An Overview of the Embedded Rust Ecosystem
Description
If you have considered using embedded rust, you may have run into questions such as “What is embedded_hal, a pac and a hal implementation?”, “What is a driver crate?” “Where does rtfm/rtic and cortex_m fit into the picture?” This talk will give you an overview of what the crates are, how they fit together and why they exist which should give you a good place to start your embedded rust journey.
A
A
B
All
right,
thank
you,
yeah,
so,
like
james
said,
I'm
gonna
talk
about
give
you
an
overview
on
the
embedded,
rust
ecosystem
and
the
reason
I
want
to
do
this
is
because
there
are
a
whole
lot
of
crates
out
there
and
what
they
do
and
their
connection
to
each
other
may
not
always
be
clear.
We've
already
seen
a
couple
of
crates
today,
like
drivers
and
arctic,
and
we'll
probably
see
many
more
so
hopefully,
this
talk
will
sort
of
show
you
how
everything
is
connected
together.
B
My
name
is
franz
garman
online.
I
go
by
the
zork2.
I
talk
too
much
about
russ,
sometimes
to
the
point
where
even
non-programmers
are
talking
to
me
about
rust,
which
is
kind
of
strange
okay
to
happen
in
the
embedded
world.
I
am
a
maintainer
of
the
stm32
f1xx
hull
crate,
which
I
hope
that
the
name
of
that
crate
will
make
more
sense
after
this
talk
than
it
does
now.
B
B
That's
not
very
important,
though
it's
more
important
who
you
are,
I
presume
quite
a
lot
of
you-
are
here
as
embedded,
dress,
users
already
and
then
most
of
the
content
in
this
talk
probably
won't
be
new
but
feel
free
to
stick
around
anyways
for
the
people
who
are
interested
in
this
court
talk.
I
would
assume
that
you
come
from
one
of
three
categories.
B
So,
like
I
said,
the
goal
here
is
that
I
want
to
explain
you
to
you
why
there
are
so
many
crates
and
what
they
do,
and
I
think
the
best
way
of
doing
that
is
by
showing
you
the
need
for
them
sort
of
showing
you
how
you
can
work
up
your
way
up
to
an
ecosystem.
That
looks
the
way
it
does
today
from
starting
from
nothing,
and
what
that
means
in
practice
is
that
the
initial
code
is
really
not
something
you
would
write
in
rust.
B
B
How
do
you
program
a
microcontroller
and
generally
you
do
that
by
controlling
registers
or
writing
and
reading
from
registers
in
order
to
affect
the
outside
world
through
the
microcontroller's
pins,
the
registers
are
typically
memory
mapped,
and
what
that
means
is
that
you,
you
write
to
them
by
writing
to
a
specific
address
in
memory
and
that
rate
gets
intercepted
at
some
point
and
handed
off
to
the
peripheral
which
controls
the
pins
and
to
see
what
to
write
where
and
when
to
write
it.
You
should
read
the
data
sheets
for
instructions.
B
I
think
this
will
all
be
more
clear
if
we
give
you
an
example.
So
the
example
I'm
going
to
show
you
is
sort
of
the
hello
world
of
the
embedded
world.
Turning
on
an
led
I'll
use,
an
sm32
f1
processor,
because
it's
the
one
I'm
most
familiar
with,
but
the
process
is
similar
for
almost
all
microcontrollers
out
there.
B
So
the
first
step
is
to
read
the
1000
page
data
sheet
of
the
processor
and
you
don't
need
to
read
all
the
thousand
pages
to
turn
on
an
led,
but
to
turn
on
the
microcontroller
and
start
up
the
corresponding
parts
and
turning
on
the
led,
you
probably
need
about
100
pages
of
reading
the
process
once
you've
done.
That
reading
is
that
you
start
with
powering
up
the
gpio
peripheral
that
stands
for
general
purpose:
input,
output
and
is
for
just
turning
pins
on
and
off
for
reading
from
pins
directly.
B
Then,
once
you've
done
that
you
want
to
configure
the
pin,
you
are
interested
in
as
an
output,
and
you
need
to
set
that
output
in
the
correct
mode,
because
there
are
many
modes
that
can
create
outputs
in
different
ways
in
different
electrical
ways,
and
you
need
to
set
one
that
is
suitable
for
your
task
and
then.
Finally,
after
all
of
this,
you
can
set
your
pin
to
high
and
your
led
will
hopefully
turn
on.
B
B
B
Then
we
want
to
write
some
values
to
that
register
and
from
this
we
can
see
that
we
want
to
write
a
1
0
in
bits,
20
and
21,
and
a
0
1
in
bits,
22
and
23,
and
this
is
for
setting
the
mode,
the
output
or
the
input
and
the
configuration
the
the
type
of
electrical
output
we
want,
and
the
same
is
true
for
the
output
value.
We
have
a
specific
bit.
We
need
to
change
in
a
specific
register
in
rus.
That
would
look
something
like
this.
I
said
before.
B
We
need
to
start
the
gpio
functionality
in
the
rcc
peripheral,
that's
done
in
the
startup
gpio
function
because
it
doesn't
fit
on
the
slide
here.
Then
we
compute
some
addresses.
So
we
have
this
start
of
the
gbio
bank
and
then
we
have
the
control
register
offset
and
the
offset
for
the
output
data
register.
So
this
will
get
added
to
the
start
value
the
patterns
we
want
to
write
to
specific
places
are
0
1
for
the
output
mode
and
1
0
for
the
push
pull
mode,
and
then
we
can
actually
do
this
writing.
B
B
Sorry
and
the
same
thing
is
true
for
the
push-pull
configuration
shifted
a
bit
more
because
that's
where
the
configuration
is
stored
and
we
do
a
bit
twice
or
between
them
and
then
the
same
thing
is
true
for
output.
So
we
compute
the
address
of
the
output
data
register
and
set
the
13th
bit
to
a
1
to
actually
turn
on
an
led
right.
That
was
not
very
fun.
At
least
I
don't
think
that's
fun
code
to
write
it's
very
unsafe.
It's
really
unergonomic.
B
We
hope
throwing
a
bunch
of
magical
constants
around
with
dereferencing
pointers,
which
you
almost
never
do
in
rust.
Yeah.
We
really
don't
want
to
work
like
this.
Luckily,
the
manufacturers
of
microcontrollers
often
publish
svd
files
which
describe
the
function
of
each
register
in
a
way
that
the
computer
is
better
at
understanding.
B
A
good
driver
talk
that
was
earlier
today
and
as
a
bonus,
we
also
prevent
reuse
of
peripherals.
Once
we
have
this
svd
file
or
as
pac,
we
have
a
struct
representing
each
register
and
we
only
have
one
of
that
for
each
register.
So
if
we
want
to
share
it
for
some
reason,
the
ownership
system
will
make
sure
that
we
do
that
properly
in
code.
B
We
want
to
modify
the
crh
register
of
jpioc,
setting
the
mode
of
a
pin
13
to
an
output
and
the
configuration
of
pin
13
as
a
push
pull
and
that's
all
we
have
to
do
now.
The
pin
is
configured
then
we
want
to
actually
change
the
output
and
to
do
that,
we
want
to
modify
the
output
data
register,
setting
the
output
data
of
pin
13
to
high
alright.
This
was
a
much
nicer
interface.
I
I'd
say-
and
I
hope
you
agree
it
does
this
through
a
lot
of
zero
cost
abstractions.
B
So
you
can
see
there's
a
bunch
of
closures
going
on
here
and
there's
a
bunch
of
weird
function
calls
all
of
this
gets
optimized
away
by
the
compiler,
though
it's
only
done
in
release
mode.
So
if
you
run
your
embedded
project
in
the
bug
mode,
it
may
be
much
much
slower
than
it
is
in
release
mode,
which
is
a
pitfall
that
is
easy
to
fall
into.
But
luckily
the
fix
is
to
just
compile
with
release
mode
and
your
code
will
be
linked
blazingly
fast.
B
B
B
That's
done
through
that
start,
gpio
function,
but
there's
never
any
check
that
we
run
that
if
we
don't,
the
program
will
misbehave
and
we'll
only
find
out
at
runtime
after
a
whole
lot
of
debugging.
The
same
thing
is
true:
when
we
talk
about
initialization,
so
there's
no
check
for
that.
You
set
correct
values
in
every
register.
B
Well,
we
first
need
to
start
up
the
gpio
or
the
rcc
register,
put
it
in
a
known
state
that
the
hull
can
work
with
that's
done
through
the
constrain
function
or
something
similar,
and
that
gives
us
a
struct
for
the
rcc
register
that
we
can
then
pass
to
the
next
function.
The
function
that
configures
the
gpio
pins
themselves
for
the
gpio
peripheral
in
the
sdm32
hull
or
f1
hell.
That's
called
split
because
it
does
a
bunch
of
other
things
than
just
turning
on
the
led
or
turning
on
the
the
gpio
peripheral.
B
But
the
key
thing
here
is
that
we
have
to
pass
this
rcc
register
to
the
split
function
and
if
we
don't,
if
we
don't
have
access
to
that
rcc
register.
That
means
we
haven't
started
up
the
rcc
peripheral,
and
that
means
our
code
would
misbehave
at
runtime.
But
we
get
told
that
at
compile
time
here
so
once
we
have
this
gpioc
struct,
we
can
configure
the
pin
we're
interested
in
pin
13
and
we
want
to
set
it
as
a
push-pull
output,
and
this
is
a
much
higher
level
function.
B
Call
there's
no
chance
of
misconfiguration,
for
example,
setting
it
as
a
push-pull
input
which
doesn't
make
sense.
So
we
get
some
safety
there
and
again
there's
a
check
that
we
have
initialized
the
gpio
before
we
start
configuring
it
and
finally,
we
just
do
lead
dot
set
high
to
turn
the
led
on,
and
hopefully
it
turns
on
and
again
we
make
sure
that
we
configure
the
pin
as
an
output
before
we
can
turn
on
the
led,
because
otherwise
we
don't
have
a
set
high
function
on
this
struct.
B
B
Right
so
the
next
step
is
to
work
with
something
more
advanced
than
just
turning
on
an
led.
Let's
say
we
want
to
talk
to
this
ultrasonic
distance
sensor.
It
has
two
pins,
one
called
trig
and
one
called
echo
to
use
it.
You
send
a
pulse
on
the
trig
pin
and
after
a
while,
you
get
a
pulse
back
on
the
echo
pin
and
the
length
of
that
pulse
is
proportional
to
this
distance.
As
the
sensor
measured
so
using
our
hull,
we
can
define
a
function
that
reads
a
measure
that
does
a
measurement
from
this
sensor.
B
The
function
takes
a
timer
and
two
pins
trig
and
echo
at
the
type
saved
system
level.
We
ensure
that
the
pins
are
configured
as
outputs
and
inputs.
If
they're
not
we'll
get
an
error,
then
we
send
the
start
pulse
using
just
a
set
high
and
set
low
functions
we
saw
before
and
the
wait
function
on
the
timer.
B
To
use
this,
we
do
the
initial
setup
I
showed
before.
I
just
moved
that
into
a
function
here,
and
then
we
configure
our
pins.
So
we
say
that
we
need
pa0
to
be
a
push-pull
output,
pa1
to
be
an
input
and
the
timer
to
be
a
configured
timer
in
the
hull,
and
then
we
can
just
call
measure
distance
using
these
pins.
B
B
We
use
types
to
ensure
that
things
are
configured
correctly
and
we
also
use
ownership
to
ensure
that
timers
aren't
shared.
So
to
go
back
to
the
previous
example,
we
made
sure
that
pin
is
in
an
output
if
we
didn't,
unlike
arduino,
where
you
could
set,
pin
mode
or
do
digital
write
on
a
pin.
That
hasn't
been
set
to
an
output
using
pin
mode.
B
We
get
that
check
at
runtime
and
also
once
we've
done
this
setup
for
the
timer,
for
example,
or
these
push-pull
outputs
we've
taken
ownership
over
the
pins
and
the
timers,
so
we
can't
accidentally
reuse
these
pins
or
timers
somewhere
else.
So
all
of
this
makes
sure
that
a
lot
of
the
debugging
we
have
to
do
we
may
have
to
do
in
hardware-
is
done
at
compile
time
here
all
right.
So
after
a
while
someone
else
pick
makes
another
hal
for
another
microcontroller.
B
It's
likely
that
this
hull
does
similar
things
they
all
the
microcontrollers
will
probably
have
gpio
functions.
All
of
them
will
have
timers
and
so
on,
but
it's
likely
it's
also
likely
that
it
has
slightly
different
apis,
because
the
registers
aren't
the
same
in
every
microcontroller
and
the
preferences
of
the
developers
may
be
different.
So
we
may
have
focused
a
lot
on
type
safety.
B
So
we're
duplicating
a
lot
of
the
work
and
that's
not
really
good
enter
embedded
hull
embedded
hull
is
a
project
that
provides
traits
for
common
peripherals
in
the
e
or
in
microcontrollers
gpio,
pins,
timers,
serial
communication
and
so
on
then
embedded
hull.
Let's
drive
hulls
implement
those
traits
and
by
doing
so,
drivers
can
use
the
traits
in
the
embedded
hall
or
in
embedded
hal
to
implement
their
functionality
and
by
doing
that,
they
are
compatible
with
every
hull
in
the
ecosystem.
B
So
we
only
have
to
write
one
ultrasonic
distance
sensor,
driver
and
every
hull
can
take
advantage
of
that
work
to
convert
our
ultrasonic
distance
sensor,
driver
to
to
use
embedded
health
rates.
It's
quite
simple:
we
import
the
traits
from
remember.hull
called
input,
pin,
pin
and
timer,
because
that's
the
three
we
used,
then
we
just
make
the
function.
Generic
over
the
input
pin
and
the
output
pin
and
the
timer
I
messed
up
here.
B
So
that's
sort
of
the
end
of
the
stack
of
lay
of
crates
on
top
of
register
manipulations,
but
there
is,
there
are
some
other
crates
that
will
that
you
will
come
across
and
that
I
want
to
explain
next.
The
first
one
is
arctic:
real-time
internet
delivering
concurrency,
which
is
a
framework
for
building
real-time
systems.
It
provides
tasks
and
communication
between
the
tasks
and
enables
real-time
analysis
among
a
whole
lot
of
other
things.
B
If
you
haven't
already,
you
should
go
back
and
back
and
watch
emil
frisk's
talk
about
this,
which
he
gave
just
an
hour
or
so
ago,
because
it
goes
into
a
lot
more
details
than
this.
It
should
be
noted
that
this
crate
was
previously
known
as
rtfm
or
real
time
for
the
masses,
but
that
acronym
turned
out
to
be
a
bit
weird,
so
they
renamed
it
to
arctic
a
month
or
so
ago,
which
means
that
you
will
still
come
across
this
rtfm
name,
but
just
remember
that
rdfm
and
arctic
are
the
same
thing.
B
There's
you
will
also
come
across
crates
called
board
support
crates
and
what
they
do
is
provide
utilities
for
breakout
boards.
So,
for
example,
I
have
this
tnc
3.6
here
it
has
a
microcontroller
in
the
middle,
but
it
also
has
a
bunch
of
pins
on
the
outside
which,
unlike
the
microcontroller,
are
labeled
with
arduino
names,
so
pin
one
two,
three
and
so
on,
instead
of,
for
example,
pa1pb1
and
so
on.
B
So
what
the
bsp
for
this
board
would
do
is
replace
the
names
of
those
pins.
It
would
also
probably
include
drivers
for
the
peripherals,
so
this
one
has
a
micro
sd
card
slot
up
here
and
the
p
bsp
for
a
team
3.6
would
include
a
driver
for
that.
Unfortunately,
in
the
three
points
in
the
teensy
case,
I
don't
think
there
is
a
bsp
for
it.
Yet
if
there
even
is
a
hull,
but
in
general
that's
what
a
bsp
does.
B
Finally,
you
will
probably
come
across
great
with
the
cortex
x
name
generally
in
the
embedded
world.
You
would
come
across
cortex-m,
but
there
is
also
a
and
r
and
cortex-m
and
similar
is
the
core
of
many
are
microcontrollers,
so
it
has
some
timers.
It
has
some
debuggers,
it
has
interrupts,
it
does
the
actual
instruction
execution
and
the
cortex-m
crate
itself
is
essentially
a
peripheral
access
crates
for
the
core
peripherals,
so
the
timers
and
the
debuggers,
and
so
on.
B
Your
controller
will
do
nothing,
that's
fine,
if
you're,
just
using
it
for
panic
messages,
but
if
you're
starting
to
print
to
the
debugger
and
then
disconnect
that
things
may
go
wrong.
So
keep
that
in
mind
with
that
we're
getting
to
the
end
of
my
talk.
Embedded
hull
is
sort
of
the
core
of
the
ecosystem.
B
By
health-
and
this
is
usually
done
through
peripheral
access
crates,
then
drivers
can
talk,
can
use
these
embedded
health
crates
to
talk
to
external
devices
and
that
allows
reuse
across
the
ecosystem.
There's
also
a
bunch
of
other
crates
that
you
will
come
across
arctic
to
provide
concurrency,
as
we
did
your
rest
for
generating
pacs,
the
cortex,
something
family
of
crates
and
so
on.
B
So
if
you're,
starting
out
with
a
metal
brush,
you
may
still
have
the
question:
where
should
I
start?
Should
I
always
start
with
han?
Should
I
start
with
the
pac,
and
I
would
say,
hulls
are
really
nice.
You
want
to
work
with
a
hal
if
you
can
so,
if
you're,
starting
from
scratch,
I
would
say,
pick
a
microcontroller
with
a
good
hal.
B
If
you're
starting,
if
you
have
a
specific
project
in
mind
with
specific
hardware,
you
should
start
off
by
looking
for
a
hull
and
I'll
give
you
a
list
of
hulls
that
exist
at
the
end
here.
If
there
are
no
hulls
for
your
hardware
check,
if
there's
a
peripheral
access
crate,
maybe
you
can
use
that
to
build
your
own
hull
or
check.
If
there
are
sod
files
and
users,
you
need
to
rush
to
generate
it
and
then
build
your
hell
on
top
now.
B
This
will
be
a
whole
lot
more
work,
but
that
work
will
only
have
to
be
done
once
and
then
the
whole
community
can
take
advantage,
especially
if
you're
using
the
embedded
health
rates
and
the
same
is
similar
or
the
same
steps
apply
for
drivers.
You
should
look
for
a
driver
if
there
isn't
one
already
or
to
see
if
there
isn't
one
already.
B
Finally,
and
this
is
my
last
slide-
this
is
just
a
few
resources.
Almost
all
of
the
relevant
resources
for
embedded
rust
can
be
found
on
this
rust
embedded,
also,
member
rust,
repo
that
has
a
list
of
hulls,
a
list
of
drivers,
a
list
of
pacs,
a
list
of
chat
rooms,
tutorials
and
probably
a
bunch
of
other
things
that
I'm
forgetting
there's.
B
Also,
the
embedded
working
group
chat
room
where
you
can
come
and
ask
questions
if
you
run
into
any
issues
and
finally,
there's
the
community
discord
where
you
can
also
ask
questions
in
the
embedded
channel.
I
think
both
of
these
are
linked
from
the
awesome
member
stream,
and
with
that
I
want
to
thank
you
for
listening,
and
I
wish
you
good
luck
with
all
your
embedded
rust
projects.
A
All
right,
thank
you
very
much
funs.
We
did
actually
have
a
a
number
of
questions
in
the
chat,
so
let's
see
how
many
we
can
go
through
in
the
next
five
minutes
or
so.
The
first
question
that
I
see
is:
what
is
the
state
of
code
sharing
between
similar
hows,
so
not
necessarily
through
the
embedded
hal
traits,
but
rather
between
something
like
the
stm32f1xx
and
the
stm32f4xx.
B
B
A
A
B
B
Well,
I
guess
there's
the
embedded
hall
crate,
so
it's
useful
if
the
hull
implements
everything
in
embedded
hull,
because
otherwise
you
may
have
drivers
that
don't
work
with
embedded
hull
or
don't
work
with
the
hull
but
work
with
them,
but
at
home
other
than
that.
I
don't
think
there
are
any
standards,
but
in
general
you
would
want
to
support
everything
that
is
on
the
microcontroller.
A
Definitely
someone
was
asking
about
debug
versus
release.
You
mentioned
the
the
pack
code
being
slow
in
debug
mode.
Someone
mentioned
that
they've
seen
that
you
can
override
optimization
flags
and
rust
for
specific
crates.
Is
it
reasonable
to
optimize
just
the
pack
and
then
leave
the
user
code?
Debug
optimized.