►
Description
Scheduler for dynamic patching of task. It's based over FreeRTOS and it helps the user to dynamically update / patch the task without the need for system reboot.
A
A
A
So
so
yeah,
so
we've
got
a
little
little
presentation
here.
I
wonder
if
I
can
get
rid
of
that
yeah,
that's
better
a
little
presentation
here
that
just
goes
through
what
problem
needs
to
be
solved,
so
this
is
just
a
reminder
for
those
that
maybe
are
new
to
this.
This
development
that
we've
been
undertaking
over
probably
since
june
last
year,
so
sort
of
sort
of
thing.
A
So
this
is
a
kind
of
actual
in
his
in
his
spare
time,
giving
up
his
time
to
sort
of
try
and
further
this
work.
So
I'll
just
describe
what
problem
he's
trying
to
solve.
There's
a
little
bit
about
requirements:
analysis
where
we
are
in
the
project.
What
we're
trying
to
do
angel's
then
going
to
give
us
a
little
demo
and
then
there's
a
there's,
a
sort
of
open
time
for
questions
and
we'll
then
discuss
the
next
steps
on
the
project.
A
But
what
I
will
say
is
ansel
is
a
very
as
as
all
very
you
know,
intelligent
and
clever
people.
We
have
a
tendency
and
I'll
say
we,
because
I
include
myself
in
that
category
yeah,
I
know
yeah,
but
we
we
have
a
tendency
to.
You
know
dive
into
the
you
know
the
ones
and
zeros
quite
quickly
and
what
I
want
to
encourage
everybody
on
the
call.
A
If
you
don't
understand
something,
please
ask
there
and
then
don't
leave
it
just
you
know
this
is
kind
of
a
you
know,
we're
inviting
for
people
to
try
and
understand
what's
being
presented
rather
than
kind
of
go.
I
understood
it
up
to
a
certain
point
and
now
I'm
lost
but
not
saying
anything
if
that
makes
sense.
So
if
everybody's
comfortable
with
that.
A
Directing
everybody,
no,
I
mean
and
you're
very
capable
as
well.
You
know,
I
put
you
in
that
same
category,
I'm
just
I'm
just
aware
that
you
know
you're,
not
a
you
know
a
software
engineer
in
the
same
sense,
but
so
yeah.
Here
we
go
so
intros
you.
You
probably
know
this.
I
think
most
people
on
the
call
so
anshul
is
currently
working
for
oracle.
A
B
A
A
I
am
so
I'm
just
someone
who's
trying
to
organize
open
source
software
collaborations,
so
work
started
in
july,
2020
part
of
the
open
source
satellite
program,
so
everything
that's
being
developed,
will
go
open
source
and
we're
hoping
to
do
that
very
soon.
But
you
know
before
we
get
to
that
point.
Let's
talk
about
the
problem,
so
we
need
to
be
able
to
modify
code
in
orbit
and
typically,
the
way
this
has
been
done
in
the
past,
with
certain
technologies
is
to
upload
small
patches
of
software.
A
A
So
that's
kind
of
you
know
it
takes
a
little
bit
more
bandwidth
to
get
the
the
data
up
to
the
spacecraft
and
there's
there's
associated
risks
with
you
know,
swapping
out
tasks
in
that
manner,
but
the
more
sort
of
kind
of
safer,
but
also
problematic
way
of
doing
things
is
to
do
a
full-time
image
replacement.
So
that's
where
you've
got
one
image
of
you
know
one
bunch
of
ones
and
zeroes,
which
makes
up
your
program,
and
now
you
want
to
switch
to
a
different
set
of
ones
and
zeros.
A
A
It's
got
a
shortfall
in
the
sense
that
it
it
doesn't
really
support
this
kind
of
functionality
to
be
able
to
replace
a
task
at
runtime
it
doesn't
it
it
kind
of
does,
because
it
has
this.
This
api
call
called
x
task,
create,
which
can
be
called
any
point.
So
you
could,
you
know,
create
a
task
at
any
point,
the
problem
being
that
you
need
to
be
able
to
link
dynamically
the
uploaded
thing
that
you're
uploading
to
the
already
existing
software
and
that's
the
tricky
bit.
A
So
the
tricky
case
is
kind
of
illustrated
here.
Let's
say,
you've
got
a
aocs
task
and
you
have
another
task
over
here:
gathering
historical
telemetry
and
both
of
them
make
an
api
call
to
fetch,
telemetry
and
they're
fetching
that
telemetry
from
this
task.
This
telemetry
server
task,
but
you
know
you've
got
a
bug
in
here
that
you
need
to
fix.
So
you
need
to
replace
this
this
task
and
the
problem
with
doing
so
is
that
these
links
that
you
know
this.
A
A
The
the
project
to
date
has
we've
done
an
iteration
one,
which
was
completed
in
february
2021.
We
ran
two
different
elf
files,
so
just
so
you
know,
an
l
file
is
like
an
executable
sort
of
it's.
It's
it's
a
format
of
a
file
which
describes
where
the
functions
and
the
the
the
software
functions
are
going
to
be
located
and
it's
typically
the
output
from
the
compiler
and
the
linker
and
normally
what
you
do
well.
Normally,
if
you,
if
you
have
like
a
free,
rtos
distribution,
you
only
have
one
elf
file.
A
So
you
know
you
build
all
of
the
code
into
one
lump,
which
is
one
l
file.
Now
that
poses
a
problem
because
we
want
to
be
able
to
upload
more
than
one
thing.
So
we
wanted
to
demonstrate
the
you
know,
working
with
two
l
files,
so
one
with
one
lot
of
code
and
one
with
another
bit
of
code
and
then
kind
of
mashing
them
together
on
on
something
representative
to
demonstrate
that
that's
possible
with
freeattas
running
as
well.
A
A
And
then
there's
iteration
two
which
hopefully
we're
going
to
complete
today.
So
that's
running
one
execute
executable
task
on
target,
which
is
software,
including
free
rtos.
So
it's
quite
a
lump
of
software.
You
know
including
free
art,
ours
and
lots
of
bits,
and
then
we
then
anshul's
going
to
demonstrate
the
upload
via
uart
of
an
elf
file.
A
A
The
only
thing
that
we
haven't
done
so
far
is
to
make
that
that
open
source,
so
we
haven't
got
to
that
stage.
Yet
we
have
everything
in
a
private
github
repository
and,
as
you
might
know,
we've
also
engaged
with
richard
barry
along
the
way,
who
is
the
author
of
friatas,
who
seem
quite
interested
in
what
we're
doing
he's
gone
quite
quiet,
since
we
did
our
first
demo,
which
is
a
bit
of
a
shame.
So
I
think
maybe
one
of
the
actions
is
to
try
and
follow
up
with
him.
C
How
does
that
work
with
our
free
rtops?
Because,
obviously,
is
there
somebody
who
owned,
who,
who
basically
looks
after
free
rtots
and
only
lets
in
things
that
they're
happy
with,
because
obviously
you're
then
releasing
this
that
works
with
free
articles?
How
does
just
do
they
have
to
sign
off
on
this,
or
can
you
just
release
it,
and
and
people
can
use
it
with
free
assets
if
they
want
to.
A
Well,
it's
it's
completely.
It
works
without
modifications
to
friata's,
so
it's
it's
kind
of
standalone
bit
of
code,
and
so
we
could
release
it
under
our
own
banner.
You
know
without
really
affecting
friatos,
but
richard
barry
has
an
interest
in
it
and
may
want
to
in
some
way
incorporate
aspects
of
it
more.
You
know
into
friata
as
as
a
thing
if
you
get
the
meaning
yeah.
So
that's
that's
a
good
reason
to
to
talk
to
him
plus.
Obviously
he
has
got
a
lot
of
contacts
in
the
embedded
industry
as
well.
A
A
Yeah,
so
it
just
me,
it
means
what
it
kind
of
sounds
like
it
means
it
it
it's
basically
just
both
tasks
running
simultaneously,
so
they're
actually
separated
that
you
know
when
we
say
replacement.
What
we
mean
is
we're
uploading,
a
replacement
task
to
a
different
location
of
memory,
so
it
doesn't
mean
that
the
other
one
disappears.
It's
still
there.
C
C
A
Yeah
yeah
well,
yeah
I
mean
as
it
stands.
They
can
use
resources
simultaneously.
They
can
do
things
independently,
so
in
in
the
case
of
a
ao,
let's
say
we
were
to
make
this
a
real
sort
of
you
know,
take
it
to
the
to
a
real
situation
where
we
have
an
aocs
task
and
we
want
to
replace
it.
We
probably
wouldn't
do
this,
which
is
to
to
run
them
simultaneously
for
a
time
and
then
replace
one
with
the
other.
A
B
A
A
Yeah,
that's
right
it
just
kind
of.
As
you
see
the
demo,
it
probably
helps
you
to
understand.
What's
going
on
a
little
bit
better,
if,
if
you
have
that
point
three
in
there,
so
it's
really
more
for
a
demo
purpose,
really,
okay,
so
yeah!
So
I
think
at
that
point
I
will
hand
over
to
anshul
I'll
stop
sharing
my
screen.
B
A
B
D
B
B
B
So
design
consideration,
as
I
mentioned,
small
footprint
and
program
memory,
that
should
be
there.
Another
thing
is
that
free
rtos,
it's
quite
a
huge
monolithic
blob,
so
that
has
to
be
separate
from
the
application
binaries
or
the
tasks
that
we
will
be
uploading
from
the
ground
station.
So
those
have
to
be
completely
different
part.
Otherwise
the
whole
purpose
is
lost.
A
B
Those
tasks
should
start
executing,
so
it
should
be
kind
of
plug-in
architecture.
That
was
my
design
consideration
again.
Another
important
aspect
was
no.
Changes
should
be
made
on
free
rtos,
so
whatever
I
have
to
do,
it
has
to
be
based
on
top
of
free
order.
So
that's
what
again
I
have
taken
care
and
then
again
minimum
performance
overhead,
and
I
I
do.
I
divide
free
outdoors
and
my
solution
into
different
components.
B
So
this
is
an
implementation
overview.
Just
to
give
you
a
high
level
overview,
so
application
binaries
are
compiled
independently
from
the
system.
Binaries
application
binaries
are
position
independent
and
relocate.
Well,
it's
a
software
term,
but
it
helps
to
place
the
binaries
in
whatever
memory
location.
I
want
on
the
card.
Yeah.
C
A
Yeah,
so
I
think
from
from
our
perspective,
what
we
need
to
do
is
identify
those
components
which
are
likely
to
require
changing
you
know
and
then
separate
them
architecturally
into
different
compilable
artifacts,
so
that
we,
you
know
the
obvious
one
is
aocs,
isn't
it
there?
There
will
be
others
as
well,
some
payload
stuff,
perhaps-
and
maybe
even
some-
you
know
service
layer,
things
like
telemetry
capturing
and
things
like
that.
So
there's
yeah.
A
C
Something
that
is
a
a
bigger
elf
file
that
consists
of
several
things.
Several
tasks
you'd
have
to
upload
that
entire
alpha,
because
you,
you
know,
I'm
just
thinking
two
years
into
a
mission,
you
might
suddenly
find
a
bug.
I
know
you
know.
Sometimes
you
do
find
you
know,
because
you
just
happen
to
end
up
in
a
place
where
you
didn't
expect
to,
and
so
on,
something
that
you
consider
robust
and
heritage.
You
might
still
need
to
make
a
a
mod
yeah.
A
C
A
Yeah-
and
I
think
it's
worth
pointing
out
that
if,
if
that
were
to
be,
let's
say
that
that
that
bug
was
found-
let's
say
even
in
the
free
artist
operating
system
and
we
need
to
make
a
change
there.
I
would
imagine
the
and
correct
me
where
I'm,
if
I'm
wrong
here
anshul,
but
my
feeling
is
we
probably
have
to
then
you
know,
revert
back
to
uploading
everything.
You
know
yes,
rather
than
trying
to
patch
a
particular
task
on
top
of
friatos.
A
C
B
That's
the
whole
intention
yeah
so,
and
it's
if
you
want,
if
you
think
that
some
of
the
binaries
are
quite
stable
enough
and
they
are,
they
should
be
part
of
the
system.
Then
you
can
make.
Then
you
can
compile
them
along
with
free
outdoors.
So
you
have
that
flexibility.
Also,
then
they
will
be
as
part
of
free
autos
and
others
can
be
loaded
independently.
B
B
Then
the
application
binary
execution
start
then
next
step.
If
you
want
to
upload
any
application,
v1
binary,
then
it's
uploaded
from
the
ground
station.
The
app
v1
is
registered,
allocated
and
link.
Then
task
state
of
app.
The
old
binary
is
transferred
to
app
v1.
Then
the
old
app
is
halted
and
app.
V1
starts
so
yeah.
B
B
B
B
So
I
wanted
to
control
all
the
aspects
of
this
binary
because
it's
quite
critical
path
and
that's
why
I
went
for
elf
binary
and
now
what
all
things
all
the
things
that
os
does
within
elf
binary.
Now
my
module
is
doing
before
handing
the
binary
to
free
rtos
operating
system.
So
I
have
my
module
for
memory
allocator
that
will
read
the
elf
allocate
the
memory
whether
it's
dynamic,
static.
Whatever
elf
says,
I
will
do
that
it
will.
B
I
will
register
it
with
a
binary
tree,
I'm
using
a
binary
tree
to
keep
track
of
all
the
application
binaries
that
I
am
running
and
then
we'll
link
all
the
tasks.
So
basically
all
the
things
that
os
does-
I
am
doing
in
my
own
module
so
as
to
keep
control,
keep
complete
control
of.
I
keep
complete
control
and
track
of
all
the
application
binaries.
I
am
executing
in
my
system.
B
Yes,
so
when,
when
and
when
a
task
is
registered,
then
I
keep
an
entry
in
the
splay
tree
or
there
is.
There
is
a
splay
tree
and
a
red
black
tree.
Then
each
of
the
memory
modules
memory
areas
that
it
allocates
again.
I
keep
them
in
the
in
the
tree,
and
this
helps
me
for
quick,
searching
and
replacement.
A
Okay,
yes,
so
so
it's
a
way
of
it's
a
way
of
organizing
memory
from
you
know
what
you,
what
you're
interpreting
from
the
elf
file,
so
the
l
file
stay
here.
The
stack
is
here
and
the
let's
say
that
the
heap
is
here
and
the
you
know
that
there's
some
I
don't
know
some
members.
Some
memory
for
this
function
requires.
A
B
Yeah
local
variables
are
here:
there
are,
there
can
be
as
we
as
we
as
the
size
of
modules
grow.
There
can
be
multiple
heaps,
multiple
memory,
multiple
malloc
calls.
So
all
these
things
and
it's
the
same
thing-
that's
used
in
linux,
kernel
linux
kernel
also
uses
red
black
tree
to
track
memory
allocations.
C
B
B
A
B
So
yeah
code
flow,
it
will
be
better
understood.
Okay,
let
me
go
through
it.
So
elf
binary
is
inserted
into
the
memory.
It's
again
a
bit
of
repetition,
but
just
at
high
level,
elf
binary
is
inserted
into
the
memory
the
system
as
a
whole,
how
it
recognizes
it
recognizes
all
the
tasks
and
their
entry
points
via
e-left
binary.
B
The
system
registers,
all
the
tasks
to
a
task
manager
task
manager
is
an
entity
again.
It's
it's
a
part
of
system
layer,
that's
just
that
sits
above
free
rtos
and
it
makes
the
entries
into
the
red
black
tree
and
splay
trees.
So
that's
the
role
of
task
manager,
it
registers
all
the
tasks
that
are
executing
in
the
system
system
is
able
to
create
new
free,
autos
task
with
now
once
the
task
is
registered.
B
A
And
one
one
thing
I
should
mention:
we
do
have
a
a
risk.
I
have
an
action
to
sort
of
log
the
risks
on
on
the
on
the
projects
and
we've
got
one
about
mpus
and
things
which
I
think
is
a
low
risk,
but
there's
another
one,
basically,
because
one
of
the
goals
is
to
to
minim.
You
know
one
of
the
one
of
the
aims
is
to
minimize
the
amount
of
information
that
needs
to
be
uploaded
when
we
replace
code
now,
elf
files
aren't
binary
files
they're.
A
Well,
they
are
binary,
but
they're
they're
sort
of
they're,
perhaps
bigger
than
than
if
you
were
just
to
upload
the
you
know
the
dot
bin
file,
if
that
makes
any
sense,
so
the
compiler
spits
out
different
files,
there's
a
dot
bin
file
which
is
kind
of
the
very
low
level.
This
is
exactly
what
you
know
the
the
the
processor
is
executing.
Then
you
have
an
elf
file
which
includes
more
information
that
can
be
used.
A
A
The
the
downside
of
that
is
that
l
files
are
bigger
than
bin
files,
so
we
we
kind
of.
We
need
to
recognize
and
track
that
risk
that
you
know
that
by
you
know,
we
might
end
up
with
something
that
allows
us
to
efficient.
You
know
to
replace
things
at
runtime,
which
is
advantageous
from
a
disruption
point
of
view,
but
we
might
not
get
that
benefit
of
the
uploads
taking
a
lower
amount
of
time,
because
the
l
file
is
bigger
than
the
bin
file.
A
So
you
know
one
option
is
to
perhaps
compress
the
bin
file
or
sorry
compress
the
l5
or
something
like
that
on
the
way
up
and
then
decompress
it
before
we,
you
know,
use
it
or
something
like
that,
but
we
we
need
to
to
sort
of
track
that
risk
as
we
go
along.
So
sorry
angel.
Sorry
for
disturbing
you
no.
B
No,
that's
absolutely
valid
point
yeah
we
need
to.
We
need
to
also
figure
out
how
much
of
a
difference
it
is
between
a
pin
file
and
an
l
file,
and
a
second
point
will
be
yes,
as
you
can
see.
If
during
compilation
I
can,
I
can
pass
on
some
flag
to
reduce
the
size
of
l5.
That's
another
option.
We
can
try
and
compression
is
another
thing
that
you
have
mentioned.
B
So
so
this
is
a
just
high
level
diagram,
so
create
drc
is
basically
task.
It
goes
from
here
to
here.
If
it's
unregistered,
then
we
go
from
here.
It
needs
to
be
registered
once
it's
registered
with
this
api
called
task.
Register
task
register
is
a
call
in
task
manager.
Still
it
has
not
reached
free
rtos
domain
once
the
task
register
is
done,
then
we
go
for
task
alloc
again,
it's
my
call
task
catalog.
C
D
A
B
B
A
B
B
So
yeah
as
paul
mentioned,
so
this
was
the
current
phase
goal
application
binary
task
executes.
It
reaches
an
inconsistent
state
and
then
we
wait
for
it
to
reach
in
a
consistent
state,
then
suspend
original
task
allocate
updated
task,
link
the
updated
task,
copy,
the
memory
location
copy,
all
the
atomic
pointers
and
everything
whatever
is
needed
start
the
task
put
it
in
os
control
state
and
start
the
execution
of
the
updated
task.
So
this
was
the
code
just
again
high
level,
graphic
representation.
So
we
have
this
migration
process,
2
3,
4
5
task
code.
B
This
is
code,
v1
v1,
the
ask
data.
So
let's
call
it
task
state
v1,
v1.
The
task
is
executing.
Now
a
request
comes
to
replace
the
task,
so
we
wait
for
the
task
to
reach
a
checkpointable
state.
That's
an
important
state.
This
is
a
state
where
it's
not
making
any
calls
to
any
of
the
libraries
it's
in
its
independent
state.
So
we
wait
for
it
to
achieve
a
checkpointable
state
and
and
then
the
replacement
happen.
And
then
we
have
code
v2
and
then
task38v2v2.
A
A
A
B
C
E
D
A
B
It
will
it
will
be
dependent
on
that
now.
How
soon
can
you
reach
to
checkpointable
state
again,
it
depends
how
you
have
written
your
task.
If
it's
making
a
lot
of
function
calls
and
in
that
function
call
you
are
spending
a
lot
of
time.
Then
that's
a
bad
thing,
but
if
you're
making
a
function
call
returning
it
immediately,
then
you
can
quickly
reach
to
a
checkpointable
state.
So
these
are
two
important
things
we
need
to
take
care.
While
we
are
writing
our
task.
Okay,.
A
Yeah
and
just
so
you're
aware,
anshul
the
way,
the
way
we're
hoping
to
write
this
this
task,
and
this
this
might
be
of
interest
to
you-
we're
hoping
to
use
simulink,
which
is
a
you
know,
maths
tool,
which
also
has
the
capability
to
spit
out
c
code.
So
we
develop
a
a
simulink
model
with
some
associated
matlab
code
and
stuff.
A
A
So
there
isn't
an
intermediate
point
where
you
know
it
comes
back
and
then
goes
back
in
again.
It
just
kind
of
does
what
it
does
and
then
comes
out.
So
I'm
imagining
that
what
we
would
end
up
with
is
you
know,
you're
in
your
simulink
code,
doing
your
stuff
and
then
you
come
out
and
then
you
might
try
and
enter
your
your
checkpointable
side.
B
A
B
I
think
yeah,
it's
important
to
understand
I
I
can
put
a
check
pointable
state,
even
when
you
have
made
a
call,
but
at
the
time
of
copying
your
your
stock,
your
stack,
your
local
variables,
will
not
be
in
updateable
state,
so
it
all
depends
upon
your
requirement.
I
have
no
problem.
I
can
define
a
checkpointable
state
whenever
you
want,
but
then
you
will
get
old
stack,
which
you
don't
want.
So
just
think
of
from
that
perspective,
what
lakehold
variables?
What
stack,
what
heap
you?
A
So
I'm
just
kind
of
thinking
this
through
then.
So
what
what
we've
got
here
is
something
that
sounds
quite
intricate
and
quite
clever
in
the
sense
that
not
only
are
we
replacing
the
task,
we're
also
replacing
the
cut
or
maintaining
this
the
context
of
the
task
in
terms
of
its
its
its
its
local
variables
and
stuff.
Yes,
now
the
question
I
would
have
is
if,
by
modifying
the
task,
you
know
you
introduce
more
interfaces
or
you
interview
in
you
know
you
change
the
the
nature
of
the
way
the
stack
would
be
create.
A
A
I'm
just
sort
of
thinking
through
I,
I
guess,
there's
a
limit
to
how
much
you
can
change.
You
know
if
you
were
to
completely
re-engineer
your
afcs
code
and
then
try
to
use
this
method.
Would
it
just?
Would
you
just
end
up
there's
no
point
sort
of
trying
to
do
you
know.
Do
you
have
to
you
have
to
write
a
bit
of
code
to
translate
the
stack
or
the
the
the
data
into
the
new
task?
A
Let's
say
that
you
wanted
to
introduce
a
new
variable
for
integrators
or
on
some
new
loop,
or
something
like
that.
That
required
a
data
structure
which
was
different
from
the
old
task,
which
you
have
to
have
something
that
translated
the
data
from
the
old
task
into
the
format
of
the
data
for
the
new
task.
B
Look
what
I
am
translating
is
suppose
you
have
new
variables
introduced
into
the
stack,
so
that
will
be
there
in
the
new
task.
All
variables
in
the
stack
will
be
there
in
the
new
stack
similar.
All
the
heap
memory,
alias
memory
areas
allocated
in
the
old
tasks
will
be
carried
forward
to
the
new
task
and
the
pointers
that
were
pointing
to
those
memory
areas.
Those
will
be
updated
with
new
addresses.
C
A
A
A
C
B
E
C
B
E
Yeah
to
dive
up
things
too
much
just
a
quick
comment
so
in
terms
of
sort
of
task
uploads,
but
again
stick
with
asgs.
If
we
were
to
just
generate
the
whole
aocs
software
from
simulink,
obviously
it
will
chuck
out
like
one
it
chucks
out
like
one
function
that
can
be
run.
That
is
the
full
you
know.
Obviously,
inside
that
function
she
does
in
the
detail,
but
in
terms
of
what
the
task
is
doing.
It's
just
running
that
one
function,
which
is
the
whole
ocs
task.
E
A
It
was
one
of
them
to
replace
the
whole
thing
just
for
you
know
for
a
tiny
update,
yeah
and
certainly
in
in
the
presentation
I
gave
previously.
There
was
a
sort
of
another
method
which
you
know
people
have
employed
previously,
which
is
a
small
patch.
Yes,
so
you're
patching
little
bits
of
code
little,
you
know
literally
bits
of
binary
in
and
sometimes
you
can
do
that,
and
sometimes
you
can't
because
it
depends
upon
the
nature
of
how
you're
doing
it
yeah.
E
And
everything
else
is
I've.
Seen
you
know,
sort
of
the
advised
way
of
dealing
with
the
model
based
stuff
is
to
not
actually
touch
the
code
at
all.
In
terms
of
what's
generated,
you
always
go
back
to
the
model.
I
mean
yeah,
so
that
that's
all
lends
itself
to
not
doing
the
patching.
If
you
follow
that
exact,
you
know
follow
that
guideline.
A
A
So
then
you've
got
your
binary
and
then
let's
say
you
want
to
make
a
very,
very
small
change
to
the
code.
So
what
you'd?
What
you
could
do,
then,
is
change.
Your
simulink
model
create
your
your
c
code,
compile
your
c
code
and
now
you've
got
another
binary
and
what
you
can
do
is
compare
the
two
binaries
and
see
what
the
differences
are.
C
Yeah,
I
think
I
think
you
have
to
do
it
on
a
case-by-case
basis
in
that
instance,
because
some
some
changes
will
be
patchable
and
some
won't,
and
it
was
always
whenever
we
did
it.
Whenever
we
used
a
patch,
especially
on
something
like
the
aocs,
it
was
very
much
a
last
resort.
It
was
not
something
that
we
would
like
to
entertain,
just
because
it
leaves
you
open
to
so
many
risks,
whereas
if
you,
if,
if
you
can
replace
the
entire
task,
it's
a
lot,
it's
better
defined.
A
C
B
And
one
more
thing:
I
was
just
thinking
over
that
so
when,
when
when
a
new
task
is
uploaded,
I
go
through
the
very
because
the
variables
that
are
defined
in
the
old
dlf
and
the
new
elf,
whatever
you
want
to
reuse,
those
names
will
be
same.
So
I
go
through
the
tree
and
then
copy
only
those
ones
which
exist
in
the
tree
and
are
there
in
the
new
elf.
B
A
But
I
guess
then
I
by
the
way
I
you
know,
I'm
a
typical
software
engineer,
I'm
always
trying
to
find
the
problems
right,
but
but
this
this
is
really.
If
we
could
get
this
to
work,
it
would
be
fantastic
because
it's
it's
it's
proper,
live
patching.
You
know
maintaining
the
context
between
one
thing
to
the
next.
It's
really
efficient
from
a
operational
point
operations.
Point
of
view
it's
challenging
from
a
coding
point
of
view,
which
is
why
I'm
glad
you're
here,
but
I'm
sort
of
thinking
about
okay.
A
A
A
B
C
C
So
we
could
do
some
experiments
where
we
would
just
spin
it
at
very
low
speed
without
putting
it
in
the
control
loop,
because
the
other
wheels
could
compensate,
and
that
was
fine,
but
there
became
a
point
where
we
needed
to
add
it
into
the
control
loop
and
so
that
that's
what
would
would
be
your
your
your
context?
There
paul
is
where
we
put
it
in,
but
that
again
it's
a
very
you
know
it's
a
it's
a
one-off
case,
probably.
A
A
C
There
will
always
be
occasions
where
you
just
have
to
revert
back
to
something
else,
and
I
think
we
need
to
make
sure
that
we
we
want
to
keep
this
as
simple
as
possible
and
have
it
very
well
defined
and
not
try
and
expand
the
boundaries
too
much.
I
think
we
just
need
to
be
careful
that
we
just
don't
you
know,
do
that.
A
C
A
A
D
B
C
B
C
B
B
The
code
stops
in
this
loop
just
for
understanding,
then
it
will
wait
for
some
number
of
it
will
wait
for
some
amount
of
time
to
get
the
binary
and
then
the
processing
will
happen.
So
I
will
do
that
and
this
is
the
uart
screen
here.
You
will
screen
the
here.
You
will
see
the
output
and
here
you
will
see
both
tasks
are
executing
simultaneously
and
then
one
stop
at
the
start.
It's
not
pretty,
but
it's
console
output,
that's
the
best.
I
can
do
yeah.
B
B
A
B
D
B
C
A
A
C
B
A
A
Oh,
it
might
be,
it
might
be,
a
load
of
you
know,
zeros,
just
padding
yeah
I
mean
because
the
l
file
doesn't
have
padding
in
it.
It
just
says
put
this
to
here:
put
that
there
put
that
the
other,
whereas
the
bin
file
can
include
well,
it
will
include,
you
know,
all
padding
information
and
everything.
So
actually
it's
smaller.
B
E
A
C
A
You
yeah
yeah,
it
is
excellent
and-
and
it
is
it's
really
nice
to
have
you
know
quite
often
you
work
in
you
know
when
you
work
in
the
space
industry,
you're
working
with
people
who
are
space
people
but
you're,
not
working
with
people
who
are
like
experts
in
operating
systems.
You
know
and
and
that's
the
beauty
of
what
we're
doing
here.
You
know
you're
an
expert
in
operating
systems
and
hypervisors,
and
all
of
this
stuff,
which
you
know
most
space
people
won't
touch
with
a
barge
pole.
A
A
C
A
question
on
making
open
source
so
obviously
the
demo
worked,
which
is
brilliant
and
I
guess
paul.
You
have
an
angel
if
you,
if
you
sort
of,
come
together
and
review
the
the
testing
aspects
of
it
so
that
you
know
you're
both
happy
that
it's
been
through,
because,
obviously,
if
we're
going
to
make
it
open
source,
we
need
to
have
made
sure
that
we've
done
sufficient
testing
to
make
sure
that
it's
robust
and
no
disrespect.
But
you
know,
obviously
we
need
to
do
that.
So
has
that?
Has
that
been
done.
A
No,
we
haven't.
This
hasn't
gone
through
like
a
type
2
development
cycle.
This
is
very
much
type
1,
because
it's
it's
all
to
do
with
you
know
it's
like
an
experimental
thing.
So
what
I
was
gonna
do.
I
was
going
to
release
it,
but
with
you
know,
there's
there's
no
just
being
upfront
about
the
level
of
testing
that
it's
got.
You
know
there's.
A
Yeah
there's
no
warrant;
there
won't
be
any
way
because
of
the
license
agreement
on
the
open
source
stuff,
but
certainly
you
know
just
being
upfront
about
the
nature
of
this
software.
If
we,
you
know,
I
think,
probably
in
the
roadmap
to
get
us,
you
know
on
the
satellite,
we
probably
want
to
do
some
more.
You
know
unit
testing,
get
the
code
coverage
up
and
all
of
this
kind
of
stuff,
but.
A
A
So
in
the
future
we
could
actually
put
that
into
an
iteration,
so
we're
trying
to
actually
demonstrate
a
full-blown
aocs
task
being
replaced
by
another
one,
so
hand
maintaining
context
and
carrying
on
you
know
what
I
mean
like.
Actually
you
know
we
changed
the
algorithm
and
the
loop
is
running
and
now
it's
still
running
with
a
different
algorithm.
You
know
and
it's
seamless,
wouldn't
that
be
beautiful.
That
would
be
a
thing
of
legends.
A
E
They
were
sort
of
forced
to
think
about
all
like
I
mean
we've
talked
about
it
briefly
before,
but
it
was
to
think
more
about
how
we
physically
would
integrate.
You
know
the
significant
codes
in
the
real
software
until
you
talk
about
you
know
the
structures
going
in
and
out
in
terms
of
how
you
should
give
it
inputs
and
outputs.
You
actually
make
me
think
about
that
in
more
detail.
D
C
A
B
A
A
All
right
exactly
because
I
know
one
of
the
main,
the
main
features
of
this
in
this
demo
is
to
print
things
to
the
serial
port,
so
you've
got
to
kind
of
you
know,
print
the
serial
port
function.
Call
and
you've
got
that
going
on
in
the
binary
that
exists
in
the
big
lump,
the
first
binary,
the
big
l
file
and
then
you've
got
another
call
to
the
same
function
in
the
new
l
file.
A
A
A
A
A
B
B
A
A
A
Okay,
yeah
so
but,
but
maybe
I
don't
know,
maybe
what
we
could
do
is
open
source.
What
we
have,
including
some
instructions
on
how
to
how
to
demo
it
and
that's
the
sort
of
high
priority
and
at
that
point,
tag
it
and
and
there's
probably
another
action
to
to
go
through
testing
testing
in
what
andrew
was
saying.
B
B
A
A
B
B
A
A
No
impact
have
a
look
at
tasks
being
replaced.
They're
called
by
other
tasks,
see
if
there's
a
ways
to
linking
the
replacement
task,
even
though
changing
location
so
that
one's
on
the
backlog.
I
don't
know
if
you
can
understand
that,
I'm
just
trying
to
marry
up.
You
know,
what's
in
the
backlog,
with
what
we
should
put
in
for
the
next
iteration.
Basically,.
B
A
Well,
andy
advised
not
because
what
we
could
do
is
have
the
interaction
between
the
tasks
go
through
the
operating
system.
You
should
use
queues
or
you'd
use.
Some
kind
of
you
know
no
direct
calls
between
one
task
and
another,
because
I
think
to
do
that.
You'd
have
to
build
them
as
one
big
blob
anyway,
so
yeah
so
yeah.
I
think
this.
This
needs
to
change,
focus
slightly
yeah,
okay,
so
we'll
leave
that
there.
B
A
D
A
B
E
A
It's
all
good,
that's
all
good!
Well,
actually,
I
think
it's
it's
a
really
good
demo.
I
think
it's
been.
You
know
I
think,
from
where
we've
been
before
as
well.
Just
in
terms
of
you
know
what
we've
done
today
this
this,
you
know
it's
been
a
lot
more
good.
It's
been
better
for
those
you're
presenting
to.
I
think
I
don't
know
if
everybody
would
agree.
Yeah.
C
B
A
C
Yeah,
so
if
I
have
to
power
cycle
the
obc,
for
instance,
it
goes
back
to
the
state
that
I
was
in
after
I
had
uploaded
that
new
task,
because
you
wouldn't
want
to
you,
wouldn't
want
to
necessarily
have
to
upload
it
again
because
you
put
it
in
there
for
a
reason.
It's
a
good
catch
like
jamie.
I
haven't
thought
about
that.
B
C
B
A
B
A
Yeah
yeah
so
yeah
I've
just
added
something
into
the
backlog
there
too,
so
that
we
can.
We
can
just
not
lose
sight
of
that
in
the
future.
Yeah
brilliant
okay,
so
I
think
we've
got
an
idea
of
what
we're
aiming
for
for
november
and
it
just
really
just
remains
me
to
say
I'm
in
awe
of
your
you
know
software
engineering
prowess.
I
wish
I
was
as
clever
as
you.
A
C
A
A
A
A
There's
lots
of
opportunities
continuously
coming
up
that
john
john
looks
at
and
he's
looking
at
it
and
saying:
okay:
well,
does
this
fit
with
ossat?
Does
it
fit
with
maybe
something
else?
So
the
answer
is
no,
we
don't
have
enough.
Well,
we
don't
it's
not
a
good
update.
The
update
is
we
didn't
get
a
load
of
funding
so.
C
But
I
think
the
key
thing
is
we're
pushing
forward,
because
when
we
get
an
opportunity
we
want
to
be,
you
know
if
we
can
be
further
down
the
line,
then
that
that's
great
so
we're
you
know
we're
still
moving
forward
a
pace
to
try
and
get
the
the
project
moving
forward,
such
that
when
we
do
get
these
customers
there's
there's
less
to
do
than
you
know
previously.
So.