[Ovmsdev] Merging in Twizy and Volt/Ampera work
Michael Balzer
dexter at expeedo.de
Sat Nov 10 22:10:09 HKT 2012
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
-------------- 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/20121110/1eb15cc0/attachment-0002.vcf>
More information about the OvmsDev
mailing list