Add MCM & MVEC Endpoint Structs to Reduce Client Const Definitions

[Ryanbahl9]

Add MCM & MVEC Endpoint Structs to Reduce Client Const Definitions

Add endpoint structs for MCM Interfaces, MCM Relays, and MVEC Relays to help simplify the number of constants the client needs to store.

Questions:

1. Did I put the structs in the right files? Should they live in those header files or somewhere else?

SygnalInterfaceSocketcan

Structs Added

/// @brief Represents an interface endpoint in the Sygnal CAN interface
struct InterfaceEndpoint
{
  uint8_t bus_id;
  uint8_t subsystem_id;
  uint8_t interface_id;
  int min_value;
  int max_value;
  bool is_continuous;
  std::string_view name;
};

/// @brief Represents a relay endpoint in the Sygnal CAN interface
struct RelayEndpoint
{
  uint8_t bus_id;
  uint8_t subsystem_id;
  uint8_t relay_id;
  std::string_view name;
};

Wrapper Functions Added

SendCommandResult SygnalInterfaceSocketcan::sendControlStateCommand(
  InterfaceEndpoint interface,
  SygnalControlState control_state,
  bool expect_reply,
  std::string & error_message)
{
  return sendControlStateCommand(interface.bus_id, interface.interface_id, interface.subsystem_id, control_state, expect_reply, error_message);
}

SendCommandResult SygnalInterfaceSocketcan::sendControlCommand(
  InterfaceEndpoint interface,
  double value,
  bool expect_reply,
  std::string & error_message)
{
  return sendControlCommand(interface.bus_id, interface.interface_id, interface.subsystem_id, value, expect_reply, error_message);
}

SendCommandResult SygnalInterfaceSocketcan::sendRelayCommand(
  InterfaceEndpoint interface, bool relay_state, bool expect_reply, std::string & error_message)
{
  return sendRelayCommand(interface.bus_id, interface.subsystem_id, relay_state, expect_reply, error_message);
}

MvecRelaySocketcan

Structs Added

/// @brief Represents an MVEC Relay endpoint..
struct MvecEndpoint
{
  uint8_t id;
  std::string_view name;
};

Wrapper Functions Added

void MvecRelaySocketcan::set_relay_in_command(MvecEndpoint relay, uint8_t relay_state)
{
  relay_impl_.set_relay_in_command(relay.id, relay_state);
}

[zeerekahmad]

We should do the value checking/min maxing in this send since the metadata we're checking against is being passed into it via the InterfaceEndpoint

[Ryanbahl9]

This would involve adding the min and max and new function parameters, which would break backwards compatibility. Is that fine with you? I can take the time to refactor LEV02

[Ryanbahl9]

@zeerekahmad , I'm going to add this in a future PR. I want to create linked PR's that will update the function definition here at the same time I update usage in LEV02 and LEV05

[Ryanbahl9]

Added a TODO and a github issue here.

[emersonknapp]

is this expect_reply necessary? can't the user just drop/ignore the provided future themself?

[Ryanbahl9]

@zeerekahmad did you have rational for this? or should I remove expect_reply from all functions here? If I should remove them, I'll do that in a new PR because that is outside the scope of this PR

[Ryanbahl9]

Since all of the control commands have expect_reply, I'd like to change all of them at the same time. I made an issue for this and will circle back to it.