lishen2/isotp-c

An implementation of the ISO-TP (ISO15765-2) CAN protocol in C

isotp-c's Issues

Struct parameter receive_arbitration_id is never used

I think the intention was probably to match up a on_can_receive id with the receive_arbitration_id, but it seems instead you just trust that the user didn't call on_can_receive feeding in the wrong can message to the wrong associated link.

So at least a comment saying THIS IS UNUSED would be good if not the 4 bytes removed from the structure entirely.

LINE 43 isotp.h

Transmit of multi-frame data.

I do not see where the uint32_t receive_arbitration_id is ever used.

System functions as callbacks?

Have you considered implementing isotp_send_can(), isotp_user_get-ms() and isotp_user_debug() as callbacks that are registered as arguments to isotp_init_link() and stored in IsoTpLink? This would permit using different instances of the functions for each instance of IsoTpLink.

In my case, I wish to manage CAN send buffer queue's differently for each IsoTpLink instance. I also wanted to pass a pointer my own printf() function instead of writing a wrapper. For this I edited isotp_user.h to make isotp_user_debug a macro that redirected to my function, but I can see cases where the debug console stream from each IsoTpLink instance may wish to be handled differently.

I see little need for different isotp_user_get_ms() instances, but I like the clean implementation of dependency injection and treating this function the same way keeps the pattern uniform.

I may implement this for myself. If there were interest I should be able to create a pull request.

I don't have isotp-c running yet, but it looks well done. Thank you!

message in isotp_on_can_message

hello everyone ,
message in isotp_on_can_message function is declared in the function and it is used just afer the declaration can anyone tell me message.as.common.type when it was declared ?

about different addressing modes.

Hello
seems to work only with normal addressing.
what about extended addressing mode?

br
Zahari

handling multi-frame receive?

Does this library currently handle multi-frame receive?
I don't see it providing a user-defined function for something like isotp_user_receive_can which can be polled along with sending flow control messages to receive a full message package over multiple frames.

multiple frame transmition with different ID's

Hi all,

I am trying to understand how the library can separate messages with different ID's. For example.. if i have 3 devices connected on the can bus and device A tries to send a multiple frame message on the bus with iso tp, and half way of the message sending device B starts also with a multiple frame message sending on the same bus. How can the receiving devices C determine from who is the frame ? Do i really need to make a g_link handle for every possible Arbitration ID i have??? this is a lot, since in OBDII systems for example this is a large list of message id's.

I hope you understand my question .

Kind Regards,

Corné

Handling of Unexpected arrival issue

Hi folks,
I have traced the code and have a doubt on handling of unexpected arrival.
In this implementation, link->receive_protocol_result will be assigned to ISOTP_PROTOCOL_RESULT_UNEXP_PDU when ink->receive_status is ISOTP_RECEIVE_STATUS_INPROGRESS and FF and SF is received, it compliant Table 18 ISO-15765-2.
But when CF is received and ink->receive_status != link->receive_status(i.e., the link is in segmented transmission state and CF is received), the implementation treated it an unexpected arrival, but according to Table 18 ISO-15765-2, the sender should just skip the PDU silently.

On another hand, when FC reception, the sender should accept the FC depends on how many CF has been sent. For example, the sender needs to sent 3 CF then waits for an FC, if the FC is coming after 1 CF transmission, then the sender need ignore the FC silently.

Please correct me if i'm wrong.
Thanks
/Sgetz

handling multi-frame send..

Hi,
Got the multi-frame receive to work just fine. but have some trouble with the multi-frame send..
Trying to send back a reply when I received a multi-frame message with a multi-frame response. The below handle_message parse the received payload and respond with a pointer to a 8 byte buffer. I CAN monitor the signals go out on CAN but never handles the flow control frame.

Send first frame 10 00 62 04 08 0A
Receive Flow control 30 08 00
Then nothing.

Also running the isotp_poll separately to the below function call

void isotp_user_recv(can_frame_t frame) {
	int ret;

	isotp_on_can_message(&g_link, frame.data, frame.dlc);

        /* Poll link to handle multiple frame transmission */
	isotp_poll(&g_link);

	ret = isotp_receive(&g_link, payload, payload_size, &out_size);
	if (ISOTP_RET_OK == ret) {
		// receive ok
		/* Handle received message */
		data_t * data = handle_message(payload, &out_size);
		if (NULL != data) {
			ret = isotp_send(&g_link, data->buffer, data->size);
			if (ISOTP_RET_OK == ret)
			{
				// send ok
			}
		}
	}	
}

isotp_user_debug() specifies varargs, but then avoids using it

isotp_user.h defines isotp_user_debug() to use varargs:

void isotp_user_debug(const char* message, ...);

However, that feature is never used and is avoided in the only case where more than a simple immediate string is sent in isotp.c:isotp_send():

        char message[128];
        sprintf(&message[0], "Attempted to send %d bytes; max size is %d!\n", size, link->send_buf_size);
        isotp_user_debug(message);

If it is preferred to avoid use of varargs, the signature for isotp_user_debug() should not include it. If avoidance is not desired, then isotp_send() should not avoid it?

Preferences?

Retransmission support

Studying the current implementation, it seems that no retransmission mechanism is implemented. E.g. to recover from simple collisions.
Are there plans to implement it?

problem about send_bs_remain

when sending multi-frame, tp_poll handle remain packets. but in isotp_send_with_id function，send_bs_remain set to 0, causing tp_poll can not do sending. link->send_status will stay in ISOTP_SEND_STATUS_INPROGRESS.
/* send multi-frame */
ret = isotp_send_first_frame(link, id);
if (ISOTP_RET_OK == ret) {
link->send_bs_remain = 0;
link->send_st_min = 0;
link->send_wtf_count = 0;
link->send_timer_st = link->isotp_user_get_ms();
link->send_timer_bs = link->isotp_user_get_ms() + ISO_TP_DEFAULT_RESPONSE_TIMEOUT;
link->send_protocol_result = ISOTP_PROTOCOL_RESULT_OK;
link->send_status = ISOTP_SEND_STATUS_INPROGRESS;
}
....
void isotp_poll(IsoTpLink *link) {
int ret;

/* only polling when operation in progress */
if (ISOTP_SEND_STATUS_INPROGRESS == link->send_status) {

    /* continue send data */
    if (/* send data if bs_remain is invalid or bs_remain large than zero */
    **(ISOTP_INVALID_BS == link->send_bs_remain || link->send_bs_remain > 0)** &&
    /* and if st_min is zero or go beyond interval time */
    (0 == link->send_st_min || (0 != link->send_st_min && IsoTpTimeAfter(link->isotp_user_get_ms(), link->send_timer_st)))) {
        
        ret = isotp_send_consecutive_frame(link);

......

isotp-c/isotp.c:2:19: error: debug.h: No such file or directory

When attempting to compile the sources, the aforementioned error shows.
I'm unable to find the debug.h file.

Is it part of the GCC tools? Replacing "debug.h" w/ "assert.h" seems to resolve at least the compiler issues.

CANoe DIVA Test Results

Hello @lishen2 ,

thanks for your code. Could you add to the repo or share your performed CANoe DIVA Tests and/or DIVA testresults? It would be great to know the limitations or open issues of this SW stack.

Regards,
stefan325