►
From YouTube: Introduction to Rust programming on bare metal hardware by Mike Kefeder - Rust Zürisee March 2023
Description
In this talk we will look at embedded Rust programming, specifically communication between the host and the microcontroller, and how Mike builds software on and with the Raspberry Pi Pico (RP2040). There will be a demo so let us all send good vibes to the live demo gods.
Slides: https://github.com/rust-zurichsee/meetups/tree/master/2023-03-28_embedded-hpc
Watch more of our meetup: https://www.youtube.com/playlist?list=PL85XCvVPmGQipj690WrVgsnU4K4x7qFGy
Join us next time: https://www.meetup.com/de-DE/rust-zurich/
Would you like to chat or give a talk? Join us in our Matrix room:
https://matrix.to/#/#rust-zuerisee:matrix.coredump.ch
Chapters:
00:00 Introduction
01:49 Bare Metal Targets
10:56 Live Demo rp2048 Raspberry Pi Pico
14:27 Flashing the Pico with another Pico
28:55 Communications Protocol Host ↔ Pico
37:05 RTIC v2 & USB CDC
50:35 Live Demo interactive Commands over USB
53:23 Questions
A
So
my
name
is
Mike
and
I'm
going
to
hold
to
talk,
as
you
can
see,
introduction
into
rust
programming
on
bare
metal
hardware
I
was
way
too
ambitious
for
this
talk,
so
I
had
to
chop
it
down
quite
a
bit,
and
that
includes
the
introduction
of
myself.
So,
if
you
want
to
know
more
about
me,
follow
those
links,
so
my
name
is
Mike
and
I
like
penguins.
A
This
I
left
in
so
who
is
this
talk
for
well,
everybody
that
has
written
rust
software
and
have
has
written
something
cooler
than
the
Hello
World
app
and
used
the
cargo
Built
tool
to
do
it
and,
of
course,
existing
embedded
programmers,
be
it
in
rust
or
Ada,
C,
plus
plus
micropython
yeah.
What
have
you
to
get
a
feel
of
what's
happening
so?
Who
is
an
existing
rust
programmer?
A
Almost
everyone
I
saw
before
even
cool
and
who
is
writing
embedded
code
for
a
living
for
a
while,
okay,
I
hope
I
can
teach
you
something
new.
It's
an
introduction
mind
you
good!
So
that's
the
content
for
people
on
YouTube
when
they
know
that
they
don't
know
all
of
this,
and
they
can
already
continue
the
next
video
basically
I'll,
be
explaining
what
is
the
bare
metal
hardware
and
what
this
this
is
an
ostd
thingy.
Then,
of
course,
we
will
run
the
rust
code
on
a
microcontroller
which
I
have
prepared.
A
A
So
bare
metal
targets-
oh
I,
should
explain
first,
what's
parametal
programming,
so
normally,
when
we
program
we
have
an
operating
system
that
helps
us
quite
a
bit
right.
It
gives
us
a
file
system
and
a
networking
stack
and
all
kinds
of
other
cool
stuff,
and
sometimes
we
even
actually
program
for
a
browser
which
runs
an
operating
system.
Then
you
know,
and
then
it
layers
get
deeper.
When
you
go
onto
the
cloud
and
stuff
bare
metal
means
we
talk
to
the
processor
or
the
microcontroller
directly.
A
That
means
we
have
to
write
everything
ourselves
right.
There's
no
memories
management,
there's
nobody
taking
holding
our
hands
for
networking.
No
file
system
exists
and
that's
what
I'll
be
talking
today.
So
embedded
programming
can
also
be
on
an
embedded,
Linux
machine,
and
here
are
some
targets
that
I
have
personally
used.
There
are
way
many
more
at
the
bottom.
You
can
see
the
link
for
what
is
potentially
possible
with
the
rust
compiler
I.
A
Do
not
suggest
anyone
to
use
the
Arduino
the
first
one,
because
the
llvm
actually
does
not
have
good
support
for
those
AVR
based
chips.
So
I
ran
into
funny
problems,
even
with
basic
arithmetic.
So
really,
if
you
want
to
have
a
fun
time
with
an
8-bit
processor,
go
ahead,
but
maybe
not
for
a
beginner
than
the
sde
microboards,
the
stm32
series,
they
are
actually
fairly
cool
to
use.
They
of
course,
use
a
super
old
USB
connector,
but
they
have
compatibility
often
with
existing
Arduino
boards.
So
that
would
be
a
good
starting
platform.
A
Then
the
silinks
sync
series
this
is
super
expensive
stuff
because
it
has
an
fpga
attached
to
the
arm
CPU
and
it
is
also
way
more
actually
a
computer
with
an
fpga
and
runs
Linux
by
default.
But
there
is
a
silinks
or
actually
a
sync
RS,
great
or
collection
of
crates
that
basically
provides
everything
that
you
need
to
run
the
ethernet
with
a
small
TCP
to
run
the
file
system
on
the
SD
card,
well,
file
system
and
all
the
other
stuff.
A
So
you
get
away
without
actually
running
a
Linux
kernel
and
can
boot
directly
into
the
board,
which
is
actually
super
cool
because
you
have
virtually
no
boot
time
when
I
tried
this.
It
was
up
in
one
second,
and
that
was
more
or
less
a
delay,
getting
an
IP
address
from
the
DHCP
server.
So
that
could
be
an
interesting
Target
for
people
that
need
an
fpga
going.
A
The
one
I
will
be
showing
today
is
the
Raspberry
Pi
Pico,
that's
fairly
easy
to
use
board
because
they
came
up
with
a
clever
idea
of
how
to
make
it
programmable
by
a
normal
person
that
has
never
touched
a
microcontroller
and
I
think
that's
a
really
cool
approach
to
get
people
into
the
world
and
then
after
they
have
discovered
that
they
can
go
to
the
more
complicated
ones
and
the
espressive
series.
They
are
kind
of
interesting
because
they
have
both
offered.
A
They
have
arm
cores
and
risk
five
and
risk
5
should
be
the
future
I
guess,
especially
now.
That
arm
is
actually
trying
to
step
up
the
licensing
fees
and
stuff,
and
the
th
Zurich
has
a
really
big
group
that
does
super
cool
core
implementations
with
floating
point
and
all
the
other
extra
features.
So
if
you're
at
the
University
there
I
suggest
you
look
into
risk
5
a
bit
and
cool
news
from
I.
Think
last
week
in
yeah
they
released
a
more
Automotive
embedded
chip
with
official
rust
support
by
the
company.
A
A
So
if
we
see
here
thus
main
RS,
while
this
we
have
seen,
we
are
in
our
comfort
zone,
everything's,
fine
right,
then
the
same
is
true
for
our
cargo
Tomo,
the
cargo
lock,
we
don't
touch,
but
it's
generated
for
us.
We
have
seen
it
everything's
fine,
but
what's
up
with
builders,
fewer
people
will
have
run
into
this.
This
is
used
at
the
build
time
for
by
cargo,
mostly
to
emit
the
Linker
information,
for
example,
or
also
to
prepare
code
right.
A
A
Then
another
file,
you
probably
have
never
seen
or
haven't
used
very
often
is
this
dot
cargo
config
or
config
terminal
file.
This
is
more
a
luxury
I
guess,
but
it
holds
easy
to
use
run
commands
afterwards.
So,
while
you're
developing,
you
do
not
have
to
remember,
oh,
how
do
I
flush
the
thing?
How
do
I
start
in
everything?
You
can
prepare
your
commands
that
you
want
to
use
in
there
and
then
it
will
be
automatically
run
for
you,
and
it
also
holds
some
information
for
building
the
binary
in
the
end,
like
Linker
Flags,.
A
A
This
holds
the
information
of
the
memory
locations
on
the
microcontroller
so
where
the
actual
binary
code
has
to
go
where
the
ram
starts
and
where
the
flash
ends
and
stuff
like
that,
none
of
these
files-
you
actually
have
to
code
yourself
so
for
every
controller
that
I've
showed
you
before.
There
are
template
files
on
GitHub
or
files,
template
repositories
with
those
prepared
with
the
standard
hello
world
of
the
embedded
World,
which
is
blinking
an
LED.
A
So
don't
be
scared
of
all
those
extra
files.
You
don't
have
to
write
them
yourself.
They
are
there
for
you
and
you
just
have
to
modify
the
main
RS
and
the
last
one
is
this
embed
terminal.
This
is
now
the
Uber
luxury.
You
can
install
the
cargo
embed
tool
and
then
you
have
a
new
cargo
command.
That
is
called
embed
that
will
Flash
the
MCU
for
you
and
automatically
start
a
debugging
session
and
give
you
output,
and
it's
super
fancy
I
like
it,
but
yeah
optional,
and
in
this
normal
value
configure.
A
A
How
does
that
work
in
the
rust
world?
Well,
in
Rust
we
have
a
powerful
type
system,
so
we
use
the
type
State
pattern
to
abstract
the
machine
states
of
the
microcontroller
in
the
programming
language,
meaning
we
can
avoid
problems
that
can
happen
if
you
write
normal
C
code,
for
example,
that
would
classically
have
a
Define
and
then
a
number
that
is
supposed
to
be
the
pin.
A
Then
you
pass
this
around
and
then
you
hope
cross
your
fingers
that
this
is
now
Air,
Supply,
I,
Square
t
setup,
and
you
can
actually
talk
to
your
temperature
sensor
and
rust.
This
Crossing
of
fingers
is
not
necessary
because
once
you
have
configured
your
PIN
to
be
I
squared
C,
it
will
have
the
type
of
being
I
squared
C
trade
compatible
and
therefore,
whatever
driver
you
have
written,
just
accepts
this
type,
and
you
cannot
run
into
the
problem
of
a
misconfigured
pin,
for
example,
or
some
typo
error
right.
A
A
Then
I
will
show
you
well
how
to
flash
the
firmware
in
multiple
ways:
yeah
how
you
can
do
logging
and
while
printf
debugging,
basically
and
yeah,
then
how
to
do
a
remote
debugging
session
in
lldb,
because
GDP
doesn't
work
on.
My
computer
I
found
out
shows
you
how
a
specialist
of
debuggeran
and
the
amazing
cmc's
DRP
has
the
role
of
the
tongue,
common
microcontroller
software
interface,
standard,
debug
access
port,
but
that's
what
implemented
as
a
firmware
that
you
can
freely
flash
onto
a
recipe
and
that's
the
cool
part.
A
You
can
use
two
Raspberry
Pi's
Pico
to
flash
them
and
debug
them,
so
you
don't
have
to
buy
an
expensive
debug
probe
that
runs
in
a
few
hundred
bucks.
Normally
you
just
get
two
of
them,
which
you
would
have
probably
anyways,
because
you
have
one
actual
project
that
you're
running
with
and
the
second
one
will
be
your
development
board
all
right.
So,
let's
hop
into
the
code.
A
A
B
A
Then
here
we
have
our
cargo
Tomo,
the
config
file
for
the
cargo
building,
and
we
can
see
in
this
line.
It
is
configured
for
a
runner,
so
on
cargo
run
to
actually
run
this
program
thing
for
our
rp204d
chips,
which
is
the
chip
on
the
Pico
and
further
down.
You
can
see
the
rust
flag
is
necessary
to
pull
this
off,
and
this
is,
as
I
said,
provided
to
you
in
order
to
flash.
A
A
Okay,
you
can
see
this
button
that
says
the
boot
select
right
there
and
that's
the
cool
part.
If
I
hold
this
button,
I
have
to
take
off
the
microphone
now
and
connect
it
to
the
USB.
It
will
be
a
mass
storage
device
for
the
computer,
so
it
will
show
up
like
a
USB
thumb
drive
and
then
I
can
copy
these
Ulf
files.
B
A
A
If
we
now
look
in
our
volumes,
we
will
see
that
there
is
this
raspberry
Pico
mounted
right
and
what
the
elf
tool
does
for
us.
It
automatically
pushes
the
image
onto
the
picot
when
it
finds
it
and
where
it
finds
it.
So
all
I
have
to
do
now
in
this
picot
example
is
to
Cargo
run
and
it
will
build
it
flash
it,
and
now
you
can
see
that
the
Pico
is
blinking.
B
A
But,
as
you
have
seen,
I've
struggled
pushing
this
button
putting
the
USB
inside
now.
If
you
were
to
write
a
new
integration
of
your
blinking
code,
and
you
have
to
do
this
on
a
loop,
that's
annoying
and
probably
also
at
some
point.
You
will
break
your
USB
connections,
I
guess
so.
The
other
option
is
I.
A
Have
two
raspberry
picots,
oh
wait:
I
will
have
to
go
back
to
the
camera,
so
I
have
two
raspberry
Picos
connected
to
each
other
in
a
funny
cable
configuration-
and
this
one
here
at
the
end
is
connected
to
three
pins
that
are
not
by
default.
Soldered
on
you
will
have
to
do
this
yourself,
but
these
are
the
ones
that
are
actually
doing
the
single
wire
debugging
for
the
pickup
port,
and
then
there
are
two
mores
connected
here.
My
finger
is
visible
or
not.
A
Yes,
this
is
the
C
report
connection.
So
with
the
single
by
debugging,
you
can
put
the
processor
into
a
mode
where
it
accepts
a
new
firmware
coming
in
through
the
serial
Communications
and
then
the
other
one
is
connected,
but
all
of
these
informations
are
available.
When
you
go
to
the
program
software,
they
will
show
you
how
to
connect
all
of
these
up.
A
C
A
Know
so
because
we
want
to
use
the
program,
but
that's
in
the
future.
Let's
look
at
the
other
cool
files
that
we
have.
Thank
you
I
think
I
should
be
fine.
From
now
on,
we
looked
at
memory
X
at
the
main
RS.
We
haven't
really
looked.
Let's
look
at
embed
Tamil
next,
just
a
quick
overview
at
the
very
top
it
says.
No,
it
was
swd
is
a
single
wire
debug.
A
A
However,
if
you
have
some
custom
things
that
you
want
to
do
it's
in
there
and
then,
of
course,
the
actual
code.
So
how
do
we
make
the
raspy
blink?
The
first
line?
That
is
another
comment,
is
no
STD.
That's
not
sexual
transmitted
diseases.
That's
no
standard
library
is
available.
So
once
you
use
that
definition
in
one
of
the
attributes
of
a
rust
code,
you
will
not
get
any
of
the
luxury.
Like
a
memory
management.
A
A
The
next
code
lines
are
kind
of
important
because
they
import
all
the
stuff
that
you
need
to
do
comfortable
debugging
with
the
machine.
The
first
one
is
just
the
entry
point,
but
then
this
de
format
that
means
deferred
formatting.
It's
a
very
clever
solution,
where
your
logging
statement
is
a
string
normally
right
that
has
some
formatting.
You
want
to
put
some
variable.
You
want
to
print
some
variable,
but
doing
the
actual
string
formatting
on
the
MCU
is
taking
quite
a
lot
of
processing
power.
So
what
this
one
does
is
it
uses?
A
The
string
sends
off
the
string
with
the
formatting
information
and
serialized
the
data
that
is
supposed
to
be
formatted,
and
your
host
computer
actually
does
the
string
formatting
in
the
end.
So
you
don't
use
a
lot
of
CPU
power
to
do
that.
It's
literally
just
pushing
bits
off
to
the
other
machine
and
the
deformat
rtt
is
the
protocol
that
is
used
to
send
off
the
binary
information.
Is
the
segger
rtt
I
forgot
what
it
means
real
time,
something
something
yeah.
So
the
next
line
I
can
actually.
A
Yeah
so,
as
I
said
notice,
the
format
basically
Imports
the
the
login,
so
this
holds
the
info
stuff
and
so
like,
as
if
you
were
using
logarith
that
you
know
from
your
ones,
that's
correct.
So
if
I
had
a
variable
written
here
with
the
the
curly
braces,
it
would
do
the
formatting
on
the
host.
But
in
this
case
it
just
pushes
the
string
towards
my
machine
and
that's
what
this
does.
Yeah
correctly
yeah
we
are
using
an
output
pin,
so
the
actual
led
to
make
it
blink
is
a
binary
pin.
A
So
we
want
to
put
it
high
or
low
or
toggle
it
to
make
it
blink.
So
we
need
that
trade
imported
and
that's
where
this
Hal
comes
in
the
hardware
abstraction
layer
and
this
one
is
by
the
current
rust
community
of
embedded
programming
providing
trades
to
abstract
the
hardware
that
is
common
between
all
the
microcontrollers
right.
Most
of
them
will
have
this
input.
A
The
peripheral
access
crate
and
there
you
have
lots
of
unsafe
rust
code
because
there
you
have
to
write
directly
onto
different
registers
to
enable
pins
and
do
all
kinds
of
shenanigans
and
that's
why
we
have
those
multiple
layers
to
keep
the
safe
layer
towards
the
programmer,
and
only
if
you
have
to
implement
a
completely
new
driver
or
a
completely
new
board,
then
you
go
on
the
PAC
level
and
oftentimes.
These
PCS
are
not
programmed
by
hand.
A
They
are
just
converted
from
the
information
that
the
MCU
provider
gives
you
and
it's
Auto
generated
more
or
less
from
the
SVD
files.
So
if
there
are
embedded
programmers,
they
know
yeah,
and
that's
also
why
we
are
importing
from
this
Hardware
extraction
layer
and
the
bsp
is
our
Raspberry
Pi
Pico
and
you
can
see
here
an
alternative.
So
there
are
some
other
boards
that
are
based
on
the
RP
2040
that
provide
some
other
peripherals
or
maybe
less
or
maybe
more
depends
on
the
implementer.
And
for
these
you
would
have
other
ones.
A
A
A
So
here
we
get
our
peripherals
and
all
the
other
stuff.
That
is
basically
standard
that
you
will
have
to
set
up
to
then
get
your
clocks
and
with
the
clock
you
can
then
set
up
your
delay.
Handler
I
could
explain
all
this,
but
it
will
take
too
much
time,
but
this
is
basically
also
happening
if
you
are
using
the
Arduino
IDE
with,
but
there's
some
code
in
C
plus
plus
hidden
somewhere
in
the
back.
A
A
A
However,
this
quickly
gets
out
of
hand
right.
So
right
now
we
are
blinking
an
LED,
and
maybe,
if
you
are
all
you
are
doing,
is
repeatedly
checking
a
temperature
sensor.
Then
the
loop
is
also
fine,
but
as
soon
as
you
wanna
at
the
same
time,
communicate
with
your
host,
read
multiple
sensors,
maybe
process
the
data
before
you
send
it
off
right.
If
you
want
to
use
Laura
one
to
send
it
off,
you
will
not
be
able
to
send
kilobytes
of
data.
You
have
to
be
able
to
compact
this
a
bit.
A
A
A
And
this
way
you
don't
have
to
plug
and
do
some
weird
stuff.
You
can
just
run
your
code.
You
see
what's
happening
with
your
login
messages
and
you
have
to
have
full
control
as
if
you
were
losing
logger
right.
You
can
do
different
error
levels
and
format
your
data
types.
You
have
to
use
a
different
formatting
trait
though,
but
this
I
will
show
later,
hopefully.
A
A
A
B
C
A
A
A
And
process
interrupt,
we
can
stop
it
again
and
then
you
can
inspect
the
registers
on
the
machine
and
even
jump
into
your
code
and
stuff
like
that.
This
is
a
bit
more
comfortable
and
visual
code.
I
personally,
don't
debug
too
much
because
I
from
experience
haven't
had
I,
don't
know
too
much
experience
where
it
actually
helped
me
debug
stuff.
It's
mostly
my
brain,
so
I
will
equip
this,
but
you
see
in
principle
it
works
and
it
is
provided
fairly
easily
to
you
when
you
use
the
cargo
embed
tool.
A
A
Right,
so
if
we
want
to
talk
to
the
raspy,
we
have
to
come
up
with
a
protocol
right
and
sure
we
can
go
big,
because
this
Pico
is
actually
a
very
powerful
CPU
and
use
the
Json
or
grpc
or
some
other
fancy
thing.
But
this
is
the
embedded
world
we
should
be
as
small
and
concise
as
possible,
and
there
there
I
also
have
prepared
some
code.
B
C
B
A
Okay,
at
the
very
top,
you
can
now
see
how
you
can
mix
no
standard
with
a
standard
code,
because
if
we
want
to
use
this
on
the
host
well,
it
needs
a
standard
library
to
function
and
if
we
want
to
run
it
on
the
Pico,
because
we
want
to
create
a
message
on
the
Pico
as
well
to
send
it
back.
We
have
to
use
no
STD
where
you
have
no
standard
library
right
and
at
the
very
top.
A
You
can
see
that,
if
I'm
not
using
the
feature
as
standard,
then
well,
I
am
not
using
the
standard
Library
and
then
the
deformatting,
the
the
Deferred
format,
is
only
necessary
if
I
have
no
target
OS
again
using
it.
On
the
embedded
controller,
it's
not
necessary
to
run
this
on
the
host
code
and
from
there
we
have
then
some
other
cool
crates
that
work
on
both
systems.
So
heapless
provides
us
an
interface
to
a
vector,
but
that's
not
a
vector
in
the
common
sense.
A
You
have
to
pre-initialize
some
Maximum
buffer
size
that
this
Vector
can
hold
and
therefore
you
don't
need
a
memory
allocator
and
it's
an
easy
hack
to
quickly
get
more
complicated
Argos
that
needs
some
Vector
operations
going
and
then
postcard
is
the
actual
protocol.
If
you
want
so
that's
a
very
compact
form
of
serializing,
the
struct
or
other
data
types
that
you
want
to
send.
A
So
since
we
are
at
Rasta
Zurich,
the
header
I
chose
to
keep
our
packets
separated
is
our
crh
and
the
maximum
message.
Buffer
size
is
260
way
Overkill,
because
we
are
not
sending
much
complicated
stuff,
Across,
The,
Wire
and
here's
the
cool
part.
We
get
to
write
everything
in
Rust,
so
there's
no
grpc
definitions
that
need
to
be
pre-changed
into
rust
code.
That
then,
is
injected
into
your
thingy
and
then
breaks
or
whatever
we
write
rust
code.
How
we
like
it,
which
is
an
enum.
We
have
three
different
messages.
A
We
have
a
ping
upon
and
to
change
the
how
the
LED
is
behaving
so
blinking
on
and
off,
and
how
long
the
pause
between
the
blinks
is
supposed
to
be
and
yeah.
The
Ping
and
pong
makes
a
lot
of
sense
to
just
on
principal
test.
If
what
you're
building
is
working
or
is
the
controller
there?
So
these
messages,
I
kind
of
always
include,
and
the
idea
I
found
also
kind
of
practical,
because
you
then
can
figure
out
dark.
A
A
Then
I
provide
two
internal
methods,
functions
to
encode
and
decode
the
messages,
and
here
we
now
have
our
parser.
It's
a
really
dumb
one.
So
don't
use
that
in
production,
I
guess,
but
it
looks
for
the
header
once
it
found
it.
It
just
tries
to
then
figure
out.
Oh,
how
long
is
the
message
and
then
puts
this
into
postcard,
tries
to
deserialize,
and
if
it
is
not
happy,
it
returns
all
kinds
of
error.
A
States
and
again,
once
we
are
in
standard
Library,
we
get
to
use
this
one
to
write
a
message
onto
something
that
implements
the
right
trait,
and
here
we
have
something
that
wraps
the
message
into
the
binary
format
that
is
supposed
to
be
down
here
in
the
tests.
You
might
get
a
feel
for
how
this
works
here.
You
can
see
the
Vector
setup,
so
you
have
to
provide
the
maximum
size
that
this
Vector
can
hold
right.
This
is
the
heapless
vector
and
not
the
standard
one.
A
So
it's
a
side
of
the
type
is,
as
you
know,
right
we
have
a
u8
for
the
bytes
and
then
16
of
those
can
be
held.
So
if
you
keep
pushing
to
your
vector
more
than
16
bytes,
this
will
fail,
of
course,
because
we
cannot
allocate
more
memory,
so
these
16
bytes
are
held
on
the
stack
basically
in
the
MCU.
If
you
want
right
so
here
we
are
just
pushing
a
message
that
doesn't
make
sense
and
the
password
result
will
be.
Of
course,
the
header
is
invalid.
A
I
haven't
found
the
message,
and
there
are
the
other
tests
are
basically
doing
all
of
the
same
and
down
here
you
can
actually
see
if
we
create
this
ping
message.
It's
super
compact
because
those
first
four
bytes
are
actually
our
weird
header.
So
this
is
the
tiny
small
R
and
then
crh
and
the
Ping
message
is
this
two
a
zero
and
the
five
is
from
this
ID.
A
So
that's
super
compact,
postcard
I
can
strongly
suggest
using
and
the
really
cool
part
is.
You
can
actually
use
this
through
the
whole
stack.
So
you
have
your
embedded
controller.
This
talks
to
host
machine
that
then
talks
to
a
web
front
end.
If
you
write
this
web
front
end
in
wasm,
then
you
can
push
this
postcard
message
all
the
way
to
the
browser
and
you
never
have
to
convert
into
Json
or
do
some
other
magic
it.
It
stays
in
Rust.
It's
stable
and
super
fast.
A
A
A
So
here
I'm
using
this
write
message
that
we've
implemented
before
so
if
we
have
something
that
implements
standard
right,
so
in
this
case
the
TTY
I
can
send
off
the
message
super
comfortably.
It's
just
one
line
of
code
and
that's
how
that
works
and
the
other
way
around
if
it
comes
in,
which
is
this
Loop
here.
So
if
we
read
on
the
port,
then
we
can
parse
it
out
and
we
react
to
the
different
error
States
and
show
what's
up.
C
A
Arctic
used
to
be
called
rtfm,
but
they
changed
their
name,
but
a
long
time
ago,
I
think
already
like
a
year
ago
whatever,
and
they
recently
kind
of
stabilized
version
two
in
the
sense
that
the
API
is
stable
and
since
I
wanted
to
hold
this
talk.
I
was
thinking.
Okay,
I
will
show
version
2
already,
because
it
allows
to
use
async
tasks,
which
is
really
cool
and
yeah.
This
talk
will
be
old
faster
than
I
want.
If
I
would
have
shown,
you
number
one
right
with
this
async
task.
A
A
Real-Time,
interrupt
control
and
it's
easy
to
handle
interrupts
to
interrupt
handling
themselves,
though,
are
not
asynchronous.
They
are
still
normal
functions
that
get
triggered
by
the
interrupt
of
the
microcontroller
and
the
way
we
will
talk
to
the
actual
controller
is
or
the
microcontroller
is
over
USB
CDC,
so
communication
device
class,
which
is
implementing
a
Serial
terminal
and
yeah
in
order
to
keep
the
US
Peak
polling
going.
We
are
using
interrupts
and
that's
also
one
of
the
limitations.
A
Ride
so
here
we
are
back,
they
are
also
nice
to
us.
They
also
provide
a
Raspberry
Pi
Pico
template
for
us,
the
Arctic
guys
first
lines.
We
have
already
seen
right.
We
don't
have
a
stable
standard,
Library,
there's
no
main,
but
we
have
to
use
nightly
and
we
need
this
feature
because
otherwise
the
whole
async
thingy
wouldn't
work.
A
Then
I
used
the
atomic
for
counting
messages,
I
believe,
yes,
exactly
so
that's
down
here,
then
the
defer
the
formatting,
the
Panic
probe,
is
necessary
when
the
machine
panics
that
it
stops
working
here
we
have
the
default
formatting
time
stamp,
so
the
atomic
countries
used
to
count
how
many
messages
the
Deferred
formatting
was
already
sending
off,
and
this
is
then
kind
of
like
a
prefix.
So
if
you
know
from
log
formatting,
you
often
have
like
a
timestamp
or
some
other
prefix
information
which
machine
this
is
running
on
or
whatever.
A
A
A
A
Okay,
so
inside
this
module
we
are
importing
all
the
stuff
that
we
need,
which
one
is
actually
pertinent,
not
too
many
yeah.
This
one
is
important.
So
in
order
to
handle
a
delay
or
a
timeout,
the
Arctica
is
implemented
differently
than
before.
So
before
we
got
the
delay
Handler.
That
is
using
the
statistic
of
the
raspberry
Pi
Pico
and
that's
actually
kind
of
a
waste
right.
If
I'm
waiting
for
500
milliseconds,
it
will
wait
4996
and
on
the
500th
it
will.
You
know,
let
you
do
something.
A
A
And
then
here
we
have
the
import
to
set
up
a
USB
device,
so
luckily
rust
provides
that
to
us
and
then
on
top
of
that
there
is
a
crate
that
provides
us
a
Serial
device.
On
top
you
can
also
Implement
I,
don't
know
a
keyboard,
a
mouse,
a
joystick.
All
of
this
is
kind
of
already
written
from
somebody,
but
of
course,
come
up
with
your
own
ideas
and
then
write
your
own
crate,
USBS,
fairly
flexible.
B
A
Then
that's
an
important
concept
here
we
set
up
our
LED
pin.
Now
we
have
to
know
the
number
25
it's
no
longer
nicely
available
for
us,
because
we
had
to
import
it
at
the
top
from
the
pack
and
then
we
mark
this
struct
shared
and
shared
means
that
these
are
resources
that
multiple
tasks
within
the
Arctic
system
can
be.
A
That
then
holds
those
messages
to
be
reacted
on
so
these
informations
we
have
to
share,
but
local
information
is
also
available.
So
our
task
that
will
actually
blink
the
LED
will
be
the
only
one
that
has
access
to
this
Hardware,
which
will
often
be
a
restriction
rate.
If
you
have
an
SPI
Connection
open,
you
don't
want
to
share
that
with
other
tasks,
because
then
you
would
have
to
hand
off
the
access
to
it
and
then
you
can
easily
come
up
with
a
synchronization
problem
and
then
also
locally.
A
We
only
use
the
USB
device
once
and
we
only
also
have
one
task-
or
in
this
case
the
interrupt
Handler
that
talks
to
the
serial
port
and
then,
of
course,
we
need
a
message
buffer
for
our
blink
protocol
and
we
have
defined
the
mesh
the
maximum
message
buffer
size.
So
if
you
ever
change
that
it
changes
all
over
the
code-
and
we
don't
have
to
manually
rewrite
the
code,
so
initialization
is
a
long
block.
Is
there
anything
that
is
super
important
to
show
not
really.
A
A
Here
we
set
up
the
serial
Port
that
gets
handed
over
the
USB
bus
and
then
once
we
have
this
USB
device,
we
can
now
come
up
with
a
manufacturer
name,
see
report
whatever
and
the
serial
number
and
which
cluster
device
has
and
we
are
ready.
Then
we
set
our
variable
that
we
want
to
use
to
true,
because
we
want
to
Blink,
and
this
is
the
command
that
will
spawn
the
task
that
actually
blinks
the
LED.
A
A
So
again,
here
we
have
the
shared
information
between
the
tasks,
blinking,
LED
and
the
local
stuff.
This
needs
to
be
returned
from
the
init
function
and
Arctic
generates
code
for
you.
That
then
passes
this
around
and
then
makes
the
magic
happen
for
these
macros,
because
here
you
have
the
to
Define,
which
local
stuff
you
want
to
have
access
to.
So
in
this
task,
we
want
to
talk
to
this
local
LED
thing.
A
If
I
wanted
to
use
this
again
in
another
task,
the
compiler
will
not
work
because
you
can
use
local
stuff
only
for
one
task
and
the
shared
thing
is
I
want
to
use
the
blink
and
pause
information,
and
here
we
have
our
loop
again
with
our
pause.
But
now
we
want
to
be
able
to
dynamically
react
to
a
pause.
We
set
up
a
default
of
500
milliseconds.
So
if
we
haven't
received
any
message
yet
we
are
still
blinking,
and
here
you
can
see
how
we
can
actually
access
those
shared
informations.
They
have
to
be
locked.
A
It
is
a
mutex
if
I'm
not
mistaken
what
they
will
use
in
the
background
for
you
by
Arctic,
and
so
you
get
your
context
from
here
right
that
is
auto
populated
with
this
macro
from
up
here,
and
you
have
access
then
to
your
blinking
and
the
pause
information.
Once
you
have
the
lock.
This
gets
passed
into
disclosure
with
the
two
arguments,
and
here
I
can
check.
If
LED
blink
is
true,
then
I
will
use
the
toggle
method,
which
is
pretty
cool.
C
A
A
A
There
would
be
only
a
single
execution,
always
there
would
have
been
need
for
locking
yes
on
the
raspberry
Pico.
They
do
not
directly
support
multi-core
support.
You
can
run
two
arctics
at
the
same
time,
though
so
on
each
core
one,
and
then
you
have
to
communicate
between
them.
That's
the
kind
of
possible
I
think
that
they
actually
abstract
into
mutex,
where
the
system
can
do.
As
you
just
said,
multiple
things
in
actual
parallelity,
but
here
they
do
it.
A
Also
because
it's
easier
for
how
to
implement
you
know
the
async
executor
to
make
sure
that
this
resource
is
locked
for
you,
since
it
is
shared
with
multiple
tasks.
So
if
it
is,
in
this
case
shared
with
an
interrupt
your
actual
code,
execution
is
halted
halted
by
the
MCU
and
then
this
new
function
jumps
in
and
if
it
wants
to
modify
the
thing,
but
the
lock
is
open
is
held,
then
it
should
not
work.
C
A
A
Okay,
do
we
have
to
show
this
not
really
just
quickly
how
this
internet
spine
is
binding
works?
So
here
you
really
bind
to
this
USB
control
interrupt
so
on
USB.
We
are
actually
handling
this
important
polling
and
if
there's
nothing
that
is
coming
from
the
host,
then
we
immediately
turn
interrupt
done.
If
there's
actually
some
information,
we
continue
and
read
from
the
Civil
port.
A
A
B
C
B
A
A
B
B
A
The
whole
point
of
how
the
current
info
ecosystem
on
Rust
works.
Anyways
right,
you
have
this
Pac
that
the
packs
they
have
a
lot
of
unsafe
code
because
they
directly
talk
to
the
hardware
and
do
stuff,
but
you
barely
really
use
them.
Unless
you
implement
something
like
Arctic
right,
then
you
have
the
ATL
the
hardware
extraction
layer
that
is
already
safe
code,
there's
no
more
answer
from
this
moment
onwards
and
then
creates
like
Arctic
or
Embassy.
There
are
many
solutions
out
there
that
will
help
you
write
concurrent
code.
A
C
A
Supporting
some
architectures,
which
is
just
impossible
due
to
safety
guarantees
and
for
us
well,
the
actual
talking
to
the
microcontroller,
is
done
with
unsafe
code.
So
from
this
point
of
view,
no,
but
in
practice
there
are
limitations
because
rust,
as
of
today,
is
only
available
realistically
with
llvm
as
the
back
end
and
llvm
does
not
have
the
biggest
support
for
lots
of
microcontrollers
right.
So,
like
the
the
Arduino
Uno,
this
chip
is
a
tire
tier
three
and
has
actual
problems,
but
not
because
rust
doesn't
know
what
to
do
with.
A
Llvm
is
actually
having
bugs
so
arms
you're
kind
of
safe
risk.
5
is
very
well
supported.
Then
there
are
some
other
ones
like
the
new
Infinium
thingy
that
has
official
rust
support
right
yeah.
You
will
have
to
find
out
yourself
from
this
limitation,
but
since
GCC
is
working
on
a
rust
front
end
for
their
compiler
and
they
have
a
lot
of
good
support
for
all
kinds
of
embedded,
then
this
problem
will
solve
itself.