[Ovmsdev] v2.2.2

Tom Saxton tom at idleloop.com
Thu Jan 17 14:09:48 HKT 2013 

That's all great. I've updated the firmware page to include a link to the
OVMS Vehicle Support page.

I notice that the vehicle support matrix says that Digital Speedo is "Yes"
on Roadster v1.x and "Not Yet" on 2.x. Shouldn't it be "No" for 1.x?

    Tom

on 1/16/13 9:53 PM, Mark Webb-Johnson wrote:

> 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/vehic
>>>>> le
>>>>> /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/vehicl
>>>>> e/
>>>>> 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/veh
>>>>>>>> ic
>>>>>>>> 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 at lists.teslaclub.hk
>>>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> OvmsDev mailing list
>>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OvmsDev mailing list
>>>>>> OvmsDev at lists.teslaclub.hk
>>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>>> 
>>>>> _______________________________________________
>>>>> OvmsDev mailing list
>>>>> OvmsDev at lists.teslaclub.hk
>>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OvmsDev mailing list
>>>> OvmsDev at lists.teslaclub.hk
>>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.teslaclub.hk
>>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

More information about the OvmsDev mailing list