[Ovmsdev] OVMS v3 framework on GITHUB

[Mark Webb-Johnson]

Steve,

Just double-checked my instructions. I said set flash size to 1MB, but meant 4MB. That’ll work better for DEVKIT-C.

I think if you change partitions.csv to this, it should work ok in 4MB flash:

# OVMS 16MB flash ESP32 Partition Table
# Name,   Type, SubType, Offset,   Size
nvs,      data, nvs,     0x9000,  0x4000
otadata,  data, ota,     0xd000,  0x2000
phy_init, data, phy,     0xf000,  0x1000
factory,  app,  factory, 0x10000, 0x280000
store,    data, spiffs,  ,        1M

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.

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).

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).

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:

Microrl tab expansion

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}.

Microrl cursor history display bug

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.

Command argument specification

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).

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.

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.

Regards, Mark.

> On 3 Jul 2017, at 1:22 AM, Stephen Casner <casner at acm.org> wrote:
> 
> Mark,
> 
> I've pulled down the code and built it and loaded it successfully on
> the DEVKIT-C per your instructions.  I have mine mounted on a
> breadboard and could add the 16MB RAM, but the chip you reference
> seems not to be available from DigiKey, Mouser, etc.  Google only
> lists hkinventory.com as a source.  Are there some available mounted
> on a breakout board suitable for use in the breadboard?  I am able to
> solder an SOIC device to a breakout board if needed.  Or are you
> planning to distribute OVMSv3 prototypes in a similar timeframe?
> 
> Looking over the TODO list, perhaps some thing in the Console/Command
> section would be a good place for me to start?
> 
>                                                        -- Steve
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20170703/76eaf5a9/attachment.htm>