[Ovmsdev] v2.2.2

Mark Webb-Johnson mark at openvehicles.com
Thu Jan 17 14:15:36 HKT 2013 

> 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?

Fixed.

Regards, Mark.

On 17 Jan, 2013, at 2:09 PM, Tom Saxton wrote:

> 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
> 
> 
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev

More information about the OvmsDev mailing list