<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Steve,<div class=""><br class=""></div><div class="">Just double-checked my instructions. I said set flash size to 1MB, but meant 4MB. That’ll work better for DEVKIT-C.</div><div class=""><br class=""></div><div class="">I think if you change partitions.csv to this, it should work ok in 4MB flash:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""># OVMS 16MB flash ESP32 Partition Table</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class=""># Name, Type, SubType, Offset, Size</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">nvs, data, nvs, 0x9000, 0x4000</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">otadata, data, ota, 0xd000, 0x2000</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">phy_init, data, phy, 0xf000, 0x1000</span></font></div><div class=""><font face="Andale Mono" class=""><span style="font-size: 18px;" class="">factory, app, factory, 0x10000, 0x280000</span></font></div><div class=""><span style="font-size: 18px; font-family: 'Andale Mono';" class="">store, data, spiffs, , 1M</span></div></blockquote><div class=""><br class=""></div><div class="">I haven’t tested, but that seems about right. 2.5MB for the factory app, no OTA, and 1M to be ready for spiffs (config) when it comes.</div><div class=""><br class=""></div><div class="">I got my 16MB (128Mbit) flash chips from aliexpress/taobao. It seems that the winbond stuff is more popular in China. If you stay helping out on the framework side of things for the moment, the 4MB DEVKIT-C should be fine. Only pain is having to hold down that BOOT button to flash it (which newer modules, including OVMS v3, avoid with better transistor logic).</div><div class=""><br class=""></div><div class="">Helping out on the framework would be really useful. Would free me up some time to work on the other impacting stuff (in particular SPI and power consumption are the most pressing).</div><div class=""><br class=""></div><div class="">If you could work on the console/command system, that would be wonderful. The basics are there, but some polishing would be most appreciated. In particular:</div><div class=""><br class=""></div><div class=""><ul class="MailOutline"><li class="">Microrl tab expansion<br class=""><br class="">Microrl has a tab expansion callback mechanism (set callback with microrl_set_complete_callback). That would presumably need to be able to ask the command system for completion results, and return them to microrl. Not too difficult, and perhaps a good starting point. This is in command.{h,cpp} and console.{h,cpp}.<br class=""><br class=""></li><li class="">Microrl cursor history display bug<br class=""><br class="">It seems that ESP32 console (printf, etc) does buffering. I worked around that with a fflush(stdout) in appropriate places, but there is one place it still doesn’t seem to work correctly. Type “help” as an example command. Then cursor-up, and the display doesn’t change. But, press ENTER and “help” command is displayed and run. It seems that cursor up/down history recall is always one line behind the actual history recalled. I’m guessing this is to do with buffering, but maybe completely unrelated. This would be a good one to fix. This is in console_async.{h,cpp} and the microrl component.<br class=""><br class=""></li><li class="">Command argument specification<br class=""><br class="">Currently, we register commands with "RegisterCommand(std::string name, std::string title, void (*execute)(int, OvmsWriter*, int, const char* const*))”. It would be good to have commands also register the minimum and maximum number of parameters they expect (and store in class OvmsCommand). Then, when a command is executed, validate the parameters centrally and output errors if the parameters supplied don’t match. That way, we don’t need to validate them in each and every command implementation. This is in command.{h,cpp}, as well as anywhere that calls RegisterCommand (although presumably if we put the parameters on the end of the RegisterCommand list with =-1 as defaults, to signify no limit, or minimum=0 maximum=999?, we could have sensible defaults that wouldn’t require changing everything).</li></ul></div><div class=""><br class=""></div><div class="">With that, the command/console system would be pretty complete. The only other thing on that is the ‘alert/progress messages’ thing (which is about interrupting the entry of a command to display an alert/progress message, then re-drawing the command input and letting the user carry on typing). I just haven’t thought much about how to actually implement that. It is related to the event system, but also the ability for commands to start tasks that feedback data after the command has completed.</div><div class=""><br class=""></div><div class="">In general, you need to have a github account and clone the Open-Vehicle-Monitoring-System-3 project to your own account, then pull from there. When you make a change, make it to your own clone. Then, when you have something to contribute back, you send us a pull request (using github). I’ve explained that really badly, but hopefully you get the idea.</div><div class=""><br class=""></div><div class="">Regards, Mark.</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 3 Jul 2017, at 1:22 AM, Stephen Casner <<a href="mailto:casner@acm.org" class="">casner@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Mark,<br class=""><br class="">I've pulled down the code and built it and loaded it successfully on<br class="">the DEVKIT-C per your instructions. I have mine mounted on a<br class="">breadboard and could add the 16MB RAM, but the chip you reference<br class="">seems not to be available from DigiKey, Mouser, etc. Google only<br class="">lists <a href="http://hkinventory.com" class="">hkinventory.com</a> as a source. Are there some available mounted<br class="">on a breakout board suitable for use in the breadboard? I am able to<br class="">solder an SOIC device to a breakout board if needed. Or are you<br class="">planning to distribute OVMSv3 prototypes in a similar timeframe?<br class=""><br class="">Looking over the TODO list, perhaps some thing in the Console/Command<br class="">section would be a good place for me to start?<br class=""><br class=""> -- Steve<br class="">_______________________________________________<br class="">OvmsDev mailing list<br class=""><a href="mailto:OvmsDev@lists.teslaclub.hk" class="">OvmsDev@lists.teslaclub.hk</a><br class="">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br class=""></div></div></blockquote></div><br class=""></div></body></html>