Thruster RX bytes never reaches the ParseReadRequest() method

[RobertK66]

I think your checking the RX length in thr.c ine 185 (commit d06a41d2fba3cb4b42d06dd4902412bd9e1fd4be ) is not working correct.

I wrote a 'Thruster-Simulator' connected to the RS485 UART and simulated OK answers to Register Set and Data answers to Register read requests. When I change the line 185 to check '<=' iso '<' everything seems to work !?

Not sure if this is the 'correct' resolution or the setting of the variable l4_thr_ExpectedReceiveBuffer is to be blamed here .....

[kodsurf]

https://github.com/RobertK66/obc_1769_core/commit/efc8efae9810cca3a6c0a9259cb59c573ca2d461

I make complete redesign of the module in this branch

But it's not yet ready. New parser looks more efficient. I will test it again today and clean the code.

I moved all thruster request functions to the.c

And will use l4 only for sequence execution

[kodsurf]

https://github.com/RobertK66/obc_1769_core/tree/feature/thruster-major-rework

I removed all the loops and data conversions from parser.

Goal of new parser is simply to load bytes into datastructure that should cary all register values.

I made read/set functions with switch-case to convert values from this structure into double. In my understanding this should be much faster.

I also removeddouble REGISTER_DATA[108] array. To save RAM memory. Datastructure should take much less memory

If this kind of functions are fast enough - then I think it is a better approach

Whenever we need - we will read and convert. Instead of forced conversion into double upon every reception of thruster RX message. In my oppinion new way should be more efficient ?

[RobertK66]

Looks ok to me. But pls. have in mind that we should get a final version in order to proceed with our developer branch ;-).

It should be the exception to have that long lasting pull request and reviews, because this makes life more difficult for all 'other guys' developing for OBC. (branching from develop and implement the next/own feature/bugfix) -> if you can keep things compact and timely (days and weeks, not months) then this helps everybody to avoit to big merging and other conflicts with changes .....

[RobertK66]

Also synchronizing tool releases with OBC releases should be done with more releases from develop having some useful documented status (like I now start debugging my thruster simulator on the tool side, and I would like to use develop for that again....)

[RobertK66]

fixed with #59