Generated code do not support extended messages

[FZGabriel]

Hi,

In my dbc, I have a message with an ID of 0x100 in extended mode.

BO_ 2147483904 IVT_HVBattery: 8 IVT_30_Node

The problem is that instead of generating an id of 0x100 the code generates the following:

int unpack_message(can_obj_ivt30_h_t *o, const unsigned long id, uint64_t data, uint8_t dlc, dbcc_time_stamp_t time_stamp) {
	assert(o);
	assert(id < (1ul << 29)); /* 29-bit CAN ID is largest possible */
	assert(dlc <= 8);         /* Maximum of 8 bytes in a CAN packet */
	switch (id) {
	//...
	case 0x80000100: return unpack_can_0x80000100_IVT_HVBattery(o, data, dlc, time_stamp);
        // ...

This message ID is therefore impossible to use, because of the assert(id < (1ul << 29));.

I would suggest generating the following:

int unpack_message(can_obj_ivt30_h_t *o, const unsigned long id, uint64_t data, uint8_t dlc, dbcc_time_stamp_t time_stamp) {
	assert(o);
	assert(id < (1ul << 29)); /* 29-bit CAN ID is largest possible */
	assert(dlc <= 8);         /* Maximum of 8 bytes in a CAN packet */
	switch (id) {
	//...
	case 0x100: return unpack_can_0x100_IVT_HVBattery(o, data, dlc, time_stamp);
        // ...

Best regards,
Gabriel

[howerj]

Ahoy! The CAN ID 2147483904 is 0x80000100, I might be wrong, but that seems invalid? (unless that top bit is set for other reasons)
Cheers,
Richard

[FZGabriel]

I think the top bit is used in the dbc format to indicate that the CAN ID is in Extended mode.

[FZGabriel]

Hi Richard,
Thanks for your answer.

I think the top bit is used in the dbc format to indicate that the CAN ID is in Extended mode.
Here's a test to prove my hypothesis:

EDIT: sorry for the message duplication; I can't seems to delete it at the moment.

[howerj]

I'm working on a branch called 'fixes-and-reorg', which should address the issues you've raised. I think it has fixed all of them, just need to do some testing and more work.