►
Description
A look into all the things that happen before main gets called on embedded devices running Rust.
Rust and Tell is a monthly event (the last Tuesday of every month) to share ideas and learn about new things about Rust.
Check out https://berline.rs/ for more.
A
Okay,
can
everyone
hear
me
even
the
back
sounds
good
cool,
alright,
so
I'm
James
Muntz-
and
this
is
my
talk-
called
life
before
main.
So
this
talk
is
sort
of
about
embedded,
embedded
development
and
rust,
but
not
entirely
a
lot
of
it's
totally
true,
whether
you're
writing,
C
or
rust,
for
embedded
systems
or
on
a
desktop,
but
I
want
to
investigate
everything
that
happens
before
when
you
start
running
your
program
and
you
execute
the
first
line
of
main.
A
So
a
little
bit
about
me,
I'm
James
months,
I'm
bit
shift
mask
on
Twitter
I
talk
a
lot
about
embedded
stuff.
So
if
that's
your
kind
of
thing,
I
would
recommend
following
me:
I
work
for
a
company
upstairs
called
Faris
systems.
We're
a
software
consultancy
focused
on
system
development
in
rust,
so
whether
that's
embedded
systems
distributed
databases,
any
kinds
of
fun,
hard
low-level
problems
in
rust.
We
help
out
with
those
kind
of
things
so
actually
before
I
get
started.
How
many
people
here
have
start?
Who
here
is
written
rust
before
all
right
for
the
camera?
A
That's
almost
everyone
in
the
room
at
least
most
people,
how
many
people
have
written
microcontroller
code
before
okay,
we've
got
like
a
third
room.
How
many
people
know
what
a
microcontroller
is?
Okay
again
most
of
the
room
so
for
anyone
who
didn't
raise
their
hands
or
anyone
on
the
video.
A
microcontroller
is
a
really
tiny
little
computer
system.
They
typically
power.
Almost
every
computer.
A
You
don't
sit
in
front
of
so
whether
you
have
a
SmartWatch,
whether
you
have
a
step
counter,
whether
you
have
an
engine
control
system
for
your
car,
that's
running
code
and
it's
probably
running
code
on
a
microcontroller,
but
we
write
code
for
them.
But
how
do
they
know
how
to
run
that
code?
So
when
you
power
these
embedded
systems
on
you
connect
them
to
a
battery
you
plug
them
into
the
wall
step,
one
apply
power,
great,
that's!
Definitely
where
you're
gonna
start
you're
gonna
plug
the
USB
cable
in
you're,
gonna
flip.
A
The
switch
great
makes
sense
so
far,
step
two
step:
three
run
code
profit.
This
is
gonna
work
great!
It's
gonna
start
running
all
that
imbed
code.
We
wrote
and
everything's
gonna
work
perfectly,
but
what
what
happened
in
between
like
I
started
shoving
electrons
into
my
system
and
then
code
came
out
well.
I
mean
there's
a
couple
things
that
go
into
this.
Let's
say
we
were
writing
the
simplest
embedded
system
in
the
world.
We
were
writing
a
blinky
light.
This
is
like
hello
world
for
embedded
systems.
A
lot
of
embedded
systems,
don't
have
a
screen.
A
So
how
do
you
say
hello?
Well,
if
the
only
thing
they
have
is
a
light.
Well,
you're
gonna
blink,
an
LED,
so
in
rust
some
blinky
LED
hello,
world
code
might
look
like
this,
so
we
have
main
so
this
is
gonna
feel
really
familiar,
whether
you're,
you've
implemented
embedded
systems
or
not,
let's
see,
do
I
have
a
laser.
What
I
do
have
a
laser
pointer.
So
some
of
this
is
specific
and
rust
and
I'm
not
gonna,
get
into
this
in
this
talk.
But
we
have
these
libraries
that
tell
us
how
to
work
with
our
board.
A
For
example,
the
board
I'm
using
this
demo
is
a
board
called
the
DWM
1001.
So
we're
gonna
go
ahead
and
grab
our
drivers
for
that.
We're
gonna
start
a
timer
and
then
this
is
our
wonderful
master
piece
of
code.
We
have
an
endless
loop
that
turns
an
LED
on
it
waits
20
milliseconds
and
then
it
turns
the
LED
off
and
it
waits
230
milliseconds.
So
it's
gonna
go
blink,
blink,
blink
blink
over
and
over
again-
and
this
is
great-
this
is
a
whole
functional
embedded
system.
A
It's
the
best
thing
that
can
ever
be
shipped,
but
this
is
your
code,
but
how
does
that
actually
make
the
whole
system
go?
Well,
it's
not
just
your
code.
If
I
zoom
out
on
this
example
a
little
bit
your
codes
in
main,
but
also
this
is
rust,
so
you've
probably
included
some
libraries
so
at
the
top
of
your
file,
you
might
have
a
line
that
says
this
is
no
standard,
we're
on
an
embedded
system
here,
there's
no
standard
library,
I'm
gonna,
use
that
DW
on
1001.
A
This
is
where
I've
defined
all
my
drivers
and
stuff
like
that
I
didn't
have
to
write
it.
Someone
else
did
I'm.
Also
gonna
pull
in
this
crate
called
cortex
MRT,
specifically
the
entry
macro.
So
we
saw
that
back
on
this
slide.
You
know
we
had
a
little
entry
attribute
hanging
out
on
top
of
main
panic
halt.
This
says
what
happened,
what
our
embedded
system
should
do
if
it
panics,
because
again
this
is
an
embedded
system
and
there's
no
operating
system.
So
if
you
panic,
normally
your
application
is
stopped
by
the
operating
system.
A
Everything
stops,
but
if
you
don't
have
an
operating
system,
you've
got
to
tell
the
embedded
system
how
to
do
this,
and
then
we
pull
in
some
other
things
specifically
about
the
driver,
but
we
still
haven't
answered
what
what
happened.
So
we've
got
some
more
code.
We
know
there's
more
code
involved
now,
because
this
is
rust
and
we
have
a
library
pulled
in
and
things
like
that.
But
what
are
all
the
parts
that
take
the
code?
A
You
write
that
10
lines
of
main
or
whatever
I
had
I'm
gonna
move
this
away
from
my
mouth,
because
the
topic
a
little
bit,
what
makes
it
actually
run
on
your
hardware?
Well,
there's
a
couple
parts
that
go
into
this
there's
code.
So
a
little
bit
of
your
code,
you
write
the
main.
You
define
the
business
logic
and
stuff
like
that,
but
a
lot
of
other
people's
code,
and
you
didn't
see
that
because
we
just
pulled
those
in
as
crates
but
we'll
get
into
that.
The
compiler
helps
so
from
the
rust
side.
A
The
compiler
front-end
rust
C
helps
with
a
bit
of
this
and
then
the
compiler
back-end
LVM
helps
out
with
some
of
this,
but
less
than
you
might
think.
You
might
think
the
compiler
is
pulling
all
the
magic
here,
but
it's
really
not
all
of
it.
We
also
have
the
linker.
So
if
you're
writing
desktop
applications,
you're
still
using
a
linker
linker
is
what
takes
the
compiled
code
and
makes
your
final
executable.
But
you
don't
think
about
it
very
much
when
you're
writing
desktop
code
because
it
just
works,
you
don't
have
to
interact
with
it.
A
Unless
you
get
weird
symbols
like
I,
don't
know
what
this
is.
You
need
to
define
this
and
tell
me
what
it
is,
but
for
emitted
systems.
This
does
a
lot
more
heavy
lifting
than
you
might
think,
and
then
finally,
you've
got
the
actual
hardware.
In
this
case,
our
embedded
system
is
actually
going
to
do.
Some
of
this
magically
for
us
when
I
say
magically,
we
need
to
put
things
in
the
right
place,
but
then
it's
gonna
take
over
the
show
and
then
finally
last
your
code
again,
but
not
as
code
as
machine
code.
A
So
this
is
something
that
your
compiler
is
going
to
generate
and
it's
gonna
create
a
bunch
of
machine
code
or
the
output
of
the
compiler,
and
this
is
what's
gonna
actually
run
on
your
system.
This
is
what's
blinking
the
LED,
so
I
have
a
slide
says.
What
is
a
runtime
real
quick
poll
is
rust,
a
language
that
has
a
runtime.
Yes,
raise
your
hand,
no
raise
your
hand.
Okay,
we
got
more
nose.
How
about
C
is
C
a
language
with
the
runtime,
raise
your
hand
for
yes,
raise
your
hand
for
now.
A
A
But
there
is
a
runtime
and
if
there
wasn't
a
runtime,
we
wouldn't
ever
be
able
to
execute
main,
because
you
just
have
to
drop
main
on
the
hardware
and
it
would
have
to
go
the
runtime
that
si
and
rust
have
is
a
little
bit
different
in
a
lot
more
lightweight,
but
there's
still
a
couple
things
that
the
language
says
need
to
be
done
before.
You
start
writing
mein,
and
this
is
true
for
an
embedded
system
or
your
desktop.
So
I
talked
about
that
thing
of
someone
else's
code,
so
at
least
in
embedded
systems.
A
The
part
that's
doing
the
heavy
lifting
from
someone
else's
code
is
to
libraries,
there's
cortex-m
RT
RT
stands
for
runtime
and
r0,
which
is
if
you've
ever
developed,
C
code
and
you've
seen
the
word
CRT:
zero,
zero,
that's
the
C
runtime
and
it's
typically
provided
by
your
compiler
unless
you're
doing
something
really
weird
and
it's
gonna
be
the
thing
that
injects
kind
of
this
before
main
behavior
and
rust-
we've
written
it
in
rust.
So
it's
just
a
standalone
crate
called
our
zero.
A
So
what
CRT
zero
is
or
excuse
me
CRT,
zero
in
rust.
What
cortex-m
RT
is
gonna
give
you
is
this
kind
of
a
function
and
I've
boiled
this
down
a
little
bit,
but
we've
got
a
couple
steps
that
our
launch
sequence
before
we
get
to
main.
So
the
first
thing
that
happens
is
we
power
up
and
this
function
starts
executing.
We
in
cortex
MRT
give
the
ability
for
people
to
define
a
pre
in
it.
A
Might
you
might
call
the
pre
init
hook
and
say
I,
don't
know:
do
this
first
seriously,
nothing
else
before
this,
then
we're
going
to
initialize
the
RAM
and
if
you've
developed
on
desktops,
you've
probably
not
had
to
think
about
Ram,
you
go,
ok,
Ram
is
there
and
it
starts
with
zero,
and
all
of
my
static
variables
are
predefined
and
they're
loaded
in
when
I
start
running.
But
something
has
to
do
this
because
the
hardware
is
not
going
to
do
it
for
you.
A
If
we're
running
on
a
microcontroller
that
has
a
floating-point
unit,
we're
gonna
turn
that
on
just
so,
we
can
do
faster
bath
or
math
that
actually
works,
and
then
we
call
mein,
hey
that
looks
like
a
normal
function.
Call
great
we're
gonna
jump
into
main
and
that's
where
your
main
actually
happens.
The
blights
start
blinking
now.
I
didn't
really
explain
much
in
that
last
thing.
On
these
embedded
systems
there
is
a
concept
called
the
reset
vector,
and
the
reset
vector
literally,
is
the
address
of
where
to
jump
to
in
the
machine
code.
A
For
where
you
start
running.
So
a
reset
vector
is
literally
the
the
hardware
boots
on
you
have
an
address
and
it
goes
thank
you
and
then
it
jumps
to
that
address.
Like
a
go-to
statement,
and
it
starts
running
that
code,
that's
called
a
reset
vector.
The
vector
means
you
go
there
now
vectors
are
not
just
the
reset
vector
on
a
microcontroller.
You
have
a
whole
thing
called
a
vector
table,
and
this
is
a
definition
where
you
put
in
all
of
these
kind
of
vectors.
A
So
the
reset
vector
is
one
of
these
kind
of
vectors,
but
it
really
is
only
one
of
them.
There
are
a
bunch
of
other
things
like
exceptions
and
interrupts
that
the
hardware
is
going
to
need
to
know
how
to
respond
to,
and
these
work
a
lot
like
callbacks,
where
you
define
a
table
and
you
put
the
address
of
some
function
in
this
whole
table
and
whenever
that
event
happens
so
on
on
JavaScript
or
something
like
that,
you'd
have
a
callback
that
gets
triggered
here.
A
You
have
an
interrupt
that
fires,
some
response
to
a
real
hardware
stimulus-
and
this
is
how
the
hardware
knows
to
say.
Oh
that
happened
run
that
code
there
right
now,
so
this
all
fits
together
in
a
couple
different
ways:
I've
talked
about.
Ok,
we
know
that
when
our
system
power
is
on,
there's
the
reset
vector
and
it
knows
to
jump
somewhere,
but
when
we
compile
the
code.
What
is
that
code?
Like
all
of
that
binary
that
we've
generated?
What
does
that
break
into?
Well,
it
turns
out
it.
A
It
breaks
down
into
about
three
big
sections:
you've
got
the
text
section,
which
is
where
all
of
your
read-only
parts
go.
So
your
actual
machine
code
that
you
generate
your
functions,
your
actual
code
lives
here,
because
you
typically
don't
modify
it
at
runtime.
It's
it's
read-only.
This
is
something
that
your
CPU
is
actually
going
to
pull
in
and
start
executing.
A
It
sequentially
also
anything
that
is
constant,
whether
you
have
predefined
data,
if
you've
ever
seen
just
strings
and
you've
kind
of
accidentally,
typed
cat
on
a
binary
file
and
you've
seen
a
bunch
of
strings
interspersed
with
a
bunch
of
garbage.
That's
because
these
constant
strings
you
have
are
encoded
as
part
of
the
binary.
We
have
another
section
called
BSS
which
stands
for
basic
service
segment.
I,
don't
remember
it's
an
archaic
term
that
we
still
use,
but
what's
that
maybe
binary
storage
space?
A
Okay
I'll
have
to
look
at
Wikipedia,
but
this
is
a
chunk
of
your
RAM,
where
everything
inside
of
it
is
expected
to
be
an
uninitialized
in
c,
if
you
were
defining
a
global
variable
that
you
never
set
to,
you
just
define
the
global
variable.
It
would
go
here
and
as
Percy's
contract,
anything
that's
uninitialized
gets
filled
with
zeros,
so
whether
that's
valid
for
that
structure
or
not
it's
gonna,
be
full
of
zeros.
Brust
I
believe
follows
this
as
well,
but
it's
much
harder
to
make
on
initialize
structured
in
rust.
A
The
compiler
really
doesn't
like
it,
although
now
with
mem
uninitialized,
maybe
you
can
be
able
to
do
that
and
then
we
have
another
section
of
your
RAM
with
dot
data.
So
if
you
would
define
a
global
variable
where
you
say
like
I've
got
some
struct
with
XY
and
Z
and
X
is
10
and
Y
is
20
and
Z
is
100,
then
that
structure
that
global
variable
is
gonna,
live
in
Ram.
So
the
actual
location
of
that
structure
lives
in
RAM,
but
those
initial
values
are
gonna,
live
somewhere
else.
A
A
But
how
does
it
know
where
to
put
stuff?
Well,
the
compiler
knows
if
you
write
some
code
and
you
compile
a
function
and
it
makes
machine
code,
it
goes
dad's
machine
code
that
goes
into
the
text
section
and
if
you
define
some
kind
of
constant,
you
know
string
or
something
like
that
text.
Section
global
variable
with
without
an
initializer
BSS
with
an
initializer
data,
or
you
put
the
initial
value
in
text
and
you
put
the
location
there,
so
the
compiler
knows
how
to
sort
these
into
buckets.
A
It
still
doesn't
know
how
to
where
they
should
live,
but
it
can
go
at
least
when
I'm
compiling
code
goes
that
bucket
that
bucket
that
bucket,
with
rusty
same
with
LVM,
they
know
where
these
things
are
supposed
to
go.
Okay,
so
I
guess
if
we
fall
down
the
chain,
the
next
thing
is
the
linker.
How
does
the
linker
know
where
to
put
stuff?
Because
that's
the
linkers
job
is
to
take
those
huge
buckets
of
object
files
that
we've
created
in
constants
we've
created
into
put
them
in
the
right
places
to
make
an
actual
executable?
A
How
does
it
know?
Well,
we
tell
it
because
it
can't
know
by
itself
I
mean
if
you're
running
on
a
desktop
and
there's
a
predefined
place
to
pull
all
of
these
like
if
you're
running,
on
Windows
or
running
on
Linux,
it's
gonna,
know
out-of-the-box,
but
on
our
embedded
systems
are
kind
of
special
in
every
embedded
systems.
A
little
bit
different
and
every
manufacturer
makes
their
hardware
a
little
bit
different
so
for
embedded
applications.
We
almost
always
have
to
tell
it
where
to
put
all
this
stuff,
and
we
do
that
using
something
called
a
linker
file.
A
Maybe
you've
heard
of
this
as
a
scatter
file,
but
essentially
there
is
a
separately
syntax
document
that
you
have
to
prepare.
That
tells
the
linker
where
to
put
all
of
these
things,
if
nothing
else
where
to
put
each
of
these
categories
of
things.
So
this
is
the
part,
that's
applicable
to
rust,
that
cortex-m
artie
library
that
we
have
provides
some
magic,
mostly
through
some
templates
and
through
using
a
build
RS
script
where
they
provide
some
defaults
of.
Where
do
you
put
this
stuff?
So
cortex-m
artie
provides
a
file
called
link
text
in.
A
A
Data
goes
here,
BSS
goes
here,
it's
kind
of
the
the
skeleton
of
where
all
this
goes
in
a
in
a
regular
embedded
system,
some
embedded
systems,
your
gonna
do
some
really
weird
complex
stuff,
so
you
might
just
jump
to
the
end,
because
you've
got
a
hard
code
where
all
this
stuff
is
anyway,
because
you
have
a
really
special
system,
but
for
most
people
who
are
writing
blinky
lights
and
even
more
complex
software,
they
can
use
this
kind
of
template.
The
next
part
is
device
Dex.
A
So,
like
I
said,
every
one
of
these
embedded
systems
are
different,
one
microcontroller
might
have
ten
interrupts
that
it
can
respond
to
and
another
might
have
a
hundred
and
because
those
all
need
to
go
into
the
vector
table
that
might
be
differently
sized.
So
you
need
somewhere
to
define
okay.
What
interrupts
does
my
hardware
actually
have?
A
You
need
the
memory
X,
so
even
if
you
have
the
same
chip
a
lot
of
times,
vendors
will
sell
like
a
cheaper
one
with
less
RAM
and
flash
and
a
more
expensive
one
with
more.
So
you
need
to
say,
like
okay,
I
have
64
kilobytes
of
flash,
that's
a
lot
of
fat
flash
or
like
a
hundred
and
twenty
eight
kilobytes
of
RAM.
A
That's
a
really
a
lot,
a
lot
of
RAM
and
finally,
these
all
get
smushed
together
by
a
build
RS
script
and
you
end
up
with
a
file
called
link
X,
and
this
is
what
gets
fed
into
the
linker
that
says.
Okay,
you
take
all
those
object,
files
that
the
compiler
is
gonna,
give
you
you're
gonna,
take
this
configuration
file,
and
that
tells
you
where
to
search
and
sort
and
put
things
in
the
right
buckets
and
put
them
in
the
right
place.
A
So
you
can
spit
out
the
final
executable
that
your
hardware
needs,
so
the
device
that
X
might
look
like
this,
where
it
defines
all
of
these
different
interrupts
mines
on
an
NR,
a
52
which
has
a
radio.
So
you
might
have
like
a
power
clock
interrupt
or
a
radio
interrupt
and
it's
gonna
provide
come
some
kind
of
default
value,
but
really
it's
gonna
list
all
of
these
interrupts.
So
it
knows
how
big
that
vector
table
is
gonna,
be
and
then
in
memory
X,
you
might
say.
A
Oh-
and
this
is
what
a
linker
script
syntax
looks
like
by
the
way
it's
kind
of
reasonable
to
read,
but
there
it's
a
whole
different
syntax
from
any
other
language,
so
we
might
have
a
section
called
flash.
This
is
our
non-volatile
memory
and
we're
gonna
say
it
starts
at
address
0.
So
on
microcontrollers
there
are
32-bit
systems,
so
every
address
is
0,
0,
0
0
to
ffff,
and
all
of
these
are
valid
address
locations.
A
So
we
say
because
we've
read
the
datasheet
that
our
flash
lives
at
0
and
we've
got
512
kilobytes
QB
bytes
of
it
and
RAM
lives
at
20,000
hex
and
it's
64
K.
So
now
we've
kind
of
told
our
linker.
We've
got
non-volatile
memory
here
and
volatile
memory
here.
So
it
goes.
Ok,
I
know
that
now
and
that
linked
X
in
so
this,
like
I,
said
it's
a
skeleton
or
a
template
and
I've
taken
out
a
lot
of
the
complicated
parts.
A
But
you
can
see
that
there
are
generally
a
couple
buckets
that
we
define
for
our
linker.
We've
got
that
vector
table
that
I
talked
about,
and
we
that
goes
at
the
top
of
flash,
because
in
a
cortex-m
system,
there's
kind
of
a
contract
between
you
and
the
hardware
that
says
that
vector
table
always
goes
at
memory
address
zero,
because
when
the
system
boots
up,
it's
gonna
look
at
memory
address
zero
and
it's
gonna
start
processing
that
vector
table
the
way
that
you've
just
defined
it
so
that
lives
in
flash.
A
Because
flash
is
the
only
thing
that's
persistent
across
resets,
because
Ram
goes
away
whenever
you
turn
off
your
power.
So
we
put
all
of
our
code
in
flash,
including
the
vector
table
so
vector
table
goes
first,
then
text.
So
that's
all
of
your
code
that
you've
actually
compiled
as
well
as
all
of
those
constants
and
things
like
that.
Then
we
scroll
down
a
little
bit
and
we've
got
data
and
BSS
and
those
are
in
there
too.
Oh
the
one
special
thing
I
wanted
to
show
you
here:
we've
got:
oh!
A
Is
that
not
updating
up
there,
I
guess
when
I
scroll
on
my
presenter,
okay,
there's
a
slightly
different
syntax
in
our
data
section.
We
also
tell
it
hey
the
data.
The
actual
variables
are
gonna
go
in
RAM
and
the
original
definitions
for
it
are
gonna,
go
in
flash.
So
it
needs
to
know
definition
here,
location
here,
so
with
all
of
this
put
together,
an
elf
is
born,
so
if
you're
building
a
an
executable
and
you're
using
the
elf
file
format,
because
you're
on
linux,
this
is
what
actually
contains
all
of
that
information.
A
A
So
now
we're
down
to
the
last
part
of
the
system.
We've
got
the
hardware,
and
this
is
the
really
magical
part,
because
once
you
put
things
in
the
right
place,
everything
just
happens
so
once
we've
taken
that
elf
file
and
we've
used
a
debugger
or
a
JTAG
unit
or
an
SWT
unit.
We've
taken
that
elf
file
that
binary
that
lives
on
your
hard
drive
and
we've
uploaded
it
onto
our
actual
microcontroller,
and
it's
been
smart
enough
where
it
goes.
Okay,
I
put
the
vector
table
at
zero.
I
put
all
the
other
code
in
there.
A
That
vector
table
points
to
the
reset
vector
which
is
inside
of
my
code
and
I've
got
all
of
this
area
of
RAM.
Where
I'm
going
to
have
my
information,
we
go
and
the
launch
sequence
looks
a
little
bit
like
this,
so
the
code
exists
in
flash
again
after
the
vector
table,
so
the
vector
table
is
up
top.
The
reset
vector
is
called
because
at
the
top
of
flash
we
said
when
you
boot
up.
You
will
call
this
function
first
and
it's
that
reset
function
that
we
talked
about
in
cortex
mrt.
A
So
it's
gonna
go
to
that
location
and
it's
gonna
start
running
that
sequence.
Eventually
it
yeah
cortex-m
runs
reset,
your
RAM
is
set
up
and
then
your
main
is
run
because
we've
upheld
the
runtime
invariants.
Essentially
it
was
just
those
two
functions
that
say
zero
at
this
chunk
of
the
RAM
and
copy
this
chunk
of
RAM
from
the
flash
section
into
the
RAM
section,
and
then
your
main
is
actually
run
and,
like
any
other
rust
program,
it
just
happens
and
by
the
way,
this
is
how
it
works
on
microcontrollers.
A
But
it's
almost
exactly
the
same
on
your
desktop
to
Windows
and
Linux
and
Mac
have
slightly
different
launch
sequences.
But
it's
going
to
be
holding
these
kind
of
invariants
the
same
because
it
has
to
have
this
runtime
behavior
so
and
then,
once
we
have
it
all
done,
let
there
be
blinky
light
and
there
is
a
blinky
light.
Running
I
actually
have
the
hardware
here.
A
So
after
the
talk,
if
you
want
to
come
up
and
see
exactly
how
this
works
and
I
can
pull
up
a
debugger,
and
we
can
step
through
instruction
by
instruction
of
how
this
actually
works,
I'm
happy
to
sit
down
and
you
will
end
up
with
a
blinky
light.
At
the
end,
so
I
have
not
been
staring
at
my
time,
but
thank
you
very
much
for
listening
to
me.
A
I
have
a
couple
plugs
so
one
if
you're
interested
in
this
kind
of
stuff
and
you're
interested
in
embedded
and
you're
interested
in
rust,
I'm
part
of
the
embedded
working
group
come
join
us
we're
working
really
hard
to
make
rust
like
the
best
ecosystem
for
embedded
systems
development.
So
if
this
is
the
kind
of
thing
that
you're
interested
in
interested
in
working
on
then
come
join
us
here,
I've
got
a
link
to
our
coordination,
repository
I
work
for
a
company
called
ferrous
systems.
A
Like
I
said
we
do
consulting
in
the
area
of
systems
level
stuff
with
rust,
including
embedded
systems
not
shown
here.
We're
also
running
a
conference
in
at
the
end
of
April
called
oxidize,
which
is
the
first
embedded
rust
conference
and
we're
having
it
here
in
Berlin,
so
we're
going
to
be
having
workshops
and
talks
on
embed,
rust,
embedded
Linux
and
bare
metal
development
like
this.
So
that's
the
kind
of
thing
that
interests
you
come
talk
to
me
after
the
talk
and
yeah.
Thank
you.