Introduction

Let's think about the initial layout for the libobd project. How do we intend for end-users to communicate to the library?

First off - what do they want to do?

Retrieve OBD2 engine codes

Maybe the MIL is on, and the user wants to retrieve the diagnostic codes from the engine using standard OBD2 (without needing to know anything about the specific scanner used).
They would connect to the vehicle using any transport they want, and once a connection is established they can start communicating via OBD2.

E.g.

int main() {
  // Initiate a connection.
  BTTransport bt;
  if (!bt.ConnectToMAC(const uint8_t* mac))
    return 1;
  
  // Create an ELM327 scanner on top of the BT transport.
  ELM327 elm(bt);

  // Create OBD2 on top of the scanner.
  // OBD2 will have the protocol logic, which should be able to work at an abstract level across scanners.
  OBD2 obd(elm);
  // We could also just return an array of codes, or something.
  obd.EnumMILCodes([] () {
    // ... do something
  });

  // Object destructor will shut down the connection implicitly.
}

Spy on CAN bus traffic

This is going to require knowledge of the scanner being used. The user would initialize a transport and a scanner, and then ask the scanner politely to start spying on CAN bus traffic.
With the ELM327 scanner, this puts it into a mode where we cannot send any other commands (it dominates traffic to the scanner).

Introduction

I hate sitting out in my hot car debugging this stuff. I'd like to be fat and lazy and debug this from the comfort of my shit-infested couch. So, this is a solution to that.

This device emulates the functionality of an ELM327 chip so we can develop logic around it.