Tom, Looks good. The V1 firmware (both experimental and production) only contains vehicle_none and vehicle_roadster. The V2 firmware (both experimental and production) contains all supported vehicles. So, no need to direct owners to particular builds. Note that in future we may need to split the V2 firmware into vehicle groups (eg; V2_production_group1, V2_production_group2, etc) if we run out of code space due to too many vehicles being supported - but that would be a good place to be at :-) For current level of vehicle support, you can refer to: http://www.openvehicles.com/vehiclesupport The difference between experimental and production is currently only that experimental includes the Tesla Roadster v2.x digital speedo code. Regards, Mark. P.S. I've removed those old firmware .hex files (VA_*, TR_*, RT_*, etc). I'm also going to .gitignore the vehicle/OVMS.x/dist tree entirely, to stop future confusion, and rely on manual copy to vehicle/firmware when we actually release. On 17 Jan, 2013, at 1:33 PM, Tom Saxton wrote:
Go it! The firmware update page is now updated with links straight to the github files, with the note to Roadster owners as well as the link to the release notes.
Is Twizzy and Volt support built into the V2 hardware production build, or just the experimental? I'm just wondering if I need to direct those owners to one build or the other.
Tom
on 1/16/13 7:53 PM, Mark Webb-Johnson wrote:
Tom,
For firmware v2.x builds, there are now just 4:
V1_experimental.hex V1 Hardware Module, experimental firmware V1_production.hex V1 Hardware Module, production firmware V2_experimental.hex V2 Hardware Module, experimental firmware V2_production.hex V2 Hardware Module, production firmware
A single firmware supports multiple vehicle types (selectable at run-time based on parameter #14 (or the fourth argument to the "MODULE" SMS command).
It may be worth pointing out the following on the update page:
For Tesla Roadster owners, once you upgrade firmware from v1 to v2, you will need to either: (a) SMS "MODULE" command again to include the fourth parameter vehicle type "TR", or (b) use the iOS App to set parameter #14 to "TR" (you can even do this in the App _before_ you upgrade). You will require this for the CAN bus stuff to work. We have updated the Tesla Roadster user guide to reflect this new parameter.
Regards, Mark.
On 17 Jan, 2013, at 11:29 AM, Tom Saxton wrote:
The idea of permanent links sounds great, but now I'm confused.
I just flashed my V1 Roadster module, and it comes up as version 1.5.1. Now that I look more carefully, I see that all of the .hex files I grabbed from my updated OVMS directory are dated 10/21/2012. For example,
vehicle/OVMS.X/dist/RT_V2_Experimental
Looking at the links in the tagged v2.2.2 folder, I just see four builds (V1,V2)x(Experimental,Production). I expected to see builds for each vehicle.
Or is V1 just for the Roadster and the V2 build dynamically figures out which vehicle it's on?
Tom
on 1/16/13 5:39 PM, Mark Webb-Johnson wrote:
I think I may have a solution for this (going forward).
If we use the git 'tags' feature, to tag each released firmware build, github will allow us to publish the tree at that time. For example, see:
https://github.com/markwj/Open-Vehicle-Monitoring-System/tree/v2.2.2/vehicle /f irmware
And an example link to the v2.2.2 V2 production firmware is:
https://github.com/markwj/Open-Vehicle-Monitoring-System/raw/v2.2.2/vehicle/ fi rmware/V2_production.hex
That link is quite clean and should be stable going forward. It will just take some discipline to set things up correctly during a release:
Build all firmware Copy the .hex files to the firmware folder Update the change log Commit Tag the commit push (--tags) to github Announce the new version
What do people think? Sensible?
Regards, Mark.
On 15 Jan, 2013, at 8:38 AM, Mark Webb-Johnson wrote:
I think this approach is ok, and given github's approach probably the best way.
I really wish that github had a 'files' repository (like sourceforge) that we could put fixed (not revision controlled) files. Release, not development, files. I tried to create symlinks (in the 'firmware' folder), but they don't work (the symlink text file is just downloaded, not the thing it linked to), and anyway that doesn't give us history.
I've got a git guru on staff here at work - I'll ask him for his advise.
Regards, Mark.
On 15 Jan, 2013, at 5:49 AM, Tom Saxton wrote:
That directory structure changes about as often as there are new official releases, as you can tell by all of the orphan build directories. Linking straight into the repository won't let me pick up new vehicles, and will break when vehicles go from "experimental" to "production" status.
The release notes aren't in the repository (AFAIK), so I have to enter those links manually as well.
Given that I have to manually update the page, I figure it's more reliable to ferret out the right versions for each vehicle and copy them to my site. This way, my page keeps working even if the repository changes, which means less work maintaining the page between releases (which is currently zero effort).
Anyone who's really into getting the latest builds can just grab the files from the repository. My page is to support those who don't care enough to climb that learning curve.
Tom
on 1/14/13 1:23 PM, Michael Balzer wrote:
> Thanks, Tom! > > Hm... to optimize the rollout, have you tried to link directly to the > repository files? > > The links in vehicle/firmware don't work, but using the github file > browser I can get for example... > > https://raw.github.com/markwj/Open-Vehicle-Monitoring-System/master/vehic > le > /OV > MS.X/dist/V2_Experimental/production/OVMS.X.production.hex > > I'm new to github, but that URL scheme looks like being designed as a > permanent link. > > Regards, > Michael > > > Am 14.01.2013 21:13, schrieb Tom Saxton: >> The firmware update guide page now has version 2.2.2 builds up. >> >> http://www.idleloop.com/tesla/ovms/ >> >> Tom >> >> >> _______________________________________________ >> OvmsDev mailing list >> OvmsDev@lists.teslaclub.hk >> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev