listener example is now 29-bit CANID aware

[JLPLabs]

modified the behavior of the example/acf-can-listener such that:

• using STDOUT it prepends 0's to make it a format that canplayer expects for 29-bit
• writing directly to vcan it keeps the 29-bit CANID

[adriaan-niess]

Hi @JLPLabs,

this is very helpful! Thanks! I would propose a small modification to your code, because there's already a field for the EFF in the IEEE1722 Header. It can be accessed like this:

uint64_t eff;
Avtp_Can_GetField((Avtp_Can_t*)acf_pdu, AVTP_CAN_FIELD_EFF, &eff);

if (eff) {
    frame.can_id |= CAN_EFF_FLAG;
}

This way it's possible to retain the extended format for CAN IDs <= 0x7FF if the EFF flag is set. Additionally it might be useful to print a warning if the EFF flag is not set, but a CAN ID > 0x7FF is used.

What do you think?

Regards,
Adriaan

[JLPLabs]

Adriaan,
I think that your two ideas are very good. I've followed both of your suggestions and there is now a second commit on this PR.

-John

[adriaan-niess]

Hi John, looks great! I'm going to merge your code tomorrow after doing a small test.

[JLPLabs]

Adriaan,
You'll see a 3rd commit on this PR.

NOTE PLEASE LET ME KNOW:
a) if this is more than you want,
b) if there is a better / more idiomatic approach I should be taking.

This last change can be summarized as:

• LISTENER

  • updated one line in acf-can-listener so that the acf_pdu pointer is moved through the ethernet frame. (right now there is logic that seems to imply that was the desired behavior, but the pointer wasn't actually being updated).

• TALKER

  • added a --count COUNT flag to the command line. This allows the user to require COUNT number of CAN frames to be packed into one Ethernet frame.
  • used the variable that already existed, num_acf_msgs for handling the count logic.

[adriaan-niess]

Hi John,

I think it's a good idea to support having multiple CAN frames transported in a single Ethernet frame. But let's separate this from the original PR for now, so that I can merge the code related to the CAN IDs first.

I've created issue #20 to discuss transmission of aggregated CAN frame separately. We should do this in another PR.

Regards,
Adriaan

[adriaan-niess]

@JLPLabs can you either undo your last commit or create a new PR? I'd like to merge your code regarding the 29bit CAN-ID.