DBC Format - Revision history

Preet: /* CAN TX */

2017-10-11T05:33:37Z

‎CAN TX

Preet at 05:19, 11 October 2017

2017-10-11T05:19:16Z

Preet: /* CAN TX with callback */

2017-10-11T05:18:11Z

‎CAN TX with callback

Proj user18: /* Signed Signal */

2016-12-17T01:06:12Z

‎Signed Signal

Preet: /* CAN TX with callback */

2016-08-24T23:10:47Z

‎CAN TX with callback

Preet at 23:07, 24 August 2016

2016-08-24T23:07:49Z

Preet at 20:33, 29 July 2016

2016-07-29T20:33:50Z

Preet at 23:16, 14 July 2016

2016-07-14T23:16:05Z

Preet at 23:15, 14 July 2016

2016-07-14T23:15:22Z

Preet: /* CAN RX */

2016-07-14T23:02:45Z

‎CAN RX

@@ Line 292: / Line 292: @@
 The transmission side is simpler than receive because you simply provide an 8-byte data storage for the CAN message, and the encode_ functions convert the C structure onto the 8-bytes that you can send out as part of the CAN message.  The encode_ functions also return the message ID and the length of the CAN message and this was done in an effort to decouple the CAN driver from the AGC.
-<syntaxhighlight>
+<syntaxhighlight lang="C">
 void period_10Hz(void)
+{

@@ Line 214: / Line 214: @@
 | -->
+|
-<syntaxhighlight>
+<syntaxhighlight lang="C">
 typedef struct {
      int8_t MOTOR_CMD_steer;
@@ Line 241: / Line 241: @@
 === CAN RX ===
 To handling the messages that are to be received, we must have "glue code" that pieces together the data of a received messages to the target structure.  Unfortunately the AGC cannot generate the glue code because it is decoupled from the CAN driver and furthermore, it leaves it up the application to provide the destination structure to convert the CAN data onto.
-<syntaxhighlight>
+<syntaxhighlight lang="C">
 #include "_can_dbc/generated_can.h"
 #include "can.h"

@@ Line 317: / Line 317: @@
 There is an alternate method of sending CAN messages that may make your life easier by defining a callback function to send a CAN message.  This way, your application doesn't have to deal with a CAN message at all!
-<syntaxhighlight>
+<syntaxhighlight lang = "C">
 // This method needs to be defined once, and AGC will call it for all dbc_encode_and_send_FOO() functions
 bool dbc_app_send_can_msg(uint32_t mid, uint8_t dlc, uint8_t bytes[8])

@@ Line 33: / Line 33: @@
 BO_ 500 IO_DEBUG: 4 IO
   SG_ IO_DEBUG_test_unsigned : 0|8@1+ (1,0) [0|0] "" DBG
-  SG_ IO_DEBUG_test_signed : 8|8@1+ (1,-128) [0|0] "" DBG
+  SG_ IO_DEBUG_test_signed : 8|8@1- (1,-128) [0|0] "" DBG
 </syntaxhighlight>
 <BR/>
 === Fractional Signals (float) ===
 A floating point variable can be sent by deciding the range, and the precision that you require.  For example, if we choose 8-bits, with <tt>'''0.1'''</tt> as a fraction, we can send the data range of <tt>'''0.0 -> 25.5'''</tt>.  On the other hand, if we want more precision and negative representation, we could use 12-bits with <tt>'''0.01'''</tt> as a fraction, and an offset.  The second fractional signal also contains an explicit minimum and maximum, which is limited by 12-bit that can represent 4096 different numbers, and by factoring in the offset, and using half of the range for negative representation, it ends up with the limited range of <tt>'''-20.48 -> 20.47'''</tt>

@@ Line 314: / Line 314: @@
 === CAN TX with callback ===
-There is an alternate method of sending CAN messages that may make your life easier by defining a callback function to send a CAN message.
+There is an alternate method of sending CAN messages that may make your life easier by defining a callback function to send a CAN message.  This way, your application doesn't have to deal with a CAN message at all!
 <syntaxhighlight>

@@ Line 69: / Line 69: @@
 *  If first 2-bits are 1 (M1), then 62-bits of data is for the car's rear sensors
-Likewise, we could use 8-bit multiplexer, and then we can send 7 bytes of unique data * 256 multiplexers using the same MID.
+Likewise, we could use 8-bit multiplexer, and then we can send 7 bytes of unique data * 256 multiplexers using the same MID.  Multiplexed messages are used quite often when:
 *  Certain information should be grouped under a single MID.
 *:  If there are 100 sensors that use 32-bit value, it is better to use a multipexer rather than 100 different message IDs.
@@ Line 77: / Line 75: @@
 *  We wish to use the same MID for CAN priority purposes
-<BR/>
+Observe the following things in the example below:
-== Auto-Generated Code ==
+*  There are two multiplexed messages, m0, and m1.
-In a nutshell, the AGC allows a C/C++ application to deal with structures, and avoid the work of packing and unpacking data from a CAN message.  Here is an example of a message defined in the DBC, and its auto-generated code artifact:
+*:  m0 has the value of 0b0000 for the MUX, and m1 has the value of 0b0001
 <syntaxhighlight>
-BO_ 101 MOTOR_CMD: 1 DRIVER
+BO_ 200 SENSOR_SONARS: 8 SENSOR
-  SG_ MOTOR_CMD_steer : 0|4@1- (1,-5) [-5|5] "" MOTOR
+  SG_ SENSOR_SONARS_mux M : 0|4@1+ (1,0) [0|0] "" DRIVER,IO
-  SG_ MOTOR_CMD_drive : 4|4@1+ (1,0) [0|9] "" MOTOR
+  SG_ SENSOR_SONARS_err_count : 4|12@1+ (1,0) [0|0] "" DRIVER,IO
-</syntaxhighlight>
+ SG_ SENSOR_SONARS_left m0 : 16|12@1+ (0.1,0) [0|0] "" DRIVER,IO
-| -->
+ SG_ SENSOR_SONARS_middle m0 : 28|12@1+ (0.1,0) [0|0] "" DRIVER,IO
+ SG_ SENSOR_SONARS_right m0 : 40|12@1+ (0.1,0) [0|0] "" DRIVER,IO
-<syntaxhighlight>
+ SG_ SENSOR_SONARS_rear m0 : 52|12@1+ (0.1,0) [0|0] "" DRIVER,IO
-typedef struct {
+ SG_ SENSOR_SONARS_no_filt_left m1 : 16|12@1+ (0.1,0) [0|0] "" DBG
-    int8_t MOTOR_CMD_steer;
+ SG_ SENSOR_SONARS_no_filt_middle m1 : 28|12@1+ (0.1,0) [0|0] "" DBG
-    uint8_t MOTOR_CMD_drive;
+ SG_ SENSOR_SONARS_no_filt_right m1 : 40|12@1+ (0.1,0) [0|0] "" DBG
-} MOTOR_CMD_t;
+ SG_ SENSOR_SONARS_no_filt_rear m1 : 52|12@1+ (0.1,0) [0|0] "" DBG
 </syntaxhighlight>
 <BR/>
@@ Line 200: / Line 199: @@
 </syntaxhighlight>
 == CAN Communication Handling in C ==
-I created auto-generation tool that operates on the DBC file that produces Auto-Generated-Code that we will refer to as AGC in this article.  AGC contains useful artifacts such as:
+I created auto-generation tool that operates on the DBC file that produces the AGC.  AGC contains useful artifacts such as:
 *  C structures that store data variables as described in the DBC message
 **  Each signal that your controller is a recipient of will occupy a member variable of the struct
@@ Line 284: / Line 308: @@
      // Queue the CAN message to be sent out
      CAN_tx(can1, &can_msg, 0);
+}
 </syntaxhighlight>
 <BR/>

@@ Line 17: / Line 17: @@
 Observations:
-*  The signal name is <tt>'''IO_DEBUG'''</tt> and MID is <tt>'''500'''</tt> (decimal), and the length is <tt>'''4'''</tt> bytes (though we only need 1 for 8-bit signal)
+*  The message name is <tt>'''IO_DEBUG'''</tt> and MID is <tt>'''500'''</tt> (decimal), and the length is <tt>'''4'''</tt> bytes (though we only need 1 for 8-bit signal)
 *  The sender is <tt>IO</tt>
 *  <tt>'''0|8'''</tt>: The unsigned signal starts at bit position 0, and the size of this signal is 8

← Older revision		Revision as of 23:16, 14 July 2016
Line 4:		Line 4:

	The second part of this article discusses how the auto-generated code can help you read and write the CAN message data. Essentially, each "message" defined in a DBC becomes a C structure with the signals being the members of the C structure.		The second part of this article discusses how the auto-generated code can help you read and write the CAN message data. Essentially, each "message" defined in a DBC becomes a C structure with the signals being the members of the C structure.
		+
		+	== DBC Data ==

	<BR/>		<BR/>

@@ Line 47: / Line 47: @@
 <BR/>
 === Enumeration Types ===
 An enumeration type is used where the user wishes to use or see names, instead of numbers.  For example, instead of a state machine showing up as "0, 1, 2", we could see it as "stopped, running, paused".  It is accomplished by adding two new lines in the DBC file.
@@ Line 63: / Line 62: @@
 <BR/>
 == Auto-Generated Code ==
 In a nutshell, the AGC allows a C/C++ application to deal with structures, and avoid the work of packing and unpacking data from a CAN message.  Here is an example of a message defined in the DBC, and its auto-generated code artifact:

@@ Line 215: / Line 215: @@
 const uint32_t            MOTOR_STATUS__MIA_MS = 3000;
 const MOTOR_STATUS_t      MOTOR_STATUS__MIA_MSG = { 0 };
 // Sample periodic task that receives and stores messages
@@ Line 220: / Line 224: @@
+{
      can_msg_t can_msg;
      // Empty all of the queued, and received messages within the last 10ms (100Hz callback frequency)
@@ Line 239: / Line 241: @@
      // successful decoding resets the MIA counter, otherwise it will increment to
      // its MIA value and upon the MIA trigger, it will get replaced by your MIA struct
-     dbc_handle_mia_SENSOR_SONARS_m0(&sensor_can_msg.m0, 10);
+     dbc_handle_mia_SENSOR_SONARS_m0(&sensor_can_msg.m0, 10);  // 10ms due to 100Hz
      dbc_handle_mia_SENSOR_SONARS_m1(&sensor_can_msg.m1, 10);