litter endian and big endian error

[hadwin2017]

`

switch (sig.byteOrder) {

  | case 0:
  | // Little endian
  | littleEndian = true;
  | break;
  |  
  | case 1:
  | // Big endian
  | littleEndian = false;
  | break;
  |  
  | default:
  | cds_error("byte order {} not suppoerted", sig.byteOrder);
  | continue;
  | }

`

here, Intel is Little endian, and byteOrder is 1, Motorola is Big endian and byteOrder is 0

[rkollataj]

@hadwin2017 Not sure if I get your comment right. Do you mean that biteOrder is wrong? I based the code on http://read.pudn.com/downloads766/ebook/3041455/DBC_File_Format_Documentation.pdf

Extract:
byte_order = '0' | '1' ; (* 0=little endian, 1=big endian *)
The byte_format is 0 if the signal's byte order is Intel (little endian) or 1 if the byte
order is Motorola (big endian).

[sangngocle]

@rkollataj I think the reference file above is outdated and not valid anymore.
According this Github Repo and this link http://socialledge.com/sjsu/index.php/DBC_Format#:~:text=DBC%20file%20is%20a%20proprietary,bytes%20of%20CAN%20message%20data.&text=Essentially%2C%20each%20%22message%22%20defined,members%20of%20the%20C%20structure. , the byteformat is 1 if the signal's byte order is little-endian and vice versa

[rkollataj]

@SNL5943 The document I shared comes from Vector which is DBC "inventor". I believe that this source is more relevant than sites that are trying to reverse engineer the format. I will leave this issue open and will try to verify endianess in CANoe when I will get a chance.

[sangngocle]

One finding, I've review dbcparser.cpp from CANdb, at line 251 as below:
CANsignal::ByteOrder byteOrder = (take_back(numbers) == 0) ? CANsignal::Motorola : CANsignal::Intel;
I don't have any Vector hardware or software so can not verify with them.

[jenszo]

I am working with a major OEM's DBCs on a regular basis which have been built and engineered using mainly Vector Hard- and Software. I can confirm that the current endinaness implementation of CANdb++ is perfectly valid and co-exist just fine with Vector products.

Little Endian is 1, Big Endian is 0. The implementation in CANdb++ had been slightly amended by me, I have to admit, but I just now confirmed it with the Vector DBC Editor.

Yet, the switch above, which is part of CANDevStudio, seems to be mixing it up, I would say.

[rkollataj]

Fixed with #206 in v1.2.1