[Ovmsdev] Newbie question & initial report

Fri Oct 6 17:25:08 HKT 2017

> Q: How do I convince git to update the esp-idf branch?

I tried the following (from developer’s guide):

$ git clone https://github.com/espressif/esp-idf.git <https://github.com/espressif/esp-idf.git>
$ cd esp-idf
$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/feature/psram_malloc
  remotes/origin/master
  remotes/origin/release/v2.0
  remotes/origin/release/v2.1
$ git checkout remotes/origin/release/v2.1
$ git branch
* (HEAD detached at origin/release/v2.1)
  master
$ git submodule update --init

That seemed ok, and a straight git pull on that origin seems to work:

$ git pull origin release/v2.1
From https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf>
 * branch            release/v2.1 -> FETCH_HEAD
Already up-to-date.

(Note, I’m using the openvehicles fork, but it should be the same)

Or, a ‘git fetch’ may be simpler:

$ git fetch -v
From https://github.com/openvehicles/esp-idf <https://github.com/openvehicles/esp-idf>
 = [up to date]      feature/psram_malloc -> origin/feature/psram_malloc
 = [up to date]      master     -> origin/master
 = [up to date]      release/v2.0 -> origin/release/v2.0
 = [up to date]      release/v2.1 -> origin/release/v2.1

There may be a better way (I’m far from a git expert), but that is how I do it.

> * I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!

The manufacturer is setup and used these 10 as a trial run to do the eFuse burning, and factory firmware burning. I also did it, with latest, to be 100% certain the 10 were ok before sending out. This is why I’ve been scrambling to get OTA working. If we can get that done, then it becomes a simple ‘ota flash http’ command to do an over-the-air update. Desperately trying to get a workable first firmware together, as feature rich as possible, to serve as factory firmware - the updates can come over the air, so long as the basic factory firmware supports it.

On that topic, I’d appreciate it if those of you with the latest firmware (today’s) can try a ‘ota flash http’ and see if it works for you. You’ll need to do a ‘ota boot factory’ afterwards, to make sure it boots from factory partition, afterwards (as normally ‘ota flash http’ will switch to ota partition after a successful flash).

Regards, Mark

> On 6 Oct 2017, at 5:02 PM, HONDA S-2000 <s2000 at audiobanshee.com> wrote:
> 
> I’ll start with my priority question, then summarize a few things I’ve learned that might be of interest.
> 
> Q: How do I convince git to update the esp-idf branch?
> 
> I grabbed the v2.1 release branch and built it without any obvious errors, but I don’t know how to pull or otherwise check that I have the latest. Here’s a snapshot of my current state:
> 
> $ git status
> HEAD detached at origin/release/v2.1
> nothing to commit, working directory clean
> $ git branch
> * (detached from origin/release/v2.1)
>   master
> $ git pull
> remote: Counting objects: 189, done.
> remote: Compressing objects: 100% (50/50), done.
> remote: Total 189 (delta 141), reused 185 (delta 137), pack-reused 0
> Receiving objects: 100% (189/189), 27.68 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (141/141), completed with 55 local objects.
> From https://github.com/espressif/esp-idf <https://github.com/espressif/esp-idf>
>    e6afe28..de750e9  master     -> origin/master
> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.
> 
>     git pull <remote> <branch>
> 
> $ git pull
> You are not currently on a branch. Please specify which
> branch you want to merge with. See git-pull(1) for details.
> 
>     git pull <remote> <branch>
> 
> $ 
> 
> 
> A: After reading the warnings about the Silicon Labs driver crashes, I decided to host my efforts on OS X Yosemite, 10.10.5, instead of any newer macOS. Therefore, I installed the legacy driver. So far, I’ve not had any problems. I’m able to connect to the OVMS v3 and communicate. I am using a cheap, $4.99 Full Speed USB hub (unpowered, because I’m too lazy to hunt for the wall wart adaptor). I realize that a powered hub is recommended, but I’ve not had any issues yet.
> 
> 
> B: Those of you who may not be familiar with the ‘screen’ application might be interested to read that I am able to connect to the USB serial converter using that program without running ‘make monitor’ - the only drawback is that I have to type Control-j instead of return/enter (but that might be resolved by another command line option that I’m not familiar with yet).
> 
> The command is ‘screen /dev/tty.SLAB_USBtoUART 115200’
> I’m avoiding /dev/cu.SLAB_USBtoUART because I assume it might activate the RTS / DTR / etc lines and cause unexpected results.
> 
> 
> C: I’m often quite paranoid about checking that new hardware is functional before I try building my own firmware, erasing any existing firmware, and therefore basically avoid trying too many steps in the first volley. Although I’ve build the esp-idf environment, I haven’t run ‘make monitor’ yet, so I was happy to see that the OVMS v3 shipped with a working firmware already installed (*). Using the ‘screen’ command detailed above, I am able to connect to the device, turn on the wifi, and execute commands.
> 
> OVMS > ota status
> Firmware: 3.0.0/factory/main build (idf v2.1-2-g7138fb02) Sep 21 2017 20:33:27
> Running partition: factory
> Boot partition: factory
> 
> OVMS > wifi mode ap TR25
> Starting WIFI as access point...
> I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
> I (575846) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE
> W (576526) phy_init: failed to load RF calibration data (0x1102), falling back to full calibration
> I (576706) phy: phy_version: 355.1, 59464c5, Jun 14 2017, 20:25:06, 0, 2
> I (575846) wifi: wifi firmware version: 407bb27
> I (575846) wifi: config NVS flash: enabled
> I (575846) wifi: config nano formating: disabled
> I (575866) wifi: Init dynamic tx buffer num: 32
> I (575866) wifi: Init dynamic rx buffer num: 32
> I (575866) wifi: wifi driver task: 3ffe9ad8, prio:23, stack:4096
> I (575866) wifi: Init static rx buffer num: 10
> I (575866) wifi: Init dynamic rx buffer num: 32
> I (575866) wifi: Init rx ampdu len mblock:7
> I (575866) wifi: Init lldesc rx ampdu entry mblock:4
> I (575866) wifi: wifi power manager task: 0x3ffef880 prio: 21 stack: 2560
> I (576526) wifi: wifi timer task: 3fff0af0, prio:22, stack:3584
> I (576706) wifi: mode : softAP (30:ae:a4:37:25:85)
> I (576716) ovms-mdns: Launching MDNS service
> [Join...]
> I (643136) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1
> I (643146) wifi: station: f4:5c:89:a3:64:cd join, AID=1, g, 20
> [Leave...]
> I (789976) wifi: station: f4:5c:89:a3:64:cd leave, AID = 1
> I (789976) wifi: n:1 0, o:1 0, ap:1 1, sta:255 255, prof:1
> 
> D: My next step is obviously to build the latest OVMS v3 firmware from git. I’m not having any trouble pulling the latest source updates because we’re not working on a branch, and it’s much easier to use git commands when working from the head / master (at least for me - I’m way more familiar with Subversion).
> 
> Brian Willoughby
> 
> * I don’t know whether Mark had to manually install the OVMS v3 firmware on each of these preliminary units, or if the assembly / manufacturing process is already set up to install an initial firmware on new boards. Either way, it’s nice that it didn’t arrive with a blank Flash!
> 
> _______________________________________________
> 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/20171006/3dac4a10/attachment.htm>