Home
Thus far MiP_commands.cpp has been an implementation of each of the messages described in WowWee's documentation. Would a different method be better? Some suggestions include:
- More fine grained getters. Doing so eases the headache of passing arrays. Doing so risks making an overly complex library but will perhaps allow the programmer more flexibility.
- Creating private variables that retain answers to past questions. Doing so would enable the above and it would reduce the need to access the UART connection which suffers from typical serial transmission errors (corrupt characters, timing issues, etc). If the volume hasn't been changed since the last time the main sketch asked, don't ask the physical MiP again - just return the buffered answer.
- Treating MiP_commands more like a MiP (object) instead of its interface. If the main sketch asks 'getHeadLEDs' it's asking MiP instead of asking that the message be passed. This would necessitate changing the file name from MiP_commands to, simply, MiP.
- Deciding on a strategy for creating enums. Right now, sounds are in a file separate from all other enums. Should the other enums get their own file? How many values or which values should get an enum?
- Similar to the above, select a style guide and stick with it.
A possible implementation:
Thoughts?