Feature/thruster fire

[kodsurf]

I were able to "solve" problem described in ISSUE-17 https://github.com/RobertK66/obc_1769_core/issues/17

using static keyword when initializing sequences.

I also tested that triggering function can indeed pass arguments to THR_HARDCODED_SEQUENCE

Therefore sequence can indeed RUN with user specified arguments.

This is to early to APPROVE this PR. I will implement ACTUAL SEQUENCES for thruster hot/cold start and firing manevre.

But in general I am quite happy that my idea with array of function pointers worked.

[kodsurf]

I would like to notify on my current plant here ...

Up till now I added several sequences devoted to "On orbit commisioning/ System Cold Test"

Everything runs as expected. OBC does not jump into hard fault loop. Even if all sequences are triggered at the same time (which obviously should never happen in case of thruster, since only one test should be run at once!). But from sequencer SW point of view - OBC does not go into hard fault. Which I am happy about.

WHAT I DONT LIKE :

I dont like that I use string argv argc for sequencer functions !!!! Probably I would have to change it to a custom datastructure which will keep for example :

function.arguments.arg_uint16_1 function.arguments.arg_uint16_2 function.arguments.arg_double_1 function.arguments.arg_double_2 function.arguments.arg_uint8_1 function.arguments.arg_uint8_2

And later on when we do hardcoding there would be a table for each sequencer function which describes how arguments should be used

for example for function thr_wait - arg_uint16_1 will be used for "wait duration"

and for thr_value_ramp arg_uint16_1 can be used for something else (ramp duration for example)

Table describing usage of arguments could be added to README and pdf report.

---

But - since I have been asked to implement workable thruster sequences till the end of month. I would like to complete it in the way as it is currently is with argc, argv. So that there would be at least one workable solution.

Afterwards - we review again whole idea about sequencer module. Consult with Robert and during design iteration think how can it all be optimized better

[kodsurf]

@RobertK66 I think you can also test code in that branch with your OBC, even despite that it lacks thruster. To check that OBC indeed does not run into hard faults upon sequence execution

Debug logging messages from debug_pure_print() should be avaliable.

Yes I know I should not use print messages. And should use MCUExpresso debugging. But it got already TOO MUCH complicated already with sequencer.

I use both logging messages and MCUExpresso debuger to investigate into bugs already !

[kodsurf]

To trigger sequence use command

8

Where sequence_id are currently {0,1,2,3}

And actions are

0 - start sequence 1 - restart 2 - repeat (after completion of sequence it will repeat from beginning) 3 - stop repeat ( after completion of sequence it will no longer repeat, if previously repeat was set to true) 4 - pause (after resuming it will continue from stage at which it was paused) 5 - resume 6 -stop (manual stop, regardless of at which stage sequence is) To start again use 0 action

Example : "8 3 0" will start System Cold Test / Neutralizer Heating Test

[kodsurf]

OBC runs into fault mode if thruster SET/READ requests are sent too frequently

One request after another without delay - causes issues

I always add manual delay between SET/READ requests when hardcoding thruster sequence

Please refer to an issue https://github.com/RobertK66/obc_1769_core/issues/49

[kodsurf]

https://github.com/RobertK66/obc_1769_core/commit/1908a3cef49dba1e8fc119d80602bf21325d4d55

I created parallel branch for thruster-fire dev where I tried out different way of hardcoding sequence.

This way we access THR_HARDCODED_SEQUENCES dirrectly wihout using temp_sequence

But this required me to change the defination of "sequences" from *pointer to a hardcoded array of fixed size

In original branch I defined this as pointer

Then I still created a temp variable with fixed length

In the end when sequence is completed I assigned it as an address

---

Which way is better ? Please advice ?

---

Update :

I think this is better : https://github.com/RobertK66/obc_1769_core/tree/feature/thruster-fire-paralel

and I will continue with new branch. Sorry for the mess in github :(

Will open PR from new branch when I complete the feature. Will leave that PR still open since there is ongoing discussion about several problems with sequencer timing

[RobertK66]

Hi - back from holidays.... Mess in github is normal - as long as we can handle it and cleanup somewhen ....

So one hint would be to work in branches only, before making a Pull request. A Pull request normally signals (to others) that the code is in a 'final for review and merging into develop after acceptance' state. As long as you make your own feature/xy or even experimental/yz branches nobody cares and you can mess around as much as you want :-)

Having design discussions as we started here - should better go to somewhere else (either to the 'main feature issue' or somewhere else (maybe to 'discussions' - not sure about using this)

That said I now switch over to #49 ....

[RobertK66]

obsolete ....