[Ovmsdev] Merging in Twizy and Volt/Ampera work
dexter at expeedo.de
Sun Nov 18 21:14:58 HKT 2012
merged & checked & flashed & works :-)
Am 18.11.2012 13:38, schrieb Mark Webb-Johnson:
> I've just pushed my last set of changes. It seems ok from my end now.
> The code runs and sms commands function as expected. I've added a
> capabilities message that is sent car->server->apps and will be useful
> to tailor the app functions to what the car can do.
> Can you merge mine in with yours, and check if it all looks ok to you?
> I'm now going to flash this firmware into my car to see how it behaves.
> Regards, Mark.
> On 18 Nov, 2012, at 8:11 PM, Michael Balzer <dexter at expeedo.de
> <mailto:dexter at expeedo.de>> wrote:
>> I reworked my command dispatcher according to the new hook:
>> ...it works, but I'm not totally happy with it. To me it looks like
>> there should be no need for two hooks. Basically the only difference
>> between them now is, if the vehicle handler has to do the auth check
>> or not. So I internally already use one dispatcher and a control
>> parameter for this. If it needs to do the auth check, I use the same
>> mode control scheme like you do. Please have a look at it, maybe we
>> can reduce this to one hook.
>> My STAT command drops the charge mode (the Twizy does not have this)
>> and inserts SOC min+max after current SOC, so that's a replacement
>> case. But I added another command handler that's clearly an extension
>> (HELP), and with my new specific DEBUG command we now have all three
>> cases, and all work as designed (at least in diag mode, have to test
>> live mode yet).
>> Am 18.11.2012 09:49, schrieb Mark Webb-Johnson:
>>> I think there is a confusion around the use of vehicle_fn_smshandler
>>> - that is to override (premsg) or extend (!premsg) an existing SMS
>>> command. I hadn't thought about the vehicle module wanting its own
>>> SMS messages.
>>> We can do this in two ways: (1) expose a vehicle sms handler table
>>> to the net_sms code and have it look there, or (2) just hook in to
>>> the vehicle and let it handle sms messages itself. For the moment,
>>> I've chosen (2) as I think there will be relatively few
>>> vehicle-specific sms messages. The old way we did this was just
>>> 'strcmp' for each possible SMS commands. If there are not too many,
>>> that is fine and probably more efficient than having a dispatch
>>> table. Anyway, I've added a vehicle_fn_smsextensions now, which is
>>> called if the incoming sms is not recognised by net_sms and allows
>>> the vehicle to look.
>>> Michael B: can you try to migrate your Twizy code to this
>>> new vehicle_fn_smsextensions framework for Twizy-specific sms
>>> messages, and vehicle_fn_smshandler for the extension to the STAT
>>> command? Regarding your vehicle_twizy_sms_handle_stat() function, is
>>> it not possible to just extend (add a couple of lines) the SMS
>>> reply, rather than replace the entire command?
>>> I also tested the new net_sms arrangement, found a few bugs, and
>>> fixed them. Code is on github now.
>>> I'm now looking at implementing a registration mechanism so that the
>>> vehicle modules can register the commands they implement, as well as
>>> other parameters for what they support, and we can push this in
>>> net_msg when we connect to the server.
>>> Regards, Mark.
>>> On 18 Nov, 2012, at 4:38 AM, Michael Balzer <dexter at expeedo.de
>>> <mailto:dexter at expeedo.de>> wrote:
>>>> I ported my STAT changes to the new framework and tried to prepare
>>>> it for my first specific commands as well:
>>>> Haven't tested yet, but the vehicle / framework distinction becomes
>>>> very clean now I think.
>>>> Regarding hooking in the vehicle cmdtable: I now think that was
>>>> nonsense, as the vehicle dispatcher will need to parse the command
>>>> itself. I'll wait for your thoughts on if/how to integrate the
>>>> common auth stuff with this.
>>>> To get internal net_sms_stat() calls to use the overloaded
>>>> function, I suggest to inject the call through the SMS dispatcher
>>>> as shown in my commit. There's only one call outside net_sms, and
>>>> that's not time critical and using fixed (no) arguments. I also
>>>> think STAT is the only SMS we need to route like this (?)
>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 206 bytes
Desc: not available
More information about the OvmsDev