Currently, CanBusControlBoard (which will be renamed to CanBusBroker in https://github.com/roboticslab-uc3m/yarp-devices/issues/263) plays the role of the YARP-CAN broker that maps a list of physical CAN nodes to motor joints, and also opens several ports exposing CAN-related channels, namely /sdo:s, /send:i, /dump:o and /load:o (https://github.com/roboticslab-uc3m/yarp-devices/issues/160). Also, there is /sync:o for the synchronization signal. This double role might violate the SRP. Besides, it has forced us to combine configuration options related to two different entities (CAN bus device and CAN thread broker) into a single bus config file.
Idea: split the port logic part into a separate device (or devices) wrapping the main one (CanBusControlBoard/CanBusBroker). This is somewhat contrary to my original intentions at https://github.com/roboticslab-uc3m/yarp-devices/issues/226. As I stated then, it is possible to map several brokers (OneCanBusOneWrapper at that time) locally via ControlBoardRemapper instances into separate limbs (example using only one mapper, but could be trivially extended to many: teo-self-presentation). The current solution was implemented since it was quite easy to combine all channels in only one, omnibus device, and it probably spared some configuration efforts. Today, however, I am more prone to using as many simpler devices (including mappers) as needed and splitting responsibilities.
Main caveat: I really want to preserve the synchronization feature across CAN channels, and this is the strongest selling point of the current broker device. Maybe an intermediate "mapper" device could be arranged to govern the main synchronization thread. Then, another newly introduced, NWS-like device, say CanBusServer, would expose the aforementioned four CAN-related ports, perhaps even the sync one, too.
Currently, CanBusControlBoard (which will be renamed to CanBusBroker in https://github.com/roboticslab-uc3m/yarp-devices/issues/263) plays the role of the YARP-CAN broker that maps a list of physical CAN nodes to motor joints, and also opens several ports exposing CAN-related channels, namely
/sdo:s,/send:i,/dump:oand/load:o(https://github.com/roboticslab-uc3m/yarp-devices/issues/160). Also, there is/sync:ofor the synchronization signal. This double role might violate the SRP. Besides, it has forced us to combine configuration options related to two different entities (CAN bus device and CAN thread broker) into a single bus config file.Idea: split the port logic part into a separate device (or devices) wrapping the main one (CanBusControlBoard/CanBusBroker). This is somewhat contrary to my original intentions at https://github.com/roboticslab-uc3m/yarp-devices/issues/226. As I stated then, it is possible to map several brokers (OneCanBusOneWrapper at that time) locally via ControlBoardRemapper instances into separate limbs (example using only one mapper, but could be trivially extended to many: teo-self-presentation). The current solution was implemented since it was quite easy to combine all channels in only one, omnibus device, and it probably spared some configuration efforts. Today, however, I am more prone to using as many simpler devices (including mappers) as needed and splitting responsibilities.
Main caveat: I really want to preserve the synchronization feature across CAN channels, and this is the strongest selling point of the current broker device. Maybe an intermediate "mapper" device could be arranged to govern the main synchronization thread. Then, another newly introduced, NWS-like device, say CanBusServer, would expose the aforementioned four CAN-related ports, perhaps even the sync one, too.