lib: add adcs library

[alexapostolu]

The main purpose of this PR is to find a good bound for code style (comments, documentation, directory structure, etc). The skeleton code I have ispractical and likely will be part of the final satellite code, so I think it's a good example for us to play around with the code style. I wanted to balance between readability, upstream Zephyr guidelines, and practicality.

Any feedback is welcome (too verbose, comments not well formatted, function return values don't make sense, etc..)! And I can add whatever feedback we agree on to our contribution guidelines for future reference

(The other purpose of this PR is to provide one single branch for the ADCS library development and testing, but this should be merged after v0.0.0)

[mshinjo]

Should this be under driver/ instead of lib/?

[mshinjo]

The main purpose of this PR is to find a good bound for code style (comments, documentation, directory structure, etc). The skeleton code I have ispractical and likely will be part of the final satellite code, so I think it's a good example for us to play around with the code style. I wanted to balance between readability, upstream Zephyr guidelines, and practicality.

Any feedback is welcome (too verbose, comments not well formatted, function return values don't make sense, etc..)! And I can add whatever feedback we agree on to our contribution guidelines for future reference

(The other purpose of this PR is to provide one single branch for the ADCS library development and testing, but this should be merged after v0.0.0)

Sounds good

[alexapostolu]

Should this be under driver/ instead of lib/?

That's a good question. I don't think so because I see drivers as low level code, but ADCS code will contain high level decision making logic (it's almost like application level logic). It doesn't really have any low level code besides sending bytes via UART. Thoughts?

[chopikus]

❗️💣 This is 16 bits not 16 bytes

[jpmedinagl]

This should be:
adcs_get_id(&adcs_id_received);

[jpmedinagl]

We could generalize this by defining a single reusable return enum for the ADCS module:

typedef enum {
    ADCS_RET_OK,
	ADCS_INVALID_ID,
	... // other success/error codes
} adcs_ret;

This approach avoids having separate per function return types and would allow us to have consistent error handling across all ADCS functions. It would make it easier to extend with additional error codes

It allows a consistent interface between module and obc (ie all ADCS functions return with adcs_ret).

But we could leave it for now or decide to go with the per function return types

[TheArchons]

Why is the id of the ADCS module 0x54? Is this documented anywhere? We could use a named constant that explains where 0x54 comes from instead of a magic number, or maybe a comment.

[TheArchons]

Minor nitpick, but for future code style should we avoid abbreviations like RET and ERR whenever possible? In this case it is pretty clear but since code completion on IDEs saves you from typing the whole variable name anyways, writing the full words is not really slower.

Suggested change

	ADCS_GET_ID_RET_ERR,
	ADCS_GET_ID_RETURN_ERROR,

[TheArchons]

Also a minor code style nitpick but why do we define ret after declaring it? We can do it in one line:

Suggested change

	adcs_get_id_ret ret;
	adcs_get_id_ret ret = adcs_get_id(adcs_id_received);

[TheArchons]

This should be ADCS_GET_ID_RET_OK.