Create a profile_management module to handle the storage of all registered profiles

Interactions-HSG / uArm-Controller

MIT License

1 stars 0 forks source link

Create a profile_management module to handle the storage of all registered profiles #7

Closed jo-bru closed 3 years ago

jo-bru commented 4 years ago

The profile_management should include the following:

[x] 1) List of all registered profiles: registered_profiles[255] + functions to manage this list (e.g.delete_profile , store_profile)
[x] 2) Configuration list: MCU port <=> profile_id mapping => this will be used to avoid overlapping registration

This profile_management module should also be later used to store the registered profiles (1) on the SD card. I think splitting the task into these two separate lists makes it simpler to manage all profiles while guaranteeing that no port is used/registered twice.

Part 1) is already partially implemented in branch dev/profile_management => this is however not working correctly right now (sometimes pb_messages are received on the MCU with a wrong message_type = 0)

jo-bru commented 4 years ago

Pause part 2) for now => port management is done on the gateway

jo-bru commented 4 years ago

To manage the registered profiles on the MCU we discussed to implement CRUD operations which can be called from the gateway. But after some thoughts, I realized that we can do the registration management completely in the gateway to keep the MCU firmware as simple as possible. I suggest using only one request type (registration, as already implemented) to update/create an existing/new profile. If a profile already exists, the old profile will simply be overwritten. In this way, CRUD operations on profiles can be handled by the gateway, but don't have to be propagated to the MCUs. I'm not sure if the "de-initialization" of MCU ports is even possible. Therefore a delete operation would only delete the entry in the registered profile list on the MCU, which is not needed if the profile management is properly done on the gateway. However, I'm not totally sure about this. What do you think? Maybe it's easier to discuss this on Wed.

iomz commented 4 years ago

CRUD for the profile is to provide the transparency for the data access throughout the system – the same design principle as I mentioned here and not because of feasibility, but at the same time I feel your motivation – the profile management with nanopb is seemingly heavy to implement extrapolating the variable field parameters for all the drivers with oneof. For me, it is totally ok to leave the profiles partially hardcoded for now, leaving the Gateway to "switch on-off", and come back later for the profile CRUD pass-thru.