►
From YouTube: A little Rusty in Quantum Physics
Description
Embedded Hardware Abstraction Layers (HALs) and other Rust frameworks work well for demos and prototype projects, but how do they hold up in real-world, professional implementations?
Stabilizer is an open-sourced hardware platform used for controlling lasers in quantum physics experiments. It offers a unique environment to exercise the usage of embedded HAL traits and the Real-Time For the Masses (RTFM) framework in a high-performance, internet-connected embedded system.
This talk will discuss the advantages (and shortfalls) of the both RTFM and the embedded HAL approach to Rust development in a real-world embedded application where timing, throughput, and internet-connectivity are crucial.
A
B
Hey
there,
everyone,
my
name
is
ryan.
I
am
an
embedded
engineering
consultant
contractor,
whatever
you
want
to
call
me.
I've
been
working
in
the
embedded
world
for
the
last,
probably
five
years
now.
I've
developed
a
whole
variety
of
languages,
all
the
whole
stacks
c
c,
plus
plus
recently
been
getting
into
rest.
B
That
is
used
for
stabilizing
laser
frequencies
and
essentially
the
board
shown
on
the
right
here
boils
down
to
two
analog
inputs
that
we
want
to
sample
really
quickly.
We
pass
the
data
through
a
digital
filter
and
then
we
can
reconstruct
the
data
on
the
output,
pass,
the
digital
codes
back
out
to
a
dac,
and
we
can
reconstruct
a
new
waveform
and
then
we
can
use
this
as
a
feedback
loop
to
control
the
laser
frequencies
because
they
need
to
have
them
really
precise.
B
They
had
an
existing
firmware
solution
that
was
working
on
the
v
1.0
hardware,
but
what
they
were
looking
for
is
converting
all
of
that
to
using
some
of
the
stm
house
that
are
out
there,
because
it
was
originally
developed
using
only
the
peripheral
access,
crate,
and
so
one
of
the
other
major
portions
of
this
project
was
that
there
is
a
mezzanine
card
that
they
wanted
to
place
on
top
of
stabilizer.
That
is
essentially
just
another
form.
B
It
implements
another
algorithm
for
stabilizing
lasers,
using
the
pound
river
hall
technique,
and
if
that's
all
you
know
about
quantum
physics,
don't
worry.
I,
the
only
parts
of
that
algorithm,
I
actually
understand,
are
on
wikipedia
if
you're
looking
for
more
in-depth
quantum
physics
here,
I'm
sorry
you're,
probably
not
going
to
get
it
in
this
presentation.
B
B
It
had
used
rtfm
as
well,
and
so
we
were
really
looking
into
how
we
can
leverage
as
many
of
the
rust
crates
in
the
rust
ecosystem,
to
implementing
this
application,
and
so
rtic,
formerly
known
as
rtfm.
If
you
watched
any
of
the
previous
talks,
this
is
going
to
kind
of
build
on
top
of
that
going
into
the
application.
Layer
of
some
of
these
crates
is
a
really
nice
kind
of
framework
for
implementing
this
kind
of
application,
because,
if
you
think
about
it,
stabilizer
essentially
only
has
three
really
large
tasks
that
we're
trying
to
do.
B
There's
taking
in
and
filtering
channel
one
taking
in
and
filtering
channel
two
and
then
handling
all
of
the
ethernet
traffic
and
handling
the
control
interface.
Sending
any
log
messages
out
that
we
need
to,
but
it's
also
a
little
bit
more
complicated,
because
we
need
to
share
some
of
that
state
between
these
various
tasks
and,
if
we're
having
some
kind
of
concurrent
where
the
filters
are
running
dynamically
in
higher
interrupt
priorities.
B
Sharing
that
state
can
get
complicated
and
risky,
and
so
rtic
posed
a
really
nice
solution
for
kind
of
working
with
this,
because
we
can
lock
the
digital
filter
states
as
we're
trying
to
read
them.
So
we
can
send
them
out
of
the
ethernet
interface
or
if
the
user
wanted
to
update
their
filter
to
change
what
it
was
doing
to
the
output
signals.
We
can
allow
them
to
do
that
as
well.
B
We
also
wanted
to
use
the.
How
obviously
for
the
peripheral
implementations
we
needed
an
I
squared
c
bus,
that's
going
on
to
a
gpio
expander,
that's
sitting
on
top
of
the
pounder
hardware,
so
that
we
can
control
some
of
the
ios
going
into
the
synthesis
chip.
We
also
needed
to
have
spy
going
to
the
adcs
and
the
dax
on
the
stabilizer
hardware.
B
We
needed
spy
also
going
to
the
digital
attenuators
that
are
connected
on
the
pounder
hardware,
and
so
there's
all
of
these
various
hardware
interfaces
that
we
needed
to
implement
and
the
hal
had
ready
to
go
implementations
for
them.
The
one
thing
that
we
did
need
that
the
hal
did
not
have
was
that
we
needed
the
quadsphy
interface
to
be
able
to
talk
to
the
dds
really
quickly,
and
so
we
knew
going
into
this.
That
was
likely
something
we
were
going
to
have
to
implement
ourselves.
A
B
Stm32H7
ethernet
crate
that
explicitly
takes
in
ethernet
peripherals
from
the
peripheral
access
crate
for
the
h7
chip
and
exposes
a
small
tcp
5
device
interface,
which
is
a
fancy
way
of
saying.
It
allows
us
to
instantiate
a
tcp
stack
without
having
to
actually
write
any
code
which
is
extremely
powerful,
and
so
next
I
kind
of
want
to
get
into
a
little
bit
more
of
exactly
what
we
were.
How
we
accomplished
this
because
we
finished
up
the
project
probably
about
a
month
ago.
B
So
we
were
able
to
leverage
small
tcp,
creating
a
network
stack
that
sat
on
top
of
that
stm32h7
ethernet
crate.
And
if
it
sounds
simple,
that's
because
it
is,
it
was
extremely
straightforward
to
get
set
up
and
working
just
configuring.
The
gpio
pins
to
the
correct,
alternate
functions,
passing
in
various
peripherals
to
the
stmh7
ethernet
hal,
creating
that
interface,
providing
that
interface
into
the
constructor
to
small
tcp,
and
it
basically
all
worked.
It
was
really
impressive.
Then
we
could
focus
on
just
implementing.
B
Now
we
have
a
tcp
port
that
we
can
open
up,
bind
to.
We
implemented
a
server
sitting.
On
top
of
that.
That
uses
certainty
and
just
passes
json
back
and
forth
so
that
we
can
have
the
user
send
in
a
request
that
says
like
hey,
can
you
modify
the
channel
one
output,
frequency
from
500
megahertz
to
400
acres,
and
then
we
can
pass
that
all
the
way
up
to
the
stack
to
go
to
actually
configuring
the
dds
chip
itself?
B
What
was
really
interesting
was
working
on
the
stabilizer
firmware,
because
that
was
this
is
the
two
channel
chip
that
is
or
a
two
channel
board,
that
is
sampling
the
rf
inputs,
filtering
them
and
sending
them
out
largely
because
this
needed
to
be
really
high
high
performance
design.
We
had
strict
timing
requirements,
we
needed
to
be
able
to
sample
the
signals
as
quickly
as
we
could
filter
them
and
send
them
back
out.
B
We
needed
to
try
and
have
fixed
delay
between
the
input
and
the
output
so
that
the
signals
were
coherent
with
each
other,
and
so
really,
if
you
start
thinking
about
it,
well,
okay,
we
need
to
have
a
timer
periodically.
We
need
to
sample
them,
we
need
to
filter
them,
and
then
we
need
to
write
them
out.
So
if
we
set
up
a
timer,
every
500
kilohertz,
then
we
get
our
interrupt.
B
Well,
it
turns
out
that,
if
we're
looking
for
a
really
fast
implementation
that
doesn't
quite
work
largely
because
just
the
spy
transactions
of
reading
from
the
adc
and
writing
to
the
dac,
if
we
incorporate
those
results
in
too
long,
the
latency,
the
maximum
frequency
we're
able
to
run
the
filter
out,
is
about
100,
kilohertz
or
so,
and
we're
trying
to
get
into
the
range
of
about
500
kilohertz
was
the
target,
and
so
we're
already
about
five
times
too
slow
for
what
we
need,
and
so
instead,
what
we're
thinking?
Okay!
B
Well,
maybe
we
can
pipeline
this
implementation
as
well,
and
so
we
set
up
a
timer
to
instead
of
performing
an
interrupt,
it
generates
a
dma
request
and
that
dma
request
writes
directly
into
the
peripheral
block
to
start
the
adc
transaction.
Then,
as
soon
as
the
adc
transaction
is
finished,
then
we
can
wake
up.
We
get
an
interrupt
that
says:
hey
your
data
is
ready.
We
pass
that
data
into
the
filter,
and
then
we
take
the
result
of
the
filter,
write
it
out
to
the
dac.
B
B
In
fact,
we
could
probably
even
get
it
going
faster
if
we
needed
to
if
we
can
optimize
the
digital
filtering
portion
of
this
as
that's
kind
of
the
bottleneck.
At
this
point,
we
also
got
a
custom
quad
spy
interface
going
using
the
stm32
help
it's
kind
of
an
interesting
peripheral,
because
there's
many
ways
you
can
use
it
there.
B
The
intended
way
typically
is
to
map
directly
some
external
flash
memory
or
ram
into
your
chip
memory
space
so
that
you
can
use
it
as
extra
memory
or
you
can
use
it
in
an
indirect
way,
just
kind
of
like
a
spy
peripheral
where
you
just
do.
Register
rights
register
reads
and
such
to
various
other
portions
of
whatever
chip
you
have
on
the
other
end.
We
also
have
a
driver
crate
going
now
for
our
ad9959,
which
is
the
dds
chip
that
generates
all
of
the
sinusoidal
outputs.
B
One
embedded
rust
is
extremely
effective
when
you're
trying
to
do
really
high
performance
time
in
critical
applications,
which
was
a
bit
surprising
to
me
coming
from
a
c
c,
plus
plus
background
where
you
really
you've
dug
into
some
of
the
disassembly
listings
of
your
previous
application.
So
you
know
exactly
what
the
compiler
is
generating
rust.
It's
a
bit
less
transparent,
because
it's
a
bit
more
of
a
new
language
for
me
and
so
really
being
able
to
hit
that
like
hit
those
timing
requirements
we
needed
being
able
to
analyze
it
with
logic,
analyzers
and
visualizing.
B
B
One
thing
that
was
interesting
to
me
is
that
we
had
a
lot
of
difficulty
with
hal,
and
I
think
this
was
largely
because
the
how
was
new
and
we
have
managed
to
work
through
the
fixes
by
working
with
the
creator
which
richard
meadows,
if
you're
watching
this.
Thank
you
very
much.
That
is
a
fantastic.
How
I
believe
he
gave
a
presentation
earlier,
but
what
I
mean
is
with
the
stm32
house.
B
Typically,
the
peripheral
has
to
be
enabled
before
you
can
start
working
with
it,
so
that
it
allows
essentially
a
clock
to
go
to
the
portion
of
silicon
that
you're
actually
working
with
and
the
quad
spy
did
not
have
any
of
any
implementation.
Yet
because
it's
a
relatively
young
hell
and
so
there's
a
lot
that
still
needs
to
be
done,
and
it's
a
very
complex
chip
and
there's
the
data
sheet
is
probably
about
2
000
pages
long,
it's
a
little
brutal
and
so
trying
to
implement
a
custom.
Quad
spy
interface
wasn't
actually
possible
with
the
existing.
B
B
Before
we
do
the
transfer
we
passed
all
of
that
configuration
into
the
spy
constructor
in
the
hal,
and
it
automatically
was
able
to
configure
the
peripheral
to
operate
in
that
way.
So
we
were
able
to
pass
these
really
hardware,
independent
hardware,
dependent
configurations
through
this
agnostic
driver
interface,
and
it
was
really
impressive
to
see.
B
We
also
discovered
that
interface
programming
and
the
embedded
hal
allows
us
to
rapidly
develop
things
in
the
sense
where
we
can
develop
the
ad
dds
chip
driver
without
having
any
hardware.
We
can
just
go
ahead
and
start
thinking
logically
reading
through
the
datasheet
implementing
things
and
compiling
it
and
checking
all
of
that,
and
that
really
allows
us
power
while
we're
working
with
our
schedules
and
that's
kind
of
what
I
wanted
to
get
into
in
the
next
portion
as
well.
B
Is
that
what
was
truly
impressive
to
me
is
how
much
of
this
we
were
able
to
accomplish
using
pre-built
blocks
from
rust
and
from
cargo,
because
we're
able
to
leverage
arctic
for
building
all
of
our
task
and
resource
management
in
the
application.
We're
able
to
use
the
hal
for
doing
a
vast
majority
of
all
of
our
peripheral
configuration
and
development.
I
the
only
the
largest
amount
of
time
I
spent
working
at
the
hardware
level,
was
developing
the
quad
spy
interface.
B
What
I
want
to
try
and
point
out
here
is
that,
as
a
result
of
that,
we
should
really
try
and
pay
it
forward.
So
taking
our
custom
driver
creates
89.959
dds
chip,
even
if
maybe
likely.
No
one
else
is
going
to
be
using
that
it's
a
very
complex
chip,
kind
of
a
niche
market
in
quantum
physics,
but
maybe
we
can
still
publish
those
and
give
them
because
give
them
out,
put
them
out
into
cargo,
because
that
helps
develop
the
ecosystem.
B
And
when
we
introduce
more
driver
chips,
then
we
obviously
get
more
interest
in
the
language
and
women's
more
interest.
More
people
are
writing
drivers.
Suddenly
we
reap
the
benefits
of
that,
even
if
we're
our
own
private
company,
because
other
people
are
now
providing
drivers
that
we
can
leverage
in
our
products
as
well
other
ways
we
can
help
pay
it
back
through
these
projects
implementing
bug,
fixes
and
house.
We
worked
closely
with
a
lot
of
the
guys
over
at
the
stm
h7
hal
to
implement
changes
into
the
api
and
such
so
that
things
just
worked
smoother.
B
If
you
look
at
this
there's,
this
is
a
tracking
of
the
time
I
spent
on
this
project,
and
the
first
portion
here
in
april
was
before
we
had
any
hardware
available.
This
was
all
just
software
development
from
a
high
level
perspective.
We
took
a
break
in
may,
while
we
were
waiting
for
the
hardware
to
come
in
and
then
over
the
next
two
weeks,
once
we
had.
B
We
really
want
to
replace
our
tcp
server,
that's
sitting
on
top
of
the
stack,
because
it's
kind
of
this
custom
cerdy
json
that
doesn't
really
make
sense,
because
it's
only
request
response
oriented.
We
want
to
replace
that
with
an
mqtt
interface,
which
is,
if
you
don't
know
what
mqtt
is
it's
kind
of
an
iot
protocol
where,
essentially,
you
can
broadcast
to
some
broker.
B
And
so
what
we
want
to
do
is
try
and
move
a
lot
of
the
telemetry
that
stabilizer
and
pounder
generate
and
broadcast
that
over
mqtt.
Instead,
we
also
want
to
work
on
getting
a
lot
of
our
hal
implementations
back
into
the
actual.
How
we
have
the
q
spy
sitting
as
a
draft
pr,
we've
got
custom
spy
configurations
that
we're
working
on
getting
the
pr
and
still
there's
a
number
of
dma
implementations
that
we
did
a
little
bit
hacky
but
work,
and
so
we're
looking
at
how
we
can
try
and
incorporate
that
back
in.
B
B
A
B
Yeah
I
artic
was
basically
the
whole
framework
that
we
were
using
without
the
whole
thing.
All
of
the
timing
for
like
adcs
and
stuff
was
all
done
at
a
hardware
level.
There
was
we
didn't
use
so
in
terms
of
scheduling
the
trend,
the
filters
to
execute
that
was
all
done
using
a
hardware,
peripheral
timer,
so
it
wasn't
using
any
of
the
cycle
counter
monotonic
of
arctic
or
anything
like
that.
A
B
Yeah,
so
I
did
not
implement
the
solution,
but
richard
meadows
did
what
he
got
going
is
a
really
nice
solution
and
it's
I
it's
called
the
p-rex
structure
and
I
don't
know
exactly
what
it
stands
for,
but
essentially
it's
an
interface
that
abstracts
the
stm32
rcc
into
a
programmable
reset
and
control
interface.
So
essentially
it
exposes
a
public
api
for
resetting
a
peripheral
or
enabling
a
peripheral.
So
take
a
look
at
the
h7.
How
for
the
p-rex
structure
and
that's
a
great
implementation.
A
B
If
I
was
starting
over,
I
would
not
have
gone
for
a
custom
tcp
server
implementation.
I
would
have
rather
gone
with
the
an
mqtt
kind
of
implementation.
There
aren't.
There
are
some
still
heavily
in
develop
heavily
in
development
and
qtt
implementations
that
we
were
looking
at,
but
it
was
a
little
too
early
initially,
so
we
have
cortic
has
a
prototype.
Mqtt
implementation
going
and
I've
had
it
running
on
the
nucleo
board
and
reporting
up
a
little
temperature
sensor
lately.
So
we're
working
on
stabilizing
that
as
well.