Design Serial protocol #65
Conversation
Initial copy from google doc
remove GET_VALUE
|
@proppy Also I have been sticking with the term "modem" you used before. Now would be a good time to change it if we want something else :) |
It looks simple, I made a few comments: but what do you think of first developing the modem as a flat |
|
|
||
|  | ||
|
|
||
| We create a Transceiver object that will manage the serial connection. It will do command detection and hand off to the appropriate Command object to handle the interaction. The Command object will be subclassed for each type of command we will receive and will handle the processing of the command and generating the response. |
There was a problem hiding this comment.
How do you plan to dynamically dispatch the command to the right instance of Command object?
And what's the lifecycle of a Command object? Does it carry any state or is it purely a function wrapper?
There was a problem hiding this comment.
what do you think of Protocol instead of transceiver, with the following instance
SerialProtocol
SPIProtocol
I2CProtocol.
There was a problem hiding this comment.
I updated the document to include this. But since all of our commands can be uniquely identified by the first word (text before whitespace) it should be trivial. We could get fancy with a module registration system, (ala REGISTER_MAPPER for MRs), but the command list is small enough it will probably just end up being a if-then tree.
I think the commands should be short lived. I don't see any of them needing to persist state and keeping the objects alive uses extra memory we could use for data handling.
How about SerialTransciever to allow the other protocols in the future? Just as a object I prefer to name it after what it is doing.
|
As for the simplified .ino, I would prefer to build a testing framework that wraps a command object and build the commands against that. It is quick to iterate and hopefully we can do it off-device. The flat .ino could work as an overall proof of concept but all of the manual testing work would be lost while the unit tests could live on to ensure we don't introduce regressions as we go. |
|
We seem in agreement here, what do you think about merging it in to the repo? |
Moving to modem-impl branch.
Moving to modem-impl branch.
|
Merged the design into the impl PR. |
#35