diff options
Diffstat (limited to 'src/obd2/obd2.c')
-rw-r--r-- | src/obd2/obd2.c | 92 |
1 files changed, 64 insertions, 28 deletions
diff --git a/src/obd2/obd2.c b/src/obd2/obd2.c index 3d501d6a..33e6da15 100644 --- a/src/obd2/obd2.c +++ b/src/obd2/obd2.c @@ -1,14 +1,15 @@ #include <obd2/obd2.h> +#define MAX_DIAGNOSTIC_PAYLOAD_SIZE 6 +#define MODE_BYTE_INDEX 0 +#define PID_BYTE_INDEX 1 + DiagnosticShims diagnostic_init_shims(LogShim log, SendCanMessageShim send_can_message, SetTimerShim set_timer) { DiagnosticShims shims = { - isotp_shims: { - log: log, - send_can_message: send_can_message, - set_timer: set_timer - }, + send_can_message: send_can_message, + set_timer: set_timer, log: log }; return shims; @@ -16,34 +17,60 @@ DiagnosticShims diagnostic_init_shims(LogShim log, DiagnosticRequestHandle diagnostic_request(DiagnosticShims* shims, DiagnosticRequest* request, DiagnosticResponseReceived callback) { - // TODO hmm, where is message_received coming from? we would need 2 layers - // of callbacks. if we do it in the obd2 library, we have to have some - // context passed to that message_received handler so we can then retreive - // the obd2 callback. there was an option question of if we should pass a - // context with that callback, and maybe this answers it. - // - // alternatively, what if don't hide isotp and allow that to also be - // injected. the user has the iso_tp message_received callback, and in that - // they call a message_received handler from obd2. - // - // in fact that makes more sense - all the diagnostic_can_frame_received - // function is going to be able to do is call the equivalent function in the - // isotp library. it may or may not have a complete ISO-TP message. huh. DiagnosticRequestHandle handle = { - // TODO why are teh shims stored as a reference in the isotp handler? - // it's just 3 pointers - isotp_handler: isotp_init(&shims->isotp_shims, request->arbitration_id, - NULL, // TODO need a callback here! - NULL, NULL), - type: 0 //DIAGNOSTIC_.... // TODO how would we know the type? - //does it matter? we were going to have a different callback + type: DIAGNOSTIC_REQUEST_TYPE_PID, + callback: callback, + status: true }; + uint8_t payload[MAX_DIAGNOSTIC_PAYLOAD_SIZE]; + payload[MODE_BYTE_INDEX] = request->mode; + if(request->pid_length > 0) { + copy_bytes_right_aligned(request->pid, sizeof(request->pid), + PID_BYTE_INDEX, request->pid_length, payload, sizeof(payload)); + } + if(request->payload_length > 0) { + memcpy(payload[PID_BYTE_INDEX + request->pid_length], + request->payload, request->payload_length); + } + + IsoTpShims isotp_shims = isotp_init_shims(shims->log, + shims->send_can_message, + shims->set_timer); + handle.status = isotp_send(&isotp_shims, request->arbitration_id, + payload, 1 + request->payload_length + request->pid_length, + diagnostic_receive_isotp_message); + + // TODO need to set up an isotp receive handler. in isotp, rx and tx are + // kind of intermingled at this point. really, there's not explicit link + // between send and receveice...well except for flow control. hm, damn. + // so there's 2 things: + // + // isotp_send needs to return a handle. if it was a single frame, we + // probably sent it right away so the status true and the callback was hit. + // the handle needs another flag to say if it was completed or not, so you + // know you can destroy it. you will continue to throw can frames at that + // handler until it returns completed (either with a flag, or maybe + // receive_can_frame returns true if it's complete) + // + // the second thing is that we need to be able to arbitrarly set up to + // receive an iso-tp message on a particular arb id. again, you keep + // throwing can frames at it until it returns a handle with the status + // completed and calls your callback + // + // so the diagnostic request needs 2 isotp handles and they should both be + // hidden from the user + // + // when a can frame is received and passes to the diagnostic handle + // if we haven't successfuly sent the entire message yet, give it to the + // isottp send handle + // if we have sent it, give it to the isotp rx handle + // if we've received properly, mark this request as completed + return handle; } DiagnosticRequestHandle diagnostic_request_pid(DiagnosticShims* shims, DiagnosticPidRequestType pid_request_type, uint16_t pid, DiagnosticResponseReceived callback) { - // decide mode 0x1 / 0x22 based on pid type DiagnosticRequest request = { mode: pid_request_type == DIAGNOSTIC_STANDARD_PID ? 0x1 : 0x22, pid: pid @@ -52,12 +79,21 @@ DiagnosticRequestHandle diagnostic_request_pid(DiagnosticShims* shims, return diagnostic_request(shims, &request, callback); } -void diagnostic_receive_can_frame(DiagnosticRequestHandle* handler, +void diagnostic_receive_isotp_message(const IsoTpMessage* message) { + // TODO +} + +void diagnostic_receive_can_frame(DiagnosticRequestHandle* handle, const uint16_t arbitration_id, const uint8_t data[], const uint8_t size) { - isotp_receive_can_frame(handler->isotp_handler, arbitration_id, data, size); + isotp_receive_can_frame(handle->isotp_handler, arbitration_id, data, size); } +// TODO argh, we're now saying that user code will rx CAN messages, but who does +// it hand them to? isotp handlers are encapsulated in diagnostic handles + + + // TODO everything below here is for future work...not critical for now. DiagnosticRequestHandle diagnostic_request_malfunction_indicator_status( |