►
From YouTube: 2022-05-16 Cross Team Collaboration Fun Times (CTCFT)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
hello,
everybody
welcome
to
the
may
ct
cft
for
2022.
this
week.
We
have
quite
a
few
speakers
and
quite
a
large
audience,
so
I'm
going
to
try
to
keep
my
sections
as
short
as
possible,
so
just
starting
off,
of
course
we're
following
the
rust
code
of
conduct
and
we
have
several
moderators
that
will
will
be
on
hand
in
the
chat
as
well
as
you
like
people
you
can
reach
out
to
afterwards.
A
You
can
always
send
us
an
email
to
our
ctcft
at
if
rustling.org,
I
believe
so
that
is
good
and
just
a
reminder
with
camera
and
audio,
so
when
possible,
just
make
sure
that
you
are
muted
and
your
camera
is
off.
If
you
are
speaking
you're
asking
a
question
of
course
feel
free
to
turn
it
on
and
we'll
try
to
relay
as
much
as
we
can
for
any
questions
from
the
chat
to
to
the
speakers,
and
so,
if
you're
more
comfortable
with
that,
that
should
be
all
right.
A
So
as
for
the
agenda,
as
always,
we're
looking
for
people
to
come
and
give
talks
about
the
the
topics
that
fit
within
the
theme-
and
so
this
month
is
focused
on
embedded
rust
and
for
june.
I
believe
we've
settled
on
global
being
the
theme,
but
if
you
have
any
ideas
of
what
could
be
talks
for
next
month,
do
feel
free
to
reach
out
and
submit
proposals.
A
We
also
do
some
work
to
try
and
find
people
that
we
think
would
do
quite
well,
but
we
always
want
to
make
sure
that
we
keep
it
open
for
anybody
to
suggest
so
we'll
get
started
right
away.
I'm
gonna
pass
it
over
to
our
first
speaker,
who
is
going
to
give
us
a
whirlwind
tour
of
embedded,
rust
and
so
james
I'll
pass
it
over
to
you.
B
Yeah,
it
says
I
can't,
while
you're
sharing.
A
Let
me
do
this
and
also
make
sure
we
have
permission
set
up
properly,
yeah,
give
that
a
go.
B
All
right,
let
me
pull
something
onto
my
main
screen:
real,
quick,
all
right,
so
hey,
I'm
james!
This
is
gonna,
be
a
whirlwind
tour
of
embedded
rust
and
I
have
a
lot
to
cover
in
a
very
short
amount
of
time.
I've
been
part
of
the
embedded
working
group
for
forever.
B
I
guess
until
since
it
started
and
I've
given
a
talk
about
what
is
embedded
rust
a
lot
of
times,
so
I
decided
to
mix
it
up
and
go
full
out
there
on
this
one
and
try
and
explain
a
lot
of
things,
but
also
show
a
lot
of
things
and
if
you
don't
follow
all
the
details
of
what
I'm
doing,
that's
totally.
B
Okay,
I'm
gonna
post
this
up
in
a
git
repo
afterwards,
once
I
polish
it
up
a
little
bit,
including
with
all
the
pictures
and
stuff
like
that,
so
if
you
don't
follow
along,
don't
worry.
My
main
gist
here
is
that
developing
embedded
systems
with
rust
is
more
like
developing
rust
than
developing
embedded
systems.
And
if
you
are
already
someone
who
can
develop
rust,
you
probably
would
have
a
really
good
time
developing
embedded
systems.
B
So
before
I
talk
about
anything
else,
I
should
probably
define
my
terms.
What
are
embedded
systems
embedded
systems
are.
My
joking
answer
is
every
computer
you
don't
sit
in
front
of
this.
Is
every
computer
that
typically
has
one
specific
purpose
rather
than
being
a
general
purpose.
Computer.
Now
your
desktop
your
laptop,
a
server,
your
phone.
I
would
call
those
general
purpose,
computers,
because
you
can
run
any
kind
of
program
on
them.
Embedded
systems
typically
have
exactly
one
program
that
they
run.
B
This
could
be
something
like
your
fitness
band
or
a
treadmill
or
a
tv,
remote
or
all
the
parts
that
make
up
a
tesla,
for
example.
So
these
are
all
systems
that
have
different
constraints.
Some
of
them
have
to
be
really
fast.
Some
of
them
have
to
be
really
reliable.
Some
of
them
have
to
be
both,
but
these
are
all
the
systems
that
have
really
large
constraints
on
them
and
they're
designed
to
do
exactly
one
thing.
B
So
why
is
rust
a
good
match
for
embedded
systems?
Well,
embedded
systems
tend
to
be
made
as
close
to
the
requirements
as
possible,
which
means
you
want
to
put
the
smallest
cpu
and
the
smallest
amount
of
ram
there,
because
when
you're
making
a
million
of
them,
it
costs
the
least
or
when
you
have
to
deliver
on
some
kind
of
deadline.
B
If
you
want
to
control
exactly
how
you
allocate
memory,
you
can,
if
you
want
to
control
exactly
what
you're
doing
in
different
environments
and
contexts,
and
things
like
that,
you
can,
even
though
rust
was
never
designed,
at
least
from
the
beginning,
to
be
an
embedded
systems
language.
It
has
the
same
kind
of
design
constraints
as
something
like
a
browser
or
an
operating
system
where
you
need
to
be
the
one
as
the
developer,
who
controls
all
of
those
things
now.
B
Now
most
of
these
operating
systems
don't
or
excuse
me
most
of
these
embedded
systems,
don't
have
an
operating
system,
they
run
one
application
and
the
application
is
both
the
program
and
the
operating
system,
which
means
that
we
can't
use
the
standard
library
in
rust,
usually
there's
all
kinds
of
different
embedded
systems.
Like
I
said,
a
tesla
might
have
less
constraints
than
your
tv
remote,
but
most
of
the
time
when
we're
talking
about
embedded
systems,
we're
talking
about
systems
without
an
operating
system.
B
Now,
when
you
develop
for
a
desktop,
you
typically
think
of
it.
Like
this,
you
have
some
code.
It's
on
your
hard
drive.
You
open
it
up
in
the
compiler,
the
compiler
compiles.
That
code
creates
an
application,
and
then
you
ask
your
operating
system
to
load
that
program
and
run
it.
So
it's
going
to
look.
B
Can
I
make
this
bigger
cool,
so
it's
going
to
go
ahead
and
load
that
program
and
run
it
and
you're
both
building
and
running
that
program
on
the
same
machine
now
lots
of
folks
out
there
have
probably
developed
for
servers
too
and
we're
getting
a
little
bit
closer
here
and
you'll
see
why
I'm
going
down
this
direction
in
a
second
when
you're
developing
for
a
server
either
somewhere
else,
or
you
know,
in
a
virtual
machine,
you're
building
your
code
locally
and
then
you're
deploying
it
typically
over
the
network,
so
you're
pretty
much
pushing
your
application
over
there
and
then
maybe
through
ssh
or
some
tool
you're
getting
the
logs
back
so
again,
now
you're
in
kind
of
a
two
computer
world
where
one
computer
is
where
you're,
compiling
and
one's,
where
you're
running
now
in
embedded
systems.
B
This
gets
a
little
bit
more
detailed
because,
like
I
said,
we
have
no
operating
system.
We
can't
just
ask
the
operating
system
to
run
a
program
for
us,
so
we
do
what's
called
cross
compiling.
We
are
taking
our
code,
that's
running
on
our
desktop,
compiling
it
into
an
application,
but
for
a
different
architecture.
B
I
think
that's
all
I
have
for
this.
So
again
the
difference
is
we're
building
here,
we've
got
to
get
it
to
the
embedded
system
and
then
we've
got
to
run
it
there.
Now.
The
other
thing
that's
really
great
about
embedded
rust
is
we
still
get
to
use
all
of
the
great
tools
from
rust
we
get
to
use
tools
like
cargo
generate
and
com
rust
or
excuse
me.
B
Cargo
plug-ins
that
allow
us
to
make
running
an
embedded
system
feel
a
lot
easier,
so
I'm
actually
going
to
go
ahead
and
plug
in
some
hardware,
and
you
can't
see
it,
but
that's
okay,
but
for
the
sake
of
demonstration
I
don't
know
how
visible
this
will
be.
I
have
a
tiny
embedded
system
here.
It's
a
little
microcontroller,
it's
64
megahertz.
It's
got
8
kilobytes
of
ram
and
64
kilobytes
of
storage,
and
it's
going
to
be
our
test
subject
today.
B
Yes,
cool
all
right,
so
I'm
not
going
to
show
you
all
of
the
code,
because
I
realized
that
I
have
much
less
time
than
I
think
so.
We're
going
to
fast
forward
you'll
have
to
trust
me
on
some
of
these
things,
but
I
used
a
tool
called
cargo
generate
to
make
a
template
of
an
application
for
me
and
it
went
ahead
and
set
up
everything,
except
for
the
parts
that
are
specific
to
exactly
what
hardware
I'm
running
on
it
set
up
the
tooling.
B
B
So
now
that
I've
plugged
my
usb
device
in
it
went
ahead
and
compiled
my
program
for
a
different
architecture,
uploaded
it
and
ran
that
program
for
me
and
gave
me
the
logs
back.
So
with
this
kind
of
tooling,
we
want
the
experience
of
writing
embedded
code
to
feel
a
lot
like
writing
code
for
a
server
you're
taking
code
from
here
and
uploading
it
over
there
and
our
code
itself.
Doesn't
look
too
strange.
There's
going
to
be
a
couple
attributes
you
might
not
have
seen
before,
but
we've
got
a
main
function.
B
Now,
there's
a
bunch
of
libraries
that
go
into
this,
but
the
thing
that
I
really
want
to
push
here
more
than
any
specific
details
is
that
all
of
this
stuff,
that
let
me
write
code
for
my
specific
chip,
isn't
something
special
and
bespoke
to
embedded.
I
can
look
in
my
cargo
tunnel
here
and
my
dependencies
for
all
of
my
drivers
are
just
rust
crates,
which
means
there's
this
whole
ecosystem
of
embedded
driver
development
that
I
can
just
pull
in,
like
a
normal
application.
B
I've
got
dependencies.
I
can
use
my
cargo
profiles,
everything
like
that
and
I'm
able
to
run
my
code
here.
B
Now
one
other
thing
that
I
really
wanted
to
touch
on
here
is
that
traditionally
writing
portable
code
for
embedded
has
been
very
difficult
most
of
the
time
those
drivers
that
I
mentioned,
if
you're
writing
them
in
c
or
other
languages,
come
from
the
people
who
sell
you
the
hardware
they
maintain
the
drivers
and
that
driver
isn't
really
portable
to
anything
else,
which
means
when
you
write
a
lot
of
your
code.
It
needs
to
be
specific
to
that
one
chip.
B
B
Now,
let's
see
the
way
it
works
in
rust,
is
we
actually
have
the
ecosystem
broken
up
into
like
three
parts
and
to
make
things
portable?
You
might
say:
well,
there's
a
thing
for
that
in
rust,
there
are
traits,
and
we've
leaned
really
hard
to
that
in
embedded
rust,
we
have
a
bunch
of
traits
called
embedded
hal
traits
which
describe
a
bunch
of
normal
stuff
that
embedded
systems
do
sending
data
over
a
serial
port
reading
a
gpio,
parsing
things,
and
things
like
that.
Those
are
all
going
to
be
in
embedded.
B
B
B
The
way
that
you
would
typically
do
this
on
a
desktop
would
be
that
you'd
have
hardware
drivers
which
talk
to
your
operating
system
and
something
like
your
network
stack
that
talks
your
operating
system
and
your
application
is
just
going
to
talk
to
your
operating
system,
but
again
no
operating
system,
and
we
can't
really
handle
that
much
overhead.
B
Now
I
think
we're
actually
pretty
getting
pretty
close
to
the
end
of
my
15
minutes.
So
I
wanted
to
mention
one
thing:
that
if
you're
looking
for
the
kind
of
things
that
are
possible
today
or
you
want
an
idea
of
what
kind
of
code
already
exists
out
there,
the
rust
embedded
working
group
has
a
coordination
repository
at
rust,
embedded
wg.
B
We
have
a
lot
of
things
here,
but
if
you're
looking
for
inspiration,
one
of
my
favorite
things
is
the
awesome
embedded
rust
list
which
is
sort
of
a
community
maintained
list
of
all
the
stuff.
We
have
drivers
for
people
who
have
written
cool
blog
posts
or
learning
materials,
or
things
like
that,
and
even
things
like
a
listing
of
chat
rooms
where
you
can
find
other
people
who
are
working
on
the
same
kind
of
problems
that
you
want
to
be
working
on
now.
B
B
Hello
world,
so
you
can
even
do
all
kinds
of
things,
so
this
is
using
one
of
those
embedded
how
drivers
to
control
the
leds
in
a
portable
way
with
the
drivers
for
this
specific
chip
that
are
running
on
here
and
you're,
able
to
control
all
kinds
of
things
like
led
strips
or
sensors,
and
things
like
this.
B
A
Great,
thank
you
so
much
and
we'll
open
the
floor
for
a
question
or
two.
If
anybody
likes,
I
will
give
that
an
opportunity.
A
And
I
think,
oh
I
see
nico
here
nikola,
you
speak.
C
I
got
a
question.
This
looked
really
awesome,
I'm
wondering
what
are
the
things
that
are
kind
of
cutting
edge
like
what
what
makes
embedded,
where
does
the
slick
tooling
start
to
fall
off
and
where
which
would
you
say
it
needs
more
work?.
B
Yeah,
so
I
mean
the
tooling
is
definitely
probably
the
most
innovative
thing.
Embedded
tooling
in
the
past
has
traditionally
been
a
real
pain
to
use,
because
it's
bespoke
to
every
piece
of
hardware
you
use,
which
means
you
don't
get
to
build
up
a
lot
around,
that
in
embedded
rust,
we've
done
a
really
good
job
of
making.
It
feel
like
the
rest
of
the
rust
ecosystem.
B
B
Sometimes
so,
there's
definitely
some
longer
tail
things
in
embedded
and
embedded
is
full
of
long
tail
things,
but
the
tooling
is
absolutely
a
shining
star
and
the
ecosystem
really
has
been
growing
over
the
past
years,
filling
in
all
of
the
different
pieces
of
hardware
yeah,
and
I
think,
just
rust
itself.
Making
things
available
to
be
used
at
whatever
level
you
have
coming
is
good,
because
you've
got
people
like
this
running
on
a
microcontroller
with
8k
of
ram,
where
I
have
no
heap
and
anything
like
that.
B
There
are
folks
like
the
esp32
folks
who
make
those
wi-fi
microcontrollers,
where
they
have
much
more
resources
and
they
even
have
a
real-time
operating
system
based
on
freertos
and
they've,
implemented
the
russ
standard
library
on
top
of
that
real
time
operating
system.
So
you
can
even
still
use
the
standard
library
and
allocations
and
things
like
that
on
those
platforms.
So
it's
been
really
nice
that
russ
scales
with
the
amount
of
power
you
have
available
to
you.
A
Perfect,
so
I
think
we'll
hop
over
to
our
next
speaker.
Thank
you
so
much
james
and
just
a
reminder
to
everybody
in
the
social
hour
that
we'll
be
following
the
presentations
today,
you
can
feel
free
to
reach
out
to
any
of
the
speakers
and
ask
any
more
questions
perfect,
so
james,
yes,
okay,
perfect
and
then
daario.
I
will
pass
it
over
to
you
to
talk
about
async,
embedded.
D
So
hello,
everyone,
I
think
you
can't
see
me.
D
D
Great
so
so
james
did
a
great
presentation
on
how
acl
how
embedded
works
in
general,
so
I'm
going
to
focus
on
one
aspect
which
makes
rust
awesome
for
embedded
and
is
something
like
people
developing
embedded
with
c
have
like
never
seen.
So.
In
my
opinion,
this
is
one
of
the
groundbreaking
things
rust
allows
on
embedded,
which
is
it
allows
use
of
async
without
the
typical
downsides
of
like
other
async
runtimes
in
other
languages.
D
So
basically
the
the
talk
would
be
like
a
short
overview
of
like
how
do
you
usually
handle
concurrency
on
embedded
systems
like
how
do
you
do
multiple
things?
At
the
same
time,
so,
for
example,
you
might
have
an
embedded
system
which
is
like
blinking,
a
light
to
indicate
some
status
to
the
user
and
then
controlling
some
motors
with
some
timers
and
then
handling
like
usb
or
serial
port
for
allowing
another
system
to
control
it.
D
So
typically,
you
have
like
some
amount
of
concurrency
in
an
embedded
system
and
there's
a
few
ways
to
handle
it
and
then,
in
my
opinion,
async
is
like
the
the
best
as
we'll
see
why
shortly
so
short
overview
of
like
how
embedded
hardware
looks
like
we're
talking
about
like
really
embedded
hardware,
so
embedded
microcontrollers,
no
embedded
linux,
where,
like
every
single
instruction
running
on
it,
is
written
by
us.
So
there's
absolutely
no
os.
D
That
will
do
things
for
us.
They
are
typically
tiny
systems
like
low
end
could
be
considered
like
4k
of
ram
16k
of
flash
high
end
would
be
considered
like
256k
of
ram.
One
megabyte
of
flash,
which
is
like
really
tiny,
even
like
even
high
end,
is
really
tiny
and
something
interesting
is
you
use
it
often
like
with
no
hip,
because
you
have
so
little
run
that
you
really
need
to
make
sure
at
compile
time
that
everything
you
want
to
do
fits
in
run.
D
D
D
D
So
you
write
registers
to
tell
it
to
do
things,
and
then
you
can
read
back
the
values
of
registers,
so
you
can
know
the
status
of
the
stuff.
You
asked
the
peripheral
to
do
so.
The
most
basic
way
to
do
things
using
these
peripherals
is
just
outright
blocking.
D
So,
for
example,
this
is,
how
would
you
do
serial
are
read
on
a
serial
port
on
an
nrf
chip
from
nordic
semiconductor,
which
is
the
same
chips?
James
was
talking
about
before.
D
So
these
things
here
are
registers
and,
as
you
can
see,
we
can
write
to
them
or
we
can
read
to
them.
So,
for
example,
we
allocate
a
buffer
of
eight
bytes
and
then
we
write
the
pointer
and
the
length
to
this
buffer
to
the
peripheral,
and
then
we
tell
it
hey
start
a
receive
rx
means
receive.
So
we
tell
the
peripheral,
hey
start
receiving
data
on
this
buffer.
D
D
So
what
we
do
is
just
we
can
simply
slip.
No,
we
can
spin.
While
this
bit
is
not
set.
We
spin,
like
it's
a
while
loop,
that
does
nothing
just
waits
for
this
bit
to
be
set
and
when
it's
set
we
know
the
buffer
has
the
data.
So
we
can
do
things
with
this
data.
In
this
case
we
can
print
it,
but
in
the
real
world
we
would
like
process
it
to
be
some
control
message.
We
would
do
things
with
it,
so
this
works.
D
This
is
super
simple,
but
it
has
like
some
very
obvious
downsides,
which
is
basically
we
can
do
anything
else
while
waiting
it's
a
loop
which
is
using
100
of
the
cpu
and
remember
we
have
no
threads
here.
We
have
no
os,
so
there
is
just
one
thread.
D
We
could
like
maybe
put
multiple
things
in
this
loop,
so,
for
example,
if
we're
waiting
to
receive
data
on
two
serial
ports,
we
could
make
this
loop
check
both
registers
from
both
serial
ports
and
then
when
it
gets
data
from
one
or
the
other
process
it,
but
like
it
composes
horribly
like
idea.
Ideally,
we
would.
D
We
would
want
to
have
like
a
piece
of
code
handling,
one
serial
port
and
another
piece
of
code
handling
the
other
serial
port
and
not
having
to
like
mash
them
together
like
this,
and
also,
of
course,
it
wastes
power
like
the
core
is
spinning,
100
usage.
So,
if
you're
like
building,
say
battery-powered
devices
which
need
to
be
like
half
years
of
battery
life
on
a
single
charge,
this
is
obviously
not
not
great.
D
It's
really
bad
so
to
solve
this,
the
hardware
gives
you
something
called
interrupts,
which
is
yet
another
way
peripherals
can
communicate
with
you.
So
basically,
you
can
like
read
or
write
registers,
which
is
something
like
the
core
has
to
do
voluntarily
and
there's
also
interrupts,
which
is
something
initiated
by
the
peripheral,
not
by
the
core.
So
the
peripheral
can
signal
an
interrupt
to
the
core
which
basically
causes
the
hardware,
and
so
it's
not
not
done
by
any
operating
system.
It's
all
done
by
the
hardware.
D
But
it's
not
exactly
like
a
thread.
It
runs
on
the
main
stack,
so
it's
more
like
unix
signals
which
people
familiar
with
them
will
know.
They
are
very
cursed,
but
essentially
the
the
main
takeaway
is
sending
data
from
main
thread
to
an
interrupt,
or
the
other
way
requires
send
them
sync,
because
it
kind
of
behaves
like
a
thread.
So
you
you
have
to
require
sentencing
to
enforce.
You
don't
send
data
that
could
be
vulnerable
to
risk
conditions.
D
So
how
does
it
look
in
practice?
So,
instead
of
spinning,
we
do
the
following.
We
do
some
extra
magic
register
rights
which
will
enable
this
interrupt,
which
is
basically
asking
the
hardware
hey
when
you're
done
with
like
when
this
event
happens,
please
fire
the
interrupt
and
then
we
start
the
read
as
before,
and
then,
instead
of
actually
spinning
waiting
for
the
event,
we
do
nothing
so,
for
example,
in
arm
course
there's
this
intra
instruction,
which
is
called
wait
for
interrupt,
which
essentially
does
nothing
and
waits
for
an
interrupt
to
arrive.
D
And
then,
if
you
stick
it
in
a
loop
like
this,
basically
what
you
do
is
you
slip
the
core
in
low
power
mode?
So
this
will
not
use
100
cpu.
This
will
use
like
the
lowest
power
consumption
that
the
core
can
do,
and
then
we
we
write.
This
magic
function
with
this
attribute,
which
makes
it
be
the
interrupt
handler.
D
D
So
in
this
case,
what
I
do
is
print
it,
but
you
would
carry
on
processing
it
and
also
something
of
note
is
this
is
a
separate
function.
This
is
not
main
so
to
actually
share
the
data
between
main
and
interrupt.
I
had
to
move
the
buffer
to
a
static
mode
which
is
actually
cheating.
This
is
unsound
because
you
can
have
race
conditions
between
main
and
interrupt
so
in
the
real
world.
D
D
This
works.
This
solves
the
issue
of
spinning
the
core
at
hundred
percent.
This
solves
the
issue
of
only
being
able
to
do
one
thing
at
a
time,
but
there
are
some.
There
are
still
challenges.
D
The
interrupt
handler
is
another
threat,
so
you
need
to
put
everything
like
all
your
state.
You
need
to
put
it
in
statics
and
you
need
to
make
it
send
and
sing.
So
you
need
to
use
mutexes
and
it's
also
less
readable,
like
control
flow.
No
longer
reads
top
to
bottom:
you,
you
have
essentially
a
callback
hell
from
like
the
old
days
of
javascript,
where
it's
like.
D
Hey
do
this
thing
and
then,
when
the
thing
fires
like
when
the
thing
is
done,
this
callback
fires,
which
is
somewhere
else
in
the
code
and
then
from
that
callback,
you
need
to
start
then
doing
the
next
thing
which
we'll
call
another
callback.
So
the
control
flow
no
longer
reads
top
to
bottom.
It's
really
really
harder
to
write
code
in
this
way
and
you
have
to
turn
all
your
logic
into
state
machines,
because
in
in
your
interrupts
you
cannot
block
so
in
the
interrupts.
You
essentially
need
to
load
all
your
state
from
statics.
D
D
For
example,
if
we
wanted
to
do
this
serial
read
with
a
timeout,
we
would
need
to
have
like
the
serial
interrupt.
We
would
need
to
use
a
hardware
timer
with
the
timer
interrupt
and
then,
for
example,
when
the
serial
read
completes,
we
would
need
to
stop
the
timer
or
when
the
timer
fires,
we
would
need
to
stop
the
serial
read
so
there's
an
example
in
the
github
for
the
code
of
this
talk
that
you
can
check
later,
if
you
want
it
shows
how
complex
this
gets.
D
Also,
there's
kind
of
complex
race
conditions
that
can
happen
if
both
interrupts
fire
at
the
same
time.
So
you
need
to
use
atomics
and
things.
So
it's
it's
not
great.
It
works
it's
not
great,
so
in
c
embedded
development.
Traditionally
to
solve
these
issues,
you
use,
what's
called
a
real
timer
operating
system,
which
is
basically
a
mini
operating
system
that
you
ship
with
your
code.
It's
mostly
a
library,
it's
not
a
real
operating
system.
D
D
D
Most
of
the
mature
rtos's
are
written
in
c.
You
have
some
examples
here.
There's
a
few
upcoming
projects
in
rust.
Just
talk
os
or
hubris,
there's
also
bindings
to
crt
oss,
there's
even
a
few
std
ports,
usually
on
top
of
c
or
t
oss,
but
even
then,
like
rtos,
has
solved
this
issue,
but
they
are
still
not
great.
So,
for
example,
you
need
to
allocate
stacks
for
every
thread
which
a
common
pain
point
is
you
have
to
actually
set
a
size
for
these
stacks.
D
If
you
set
them
too
big
you're
wasting
ram.
If
you
set
them
too
small,
you
will
have
stack
overflow
errors
at
runtime,
which
could
cause
a
different
behavior
depending
on
how
you
have
configured
memory
protection,
so
rust
gives
us,
in
my
opinion,
the
ultimate
solution
to
embedded
concurrency,
which
is
async
which
basically,
in
async
we
have
this
trade
called
future,
which
allows
us
to
abstract
an
operation
which
is
in
progress.
D
D
Basically,
all
we
do
is
we
fire
the
waker,
so
the
for
those
of
you
who
are
not
familiar
with
icing
internals,
the
waker
is
a
way
to
signal
the
icing
executor
that
that
there's
work
to
do
in
this
task
and
then
the
the
the
the
the
future
registers
the
waker
in
global.
D
We
don't
have
to
worry
about
risk
conditions
and
then,
once
we
have
all
this
machinery
in
place,
we
can
simply
wait
for
a
return.
So
we
start
an
operation.
We
await
the
future
and
then
and
then
that's
it.
It
works
and
also
the
executor
will
handle
sleeping.
So
the
executor,
if
it's
properly
written
for
embedded,
will
make
sure
the
core
sleeps
when
no
task
has
to
run
so.
D
For
the
last
few
years,
I've
been
working
in
a
project
together
with
many
people
from
the
awesome
rust,
embedded
community,
which
is
called
embassy,
which
is
taking
all
these
ideas
into
an
actual
production,
ready
framework
for
using
async
on
embedded,
and
then
this
is
a
quick
peek
of
what
it
allows
you
to
write.
D
D
If
you
need
to
wait
for
multiple
things,
you
need
to
coordinate
the
interrupts
and
everything
all
this
is
handled
for
you
for
you
with
async,
so
that
the
features
nicely
encapsulate
waiting
for
a
read
or
waiting
for
a
timeout,
and
then
you
can
combine
them
with
join
with
select.
So
in
practice,
this
gives
you
smaller
code
than
rt
oss
faster,
because
you
don't
need
an
actual
os
that
handle
context
switching.
So
the
compiler
translates
all
your
code
to
a
state
machine
for
you,
it's
readable.
D
D
To
bring
this
to
production,
it
works
great,
it's
usable
in
production.
My
company
is
shipping
all
our
products
using
rust,
async
and
embassy,
for
example,
but
there's
a
few
challenges,
then
the
main
challenge
is
everything
is
needs
nightly
only
features.
D
D
So
we
use
generic
generic
associated
types
together
with
type
alias
input
rate,
to
name
the
unnamable
features
from
async
functions
again,
but
of
course
the
rust
easing
team
is
already
working
on
this,
so
we'll,
hopefully
get
async
functioning
trades
soon.
D
I
invite
you
to
check
embedded
hull
async
to
see
like
how
these
trades
look
today
and
how
great
could
they
look
like
with
real
async
functioning
trade
support
because
they
work
but
they're
not
very
readable,
and
this
is
the
biggest
challenge
we're
having
in
embedded
async
and,
I
would
say
in
embedded
in
general
if
you
want
to
use
dma
direct
memory
access
so
as
you've
seen
in
this
early
example.
D
D
So
the
the
way
to
cancel
a
feature
is
you
just
drop
it,
and
then
the
drop
implementation
for
the
future
can
do
whatever
clean
up
it
needs,
but
there's
a
huge
problem
which
is
in
today's
rest.
You
can
leak
instances
of
strikes,
which
means
you
can
de-allocate
them
without
calling
their
drop,
which
you
can
use
this
to
cause
a
different
behavior
in
in
in
these
future
apis
that
use
dma
internally.
D
So
this
is
actually
the
same
problem
as
io
urine
bindings.
So
I
o
urine
is
a
new.
I
o
api
in
the
linux
kernel,
which
is
essentially
the
linux
kernel,
doing
the
writes
to
the
process
memory,
so
it's
kind
of
like
dna
but
done
by
the
kernel,
and
they
have
exactly
the
same
problems,
so
they
they
solve
this
by
using
owned
buffers.
D
So
this
way,
if
you
leak
the
future,
you
also
lick
the
buffer,
so
the
memory
for
the
buffer
will
stay
located
forever
and
then
the
kernel
can
keep
right
into
it
and
it
would.
It
won't
cause
ub,
but
this
is
not
possible
in
embedded.
If
you
want
to
use
no
alloc
like
you,
cannot
use
box
or
back
so
there's
a
few
ideas
around
on
how
to
solve
this.
I
I
think
I'm
running
out
of
time,
so
one
of
them
is
to
use
rent
to
completion
features,
so
you
would
forbid
dropping
them
halfway.
D
Another
issue
and
another
idea
is
to
use
a
leak
or
a
trait,
so
everything
that
can
leak
things
would
require
this
trait
and
then
you
could
not
implement
for
features
that
must
not
be
leaked
but
yeah.
It's
a
very,
very
open
question
and
I
would
really
love
to
see
a
solution
for
this
from
rust
because
currently,
for
example,
in
embassy,
we're
just
pretending
this
issue
doesn't
exist.
So
we're
just
saying:
hey,
please,
don't
leak,
features.
D
A
Great,
thank
you
very
much.
I
think,
because
of
time
we'll
keep
questions
to
chat,
but
there's
definitely
a
lot
of
discussion
going
on
in
there,
and
so
it's
really
great
to
see
that
so
many
people
are
excited
about
a
lot
of
stuff
that
was
discussed.
A
E
Thank
you.
I'm
just.
F
E
I
hope
you
can
see
my
screen-
fine,
yes,
all
good
okay,
so
I
should
probably
introduce
myself,
because
you
know
florian,
who
is
actually
core
of
this
talk,
I'm
christopher
I'm
now
working
for
15
years
in
automotive
industry
and
of
course
I
have
written
plenty
of
cnc,
plus
plus
code
embedded
and
also
non-embedded
and
optimized
for
strange
target
hardwares
and
things
like
that
and
two
years
or
two
and
a
half
years
ago.
Actually
a
co-worker
of
mine
introduced
me
to
rust
and
I
got
hooked.
E
E
So
I
would
like
to
actually
structure
this
talk
into
three
parts.
The
first
one
is
about
explaining
what
exactly
is
orders
are?
You
might
actually
have
heard
that
name
before,
and
I
would
like
to
give
you
a
better
idea
about
that.
Then
I
will
give
an
introduction,
a
very
quick
introduction
to
functional
safety.
This
is
a
vast
topic
and
then
florian
can
take
over
for
the
ferrocene
efforts
on
compiler
qualification,
which
the
need
for
that
actually
should
become
obvious
after
the
second
part.
E
So
what
is
autosar?
It's
not
that
visible,
well
visible
from
these
letters
here,
but
actually
it's
made
out
of
odd
from
automotive
o
s
and
r.
So
it's
actually
an
acronym
for
an
open
systems.
Architecture
for
automotive,
which
was
created
by
a
lot
of
oems,
which
is
basically
the
car
manufacturers
and
the
so-called
tier
ones,
which
is
basically
the
companies
producing
modules
which
are
then
integrated
into
these
cars
and,
of
course,
the
tier
2s
and
ts3s,
which
is
hardware
and
silicon
and
tool
suppliers
and
all
these
the
com.
E
The
consortium
is
actually
munich-based
and
it
has
specified
two
variants.
The
classic
autosar
variant
has
been
around
for
more
than
a
decade
now
and
it's
targeting
microcontrollers.
It
has
a
c
api
and
it's
in
wide
use
across
the
industry
and
they
also
specified
a
new
one,
which
is
less
than
five
years
old.
As
fast.
I
can
recall
this
is
adaptive
autosar
and
this
one
extends
the
auto.
The
architecture
towards
dynamic.
E
I
would
like
to
concentrate
on
the
non-embedded
part
of
autosar,
because
that
is
the
one
which
currently
is
being
specified
for
using
rust
within,
and
we
would
like
to
address
that
first,
because
autos
are
adaptive
is
still
in
influx
and
it
is
still
being
worked
on
actively
and
the
others
are
classic
is
more
of
a
frozen
state.
E
So
actually
we
would
like
to
introduce
it
first
into
the
more
volatile
environment
and
then
later
on,
go
to
the
classic
one,
because
of
course,
autozoa
classic
can
also
benefit
from
the
from
rust,
especially
when
it,
when
you
introduce
in
async
to
actually
work
around
the
callback
hell
which
is
currently
present
in
all
the
photos
are
classic
so
otters
are
adaptive
relies
on
a
posix
system
which,
in
my
book,
actually
doesn't
make
it
an
embedded
system
and
all
of
the
system
is
defined
in
an
xml
variant
and
it
has
dynamic
communication
bindings,
which
are
very
similar
to
dbus,
for
example,
corebar
robot
operating
system
and
the
network
protocol
either
uses
some
ip
or
data
distribution
systems,
or
it
just
uses
locally
a
shared
memory
interface.
E
So
this
is
just
a
quick
overview
of
the
many
modules
which
actually
make
up.
Autos
are
adaptive
and
again,
actually
the
first
letters
of
these
words
are
just
taken
into
an
acronym,
so
all
of
autos
are
adaptive
is
typically
called
error
and
the
most
interesting
part
for
me
is
actually
the
error
com,
which
is
the
dynamic
communication
management.
E
So
we
created
a
working
group
at
the
autozone
consortium
to
work
on
getting
rust
into
autosar
adaptive.
Basically,
and
we
do
have
a
working
demonstration
of
static
bindings,
which
we
just
wrapped
the
c
plus
plus
apis
in
c,
and
then
call
it
from
rust
code
and
for
the
dynamic
bindings.
We
are
currently
working
on
a
demonstrator
and
we
are
defining
the
api.
E
E
So
if
you
actually
bring
software
into
an
automobile,
you
have
to
make
sure
that
the
automotive
bill
is
not
going
to
kill
people
on
the
street.
So
there
is
plenty
of
standards
which
were
created
to
just
avoid
malfunction
and
the
most
prominent
of
that.
One
of
that
is
the
iso
26262,
which
is
a
specialization
of
the
iec
61508
standard
for
automotive.
E
There's
two
standards
which
are
often
cited
in
tandem
with
it
and
one
is
actually
the
so-called
sotif
safety
of
the
intended
function,
and
this
is
about
a
working
system.
So
this
is
not
about
preventing
malfunction
but
about
keeping
up
functioning
systems
and
there's
also
the
cyber
security
standard,
which
is
also
by
s
and
iso.
E
So
there's
a
specific
part
of
that
standard
for
software
and
basically
this
is
about
documentation
of
your
development
process,
documentation
of
your
testing
process,
documentation
of
your
decisions,
so
that
actually,
when
there
is
something
happens
and
you
get
into
a
lawsuit
that
you
are
able
to
actually
verify
and
present
a
material
which
shows
that
you
have
done
your
actually.
What
was
due
and
considered
everything
fine.
E
So
the
previously
mentioned
society
of
automotive
engineers,
which
is
now
called
sae
international.
It
also
hosts
a
task
force
to
create
a
standard
on
how
to
use
rust
in
a
functional,
safe
environment.
E
And
this
task
force
is
active
and
right
now
we
are
actually
contributing
iso
26262
for
use
within
rust,
just
to
the
name
in
sa
international.
It's
a
volunteer
based
organization,
it
has
roughly
400
140k
members
and
since
it
also
created
standards
for
aerospace,
it
renamed
itself
from
society
of
automotive
engineers
to
sae
international.
E
E
Everything
was
helped
with
actually
the
linux
kernel
and
embassy,
so
everything
which
avoids
memory
allocation
helps
a
lot
yeah,
and
I
have
a
personal
proposal
about
how
to
actually
handle
more
explicit
ones,
and
I
would
like
to
actually
hand
over
to
florian
for
the
second
third.
E
F
Thanks
so
keeping
it
short
in
the
interest
of
time,
I
wanted
to
also
quickly
tell
how,
like
this
first
scene,
thing
that
we've
been
talking
about
factors
into
this
and
if
you
skip
ahead.
F
So
what
is
ferrocene
ferrocene
is
a
high
assurances
downstream
of
the
rust
compiler
quality
managed
I'll
talk
about
what
that
is
in
a
second
you'll
have
noticed
that
first
scene
is
closed
source
and
there's
a
number
of
reasons
for
it,
particularly
that
we're
working
on
additional
proprietary
targets,
where
the
whole
discussion
with
how
to
how
is
this
going
to
release
is
going
to
be
upstream
that
all
these
kind
of
things
have
to
be
discussed
with
vendor,
because
there's
multiple
operating
systems
that
are
used
in
the
automotive
market
and
it's
very
common
that
they're
still
all
proprietary
and
considered
protected
information.
F
But
what
is
one
of
the
main
activities
here?
That's
extended
testing
for
specific
configurations
and
in
this
kind
of
setting
a
configuration
is
not
only
this
compiler
on
this
target,
but
also
all
the
flags
that
we're
allowing
users
to
use.
So
we
need
to
check
for
and
to
test
the
compiler's
behavior
with
all
of
those
combinations.
F
So
the
test
matrix
can
become
quite
big
and
probably
infeasible
for
the
upstream
project
and
on
top
of
that,
a
long
term
support
organization,
because
cars
are
driving
around
the
streets
for
quite
long
in
the
term
of
decades,
and
the
car
vendors
want
support
for
that.
You
can
skip
ahead
and
again,
and
so
what
is
quality
management
quality
management
ensures
to
customers
that
they
have
a
good
understanding
of
the
tools
quality.
F
So
it's
not
the
question
of
like
not
only
answering
the
question
of.
Is
this
tool
high
quality,
but
also
why
and
how
do
we
make
sure
that,
for
example,
if
issues
come
up
that
we
inform
you
just,
for
example,
as
an
information
how
that
works?
If
in
the
upstream
compiler
there's
an
issue
popping
up
with
miscompilation
is
not
only
collaborating
on
a
fix,
but
it's
also.
F
How
do
we
make
sure
that
everyone
who
has
been
using
a
compiler
that
might
be
affected
by
this
miscompilation,
where
it
may
introduce
bugs,
is
being
informed
and
that's
basically
the
service,
so
it
gives
a
support
framework
that
allows
informing
customers
and
fixing
issues
fast,
also
means
we
need
to
explain
why
features
are
there
how
they
are
implemented
and
how
they
are
tested?
That
is
a
huge
part
of
what's
called
compiler
qualification,
so
presenting
an
understanding
on
what
the
compiler
does
and
and
yeah
and
how
it's
tested.
F
So
you
need
a
you
need
to
be
able
to
trace
from
requirements
to
testing
similar
as
it
was
discussed
before.
Okay,
you
can
skip
so.
The
question
here
is
like
how
is
the
ferrocene
project
beneficial
to
the
rust
project?
There
has
not
been
a
lot
of
activity
upstream
yet,
but,
for
example,
there's
a
number
of
pull
requests
around
test
suit
improvements,
test
runners.
So,
for
example,
there's
a
lot
of
specific
hardware.
F
I've
posted
on
twitter
a
couple
of
months
ago,
a
picture
of
a
reference
board
for
an
ecu
and
engine
control
unit
and,
for
example,
we
have
finalized
support
for
running
our
test,
harness
on
that
that's
upstreamed
documentation.
We
have
a
major
announcement
in
the
coming
weeks.
We
want
to,
if
possible,
to
upstream
targets
and
for
operating
systems
that
are
in
easily
accessible,
for
example,
that
can
be
quite
interesting
and
what
fixes
for
any
kind
of
problems
found.
F
So
this
is
mainly
a
quality
assurance
project
currently
with
a
very,
very
specific
target,
audience
yeah,
that's
it
for
my
side.
You
want
to
continue.
F
Oh
last
thing
that
I
wanted
to
mention
for
a
lot
of
details
around
this
and
how
this
whole
management
works.
There's
an
interview
on
rust
station
station
that
came
out
last
week
with
quantize
from
our
joint
venture
coordinator
core
and
me
where
we're
going
into
the
detail
of
what
actually
this
kind
of
this
quality
management
idea
means.
E
And
there
is
also
the
video
from
the
rust
format,
verification
group
on
youtube,
which
I
recommend.
E
So
just
to
wrap
it
up,
so
I
can
say:
autosar
is
defect
or
a
standard
operating
system
for
automotive.
So
it's
important
and
you
can
already
use
rust
by
wrapping
the
cc
plus
plus
api.
Also,
it's
not
that
easy
to
do
it
right
now
and
we
consider
rust
suited
for
safety
requirements.
There's
ongoing
work
on
actually
creating
standards.
A
Oh,
my
goodness,
thank
you.
I've
been
talking
for
a
few
seconds
there,
all
right
so
just
just
wrapping
up
here.
Our
next
meeting
date
is
on
june
20th.
We're
going
to
be
figuring
out
what
time
of
day
would
be
best
for
this.
The
theme
is
global,
so,
as
always
submit
any
issues
with
any
suggestions
of
anything
that
could
fit
within
this
theme
and
finally,
we
can
move
over
to
the
social
hour.
A
So
if
you
have
any
questions
for
any
of
the
speakers
or
just
want
to
hang
out
and
chat,
then
definitely
make
sure
to
join
us.
For
that.
We
will
see
you
next
time.