You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Follow-up to #176. Currently implemented as a serial device at DextraSerialControlboard, most code should be refactored and reused in its CAN-counterpart device. In fact, serial comms take a role in the Synapse class only, in which the protocol is enforced and the messages are actually formed and sent away using a handle to the locally instantiated serial device.
First, the CAN device would have to re-implement the Synapse class to handle CAN comms. Same protocol, 8-byte messages, a handle to a CAN TX broker class (the CAN device might be created externally, see #209).
This device should consider the proposed role system: #211. A board role implies that the device implements raw motor interfaces (e.g. IPositionControlRaw, contrary to IPositionControl as currently used in the serial device).
For refactorization purposes, I might consider moving the serial implementation to raw interfaces and expose it through a new wrapper. Reminds me of the TextilesHand device: you can only launch it by means of the CanBusControlboard device, same as the hereby proposed Dextra CAN device, but no CAN comms are involved (it is, in fact, another serial device). Should the CanBusControlboard be able to launch the Dextra serial device?
The text was updated successfully, but these errors were encountered:
For refactorization purposes, I might consider moving the serial implementation to raw interfaces and expose it through a new wrapper. Reminds me of the TextilesHand device: you can only launch it by means of the CanBusControlboard device, same as the hereby proposed Dextra CAN device, but no CAN comms are involved (it is, in fact, another serial device). Should the CanBusControlboard be able to launch the Dextra serial device?
I'm prone to restrict usage of "raw" devices so that they can only be instantiated by a master device - our CanBusControlboard. This latter is responsible for managing CAN (real or fake) comms, therefore all CAN-enabled raw subdevices may not perform any reads/writes without its enclosing wrapper and standalone instantiation is forbidden.
This approach would enforce several changes in certain apps, for instance, exampleTechnosoftIpos.cpp.
Device implementation ready at ce83d80. I did not implement CAN reads, though, since there is no data being published by the Dextra firmware AToW. Still waiting for #171 to make this usable on a CanBusControlboard setup.
Follow-up to #176. Currently implemented as a serial device at DextraSerialControlboard, most code should be refactored and reused in its CAN-counterpart device. In fact, serial comms take a role in the Synapse class only, in which the protocol is enforced and the messages are actually formed and sent away using a handle to the locally instantiated serial device.
First, the CAN device would have to re-implement the Synapse class to handle CAN comms. Same protocol, 8-byte messages, a handle to a CAN TX broker class (the CAN device might be created externally, see #209).
This device should consider the proposed role system: #211. A board role implies that the device implements raw motor interfaces (e.g.
IPositionControlRaw
, contrary toIPositionControl
as currently used in the serial device).For refactorization purposes, I might consider moving the serial implementation to raw interfaces and expose it through a new wrapper. Reminds me of the TextilesHand device: you can only launch it by means of the CanBusControlboard device, same as the hereby proposed Dextra CAN device, but no CAN comms are involved (it is, in fact, another serial device). Should the CanBusControlboard be able to launch the Dextra serial device?
The text was updated successfully, but these errors were encountered: