[Ovmsdev] OVMS v3 framework on GITHUB

Sun Jul 2 22:26:54 HKT 2017

I’ve released what I have so far at:

https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3>

From now on, I’ll push directly to there, and accept pull requests.

DEVKIT-C

To get it up and running on a DEVKIT-C style device, you will have to ‘make menuconfig’, and change (a) flash size to 1MB, (b) partition table to just a single factory image (no OTA). That will break when we bring the config system and SPIFS filesystem in flash online, but is workable for the moment. Our OTA and config flash will just rely on the partition table contents, so should continue to work with this (although you will need a custom partition table to work in 4MB).

A better solution is to use an external 16MB flash chip, on a breadboard with the DEVKIT-C. Not hard to do.

Physical wiring (for W25R128 and DEVKIT-C):
#1 -> IO22 (FL_CS2)
#2 -> SD0 (FL_SD0)
#3 -> SD3 (FL_WP)
#4 -> GND
#5 -> SD1 (FL_SD1)
#6 -> CLK (FL_CLK)
#7 -> SD2 (FL_HOLD)
#8 -> 3.3v

Fuse blowing (take great care - this is a one-time operation):
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_REG 1
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_TIEH 1
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse XPD_SDIO_FORCE 1
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CLK 6
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_Q 7
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_D 8
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_HD 9
espefuse.py -p /dev/tty.SLAB_USBtoUART burn_efuse SPI_PAD_CONFIG_CS0 22

If you do it right, it will look like this:

Config fuses:
XPD_SDIO_FORCE         Ignore MTDI pin (GPIO12) for VDD_SDIO on reset    = 1 R/W (0x1)
XPD_SDIO_REG           If XPD_SDIO_FORCE, enable VDD_SDIO reg on reset   = 1 R/W (0x1)
XPD_SDIO_TIEH          If XPD_SDIO_FORCE & XPD_SDIO_REG, 1=3.3V 0=1.8V   = 1 R/W (0x1)
SPI_PAD_CONFIG_CLK     Override SD_CLK pad (GPIO6/SPICLK)                = 6 R/W (0x6)
SPI_PAD_CONFIG_Q       Override SD_DATA_0 pad (GPIO7/SPIQ)               = 7 R/W (0x7)
SPI_PAD_CONFIG_D       Override SD_DATA_1 pad (GPIO8/SPID)               = 8 R/W (0x8)
SPI_PAD_CONFIG_HD      Override SD_DATA_2 pad (GPIO9/SPIHD)              = 9 R/W (0x9)
SPI_PAD_CONFIG_CS0     Override SD_CMD pad (GPIO11/SPICS0)               = 22 R/W (0x16)
DISABLE_SDIO_HOST      Disable SDIO host                                 = 0 R/W (0x0)

FIRST TIME BOOT

You should see something like this:

rst:0x1 (POWERON_RESET),boot:0x1f (SPI_FAST_FLASH_BOOT)

I (85) boot: SPI Speed      : 40MHz
I (85) boot: SPI Mode       : DIO
I (94) boot: SPI Flash Size : 16MB
I (106) boot: Partition Table:
I (118) boot: ## Label            Usage          Type ST Offset   Length
I (140) boot:  0 nvs              WiFi data        01 02 00009000 00004000
I (164) boot:  1 otadata          OTA data         01 00 0000d000 00002000
I (187) boot:  2 phy_init         RF data          01 01 0000f000 00001000
I (210) boot:  3 factory          factory app      00 00 00010000 00400000
I (233) boot:  4 ota_0            OTA app          00 10 00410000 00400000
I (257) boot:  5 ota_1            OTA app          00 11 00810000 00400000
I (280) boot:  6 store            Unknown data     01 82 00c10000 00100000

Initialising COMMAND Framework
Initialising METRICS Framework
Initialising OVMS Peripherals...
  SPI bus...
  MAX7317 I/O Expander...
  ESP32 CAN...
  ESP32 ADC...
  MCP2515 CAN 1/2...
  MCP2515 CAN 2/2...
  SD CARD...
Initialising TEST Framework
Initialising SD CARD Framework
Initialising MAX7317 EGPIO Framework
Initialising VFS Framework
Registering Vehicle: Tesla Roadster
Initialising HOUSEKEEPING Framework...
I (1657) cpu_start: Starting scheduler on PRO CPU.
I (509) cpu_start: Starting scheduler on APP CPU.

Welcome to the Open Vehicle Monitoring System (OVMS) - async console
OVMS >

CONSOLE

First thing you’ll see if we’ve unified everything into a command console. This console can be accessed over USB, and in future we’ll support WIFI, BLUETOOTH, SMS, GPRS, etc. The point is that all console commands work the same, no matter where they are called from. All core functionality will be exposed via console commands.

Here is an example session (live from my test system):

Welcome to the Open Vehicle Monitoring System (OVMS) - async console

OVMS > sd mount
Name: SD
Type: SDHC/SDXC
Speed: default speed
Size: 15120MB
CSD: ver=1, sector_size=512, capacity=30965760 read_bl_len=9
SCR: sd_spec=2, bus_width=5
Mounted SD CARD

OVMS > vfs ls /sdcard
SPOTLI~1
VFS.CPP
COMMAND.CPP
COMMAND.H
COMPON~1.MK
CONSOL~1.CPP
CONSOL~1.H
METRICS.CPP
METRICS.H
OVMS.H
OVMS_M~1.CPP
PERIPH~1.CPP
PERIPH~1.H
TERMINAL.CPP
TERMINAL.H
TEST_F~1.CPP
TEST_F~1.H

OVMS > vfs rm /sdcard/OVMS.H
VFS File deleted

OVMS > egpio output 1 255
EGPIO port 1 set to output level 255

OVMS > sd unmount
Unmounted SD CARD

OVMS > metrics list
m.version
v.b.12v                        0
v.b.cac
v.b.range.e
v.b.range.i
v.b.soc
v.b.soh
v.b.temp.ambient
v.b.temp.charger
v.b.temp.motor
v.b.temp.pem
v.p.altitude
v.p.direction
v.p.latitude
v.p.longitude
v.p.odometer
v.p.speed
v.p.trip
v.tp.fl.p
v.tp.fl.t
v.tp.fr.p
v.tp.fr.t
v.tp.rl.p
v.tp.rl.t
v.tp.rr.p
v.tp.rr.t
v.type
v.vin

OVMS > ?
egpio                EGPIO framework
help                 Ask for help
metrics              METRICS framework
sd                   SD CARD framework
test                 Test framework
vfs                  VFS framework

Tab completion is not done yet, but you can do a “?” to see what is available.

METRICS

You’ll see these metrics as a new thing in OVMS v3. The idea is that rather than having hard-coded items, we have a dynamic extendable list of metrics. Some are standard (look in metrics_standard.h), but others can be added by vehicle modules (or any part of the system, really).

These metrics will be used for MQTT, but also joined back together into groups for OVMS v2 protocol.

LANGUAGE

The code is in C++. The choice there was because (a) I wanted collections (maps, arrays, etc), (b) I wanted components to be able to self-register without having to change the framework (you just put the component in the right place and it merges itself into the system). Most of the code itself is basic C.

CODE STRUCTURE

The ‘main’ directory contains the framework itself. Only people playing with the framework should have to change that.

The ‘components’ directory contains the extension components. This is where the system is extended.

Within ‘main’, we have:
command.cpp - the console command processor
config.cpp - the configuration system
console_async.cpp - an async console for USB port
housekeeping.cpp - housekeeping tasks (e.g. measuring the 12v level every few seconds and updating the v.b.12v metric)
metrics.cpp - the metrics system
metrics_standard.h - the standard metrics
ovms_main.cpp - the main entry point
peripherals.cpp - access to all the peripherals in the system
terminal.cpp - an experiment that didn’t work and will go soon
test_framework.cpp - test framework for QC
vfs.cpp - access to the virtual filesystem (from console)
Within ‘components’, we have:
can - a unified interface to CAN buses
esp32can - CAN bus native to the ESP32
mcp2515 - CAN bus on the MCP2515 chips, controlled by SPI
esp32adc - The ADC (for measuring 12v voltage level)
max7317 - The extended GPIO (EGPIO), controlled by SPI
microrl - A command line processing library
pcp - Power Controlled Peripheral (a base layer for all out peripherals so we can power control them in a unified way)
sdcard - SD CARD control
spinodma - A SPI master driver that doesn’t use DMA (suitable for the small transfers we do) and is extendable beyond the hardware limit of 3 devices per SPI bus
vehicle - The base vehicle layer
vehicle_teslaroadster - An example project to add vehicle support for Tesla Roadster
There are some code consistency issues at the moment. Things like lowercasevariables vs ThoseLikeThis. I’m trying to clean that up, as the code has come from lots of different places.

CHANGES.TXT

There is a CHANGES.TXT file. As I make changes (or incorporate other people’s changes), I’ll update it.

TODO.TXT

There is a list of tasks outstanding in TODO.TXT. If anything interests you, please let me know and I’ll be happy to assign it to you (as well as extremely grateful :-).

I’m still trying to validate all the hardware, and ensure everything works. That means moving over the test code I have into proper libraries in this framework, and implement test_framework, or other, commands to allow them to be tested. Some are stubs, but most in the OVMS.V3 github are now live and working. See TODO.TXT for the latest status.

Enjoy,
Mark.

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