[Ovmsdev] Merging in Twizy and Volt/Ampera work
Michael Balzer
dexter at expeedo.de
Sat Nov 17 03:52:42 HKT 2012
Mark,
I followed your branch naming, "v2" on my repository adds my latest
Twizy changes to the new framework.
Stunningly, V2 worked out of the box :-) Great job!
I will look into integrating the internal GPS flag so we don't need a
compiler switch for this as well. Does it make sense to couple this to
the car type or could someone with a GPS equipped car have some reason
to occasionally use the OVMS GPS instead?
I'll also port my specific STAT? version to the new framework ASAP.
I have one concern for the overlaying of the vehicle RAM sections: I now
changed most of my state variables to uninitialized to harden against
crash resets (we've got SRAM after all). That works quite well with the
old framework. I had no reset with V2 up to now -- my concern is, that
an initialized overlay from another vehicle will initialize my variables
as well. As all vehicle modules exist side by side now, can we introduce
two data sections, one explicitly being uninitialized? #pragma idata
seems to be meant for something like that, but everything's now in
udata, even initialized vars...
Regards,
Michael
Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:
> I've just committed another night's work on this. Looks good and now runs on actual hardware.
>
> I've extended the MODULE and MODULE? SMS commands with a fourth parameter - the car type - to allow this to be set. Also SMS VERSION now shows the car type being used.
>
> I've ported the SMS commands over to the new vehicle module framework, and they look good.
>
> I've bumped the version to 2.1.1, to reflect the major restructuring that this is.
>
> This will still only run on v2 hardware at present. No reason we can't support v1 (and will) - just need to tidy up the build configurations.
>
> Regards, Mark.
>
> On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>
>> I've just committed my work-in-progress for this to the github v2 branch.
>>
>> Best I can say about it is that it compiles and links without error.
>>
>> It would be a miracle if it actually ran. I doubt it. I haven't had a chance to test it on real hardware yet.
>>
>> The framework for multiple cars is there, and seems to work ok. I can't get the overlay data section working (yet) - it is there but doesn't seem to be overlaying the different vehicle data and saving ram like it should. I re-worked the 100 byte net_msg_cmd_msg to be a pointer, saving a lot of ram but possibly breaking more advanced commands like "AT", "MMI/USSD" and "SMS" - I'll test them when I get a chance to run this on real hardware.
>>
>> I followed Michael B's suggestion for the net_msg_cmd handlers, and the hooks in general. So far, the can hooks are there, as well as the re-work of the net_msg_cmd stuff to hook through to the vehicle. I haven't had a chance to remove some of the old stub functions yet.
>>
>> The overall approach is that I've moved the old common can code to vehicle.h and vehicle.c. This defines a series of hooks, for vehicle initialisation. When the system starts up, a PARAM_VEHICLETYPE is now used to define the type of vehicle, and initialise that one vehicle module. During initialisation, the vehicle module hooks itself in to other functions it requires. If it doesn't hook in, the function is handled by the default handler. Once this part is working well, I intend to add hooks for SMS messages as well.
>>
>> To create a new vehicle, we would need to create a vehicle_* module, add the #define for it, and change vehicle.c initialisation to detect the vehicle type and initialise the module. It would be nice to have a better plugin architecture for this, but we're (a) limited by c (not c++), and (b) any such architecture would need ram space which is at a premium compared to rom.
>>
>> I've still got a bit of work to go to tidy this up, but as it is now the vehicle modules certainly look neater and have a lot less stub functions. The current approach now lets arbitrary commands make it through the the individual vehicle modules for action - which will provide amazing opportunities for expansion, as well as avoiding having stub functions in the Twizy module for locking and unlocking the non-existent doors.
>>
>> Feel free to have a look at the code, and let me know what you think and if there is anything obviously wrong.
>>
>> Regards, Mark.
>>
>> On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>
>>> I've got the framework for this 70% done. So far, it builds and looks good. Code size for experimental v2 branch has gone from 50% of flash to 55% - including all vehicle modules for tesla roadster, twizy, volt/ampera, basic odbii and a null vehicle stub. RAM has gone up about 30 bytes, but that is part of the 30% not yet done.
>>>
>>> I've merged in all Michael B's recent changes (including stuff that may need to be looked at in light of this re-work).
>>>
>>> I'm going to do one more night on it, then commit what I have to the v2 branch for others to look at.
>>>
>>> Regards, Mark.
>>>
>>> On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson <mark at webb-johnson.net> wrote:
>>>
>>>> I think the general approach here is correct.
>>>>
>>>> It is a fine line between allowing the vehicle modules to do more, and duplicating common functionality in each module. But, your suggestion to implement the core functions centrally, then allow the vehicle modules to either override or extend those core functions, is a good solution. It can also be extended to SMS messages.
>>>>
>>>> I'm not sure about using command/response ("C", "c") to allow the Apps to query the module capabilities. Those are quite expensive for the Apps to issue: App->Server->Car->Server->App latency can be 1, 2 or more seconds over GPRS - doing that each time the App starts up is going to be expensive. We can do this just as easily by a published message type giving the capabilities of the car - and that message could be issued just once on module startup (with the application receiving a copy each time it connected to the server).
>>>>
>>>> This also fits in with my email a while ago about restructuring to include a single firmware with multiple vehicle modules switchable at runtime. I'm very interested in getting a generic ODBII module working as well (which could show speed, fuel tank pressure, ODBII fault codes, etc).
>>>>
>>>> We need to maintain the stability of the v1 system, as we have so many users using it at the moment. So, what I've just done is commit the last major change to v1 code - I've update the protocol manual formatting to make it clearer - and created two new branches ("v1" and "v2). Let's work in the "v2" branch to create a single unified firmware supporting Roadster, Twizy, Volt and generic ODBII on v2 hardware. For v1 hardware users (Roadster), we can always back-port new features as necessary.
>>>>
>>>> I can work on this now, so give me a few days to try to build the framework for this re-structure.
>>>>
>>>> Regards, Mark.
>>>>
>>>> On 10 Nov, 2012, at 10:10 PM, Michael Balzer <dexter at expeedo.de> wrote:
>>>>
>>>>> Am 04.11.2012 14:21, schrieb Mark Webb-Johnson:
>>>>>> For major new feature specific to a particular vehicle, I was hoping we can handle those by the command protocol. We could, for instance, route commands 100-200 directly through to the vehicle modules for response. We could also add hooks for the vehicle modules to directly transmit messages out (the protocol itself is extensible and new message types can be easily added).
>>>>> Mark, List,
>>>>>
>>>>> for the Twizy, it's not so much about extending but about reducing, as many current standard commands do not make sense on the Twizy. Some could also use slightly different implementations (STAT SMS as seen).
>>>>>
>>>>> I've thought about that last night and had fun reading into the net code. Cool stuff. I stumbled about a very simple way to not only enable routing of special commands to the car, but to also enable overloading of builtin commands. Seems you had something like that already in mind when writing that code :-)
>>>>>
>>>>> So the system net modules could implement just the common standard commands while the car modules would dynamically extend those with just their specific commands. Using a message passing scheme to mimic an OO sub class approach, a car module will be able to...
>>>>> - either leave a command handling to the system
>>>>> - or use and extend the system handling
>>>>> - or completely implement a command itself, possibly replacing a system handler.
>>>>>
>>>>> Current car specific hook calls like can_tx_setchargemode() can then be removed from the common net framework.
>>>>>
>>>>> To configure themselves accordingly, servers and apps may want to know the type and version of the car module, and a list of the commands supported by the firmware. To enable this, I would introduce two new msg commands:
>>>>>
>>>>> - 6 = car module type + version
>>>>> => reply scheme: "MP-0 c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"
>>>>>
>>>>> - 7 = list of commands supported
>>>>> => reply scheme: "MP-0 c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..."
>>>>> More than one list of each class can be sent, clients should collect and join all.
>>>>> I think IDs are sufficient, otherwise the reply scheme could be extended.
>>>>>
>>>>> Maybe a third one will make sense for the...
>>>>>
>>>>> - 8 = list of car data properties supported
>>>>> => reply scheme: "MP-0 c8,0,..." (todo? can make life easier for the App)
>>>>>
>>>>> Due to the structural beauty of the net code, this extension should be quite easy to implement. Please take a look at my implementation draft below and give me some feedback. The SMS part should be able to use the same approach.
>>>>>
>>>>> AFAIS this extension would require no immediate change to the existing server and apps, it just offers an opportunity for the next releases.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>>
>>>>> // ------------------- net_msg module ----------------------
>>>>>
>>>>> // REPLACE:
>>>>> void net_msg_cmd_do(void)
>>>>> {
>>>>> /****************************************************************
>>>>> * MSG COMMAND DISPATCHER
>>>>> * Called by: net_msg_cmd_in() & net_state_ticker1()
>>>>> *
>>>>> * GLOBAL PARAMS:
>>>>> * net_msg_cmd_code = int command id
>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>> */
>>>>>
>>>>> delay100(2);
>>>>>
>>>>> // commands 40-49 are special AT commands, thus, disable net_msg here
>>>>> if ((net_msg_cmd_code < 40) || (net_msg_cmd_code > 49))
>>>>> net_msg_start();
>>>>>
>>>>> // Execute cmd: ask car module to execute first:
>>>>> if( !car_msg_cmd_exec() )
>>>>> {
>>>>> // Car module does not feel responsible, fall back to standard:
>>>>> if( !net_msg_cmd_exec() )
>>>>> {
>>>>> // No standard as well => return "unimplemented"
>>>>> sprintf(net_scratchpad, (rom far char*)"MP-0 c%d,3",net_msg_cmd_code);
>>>>> net_msg_encode_puts();
>>>>> }
>>>>> }
>>>>>
>>>>> // terminate IPSEND by Ctrl-Z (should this be disabled for commands 40-49 as well?)
>>>>> net_msg_send();
>>>>>
>>>>> // clear command
>>>>> net_msg_cmd_code = 0;
>>>>> net_msg_cmd_msg[0] = 0;
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> // ADD:
>>>>> bool net_msg_cmd_exec(void)
>>>>> {
>>>>> /****************************************************************
>>>>> * IMPLEMENTATION OF STANDARD MSG COMMANDS
>>>>> * Called by: net_msg_cmd_do() & car specific cmd handlers
>>>>> *
>>>>> * GLOBAL PARAMS:
>>>>> * net_msg_cmd_code = int command id
>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>> *
>>>>> * RETURNS:
>>>>> * true if cmd has been handled
>>>>> */
>>>>>
>>>>> int k;
>>>>> char *p;
>>>>>
>>>>> switch (net_msg_cmd_code)
>>>>> {
>>>>> // ...std cmds 1-5 to be inserted here if compiler does no jump table optimization...
>>>>>
>>>>> case 7:
>>>>> // List commands supported (for peer configuration):
>>>>> // standard commands:
>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
>>>>> net_msg_encode_puts();
>>>>> // (can be extended if clients need more than the cmd ids)
>>>>> return true;
>>>>>
>>>>> // ...std cmds to be inserted here...
>>>>>
>>>>> default:
>>>>> // unhandled cmd_code:
>>>>> return false;
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> // ------------------- can_<model> or maybe separate car_<model> module ----------------------
>>>>>
>>>>> // ADD:
>>>>> bool car_msg_cmd_exec(void)
>>>>> {
>>>>> /****************************************************************
>>>>> * HOOK to integrate CAR SPECIFIC MSG command handlers
>>>>> * May overlay and/or extend the standard command set
>>>>> * Called by: net_msg_cmd_do()
>>>>> *
>>>>> * GLOBAL PARAMS:
>>>>> * net_msg_cmd_code = int command id
>>>>> * net_msg_cmd_msg = char * to first parameter
>>>>> *
>>>>> * RETURNS:
>>>>> * true : cmd has been handled completely
>>>>> * false: fallback to net_msg_cmd_exec()
>>>>> *
>>>>> * OUTPUT SCHEME:
>>>>> * sprintf(net_scratchpad, (rom far char*)"MP-...");
>>>>> * net_msg_encode_puts();
>>>>> *
>>>>> * CALL SPECIFIC STANDARD FUNCTION n: (rare case)
>>>>> * [save net_msg_cmd_* if needed later on]
>>>>> * net_msg_cmd_code = n;
>>>>> * strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
>>>>> * if( net_msg_cmd_exec() ) {...success...}
>>>>> *
>>>>> */
>>>>>
>>>>> /* Command dispatcher: */
>>>>> switch( net_msg_cmd_code )
>>>>> {
>>>>> case 6:
>>>>> // Echo CAR TYPE + MODULE VERSION:
>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" );
>>>>> net_msg_encode_puts();
>>>>> return true;
>>>>>
>>>>> case 7:
>>>>> // List commands supported (for peer configuration):
>>>>> // a) standard commands:
>>>>> net_msg_cmd_exec();
>>>>> // b) car specific commands / overloads:
>>>>> sprintf( net_scratchpad, (rom far char*)"MP-0 c7,0,CAR,6,7,10" );
>>>>> net_msg_encode_puts();
>>>>> // (can be extended if clients need more than the cmd ids)
>>>>> return true;
>>>>>
>>>>>
>>>>> /************************************************************
>>>>> * CAR SPECIFIC COMMANDS
>>>>> */
>>>>>
>>>>> case 10:
>>>>> // EXAMPLE FROM TESLA MODULE: Set charge mode (params: 0=standard, 1=storage,3=range,4=performance)
>>>>> if (sys_features[FEATURE_CANWRITE]==0)
>>>>> {
>>>>> sprintf(net_scratchpad, (rom far char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
>>>>> }
>>>>> else
>>>>> {
>>>>> can_tx_setchargemode(atoi(net_msg_cmd_msg));
>>>>> sprintf(net_scratchpad, (rom far char*)NET_MSG_OK,net_msg_cmd_code);
>>>>> }
>>>>> net_msg_encode_puts();
>>>>> return true;
>>>>>
>>>>> // ...more...
>>>>>
>>>>> default:
>>>>> // Not handled, fall back to standard:
>>>>> return false;
>>>>> }
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
>>>>> Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
>>>>>
>>>>> <dexter.vcf>_______________________________________________
>>>>> 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
--
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dexter.vcf
Type: text/x-vcard
Size: 206 bytes
Desc: not available
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20121116/b9bd85a8/attachment-0002.vcf>
More information about the OvmsDev
mailing list