[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.teslaclub.hk/pipermail/ovmsdev/attachments/20121110/1eb15cc0/attachment.vcf>


More information about the OvmsDev mailing list