[Ovmsdev] Merging in Twizy and Volt/Ampera work
Mark Webb-Johnson
mark at webb-johnson.net
Tue Nov 13 23:37:38 HKT 2012
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
>
More information about the OvmsDev
mailing list