I've put together a first-draft of the OVMS developers document. Something to document, at a high-level, the OVMS code, to make it easier to extend and use it (in particular for those writing vehicle modules). You can find it on github, in the docs directory. The PDF is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... The DOCX document is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV... Note that the code development hints and tools section comes from Michael B's Firmware-Development.odt document in the same directory. Thanks, Michael. The vehicle side of this document is mostly complete. What is missing are some conclusions, and the server and apps parts. But, it is good enough to be used for vehicle side today. I will keep working on it. If you see anything wrong, or think some parts of need expanding / removing, please let me know. Regards, Mark. P.S. Like other OVMS documents, it is in DOCX and PDF format. Not because I like it, but because I've given up ;-) It pains me every time I start Microsoft Word on my Mac. Some day, the world will be rid of Microsoft Office, just not today.
Mark, excellent! Should save quite some time for Nikolay and those to come. My document can be removed from the repository, nothing left in there. My part includes an sprintf() example... I now recommend replacing that and also adding a "No sprintf()" section. I'm pretty sure we should totally avoid using that function family from now on, I've had not a single crash since removing the last sprintf() call. The section could include a simple guide on the stp_*() functions. Also, some guide and examples on using the framework network functions would be good. E.g. how to send an SMS, a MSG, buffers & status variables to use, size limits etc.. I think the raw document file format doesn't matter as long as OpenOffice can at least read it and we provide PDFs. Btw: from writing the Twizy user guide, I got the impression a common setup/network configuration guide separated from the Tesla guide could make sense. So we would have one common user guide plus the vehicle specific guides. Some parts I included in the Twizy guide could also be moved to the common guide, i.e. the "dry run" section. Regards, Michael Am 11.01.2013 15:09, schrieb Mark Webb-Johnson:
I've put together a first-draft of the OVMS developers document. Something to document, at a high-level, the OVMS code, to make it easier to extend and use it (in particular for those writing vehicle modules).
You can find it on github, in the docs directory.
The PDF is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV...
The DOCX document is here: https://github.com/markwj/Open-Vehicle-Monitoring-System/blob/master/docs/OV...
Note that the code development hints and tools section comes from Michael B's Firmware-Development.odt document in the same directory. Thanks, Michael.
The vehicle side of this document is mostly complete. What is missing are some conclusions, and the server and apps parts. But, it is good enough to be used for vehicle side today. I will keep working on it. If you see anything wrong, or think some parts of need expanding / removing, please let me know.
Regards, Mark.
P.S. Like other OVMS documents, it is in DOCX and PDF format. Not because I like it, but because I've given up ;-) It pains me every time I start Microsoft Word on my Mac. Some day, the world will be rid of Microsoft Office, just not today.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Paradestr. 8 * D-42107 Wuppertal Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
participants (2)
-
Mark Webb-Johnson -
Michael Balzer