DataMessage: Add get and set for Application Address and REQ/REP ( + CmdHandler)

[CasperBroekhuizen]

As discussed, extend the OSI Model to transportation level to application specific addresses (Services) This will need to be reflected by the PQ9Bus project, to add specific fields to the getters and setters of the PQ9 Protocol.

This field can then be processed in the CmdHandler to only respond to Requests.

[CasperBroekhuizen]

New feature on new branch:

• Core: https://github.com/DelfiSpace/DelfiPQcore/commit/00350ebb140dd9a9586aa8beb5db8aa439c61cf7
• PQ9Bus: https://github.com/DelfiSpace/PQ9Bus/commit/1a07e54be2df9391267194cfe8a0f5ed8d80010f

Change in commandHandler declaration: CommandHandler<PQ9Frame, PQ9Message> cmdHandler(pq9bus, services, 5);

Merge planned after cleaning up core services with new getters and setters

[CasperBroekhuizen]

Updated DataMessage and PQ9Message with new function and renames. A user now sets the Payload of a Message size separate to the service and req/reply indicator.

a Message has:

• Service Number
• REQ/REP Indicator
• Payload (optional)

When a user sets the payload size this does not include the Service number and REQ/REP indicator. (as the size of these fields can be different from a different Message 'protocol' than PQ9Message).

In PQ9Message specifically, the Service Number and REQ/REP indicator are both 1 byte big. Meaning that the total message size will be (PayloadSize + 2).

Commits regarding this change:

• Core: https://github.com/DelfiSpace/DelfiPQcore/commit/bfd271b92a1829a89001686967661c620c5737a0 , https://github.com/DelfiSpace/DelfiPQcore/commit/8bb659088191e1113499b6fa71efd690ec2e5f4f, https://github.com/DelfiSpace/DelfiPQcore/commit/0c86c2a67300291745d29a38560aac8dbdc3a4cd
• PQ9Bus: https://github.com/DelfiSpace/PQ9Bus/commit/52d4ac2b29023d67ebd118671ca34ec28ad07466

However this creates the following problem / ambiguity. In the older setup the entire message is called Payload. This is true, as it is the Payload of the Frame. However, services are limited to the message frames, thus their payload is within the message. Older services use the system where payload[0] is set with the service number and payload[1] is set with the message type. This system should become avoided as proper getters and setters are available. The following functions should be used:

• Properly get/set the Service with setService(uint8_t num) and getService()
• Properly get/set the MessageType with setMessageType(uint8_t num) and getMessageType()
• Set the size of the Payload with setPayloadSize(). This size excludes service number and REQ/REP, so if no payload is present it should be setPayloadSize( 0 )
• (Optional) Set the Payload using getDataPayload()[i] = value

Older services use getPayload()[i] = value, which directly accessed the entire message buffer, including service and type, hence should be avoided. And older services use setSize(value), which directly sets the size of the entire Message, and also should be avoided. Currently they are still available in order to be compatible with older services.

[CasperBroekhuizen]

The CommandHandler now performs a check if the message is a REQ, hence this check is no longer necessary in the services themselves and can be removed. The ERROR reply also no longer exists, hence the CommandHandler REPLYs with Service Number 0 and an error code on reply to a non-existing service (currently 1, but a define is available).

Housekeeping and Ping now always reply and have been cleaned and simplified. The Reset Service now expects a CommandCode in the Message Payload and REPLYs with a status number in it's payload (NO_ERROR: 0, UNKOWN_COMMAND: 1).

Commits regarding this:

• Core: https://github.com/DelfiSpace/DelfiPQcore/commit/a5d09fbc10540fb87bea863e7671b6b9bb980622 , https://github.com/DelfiSpace/DelfiPQcore/commit/09507d05e110bed95060f0f94953b5a20d73737f

[CasperBroekhuizen]

Aslo in MSP432P4111 https://github.com/DelfiSpace/DelfiPQcore/commit/8de41d23d8637a7a5c39d629c4787a84dce7e76c