►
Description
Anshul Makkar presents his work on FreeRTOS dynamic Task Upload Iteration 1 Close Out
A
Well,
maybe
not!
Oh
there
we
go
okay,
all
right,
so
I'll.
Just
give
a
little
quick
introduction
about
what
this
is
all
about,
and
then
my
colleague
angel
will
be
able
to
sort
of
give
us
a
little
demo.
Take
us
through
the
open
source
this
this,
this
development
that
he's
been
working
on
for
probably
around
six
months,
part-time
in
his
in
his
in
his
spare
hours.
A
A
You
know
we
very
much
invite
your
input
there
into
what
we're
doing
so
I'll
be
talking
about
what
the
problem
is
that
needed
solving
and
then
anshul's
gonna
take
us
through
the
requirements,
analysis,
design,
demo
and
then
we're
gonna
just
have
a
little
bit
of
time
to
be
able
to
discuss
the
route
to
opening
up
the
repository
to
the
the
wider
community
and
there'll.
Be
an
opportunity
for
any
questions.
A
B
Yeah
I've
been
associated
with
this
project
since
soon
as
paul
mentioned
working
on
this
dynamic
scheduler.
Apart
from
that
I'm
employed
with
oracle.
I
have
around
15
years
of
experience
in
linux,
kernel
and
hypervisor
stuff,
and
my
in
my
other
space
project,
I
am
investigation
investigating
on
debris
mitigation.
That's
the
new
rules
that
fcc
has
framed
around
that
so
my
research
spans
about
propulsion
system
and
how
for
geo
orbit
and
how
we
can
abide
by
debris
mitigation
and
also
doing
some
fpga
development
work,
implementing
ldpc
encoder.
A
That's
that's
what
that's
what
we're
doing,
and
so
this
particular
development
was
all
about
the
needs
that
we
had
to
be
able
to
modify
the
code
that
that
we
have
in
orbit.
So
we've
been
doing
some
requirements
analysis
and
we
identified
sort
of
three
distinct
ways
in
which
we
might
want
to
do
that.
A
Now
the
problem
that
we
have
with
that
method
normally
is
that
the
bandwidth
for
the
upload
to
a
spacecraft
is
quite
slow
and
and
the
opportunities
to
have
the
spacecraft
overhead
are
quite
limited.
So
the
amount
of
time
that
you
have
in
order
to
actually
you
know,
update
software
in
orbit
is,
is
quite
limited
and
it
can
take
a
long
time
to
actually
upload.
A
Okay,
so
we
yeah.
So,
as
I
said
we
identified,
we
love,
we
really
love
freertos,
it's
great.
It's
a
really
good
realtime
operating
system,
and
I've
worked
with
a
few
really
really
like
this
one,
because
it's
so
so
small,
and
so
you
know
it
does
what
it
says
on
the
tin
really
and
the
only
the
only
issue
we
had
with
it
is
really
that
it
doesn't
support
this
kind
of
dynamic
upload
of
code
to
upload
a
task
real
time
as
the
as
the
code
is
running.
A
But
there
are,
you
know,
there's
certainly
parts
of
it
that
do
support
it,
because
the
the
api
x
tasks
create
it
can
be
called
any
point
whether
it's
before
or
after
the
scheduler
has
been
started.
So
there
is
an
opportunity
to
do
it,
certainly,
but
there
is
no
sort
of
support
for
dynamic
linking
of
code,
and
why
is
that
a
problem?
A
Well,
if
you
take
this
example
of
three
different
tasks
running
on
the
spacecraft,
so
three
different
software
tasks,
you
might
have
an
attitude,
control
task
or
a
historical
telemetry
task.
So
these
are.
These
are
bits
of
software
that
are
running
and
they
might
rely
upon
something
that
gathers
data
or
gathers
telemetry.
A
You
know
all
the
time
one
would
be,
for
you
know:
telemetry,
that's
used
for
attitude
control
and
another
one
might
be
for
data
that
you're
collecting
to
be
downloaded
to
the
ground
later
on,
and
so
replacing
this
task
presents
a
problem,
because
these
tasks
have
an
idea
of
where
these
functions
are
that
are
invoked
in
here.
So
if
you
replace
this,
then
that
link
is
destroyed.
You
know
this
this.
B
B
A
B
So
these
all
have
been
covered
by
paul
now
requirement
just
to
briefly
go
through
the
requirements.
Again,
we
don't
want
to
go
through
the
complex
reboot
process.
There
can
be
various
complications
or
various
services
that
need
to
be
restarted,
so
the
best
alternative
is
to
patch
the
system
then,
and
there
without
need,
without
without
rebooting
system
in
linux
systems,
we
have
live,
live
patching
in
ubuntu
and
k,
supplies
in
rel
and
oracle
linux
safely,
update
or
reconfigure
part
of
the
system.
B
Some
bugs
have
bug
fixes
some
bugs
have
been
identified,
or
some
new
feature
needs
to
be
added
on
the
running
system,
so
yeah
we
should
be
able
to
do
that.
It
ensures
long
update
a
long,
uptime
and
up-to-date
software,
so
yeah
these
these
were
the
main
driving
force
and
along
with
what
paul
mentioned.
So
these
are
just
basically
adding
on
to
that.
B
B
C
D
B
E
B
One
of
the
important
design
consideration
is
that
there
should
not
be
any
change
in
free,
torque,
free
rtos
and
that's
what
I've
been
able
to
achieve.
Updatable
applications
should
be
added
as
a
plug-in
component
plug-in
component.
They
should
be
inserted
on
the
fly
whatever
patch
needs
to
be
uploaded
can
be,
it
can
be
uploaded
from
the
earth
station
and
directly
to
the
memory
of
the
system
or
or
system
at
the
spacecraft
and
from
there
the
the
new
patch
can
be.
B
The
new
patch
can
replace
the
old
patch
and
system
binary
should
be
able
to
link
with
the
latest
patch
that
has
been
uploaded,
minimal
performance,
overhead
and
basically
yeah.
That's
very
important.
There
should
be
minimum
performance
overhead
if
you
want
to
replace
old
patch
with
a
new
patch.
So
that's
again
has
been
taken
into
consideration
and
I
have
how
I
have
implemented.
The
solution
is
basically,
I
have
divided
the
solution
into
various
components
like
we
use
elf
binary.
B
B
So,
just
to
give
a
basic
overview
of
how
the
code
flows
will
help
you
to
understand
the
solution
at
a
broad
level,
and
then
we
can
go
into
much
more
details
and
I
can
show
you
the
demo.
So,
as
I
mentioned,
there
is
a
system
binary
and
an
application
binary.
I
have
considered
them
as
in
elf
format.
It's
a
compatible
with
three
32-bit
systems,
so
elf,
binary
is
inserted
into
the
memory
from
a
given
source
system.
Binary
and
application.
Binaries
are
compiled,
converted
to
an
elf
format
and
loaded
into
the
memory.
B
The
system
system
or
the
system
binary
recognizes
all
the
tasks
and
the
entry
points,
while
inside
the
elf
binary.
I
will
give
you
the.
I
will
show
you
the
code
snippets,
how
we
can
do
that,
or
I
will
show
you
now,
so
it
will
be
good
so
that
you
get
an
idea.
What
exactly
I'm
talking
about
so
this
application.ld,
it's
the
linker
script.
Now
this
is
the
main
linker
script
qmu.ld.
This
is
the
main
linker
script
and
it's
linking
application.
B
B
The
newly
created
task
can
now
be
inserted
into
free
task,
free
rtos
scheduling
list.
That's
what
I
mentioned
now.
The
task
can
use
all
the
kernel
resources
and
behave
as
a
normal
executing
task
as
if
it
has
been
loaded
statically.
It
doesn't
make
any
difference
now
to
it.
Now,
it's
under
the
control
of
vrtos,
with
dynamic
linking
tasks
can
be
externally
compiled
inserted
into
the
running
system
from
external
sources.
B
Design
and
implementation
elf
binary,
as
I
mentioned,
application
binary
elf
format,
I'm
using
two
system,
it's
two
types
system,
binaries
and
application,
binaries
that
I
will
be
using
now.
When
I
talk
about
system,
it
consists
of
following
components:
it's
basically
a
layer
above
free
rtos,
so
and
it
contains
the
following
components:
memory
allocator:
before
handing
off
the
task
to
free
out
or
scheduler
one.
B
The
system
is
a
responsible
system
or
system
binary
is
responsible
to
allocate,
as
I
mentioned,
a
system
binary
will
will
pass
the
elf
application
binary
it
will
allocate.
It
will
find
out
what
all
things
needs,
allocation
stack
heap
or
any
dynamic
allocation.
It
allocates
all
these
all
these
components
of
that
elf
application
binary.
B
Then
it
links
allocated
tasks
or
the
application
binaries,
which
is
which
it
has
loaded
to
the
main
system
binary
so
that
all
the
whatever
symbol,
resolutions
or
whatever
is
needed
it.
It
does
that
and
then
it
starts.
The
task
attaches
itself
to
the
free
rtos
scheduler
by
calling
x
task
create
and
then
once
the
task
ends
it
detaches
itself.
B
B
B
Now
the
system
startup
process,
how
the
system
boots
up
at
boot
time
system
binary,
that's
free,
rtos
and
system
code
system
code
includes
task
manager
which
I
described.
It
includes
memory,
allocator,
linker
system
application,
startup,
all
those
components
are
part
of
system
code
and
free
rtos
is
also
part
of
system
codes
at
boot
time.
So
this
loads
and
execution
starts
then
at
runtime
system
loads
and
starts
all
the
application
from
the
application
binaries.
It
happens
at
the
runtime
application.
Binaries
are
linked
to
the
system,
binaries
and
other
application.
B
B
I
won't
go
into
details
of
all
this,
but
yeah
so
yeah,
now
a
small
demo
before
going
to
the
demo
I
want
to.
I
want
to
share
that.
This
is
the
work
that
has
been
done.
My
demo
covers
that,
so
it
once
I
show
you
the
demo,
there
will
be
one
task
which
is
statically
linked
to
the
main
process
and
one
task
which
is
dynamically
linked
and
both
will
be
executing
simultaneously
going
through
the
code.
B
B
B
Here
it
passes
this
simple
simple.c
is
the
application
binary?
It's
it's
the
separate
task
which
will
print
simplest,
started,
imr,
dynamic,
simple,
it's
compiled
independently
in
make
file.
I
have
two
targets:
one
is
for
the
main
system
and
one
is
for
the
application
separate
targets
independent
of
each
other.
B
B
B
B
B
B
And
here
it
prints
and
dynamic
simple,
I
am
static,
simple,
so
yeah,
dynamic,
simple
is
the
dynamic
task
that
gets
that
has
been
linked.
Dynamically
and
static
task
is
the
static
func
static
task.
That's
directly
called
from
the
main
function
both
are
executing
simultaneously
coming
back
to
the
ppt.
B
B
So
what
are
the
risks
unknown
so
right
now
I
I
don't
have
exactly
the
performance
impact
data,
but
as
per
the
research
paper
that
I
am
following
based
on
which
I
have
framed
my
solution.
Performance
impact
should
be
minimum,
but
I
will
have
better
numbers
one
once
I
have
the
complete
demo
for
task
replacement
so
how
much
time
it
takes
to
replace
the
task.
I
still
again,
I
don't
have
the
numbers
for
that
complexity,
memory
and
the
instruction
footprint
of
the
task.
B
B
If
it's
a
multi-core
system,
then
I
need
to
take
into
consideration
how
the
memory
is
shared
and
how
how
the
what's
the
state
of
caches.
So
it
will
involve
extra,
complex
complexity,
so
right
now,
that
thing
has
not
been
considered
now
so
this
up
till
this
point,
I
have
been
able
to
execute
static
and
dynamically
linked
task
now.
My
next
aim
here
is
to
simply
modify
this
dynamically
linked
task
and
replace
this
message.
I
am
dynamic,
simple
with
something
else.
B
B
One
of
them
will
be
migrator.
It
will
be
responsible
for
migration
of
task
pointer,
tracer,
a
pointer
tracer
will
be.
It
will
build
a
memory
layout
in
a
form
of
directed
graph
to
keep
track
of
what
all
pointers
and
what
are
what
all
pointers
are
pointing
to
what
all
memory
objects,
because
you'll
be
using
pointers
and
memory
variables.
Dynamically
allocated
memory
area
memory
variables
in
your
code,
so
pointer
tracer,
will
be
the
component
that
will
keep
track
of
of
where
the
pointers
lead
to
objects
in
the
memory
dwarf.
B
If
drawfift
is,
I
will
use
the
drop
if
it's
the
debug
library
that
I
will
use
to
provide
type
information
so
as
to
get
the
type
of
the
pointer
or
the
memory
object.
That's
in
the
memory,
so
these
additional
components
will
be
needed,
so
how
how
how
task
replacement
will
happen
once
I
have
this
solution,
so
same
state
application,
binary
will
load,
it
will
be
an
inconsistent
state.
B
I
will
define
a
check
pointable
state,
every
task
that
executes
it,
has
a
task
state
associated
with
it.
So
I
need
to
define
a
state
where
it
can
be
updated
and
I'm
calling
it
as
check
pointable
state
and
the
state
in
which
it
can't
be
updated.
That's
let's
call
it
as
a
dirty
state.
Suppose
a
task
is
doing
some
ipc
calls
or
interacting
with
some
hardware.
Now
that's
a
dirty
state.
B
B
Suspend
the
original
task
allocate
the
updated
task,
link
the
updated
task
and
then
copy
the
memory
areas
or
whatever.
It
is
basically
copy
the
task
state
from
the
new
patch
to
to
the
old
task
and
link
the
new
task
and
start
execution
of
the
new
task.
So
that's
how
the
code
flow
will
look
like
in
once.
This
task
replacement
has
been
implemented
so
in
a
simple
step:
migration
process
step
code
v1.
This
is
the
task
task
code
code,
v1
v1,
and
then
it
goes
to
v2
how
it
goes.
B
Similarly
for
task
data
task
state
wave,
one
task:
state,
v1,
then
cpos
cpu
is
a
check.
Pointable
object,
so
we
create
a
checkpointable
object
or
checkpointable.
We
create
a
checkpointable
object
from
a
checkpointable
state
and
then
from
there
we
merge
onto
the
next
v2
state
again.
This
is
this
is
the
next
step.
I
will
give
a
more
detailed
demo
once
I
have
achieved
this
task
replacement
so
that
then
I
will
go
into
much
more
details
of
how
these
steps
are
executing.
B
Right
now
again,
it's
an
implementation
detail,
so
we
can
play
around
that.
I
don't
see
any
harm
in
both
the
approaches
except
from
the
memory
footprint.
But
yes,
we
can,
we
can
grow
or
we
can
go
with
the
approach
where
it
creates
data
check
pointable
object,
even
if
it
is
not
supposed
to
migrate
just
for
the
first
phase
and
then
later
on.
We
can
change
on
that,
but
yeah,
it's
just
an
implementation
detail.
Both
approaches
are
fine.
B
A
All
right,
yeah,
I
think
I
don't
see
a
great
deal
of
issue
with
that
at
the
moment.
This
is
all
in
a
in
a
private
repository,
but
certainly
this
video
we
can
publish
for
anybody
that
wants
to
see
and
and
we'll
send
it
to
yourself.
I
I
probably
need
your
email
address
actually,
but
send
it
to
yourself
and
and
richard
as
well,
so
you
you
could
have
a
look
at
what
we've
been
talking
about,
but
of
what
you
did
see.
F
A
Yeah,
no,
no
problem,
it's
great
great,
to
meet
you,
though,
and
yeah
very
good
to
to
have
you.
You
know.
If
you
know,
if
you
could
have
a
look
at
what
anshul's
been
doing,
then
you
know
it
would
be
really
really
helpful
to
get
your
sort
of
feedback
any
words
of
wisdom,
or
you
know
anything
that
might
help
us
along
the
way,
because
obviously,
you've
got
a
lot
more
in-depth
knowledge
of
friata's
than
than
we
do
so.
F
E
B
Yeah
again
in
the
challenging
problems
where,
while
I
was
designing-
and
I
was
thinking
about
all
these
points-
so
one
other
thing
was
like-
we
don't
need
to
modify
the
free
rtos
and
how
we
can
and
how
I
can
carry
out
task
replacement
without
modifying
the
the
free
autos
code.
So
I
have
to
go
through
various
research
papers
and
then
considering
reading
the
theory
and
converting
them
to
practically
practical
code.
B
That
was
the
challenge
point
and
how
how
how
I
can
structure
the
code
and
and
then
like
I,
I
said
that
there
is
a
layer
above
free
rtos
that
through
and
where
the
layer
of
a
free
rtos
is
completely
responsible
for
managing
the
application,
binaries
and
then
passing
on
once
it
has
control
of
all
the
allocations
of
that
application.
Binary
stacks
heaps,
everything
of
that
application,
binary
and
then
passing
on
to
free
rtos.
So
reaching
to
that
point,
was
the
main
challenging
point
so
designing
the
solution,
how
it
can
be
done.
B
B
I
have
integrated
that
into
one
layer
and
there
are
application
binaries
which
are
compiled
independently.
So
what
my
system
does
is
that
it
it
it
loads
the
application
binary
dynamically
at
runtime
in
an
elf
format.
Parses,
it
passes
its
elf
format,
allocates
all
the
memory
area
like
all
the
dynamic
allocation,
stacks
queues
registers,
it's
and
basically
after
allocation
in
broad
level
it
it's
it's
it
executes
that
task.
B
It
calls
x
task
scheduler
will,
with
the
allocated
area
it
has
allocated
for
the
task
and
calls
x
task
scheduler
for
x
task
create
for
that
task.
So
after
that
free
rtos
has
full
control
of
the
task
and
everything
when
I
want
to
since,
since
my
main
system,
binary
has
allocated
all
the
data
for
that
application.
Binary
system
binary
is
aware
of
where
all
the
sections
reside
and
whenever
new
task
or
whenever
the
replacement
task
comes,
it's
able
to
replace
those
memory
areas
with
the
content
of
the
new
task.
F
D
C
So
one
of
the
approaches
when
I,
when
I
was
trying
this
in
one
of
our
hackathons,
was
like,
I
partitioned
the
flash
for
every
component.
So
when
you
can
say
is
like
free,
our
task
kernel
itself
will
reside
in
a
partition
of
flash
and
the
ram
for
that
partition
is
fixed.
The
same
is
for
every
other
component.
What
I
was
calling
which
could
be
comprising
of
multiple
tasks
or
less
or
like
one
task
doesn't
matter.
Then
there
is
one
loader
component,
which
is
where
the
system
boots
into.
C
It
knows
all
the
locations
of
every
component,
and
then
there
is
a
specifically
designed
binary
header,
which
resides
at
the
beginning
of
the
component,
which
tells
the
functions
which
are
exported
from
that
component
and
the
inter
the
vector,
interrupt
handlers.
That
component
wants
to
install
and
basically
just
start.
It
just
fills
up
the
function,
pointers
table
and
any
component
when
wants
to
call
a
function
in
any
other
component,
will
have
to
go
through
the
the
loader,
which
knows
the
location
of
that
function
and
then
route
the
function
call.
So
that's
basically
any
function.
A
B
D
F
F
So
on
on
the
m7,
the
memory
protection
unit
is
a
little
bit
coarse.
Should
you
say
it's
the
way
that
you
can
partition
up.
The
memory
is
not
not
that
useful
should
we
say,
because,
because
of
the
restrictions
in
the
memory
section
sizes
and
the
start
addresses,
and
that
kind
of
thing,
but
move
it
on
to
an
arm
v8
and
like
a
cortex
m33,
I
think
there's
a
lot
more
flexibility
where
we
could
potentially
do
what
we
kind
of
call.
F
You
know
putting
tasks
within
padded
cells,
as
we
say,
all
kind
of
firewalling
the
tasks
from
each
other,
and
that
way
we
can
kind
of
protect
the
make
sure
that
the
kernel
remains
protected.
So
we
can
kind
of
dynamically
link
application
code.
If
you
think,
let
me
step
back
a
little
bit
the
reason
I
say
it
changes
the
threat
model.
So
much
is
that
at
the
moment,
most
of
our
applications
are
statically
linked
and
if
we
have,
you
know
a
signed
image
and
we
we
prevent
anybody
executing
from
ram.
F
As
soon
as
we
start
dynamically
linking
then
because
we
don't
have
that
signature
up
front
or
we
don't,
we
don't
know
in
advance
what
it
is
that
the
code
is
going
to
be
running.
Then
we
have
to
take
a
lot
more
precautions
with
it
and,
of
course
we
can
sign.
You
know,
sign
images
that
are
being
dynamically
linked
as
well,
but
that
then
becomes
a
little
bit
more
restrictive.
F
A
Yeah,
I
think,
that's
that's
quite
a
broad
area
of
interest
for
us
ourselves
as
well
and
and
what
we're
finding
out
you
know
through
the
research
that
we're
putting
in
to
gather
the
requirements
together
for
the
open
source
satellite.
Is
that
really
you
know
security
is
in
its
infancy,
particularly
in
the
space
industry.
A
F
B
This
from
the
from
this
security
perspective,
and
when
we
talked
about
this
checkpoint
will
state
checkpoint
table
state
is
memory
allocation
of
a
task
state
now
for
considering
from
security
perspective,
it's
quite
possible
that
the
checkpointable
object
or
the
state
that
that
we
create
we
can
create
that
can
be
only
of
sub.
That
can
be
only
that
can
be
the
subset
of
the
main
task
state
after
we
have
taken
security
into.
B
F
B
A
A
Yeah,
in
parallel
with
this
we're
trying
to
get
a
qemu
implementation
running
specifically
for
the
for
the
processor
that
we're
that
we're
choosing
so
yeah
we're
working
on
that
and
I've
started
taking
apart
the
mps2
qemu
model
in
order
to
try
and
repurpose
it
for
an
st,
an
stm32
processor.
That's
an
m7.
A
D
A
You
had
a
look
at
those
yeah
and
don't
think
they
have
an
m7.
So
that's
why
I've
had
to
kind
of
fudge.
Things
together
take
take
qemu
version.
Five,
I
think
that's
when
they
introduced
m7
and
then
taken
some
of
the
code
from
the
x-pac
and
then
try
to
port
it
in
in
so
that
I
can
use
the
m7
instruction
set
over
qmu.
F
Yeah,
so
the
the
m7
is
an
interesting
part
in
that
the
the
arm,
v7m
spec,
as
as
provided
by
arm,
was
never
really
implemented
fully.
I
mean
it
was
always
backwards
compatible,
but
the
m3
and
m4.
If
you
look
at
the
m3
and
m4
friata's
ports
historically,
there's
a
lot
fewer
kind
of
memory,
barriers
and.
F
Data
barriers
in
there
when
the
m7
came
out,
it
actually
implemented
the
spec
a
lot
more
fully.
I
mean
there's
nothing
wrong
with
the
m4
and
the
m3
one.
You
know
they
were
just
a
subset
when
it
comes
to
the
m7,
then
what
we
actually
did
was
update
the
m4
port
to
be
more
fully
compliant
with
the
spec,
because
the
m7s
were
the
first
chips
that
actually
needed
it.
So
I'm
just
wondering
how
that
would
impact
the
qemu
model
as
well,
so.
F
A
So
a
group
of
professionals
who've
been
involved
with
trying
to
change
the
economics
of
space
over
a
number
of
years,
and
so
this
is
kind
of
our
latest
attempt
to.
You
know
bring
about
a
shift
in
the
industry,
and
so
we
looked
at
it
and
said
well,
it
would
be
great
if
we
could
create
something,
that's
more
capable
than
what's
known
as
a
cubesat.
I
don't
know
if
you've
come
across
those
things,
particularly
yes,.
A
A
So
that's
what
we're
trying
to
do
so
we're
trying
in
doing
that
we're
trying
to
sort
of
encompass
a
lot
of
open
source
technology,
but
also
you
know
not
only
encompass
it
as
in
use
it,
but
also
give
out
open
source
as
well.
So
all
of
our
design
would
be
put
out
open
source,
and
at
the
moment
we
have
some.
You
know,
repositories
on
on
github,
and
the
hope
is
that
this
would
be
actually
the
very
first
thing
that
we
put
out
into
to
make
a
public
repository.
A
So
I
think
at
the
moment
it
you
know
it
would
be
we've.
You
know
essentially
got
a
got
a
prototype,
but
I
think
it,
regardless
of
its
state
as
a
prototype.
It
would
be
interesting
to
sort
of
make
it
public
and
and
and
get
people's
view
on
it,
and
also,
you
know,
hopefully
pick
up
some
more
collaborators
along
the
way
as
well.
F
Yeah
yeah:
well,
definitely,
you
know,
keep
us
in
the
loop
on
what
you're
you
are
doing.
I
mean
it
would
be
good
to
you
know
once
this
once
is
kind
of
published,
perhaps
write
a
little
bit
about
it
on
on
the
friata's
website,
and
these
kind
of
interesting,
interesting
projects
that
find
out
about
accidentally.
F
E
We
were
thinking
about
maybe
running
some
kind
of
poll
over
linkedin,
because
we've
got,
I
don't
know,
maybe
800
followers.
I
think,
on
on
linkedin
running
some
kind
of
poll
with
to
ask
that
question.
You
know
who's
who's
got
any
experience
of
using
free
artists
for
space
who's
actually
implemented
it.
You
know,
what's
your
experience
and
try
and
you
know
get
a
an
understanding
of
of
where
it's,
where
it's
landing
and
who's
using
it,
and
you
know,
build
build
that
community
and
use
that
to
share
share
information
about
how
we're
making
it
robust
for
space.
F
Yeah
and
that's
that's
particularly
interesting-
there
are
the
robustness,
so
this
is
an
area
we
are
focusing
quite
a
lot
on
at
the
moment,
so
grav
graf
who's
on
the
call
he's
our
our
main
guy
on
the
arm.
V810
stuff
and
he's
he's
made
some
improvements
to
the
v7
m
code
as
well
as
far
as
more
security.
So
the
original
mpu
port
was
more
safety
focused
than
security
focus.
So
graphs
made
some
improvements
from
a
security
perspective,
but
we
are
also
doing
memory,
safety,
proofs
and
some
other
kind
of
algorithmic
proofs.
F
So
the
queue
mechanism,
for
example,
has
undergone
some
thread:
safety
and
memory
safety
proofs,
so
the
as
far
as
the
the
kind
of
robustness
goes.
Then
you
know
we're
really
kind
of
trying
to
beef
that
up
a
bit
with
some
form.
You
know
formal
methods,
so
I'd
I'd
also
be
again
interested
in
in
you
know,
looking
at
what
you
guys
were
doing,
and
maybe
even
kind
of
sharing
ideas
on
on
this
kind
of
provable
robustness
as
well.
A
Yeah,
definitely
absolutely
that
sounds
really
good
guys.
I
think
there's
probably
some
things
that
you
know.
I
think
the
plan
going
forward
for
this
development.
You
talked
about
you
know
going
to
the
next
stage,
which
is
the
migration
of
one
task
to
you
know
and
the
next
one,
which
I
guess
is
the
sort
of
natural
next
step.
It
sounds
like
we
probably
you
know,
want
to
sort
of
look
at
either
demoing
it
on
some
real
hardware
or
on
a
qemu
m7
model
or
both.
A
So
you
know
just
adding
you
know,
licensing
information
to
the
repository
and
the
and
the
code
and
that
kind
of
thing,
and
then
I
think,
we're
probably
good
to
you
know,
put
it
out
there.
I'm
also
wondering
whether
we
should
maybe
use
some
of
the
the
features
on
github
to
allow
us
to
kind
of
publicize.
A
You
know
various
bits
and
pieces
that
we
might
want
developed
along
the
way
as
well.
I
don't
know
angela.
If
this
is
your
baby,
and
you
know
I
don't
want
to-
I
don't
want
to
sort
of
suggest
that
other
people
should
get
involved.
Unless
you
know
if
you've
got
the
time
and
you've
got
the
inclination
and
energy
to
sort
of
crack
on
through,
then
you
know,
you've
done
a
good
job
so
far,
so
yeah
do
you
want
to
carry
on
like
that?
Or
would
you
like
some
help?
No.
B
A
Okay,
okay,
okay!
Well,
I
I
think
that
yeah
there's,
probably
a
few
actions
which
I
won't
bore.
Everybody
with
you
know
to
sort
of
open
up
the
repository.
What
I'll
do
richard
I'll
get
that
and
the
recording
to
you?
I've
got
your
email
address,
I'm
not
sure
your
colleague,
I
don't
know
if
I
have
the
the
the
information
to
get
the
video
to
him,
but
but
we'll
we'll
get
it
to
you
somehow.
F
It
would
be
good
if,
when
you
send
it,
if
you
could
provide
everyone's
email
addresses
as
well
and
then
you've
got
mine
and
you've
got
garage,
but
I'll
reply
to
that
email
with
obviously
myself.
My
own
email
will
be
next
I'll,
be
replying,
but
with
grabs
in
there
as
well,
and
then
everybody's
got
everyone's
email
address.
A
A
Well,
I
think
I
think
that's
kind
of
that
kind
of
marks
the
end
of
this
kind
of
part
of
the
development
really-
and
I
just
want
to
say
thank
you
very,
very
much
angel
for
you
know
dedicating
your
time.
You
know
in
your
spare
time.
You
know.
Writing
this
stuff,
and
I've
been
very
impressed
with
what
you've
managed
to
achieve,
and
certainly
I
didn't
want
to
take
it
on
which
is
which
is
what
I
thought.
A
It
sounds
like
a
nasty
job
for
someone
who
is
probably
better
at
it
than
me.
So
no.
I
really
appreciate
that
and
yeah
great
to
have
you
as
involved
as
well
richard
and-
and
you
know,
people
from
friata's
really
very
much
very
much
enjoy
having
you
involved
and
found
it
very,
very
good
to
to
be
working
on
free
artists,
having
used
lots
of
different
operating
systems
and
real-time
operating
systems.
This
one's
a
good
one,
so
yeah
very
much
appreciate
your
your
efforts
over
the
years,
putting
it
together.