Hi,
I am working on an addition to APM that manages a data connection via a DroneCell or other cellular modem. It maintains control of the mobile and checks the state of the connection, instead of just putting it into transparent mode and hoping everything will be OK.
It has worked fine under ArduPlane 2.68. Now I am trying to integrate it into 2.70 while preparing for some finishing touches like being able to work with several different cellular modules.
I am running into a problem with the current design of the APM code, which I think will only get worse in the future, as we will probably have even more possibilities for data connections - on-board IP stack, 3 and 4G, etc.
The problem is that the concern of basic I/O is mixed with that of printing strings. This forces one to make more specializations for the different hardware and simulation platforms that may be necessary. I have made an UML, existingDesignWithAdditions.pdf, that shows the current layout with addition of my MobileDriver which is again made to work with 2 different modems. The need to support printing in basically all streams results in a (too) large number of subclasses for the different platforms.
In eg. Java the concern of printing character stuff is separated from that of doing I/O. That is quite nice - you can combine any I/O stream with any character printer, or with none at all. Could this be done here too?
I have put together the UML newDesign.pdf to illustrate (some trivial methods were omitted). Stream does not inherit from Print, and BetterStream basically is renamed to BufferedIOStream. To print, one makes a PrintStream with a reference to the BetterStream (could strictly just habe been a Stream). PrintStream implements the interface of BufferedIOStream but just forwards all non-print messages to its stream. For the platform specifics of printing, concrete subclasses of PrintStream for each platform exist.
Now things are orthogonal and the subclass explosion is gone.
Would there be anything in the way of using this design? OK I have only checked with ArduPlane. Is there some Arduino interface for streams that say they must have printf, and is it necessary to stick with that?
I'd happily implement it - just need to be on the developer list first... :)
Regards
Soren
Replies
The printf family of functions with formatted text messages are very costly on a 8-bit AVR processor (even to some degree on 32-bit ARM), and should be avoided at all cost when doing real time communications. It's mostly there to support the CLI mode.