Plans for expanded IO on VI

This page captures the requirements of as many reasonable use cases we could think of:

• Only send data that has been subscribed to by a host device
• Add support for request/response style CAN message
• Allow querying the CAN translator to see what types of data are actually available
• Make send_same a property of the subscription, not the CAN translator
• Allow JSON value to be an object with arbitrary keys
• Allow dynamically adding/removing CAN signal definitions at runtime
• Allow compiling with support for multiple vehicles at a time
• Allow switching to bootloader and reflashing by software command via USB
• Emulate an ELM327
• Optimize firmware for sustained writes back to CAN
• Send debug log messages over a separate USB bulk endpoint
• Return CAN write status back via USB

Control Commands

Second Pass

• Enable/disable passthrough output for messages and buses, configure properties of each (actually this will allow configuring all bus properties on the fly

{ "command": "configure_bus",
  "buses": {
    "hs": {
        "controller": 1,
        "speed": 500000,
        "raw_can_mode": "unfiltered",
        "raw_writable": true,
        "max_message_frequency: 1,
        "force_send_changed": true,
        "enabled": false
    }
  }
}

• CRUD translated signals on the fly and messages (For filtered passthrough output)

{ "command": "configure_message",
  "action": "configure",
  "message": {
      "bus": "hs", // TODO should this accept bus number or name?
      "id": 42,
      "enabled": true,
      "max_frequency": 0,
      "force_send_changed": true,
      "max_signal_frequency": 0,
      "force_send_changed_signals": true
  }
}

{ "command": "configure_message",
  "action": "delete",
  "message": {
      "bus": "hs",
      "id": 42
  }
}

• Request a list of available translated signals - two modes, one which gives all signal details, one which only gives names and ranges (if known)

This should return the complete configuration - it's up to the receiver to parse out the part they want, be it the buses, messages, signals, diagnostic requests, etc. Want to keep the VI code as simple as possible - we just need a method to convert the entire runtime into a JSON object representing the configuration (it should be identical to the VI firmware config file format!).

{ "command": "get_configuration"}

• Switch UART mode
• Set active CAN message set (i.e. switch between vehicles)
• Request a list of available signal sets
• Change the active signal set
• Register/unregister to receive a certain translated signal
  • At registration time, optionally put requested frequency
  • At registration time, optionally request that the same valued signals be sent or not
  • For updating frequency or send_same property, just re-register - should update
• Switch to bootloader for reflashing

UART

Since the UART interface only has a single I/O channel, we will implement:

• Different modes to determine what type and format of output is active
  • OpenXC data mode - same as data mode endpoint on USB
  • ELM327 Mode
    • Output - emulated ELM327 output based on whatever commands were sent on the input channel
    • Input - ELM327 commands
• Special control commands to switch modes and perform other control-related tasks
  • UART should accept the same control commands as USB, albeit in a different format
  • Switch mode - data mode or ELM327 mode