<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Following on from this, I’ve now brought across my previously uncommitted changes for ovms_script / ovms_command to the for-3.3 branch. This is a big set, affecting a bunch of modules.<div class=""><br class=""></div><div class="">The issues here were:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Duktape object and function resolution was in ovms_script, which loads quite late. After events and config, for example - so the extensions for those had to be put in ovms_script rather than their own files - ugly.<br class=""><br class=""></li><li class="">The ovms_script was dependent on ovms_command, which was dependent on ovms_script. Horrible.<br class=""><br class=""></li><li class="">The solution I implemented is to move duktape to ovms_duktape, and load that very early for duktape object and function registration. That avoids all the inter-dependency issues and allows anything to register duktape extensions.<br class=""><br class=""></li><li class="">The ovms_duktape / ovms_script code was also massive (> 3,000 lines), so I moved the non-code stuff out to their own files. Probably more can be done here, but at least now it is manageable at around 1,300 lines.</li></ul></div><div class=""><br class=""></div><div class="">With that done, I should be able to finally get the javascript command extensions implemented (the main justification for this work). This will allow javascript modules to register ovms command handlers and extend the command line.<br class=""><div><br class=""></div><div>Regards, Mark.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 30 Aug 2020, at 3:20 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div>The initial implementation of this work is in branch for-v3.3, in GitHub. That branch can be used for the upcoming 3.3 release, including potentially breaking changes.<div class=""><br class=""></div><div class="">I’d appreciate any feedback. For the SIM5360, the behaviour should be unchanged from the current implementation (except some improvements to edge cases and control logic). The major user visible change is from ’simcom’ to ‘modem’ for the console commands.</div><div class=""><br class=""></div><div class="">Regards, Mark.<br class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 20 Aug 2020, at 9:35 PM, Mark Webb-Johnson <<a href="mailto:mark@webb-johnson.net" class="">mark@webb-johnson.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">I have started the work on refactoring the modem driver to support virtual driver implementations (SIMCOM 5360 being just one of them). This is a major refactoring that will take some time to complete. It is likely that the following components/files will be affected:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Component simcom (major changes)</li><li class="">New component ovms_modem introduced</li><li class="">ovms_webserver/dev/commands.htm</li><li class="">ovms_webserver/src/web_cfg_init.cpp</li><li class="">ovms_webserver/src/web_cfg.cpp</li><li class="">Component powermgmt</li><li class="">And several other components mentioning Simcom, but only very minor changes</li></ul></div><div class=""><br class=""></div><div class="">I would appreciate it if no major changes were made to those components in the next week or two, as that may make merging difficult.</div><div class=""><br class=""></div><div class="">Once I’ve got the modem code refactored, and a compatible SIMCOM 5360 driver working, I’ll publish to the for-v3.3 branch for wider testing. I can then add the other modem drivers I have been working on.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class="">P.S. Pretty obvious that this work is to abstract out the modem type specific code, to make it easier to add support for other modem types in OVMS. This is a long-term project, and not something happening anytime soon, but I am working on it.</div><div class=""><br class=""></div></div>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class=""><a href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.openvehicles.com" class="">OvmsDev@lists.openvehicles.com</a><br class="">http://lists.openvehicles.com/mailman/listinfo/ovmsdev<br class=""></div></blockquote></div><br class=""></div></body></html>