<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Michael,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>I also tested the new net_sms arrangement, found a few bugs, and fixed them. Code is on github now.</div><div><br></div><div>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.</div><div><br></div><div>Regards, Mark.</div><div><br><div><div>On 18 Nov, 2012, at 4:38 AM, Michael Balzer <<a href="mailto:dexter@expeedo.de">dexter@expeedo.de</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
  
    <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
  
  <div bgcolor="#FFFFFF" text="#000000">
    Mark,<br>
    <br>
    I ported my STAT changes to the new framework and tried to prepare
    it for my first specific commands as well:<br>
    <br>
<a class="moz-txt-link-freetext" href="https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6">https://github.com/dexterbg/Open-Vehicle-Monitoring-System/commit/7b050c4dd92045d62bce3315122ac496c5d305c6</a><br>
    <br>
    Haven't tested yet, but the vehicle / framework distinction becomes
    very clean now I think.<br>
    <br>
    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.<br>
    <br>
    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 (?)<br>
    <br>
    Regards,<br>
    Michael<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Am 17.11.2012 19:20, schrieb Michael
      Balzer:<br>
    </div>
    <blockquote cite="mid:50A7D588.4010006@expeedo.de" type="cite">Mark,
      <br>
      <br>
      man, you're fast! :-)
      <br>
      <br>
      ...ok, that looks good for extending and replacing existing SMS
      commands.
      <br>
      <br>
      Next step will be to split the command table in standard + vehicle
      commands. That could be done by simply calling
      vehicle_fn_smshandler() before checking the standard cmdtable and
      leave everything else to the vehicle module, but I like the
      concept of net_sms_in() doing the common caller authentication for
      all commands.
      <br>
      <br>
      I assume you intend to use this for the vehicle commands as well?
      So the vehicle module will hook in a specific cmdtable+hfntable to
      be used by net_sms_in()?
      <br>
      <br>
      Thinking about auth... maybe I'm missing something, but why is
      there a need for the three auth modes? Couldn't it just be mode 3
      for every command?
      <br>
      <br>
      Regards,
      <br>
      Michael
      <br>
      <br>
      <br>
      Am 17.11.2012 16:03, schrieb Mark Webb-Johnson:
      <br>
      <blockquote type="cite">
        <blockquote type="cite">
          <blockquote type="cite">I'll also port my specific STAT?
            version to the new framework ASAP.
            <br>
          </blockquote>
          This is a little more involved. I need to re-work the SMS
          framework to hook in to the vehicle modules nicely, and that
          will require quite a bit o structural rework. Let me handle
          this - I'll get it done in the next hour or two.
          <br>
        </blockquote>
        I've done the structural work for this, and committed to github.
        <br>
        <br>
        There is now a vehicle module hook for SMS commands, that are
        run pre-command (allowing a vehicle module to completely
        override an SMS command), and post-command (allowing a vehicle
        module to add stuff onto the end of an standard sms command).
        <br>
        <br>
        I haven't re-worked Michael's Twizy STAT extensions, yet, but
        the hooks are now there.
        <br>
        <br>
        The changes were quite drastic, and I've probably broken a lot.
        It builds, but completely untested. I just wanted to get it in
        so you could have a look at it.
        <br>
        <br>
        I'll test it tomorrow, and fix as necessary.
        <br>
        <br>
        Regards, Mark.
        <br>
        <br>
        On 17 Nov, 2012, at 9:24 PM, Mark Webb-Johnson
        <a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
        <br>
        <br>
        <blockquote type="cite">
          <blockquote type="cite">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?
            <br>
          </blockquote>
          Its ok. I've handled this. Just add a bitmap flag set to
          net.h/net.c and controlled it by that. It defaults to OFF (in
          vehicle.c initialisation), and the none, obdii, Volt/Ampera
          and Twizy modules enable it.
          <br>
          <br>
          <blockquote type="cite">I'll also port my specific STAT?
            version to the new framework ASAP.
            <br>
          </blockquote>
          This is a little more involved. I need to re-work the SMS
          framework to hook in to the vehicle modules nicely, and that
          will require quite a bit o structural rework. Let me handle
          this - I'll get it done in the next hour or two.
          <br>
          <br>
          <blockquote type="cite">I have one concern for the overlaying
            of the vehicle RAM sections:
            <br>
          </blockquote>
          I'll have to think about this and have a look at how it is
          initialised at the moment. My guess is we're linking to the c
          library version that wipes all user ram to zero on reboot.
          <br>
          <br>
          Regards, Mark.
          <br>
          <br>
          On 17 Nov, 2012, at 3:52 AM, Michael Balzer
          <a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote:
          <br>
          <br>
          <blockquote type="cite">Mark,
            <br>
            <br>
            I followed your branch naming, "v2" on my repository adds my
            latest Twizy changes to the new framework.
            <br>
            <br>
            Stunningly, V2 worked out of the box :-) Great job!
            <br>
            <br>
            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?
            <br>
            <br>
            I'll also port my specific STAT? version to the new
            framework ASAP.
            <br>
            <br>
            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...
            <br>
            <br>
            Regards,
            <br>
            Michael
            <br>
            <br>
            <br>
            Am 15.11.2012 14:52, schrieb Mark Webb-Johnson:
            <br>
            <blockquote type="cite">I've just committed another night's
              work on this. Looks good and now runs on actual hardware.
              <br>
              <br>
              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.
              <br>
              <br>
              I've ported the SMS commands over to the new vehicle
              module framework, and they look good.
              <br>
              <br>
              I've bumped the version to 2.1.1, to reflect the major
              restructuring that this is.
              <br>
              <br>
              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.
              <br>
              <br>
              Regards, Mark.
              <br>
              <br>
              On 14 Nov, 2012, at 10:57 PM, Mark Webb-Johnson
              <a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
              <br>
              <br>
              <blockquote type="cite">I've just committed my
                work-in-progress for this to the github v2 branch.
                <br>
                <br>
                Best I can say about it is that it compiles and links
                without error.
                <br>
                <br>
                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.
                <br>
                <br>
                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.
                <br>
                <br>
                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.
                <br>
                <br>
                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.
                <br>
                <br>
                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.
                <br>
                <br>
                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.
                <br>
                <br>
                Feel free to have a look at the code, and let me know
                what you think and if there is anything obviously wrong.
                <br>
                <br>
                Regards, Mark.
                <br>
                <br>
                On 13 Nov, 2012, at 11:37 PM, Mark Webb-Johnson
                <a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
                <br>
                <br>
                <blockquote type="cite">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.
                  <br>
                  <br>
                  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).
                  <br>
                  <br>
                  I'm going to do one more night on it, then commit what
                  I have to the v2 branch for others to look at.
                  <br>
                  <br>
                  Regards, Mark.
                  <br>
                  <br>
                  On 11 Nov, 2012, at 10:13 PM, Mark Webb-Johnson
                  <a class="moz-txt-link-rfc2396E" href="mailto:mark@webb-johnson.net"><mark@webb-johnson.net></a> wrote:
                  <br>
                  <br>
                  <blockquote type="cite">I think the general approach
                    here is correct.
                    <br>
                    <br>
                    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.
                    <br>
                    <br>
                    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).
                    <br>
                    <br>
                    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).
                    <br>
                    <br>
                    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.
                    <br>
                    <br>
                    I can work on this now, so give me a few days to try
                    to build the framework for this re-structure.
                    <br>
                    <br>
                    Regards, Mark.
                    <br>
                    <br>
                    On 10 Nov, 2012, at 10:10 PM, Michael Balzer
                    <a class="moz-txt-link-rfc2396E" href="mailto:dexter@expeedo.de"><dexter@expeedo.de></a> wrote:
                    <br>
                    <br>
                    <blockquote type="cite">Am 04.11.2012 14:21, schrieb
                      Mark Webb-Johnson:
                      <br>
                      <blockquote type="cite">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).
                        <br>
                      </blockquote>
                      Mark, List,
                      <br>
                      <br>
                      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).
                      <br>
                      <br>
                      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 :-)
                      <br>
                      <br>
                      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...
                      <br>
                      - either leave a command handling to the system
                      <br>
                      - or use and extend the system handling
                      <br>
                      - or completely implement a command itself,
                      possibly replacing a system handler.
                      <br>
                      <br>
                      Current car specific hook calls like
                      can_tx_setchargemode() can then be removed from
                      the common net framework.
                      <br>
                      <br>
                      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:
                      <br>
                      <br>
                      - 6 = car module type + version
                      <br>
                      => reply scheme: "MP-0
c6,0,<car_code>,<car_name>,<version_major>,<version_minor>,<version_patchlevel>"<br>
                      <br>
                      - 7 = list of commands supported
                      <br>
                      => reply scheme: "MP-0
                      c7,0,<class:STD/CAR>,<cmdid1>,<cmdid2>,..."
                      <br>
                      More than one list of each class can be sent,
                      clients should collect and join all.
                      <br>
                      I think IDs are sufficient, otherwise the reply
                      scheme could be extended.
                      <br>
                      <br>
                      Maybe a third one will make sense for the...
                      <br>
                      <br>
                      - 8 = list of car data properties supported
                      <br>
                      => reply scheme: "MP-0 c8,0,..." (todo? can
                      make life easier for the App)
                      <br>
                      <br>
                      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.
                      <br>
                      <br>
                      AFAIS this extension would require no immediate
                      change to the existing server and apps, it just
                      offers an opportunity for the next releases.
                      <br>
                      <br>
                      Regards,
                      <br>
                      Michael
                      <br>
                      <br>
                      <br>
                      // ------------------- net_msg module
                      ----------------------
                      <br>
                      <br>
                      // REPLACE:
                      <br>
                      void net_msg_cmd_do(void)
                      <br>
                      {
                      <br>
/****************************************************************
                      <br>
                      * MSG COMMAND DISPATCHER
                      <br>
                      *   Called by: net_msg_cmd_in() &
                      net_state_ticker1()
                      <br>
                      *
                      <br>
                      * GLOBAL PARAMS:
                      <br>
                      *   net_msg_cmd_code = int command id
                      <br>
                      *   net_msg_cmd_msg = char * to first parameter
                      <br>
                      */
                      <br>
                      <br>
                      delay100(2);
                      <br>
                      <br>
                      // commands 40-49 are special AT commands, thus,
                      disable net_msg here
                      <br>
                      if ((net_msg_cmd_code < 40) ||
                      (net_msg_cmd_code > 49))
                      <br>
                          net_msg_start();
                      <br>
                      <br>
                      // Execute cmd: ask car module to execute first:
                      <br>
                      if( !car_msg_cmd_exec() )
                      <br>
                      {
                      <br>
                          // Car module does not feel responsible, fall
                      back to standard:
                      <br>
                          if( !net_msg_cmd_exec() )
                      <br>
                          {
                      <br>
                              // No standard as well => return
                      "unimplemented"
                      <br>
                              sprintf(net_scratchpad, (rom far
                      char*)"MP-0 c%d,3",net_msg_cmd_code);
                      <br>
                              net_msg_encode_puts();
                      <br>
                          }
                      <br>
                      }
                      <br>
                      <br>
                      // terminate IPSEND by Ctrl-Z (should this be
                      disabled for commands 40-49 as well?)
                      <br>
                      net_msg_send();
                      <br>
                      <br>
                      // clear command
                      <br>
                      net_msg_cmd_code = 0;
                      <br>
                      net_msg_cmd_msg[0] = 0;
                      <br>
                      <br>
                      }
                      <br>
                      <br>
                      <br>
                      // ADD:
                      <br>
                      bool net_msg_cmd_exec(void)
                      <br>
                      {
                      <br>
/****************************************************************
                      <br>
                      * IMPLEMENTATION OF STANDARD MSG COMMANDS
                      <br>
                      *   Called by: net_msg_cmd_do() & car specific
                      cmd handlers
                      <br>
                      *
                      <br>
                      * GLOBAL PARAMS:
                      <br>
                      *   net_msg_cmd_code = int command id
                      <br>
                      *   net_msg_cmd_msg = char * to first parameter
                      <br>
                      *
                      <br>
                      * RETURNS:
                      <br>
                      *   true if cmd has been handled
                      <br>
                      */
                      <br>
                      <br>
                      int k;
                      <br>
                      char *p;
                      <br>
                      <br>
                      switch (net_msg_cmd_code)
                      <br>
                      {
                      <br>
                          // ...std cmds 1-5 to be inserted here if
                      compiler does no jump table optimization...
                      <br>
                      <br>
                          case 7:
                      <br>
                              // List commands supported (for peer
                      configuration):
                      <br>
                              // standard commands:
                      <br>
                              sprintf( net_scratchpad, (rom far
                      char*)"MP-0 c7,0,STD,1,2,3,4,5,40,41,49" );
                      <br>
                              net_msg_encode_puts();
                      <br>
                              // (can be extended if clients need more
                      than the cmd ids)
                      <br>
                              return true;
                      <br>
                      <br>
                          // ...std cmds to be inserted here...
                      <br>
                      <br>
                          default:
                      <br>
                              // unhandled cmd_code:
                      <br>
                              return false;
                      <br>
                      }
                      <br>
                      }
                      <br>
                      <br>
                      <br>
                      // ------------------- can_<model> or maybe
                      separate car_<model> module
                      ----------------------
                      <br>
                      <br>
                      // ADD:
                      <br>
                      bool car_msg_cmd_exec(void)
                      <br>
                      {
                      <br>
/****************************************************************
                      <br>
                      * HOOK to integrate CAR SPECIFIC MSG command
                      handlers
                      <br>
                      *   May overlay and/or extend the standard command
                      set
                      <br>
                      *   Called by: net_msg_cmd_do()
                      <br>
                      *
                      <br>
                      * GLOBAL PARAMS:
                      <br>
                      *   net_msg_cmd_code = int command id
                      <br>
                      *   net_msg_cmd_msg = char * to first parameter
                      <br>
                      *
                      <br>
                      * RETURNS:
                      <br>
                      *   true : cmd has been handled completely
                      <br>
                      *   false: fallback to net_msg_cmd_exec()
                      <br>
                      *
                      <br>
                      * OUTPUT SCHEME:
                      <br>
                      *   sprintf(net_scratchpad, (rom far
                      char*)"MP-...");
                      <br>
                      *   net_msg_encode_puts();
                      <br>
                      *
                      <br>
                      * CALL SPECIFIC STANDARD FUNCTION n: (rare case)
                      <br>
                      *   [save net_msg_cmd_* if needed later on]
                      <br>
                      *   net_msg_cmd_code = n;
                      <br>
                      *   strcpy( net_msg_cmd_msg, "arg1,arg2,..." );
                      <br>
                      *   if( net_msg_cmd_exec() ) {...success...}
                      <br>
                      *
                      <br>
                      */
                      <br>
                      <br>
                      /* Command dispatcher: */
                      <br>
                      switch( net_msg_cmd_code )
                      <br>
                      {
                      <br>
                          case 6:
                      <br>
                              // Echo CAR TYPE + MODULE VERSION:
                      <br>
                              sprintf( net_scratchpad, (rom far
                      char*)"MP-0 c6,0,RT,Renault Twizy,1,2,0" );
                      <br>
                              net_msg_encode_puts();
                      <br>
                              return true;
                      <br>
                      <br>
                          case 7:
                      <br>
                              // List commands supported (for peer
                      configuration):
                      <br>
                              // a) standard commands:
                      <br>
                              net_msg_cmd_exec();
                      <br>
                              // b) car specific commands / overloads:
                      <br>
                              sprintf( net_scratchpad, (rom far
                      char*)"MP-0 c7,0,CAR,6,7,10" );
                      <br>
                              net_msg_encode_puts();
                      <br>
                              // (can be extended if clients need more
                      than the cmd ids)
                      <br>
                              return true;
                      <br>
                      <br>
                      <br>
/************************************************************
                      <br>
                           * CAR SPECIFIC COMMANDS
                      <br>
                           */
                      <br>
                      <br>
                          case 10:
                      <br>
                              // EXAMPLE FROM TESLA MODULE: Set charge
                      mode (params: 0=standard,
                      1=storage,3=range,4=performance)
                      <br>
                              if (sys_features[FEATURE_CANWRITE]==0)
                      <br>
                              {
                      <br>
                                  sprintf(net_scratchpad, (rom far
                      char*)NET_MSG_NOCANWRITE,net_msg_cmd_code);
                      <br>
                              }
                      <br>
                              else
                      <br>
                              {
                      <br>
                                 
                      can_tx_setchargemode(atoi(net_msg_cmd_msg));
                      <br>
                                  sprintf(net_scratchpad, (rom far
                      char*)NET_MSG_OK,net_msg_cmd_code);
                      <br>
                              }
                      <br>
                              net_msg_encode_puts();
                      <br>
                              return true;
                      <br>
                      <br>
                          // ...more...
                      <br>
                      <br>
                          default:
                      <br>
                              // Not handled, fall back to standard:
                      <br>
                              return false;
                      <br>
                      }
                      <br>
                      <br>
                      }
                      <br>
                      <br>
                      <br>
                      <br>
                      -- <br>
                      Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
                      <br>
                      Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
                      <br>
                      <br>
<dexter.vcf>_______________________________________________
                      <br>
                      OvmsDev mailing list
                      <br>
                      <a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
                      <br>
                      <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
                      <br>
                    </blockquote>
                  </blockquote>
                  _______________________________________________
                  <br>
                  OvmsDev mailing list
                  <br>
                  <a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
                  <br>
                  <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
                  <br>
                </blockquote>
              </blockquote>
              _______________________________________________
              <br>
              OvmsDev mailing list
              <br>
              <a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
              <br>
              <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
              <br>
            </blockquote>
            -- <br>
            Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
            <br>
            Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
            <br>
            <br>
<dexter.vcf>_______________________________________________
            <br>
            OvmsDev mailing list
            <br>
            <a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
            <br>
            <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
            <br>
          </blockquote>
        </blockquote>
        _______________________________________________
        <br>
        OvmsDev mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
        <br>
        <a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
        <br>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a>
<a class="moz-txt-link-freetext" href="http://lists.teslaclub.hk/mailman/listinfo/ovmsdev">http://lists.teslaclub.hk/mailman/listinfo/ovmsdev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Michael Balzer * Paradestr. 8 * D-42107 Wuppertal
Fon 0202 / 272 2201 * Handy 0176 / 206 989 26
</pre>
  </div>

<span><dexter.vcf></span>_______________________________________________<br>OvmsDev mailing list<br><a href="mailto:OvmsDev@lists.teslaclub.hk">OvmsDev@lists.teslaclub.hk</a><br>http://lists.teslaclub.hk/mailman/listinfo/ovmsdev<br></blockquote></div><br></div></body></html>