Electronics > Microcontrollers

CANdb++ .dbc to C/C++ .h converter

<< < (5/5)

vinicaog:
Hi gnasirator,

First of all, thank you for making the DBC to C/C++ converter. I find it very useful and well structurated.

My software receives the CAN message with this structure:


--- Code: ---typedef struct
   {
    unsigned int ID  :29;
    unsigned int DLC :4;
    uint8_t  DATA[8];
   } Can_Message;

--- End code ---
And I would like to apply the values from DATA buffer into the DBC signal.

for example:


--- Code: ---static const signal DBC_SIG_CCU_SteeringWheelAngle = {
.name = "CCU_SteeringWheelAngle",
.unit = "°",
.valueType = dbc_valueType_unsigned,
.lengthBits = 14,
.factor = 0.5f, .offset = -2048.0f, .min = -2048.0f, .max = 2047.0f
};

--- End code ---


--- Code: ---static struct DBC_MSG_CCU_VehStat {
const uint32_t ID;
const uint8_t IDE;
const uint8_t DLC;
const struct {
signal_positioned CCU_SteeringWheelAngle;
} getSig;
struct __attribute__((packed)) DBC_MSG_CCU_VehStat_getSigVal {
uint16_t CCU_SteeringWheelAngle : 14;
} *getSigVal;
} DBC_MSG_CCU_VehStat __attribute__((unused)) = {
.ID = 0x12,
.IDE = CAN_ID_STD,
.DLC = 8,
.getSig  = {
.CCU_SteeringWheelAngle = {
.position = 7,
.attributes = &DBC_SIG_CCU_SteeringWheelAngle
}
},
.getSigVal = 0
};
--- End code ---


How to write values to CCU_SteeringWheelAngle ? So I can send it later.
And also the oposit, I receive the CAN RxMessage.DATA, how to populate the new data, to the header structure?

Thank you.

gnasirator:
Hi vinicaog,

please have a look at my usage example in the first post:


--- Code: ---
{
uint8_t uid;
uint8_t RxMessage[8];
DBC_setup(DBC_IME_AI_MSG_CAN_IMED_MSG_PA_SP, RxMessage);
DBC_makeSignalAccessor(DBC_IME_AI_MSG_CAN_IMED_MSG_PA_SP, RxMessage, msg_access);
uid = msg_access->UID;
msg_access->AssignedID = 42;
}

--- End code ---

The DBC_setup and DBC_makeSignalAccessor macros basically set up a struct pointer of your defined message type to the data[8] array, here called msg_access. You can then use msg_access to read/write your signals.
Have a look at the macro definition, that should clear it all up.

I think modified to your use case it might look similar to this:

--- Code: ---typedef struct
   {
    unsigned int ID  :29;
    unsigned int DLC :4;
    uint8_t  DATA[8];
   } Can_Message;

uint16_t angle;

DBC_setup(DBC_MSG_CCU_VehStat, Can_Message.DATA);
DBC_makeSignalAccessor(DBC_MSG_CCU_VehStat, Can_Message.DATA, msg_access);
angle = msg_access->CCU_SteeringWheelAngle;
msg_access->CCU_SteeringWheelAngle = 42;


--- End code ---

All the best with your project!

superiorsoftware:
It has been several years since there have been post, but I have recently been working with this tool.  I am struggling with a big endian format dbc.  This tool does a nice job, but I must go in and remove the padding added before the first byte (that the tool adds, but I don't think should be there).  The dbc file is mandated to be big endian so I must work with that.

Here is the Can db file description:

BO_ 2565999614 BRM_V_Cell_1_to_4: 8 Vector__XXX
 SG_ Cell_Voltage_4 : 55|16@0+ (0.0001,0) [0|6.5535] "V" Vector__XXX
 SG_ Cell_Voltage_3 : 39|16@0+ (0.0001,0) [0|6.5535] "V" Vector__XXX
 SG_ Cell_Voltage_2 : 23|16@0+ (0.0001,0) [0|6.5535] "V" Vector__XXX
 SG_ Cell_Voltage_1 : 7|16@0+ (0.0001,0) [0|6.5535] "V" Vector__XXX



And here is the output from the conversion program (just a snippet from *.h file).  My question is, Is there a method to eliminate the padded bits prior to the Voltage1 in the structure.  All works fine if I do it by hand, but would really like an automated option.

/**
 * ""
 *
 * ###Parameters###
 * | Name    |   Value      |
 * | ------   |   --------   |
 * | ID:   |   0x18F20BFE   |
 * | IDE:    |   EXT       |
 * | DLC:    |   8         |
 *
 * ###Signals###
 * | Position (Bit)   |   Signal (Bitlength)   |
 * | -------------   |   ------------------   |
 * | [7]         |    @ref DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_1    "Cell_Voltage_1 (16)"    |
 * | [23]         |    @ref DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_2    "Cell_Voltage_2 (16)"    |
 * | [39]         |    @ref DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_3    "Cell_Voltage_3 (16)"    |
 * | [55]         |    @ref DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_4    "Cell_Voltage_4 (16)"    |
 *
 */
static struct DBC_INTERNAL_CAN_V11_MSG_V_Cell_1_to_4 {
   const uint32_t ID;
   const uint8_t IDE;
   const uint8_t DLC;
   const struct {
      signal_positioned Cell_Voltage_1;
      signal_positioned Cell_Voltage_2;
      signal_positioned Cell_Voltage_3;
      signal_positioned Cell_Voltage_4;
   } sigParms;
   struct __attribute__((packed)) DBC_INTERNAL_CAN_V11_MSG_V_Cell_1_to_4_sigVals {
      void    : 1;
      void    : 1;
      void    : 1;
      void    : 1;
      void    : 1;
      void    : 1;
      void    : 1;
      uint16_t Cell_Voltage_1   : 16;
      uint16_t Cell_Voltage_2   : 16;
      uint16_t Cell_Voltage_3   : 16;
      uint16_t Cell_Voltage_4   : 16;
   } *sigVals;
} DBC_INTERNAL_CAN_V11_MSG_V_Cell_1_to_4 __attribute__((unused)) = {
   .ID = 0x18F20BFE,
   .IDE = CAN_ID_EXT,
   .DLC = 8,
   .sigParms  = {
      {7,    &DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_1},
      {23,    &DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_2},
      {39,    &DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_3},
      {55,    &DBC_INTERNAL_CAN_V11_SIG_Cell_Voltage_4}
   },
   .sigVals = 0
};

gnasirator:
Hey,
happy to hear this SW getting some use!

It's been a super long time for me to actually use this as I have moved on into automotive where Vector tools are standard now. They take care of all of this.

Anyways, about your question:
When I developed this, I was using it on a little endian machine. Not sure if it properly supports big endianness. If I look at your DBC input it looks to me like there are in fact 7 unused bits in the message before the first signal, right?


--- Quote ---SG_ Cell_Voltage_1 : 7|16@0+ (0.0001,0) [0|6.5535] "V" Vector__XXX
--- End quote ---

This is what the tool is adding the padding for. I see if this DBC is now using BE, that's not really supported as you can see. I have not seen this format before in a DBC. It's a bit counter intuitive to have the first signal start at byte#1 while the other byte is on location #0.
I would've still expected the DBC to reference the signal as beginning on location byte#0 and only swapping the content due to BE... weird.

superiorsoftware:
The tool is very useful, even with the hand modifications.  I will provide more info next week, when I can get back to looking at the dbc file.

Thanks.

Navigation

[0] Message Index

[*] Previous page

There was an error while thanking
Thanking...
Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod