Commit Graph

229 Commits

Author SHA1 Message Date
rusefillc 181c4854cb inverting boolean, also better name 2025-04-27 13:25:52 -04:00
rusefillc 394ce6b95f motec 2025-04-27 13:25:52 -04:00
rusefillc a5a335415f HD 2025-04-27 13:25:52 -04:00
rusefillc 64fe796a9a ATS 2025-04-27 13:25:52 -04:00
rusefillc 1f63286f1d malibu 2025-04-27 13:25:52 -04:00
rusefillc 416c11423c progress or bug? I am very confused 2025-04-27 13:25:04 -04:00
rusefillc 2dfff3a3e9 inverting boolean, also better name 2025-04-27 13:07:00 -04:00
rusefillc 87a8ac1ca5
Update README.md 2025-04-25 18:50:33 -04:00
rusefi fbc5773b63 fresh syntax 2025-04-21 17:17:32 -04:00
rusefillc bb010fe90c distribution to write raw count 2025-04-21 17:11:37 -04:00
rusefi 819287f896 gradle-8.13 2025-04-21 17:07:57 -04:00
rusefillc 4b0d3aa89d https://github.com/rusefi/rusefi/issues/7714 2025-04-14 12:02:54 -04:00
rusefillc f70c4c4e1e
Update README.md 2025-04-01 23:20:18 -04:00
rusefillc 853addb1eb
Merge pull request #2 from esaulenka/fix_DCB_parser
Fix parsing complicated DBCs
2025-03-25 06:51:06 -04:00
rusefillc 34f12a2977
Merge pull request #3 from esaulenka/fix_improve_help
Minor: improve reader's help
2025-03-25 06:50:42 -04:00
Alexey Esaulenko 3231c8c9c2 Minor: improve reader's help 2025-03-25 12:08:55 +04:00
Alexey Esaulenko 1a797bfd99 Fix parsing complicated DBCs 2025-03-25 11:48:32 +04:00
rusefillc 4497f054e5 argument validation 2025-03-22 16:55:08 -04:00
rusefillc 9ee85419e7 auto-clipboard 2025-03-11 18:44:33 -04:00
rusefillc e2320d7bd0 PinLine 2025-01-17 13:58:37 -05:00
rusefillc 21cacf8c54 Overview Motorola vs. Intel-Format in Can-Frame
Some explanations of CAN byte order and bit numbering:

openxcplatform-bitnumbering

Mathworks-Side

CAN frame data is either in big endian or little endian byte format.

The bits are numbered by the file format either using MSB first (MSB0) or LSB first (LSB0).

With "consistent" format/numbering, bit numbering follows the byte format. MSB0 for big endian, LSB0 for little endian.

ietf-endianess

Usually the start bit referenced by the file formats reference the start of the signal data within the message independent of the endianess of the signal. With some formats (DBF), the startbit may always reference the LSB of the signal data.

Common formats:

KCD, SYM (consistent bit numbering)

little,LSB0
big,MSB0
DBC, ARXML (OSEK bit numbering)

little,LSB0
big,LSB0 (inconsistent)
DBF (startBit=LSB, startByte and startBit specified separately)

little,LSB0
big,LSB0,startBit=LSB (inconsistent)
Legacy canmatrix (yaml, json) (Note: internally canmatrix now uses consistent bit numbering)

little,LSB0
big,LSB0,startBit=LSB (inconsistent)
###First Example:

Frame with two 32-bit signals in motorola one can-frame

 7 6 5 4 3 2 1 0
0>msb-----
1  signal1
2
3       ----lsb>
4>msb-----
5  signal2
6
7       ----lsb>
DBC:

BO_ 291 newFrameMotorola: 8 Vector__XXX
 SG_ signal1 : 7|32@0- (1,0) [0|0] "" Vector__XXX  (most significant bit)
 SG_ signal2 : 39|32@0- (1,0) [0|0] "" Vector__XXX (most significant bit)
candb++ views:

signal1: 24 (least significant bit?)
signal2: 56 (least significant bit?)
Dbf:

byte 4 bit 0
byte 8 bit 0
###Second Example:

 7 6 5 4 3 2 1 0
0        >msb---
1---------lsb>
2
3
4
5
6
7
DBC:

startbit 3
length 11
candb++ views:

Startbit 9 (least significant bit?)
dbf:

length 11
byte 2 (counting starts with byte 1)
bit 1
##found docs about kcd "Least significant bit offset of the signal relative to the least significant bit of the messages data payload." least significant bit?

estimation about dbf
least significant bit?

new formulars from dmahurin
Note the basic operations used.

convert from lsb0 bit numbering to msb0 bit numbering (or msb0 to lsb0)
b = b - (b % 8) + 7 - (b % 8)

convert from lsbit of signal data to msbit of signal data, when bit numbering is msb0
b = b + 1 - length

convert from msbit of signal data to lsbit of signal data, when bit numbering is msb0
b = b + length - 1

So conversion from msbit in lsb0 bit numbering to msbit in lsb0 bit numbering is:

b = b - (b % 8) + 7 - (b % 8)

b = b + length - 1

b = b - (b % 8) + 7 - (b % 8)

byte order names
little endian == Intel == MOST-SIGNIFICANT-BYTE-LAST

big endian == Motorola == MOST-SIGNIFICANT-BYTE-FIRST
2024-11-06 21:54:49 -05:00
rusefillc fcf1119800 Overview Motorola vs. Intel-Format in Can-Frame
Some explanations of CAN byte order and bit numbering:

openxcplatform-bitnumbering

Mathworks-Side

CAN frame data is either in big endian or little endian byte format.

The bits are numbered by the file format either using MSB first (MSB0) or LSB first (LSB0).

With "consistent" format/numbering, bit numbering follows the byte format. MSB0 for big endian, LSB0 for little endian.

ietf-endianess

Usually the start bit referenced by the file formats reference the start of the signal data within the message independent of the endianess of the signal. With some formats (DBF), the startbit may always reference the LSB of the signal data.

Common formats:

KCD, SYM (consistent bit numbering)

little,LSB0
big,MSB0
DBC, ARXML (OSEK bit numbering)

little,LSB0
big,LSB0 (inconsistent)
DBF (startBit=LSB, startByte and startBit specified separately)

little,LSB0
big,LSB0,startBit=LSB (inconsistent)
Legacy canmatrix (yaml, json) (Note: internally canmatrix now uses consistent bit numbering)

little,LSB0
big,LSB0,startBit=LSB (inconsistent)
###First Example:

Frame with two 32-bit signals in motorola one can-frame

 7 6 5 4 3 2 1 0
0>msb-----
1  signal1
2
3       ----lsb>
4>msb-----
5  signal2
6
7       ----lsb>
DBC:

BO_ 291 newFrameMotorola: 8 Vector__XXX
 SG_ signal1 : 7|32@0- (1,0) [0|0] "" Vector__XXX  (most significant bit)
 SG_ signal2 : 39|32@0- (1,0) [0|0] "" Vector__XXX (most significant bit)
candb++ views:

signal1: 24 (least significant bit?)
signal2: 56 (least significant bit?)
Dbf:

byte 4 bit 0
byte 8 bit 0
###Second Example:

 7 6 5 4 3 2 1 0
0        >msb---
1---------lsb>
2
3
4
5
6
7
DBC:

startbit 3
length 11
candb++ views:

Startbit 9 (least significant bit?)
dbf:

length 11
byte 2 (counting starts with byte 1)
bit 1
##found docs about kcd "Least significant bit offset of the signal relative to the least significant bit of the messages data payload." least significant bit?

estimation about dbf
least significant bit?

new formulars from dmahurin
Note the basic operations used.

convert from lsb0 bit numbering to msb0 bit numbering (or msb0 to lsb0)
b = b - (b % 8) + 7 - (b % 8)

convert from lsbit of signal data to msbit of signal data, when bit numbering is msb0
b = b + 1 - length

convert from msbit of signal data to lsbit of signal data, when bit numbering is msb0
b = b + length - 1

So conversion from msbit in lsb0 bit numbering to msbit in lsb0 bit numbering is:

b = b - (b % 8) + 7 - (b % 8)

b = b + length - 1

b = b - (b % 8) + 7 - (b % 8)

byte order names
little endian == Intel == MOST-SIGNIFICANT-BYTE-LAST

big endian == Motorola == MOST-SIGNIFICANT-BYTE-FIRST
2024-11-06 21:51:05 -05:00
rusefillc c9580eaaf5 applyOrderForStartOffset 2024-11-06 18:38:20 -05:00
rusefillc d7cfa66425 AlwaysSameScanner 2024-11-05 22:29:54 -05:00
rusefillc 4e44fe5d98 some strange progress 2024-11-05 21:33:25 -05:00
rusefillc 0427ae0785 yFrom 2024-10-24 22:01:25 -04:00
rusefillc 1bcc179486
Update README.md 2024-10-24 11:55:00 -04:00
rusefillc d6222d1141 PinLine 2024-10-22 07:28:08 -04:00
rusefillc 53cf35734c PinoutTemplate 2024-10-22 06:41:37 -04:00
rusefillc cb253eda61 send-only proto as well 2024-10-16 22:45:03 -04:00
rusefillc d14ca16039 allowDuplicateNames 2024-10-16 22:44:42 -04:00
rusefillc 22e66be7cd timestamp scale bugfix 2024-09-22 21:21:13 -04:00
rusefillc 430ec5cd7a docs timestamp 2024-09-22 21:10:17 -04:00
rusefillc 5c89e92212 documentation 2024-09-22 20:55:58 -04:00
rusefillc 3010885aa0 dead 2024-09-22 20:54:54 -04:00
rusefillc cd4ffd6729 ByteRateOfChangeReports.filter 2024-09-12 19:28:58 -04:00
rusefillc 735ccbb04f upload-artifact@v4 2024-09-06 19:23:08 -04:00
rusefillc f3a84c7e72 smarter code 2024-09-06 19:17:03 -04:00
rusefillc e127cda824 hello September 2024 2024-09-04 23:42:20 -04:00
rusefillc c336245c02 C/C++ into _middle 2024-09-04 22:26:51 -04:00
rusefillc 609733c64a filter.rejectPacket 2024-07-25 21:37:38 -04:00
rusefillc 10700106f7 FirstPacket tool 2024-07-25 21:22:16 -04:00
rusefillc 6a63b31e11 WOW bugfix - wrong result when running multiple files! 2024-07-25 16:09:35 -04:00
rusefillc 1def6a7463 more readable report 2024-07-25 16:04:30 -04:00
rusefillc dcb6283620 ops dead code 2024-07-25 16:04:16 -04:00
rusefillc bd90ce8019 Let's use unique field names 2024-05-27 11:08:25 -04:00
rusefillc 2698a8fb30 bugfix? 2024-05-15 16:17:29 -04:00
rusefillc 63762e6900 things are a bit broken 2024-05-15 15:45:55 -04:00
rusefillc d249e28787 throw new IllegalArgumentException 2024-05-14 17:02:30 -04:00
rusefillc c6accaacb9 code style 2024-05-13 21:30:36 -04:00