Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop CAN Dextra device #227

Closed
PeterBowman opened this issue Aug 5, 2019 · 2 comments · Fixed by #229
Closed

Develop CAN Dextra device #227

PeterBowman opened this issue Aug 5, 2019 · 2 comments · Fixed by #229
Assignees

Comments

@PeterBowman
Copy link
Member

PeterBowman commented Aug 5, 2019

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?

@PeterBowman
Copy link
Member Author

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.

@PeterBowman
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant