When a diagnostic tool is connected to the server it gets the the DTC.
I want to know how the DTC data is defined and stored in the ECU.
DTC codes are usually defined as 2-byte or 3-byte values.
A common representation following ISO 15031-6/SAE J2012 is as five-character alphanumeric code (ie. P0001) with the optional low-byte appended as hexadecimal value (ie. P0001-00). The first letter being either: P for Powertrain (00b, highest bits on highest byte), C for Chassis (01b), B for Body (10b) or U for Network related DTCs (11b). ie.
P0001 (Fuel Volume Regulator Control Circuit/Open) would be represented as bytes: 0x00 0x01
P0A01 (Range/Performance) would be represented as bytes: 0x0A 0x01
C0001 (TCS Control Channel A Valve 1) would be represented as bytes: 0x40 0x01
The DTCs are stored as their respective byte representation in Non-volatile memory (NvM) of the ECU, so that it can be retrieved even if the ECU has been power cycled. Along with the DTC additional information will be stored, i.e. Freeze frame/environmental data, DTC status mask (pendingDTC/confirmedDTC/...), counter (aging/debouncing), time of first occurence, etc.
Related
I am confused on RGB565 and BGR565 color space in bits order. e.g, the hex value 0xF81E, I don't know at RGB565, R is high 5 bits in (0xF81E & 0xF800), or R is low 5 bits (0xF81E & 0x001F)
If you have a 16-bit value, then in RGB565 the R component will be the most significant 5 bits (ie high bits), whereas in BGR565 it'll be the least-significant 5 bits (low bits).
That said, if you are reading such 16-bit values from serialized bytes (eg a raw dump to file), then also consider the byte order of the serialization. For example, if the serialization isn't big-endian (network byte order), then 0xF81E appearing in adjacent raw bytes might indicate RGB565 value 0x1EF8.
ITU T.81 states the following:
B.1.1.2 Markers
Markers serve to identify the various structural
parts of the compressed data formats. Most markers start marker
segments containing a related group of parameters; some markers stand
alone. All markers are assigned two-byte codes: an X’FF’ byte followed
by a byte which is not equal to 0 or X’FF’ (see Table B.1). Any marker
may optionally be preceded by any number of fill bytes, which are
bytes assigned code X’FF’. NOTE – Because of this special
code-assignment structure, markers make it possible for a decoder to
parse the compressed data and locate its various parts without having
to decode other segments of image data. "
B.1.1.5 Entropy-coded data segments An entropy-coded data segment
contains the output of an entropy-coding procedure. It consists of an
integer number of bytes, whether the entropy-coding procedure used is
Huffman or arithmetic.
NOTES
(1) Making entropy-coded segments an
integer number of bytes is performed as follows: for Huffman coding,
1-bits are used, if necessary, to pad the end of the compressed data
to complete the final byte of a segment. For arithmetic coding, byte
alignment is performed in the procedure which terminates the
entropy-coded segment (see D.1.8).
(2) In order to ensure that a marker
does not occur within an entropy-coded segment, any X’FF’ byte
generated by either a Huffman or arithmetic encoder, or an X’FF’ byte
that was generated by the padding of 1-bits described in NOTE 1 above,
is followed by a “stuffed” zero byte (see D.1.6 and F.1.2.3).
And in many other places where well known Stuff_0() function is also named.
Not sure where standard ITU T.87 stands in regard to the encoding escape sequence 0xFF 0x00 specified by standard ITU T.81:
Standard ITU T.87 it self that do not specify this but expects it.
Where Standard test samples are incorrectly formed, clearly do not have encoding escape sequence 0xFF 0x00 in encoded streams. For example 0xFF 0x7F, 0xFF 0x2F, and other sequences can be found in encoded streams of .jsl test samples : namelly "T8C0E3.JLS". And no one saw it all these years;
Or if Standard ITU T.87 actually overrides the ITU T.81 regarding this rule for encoded streams and doesn't allow encoding of escape sequence;
In decoder we could make logic to detect decoder errors when 0xFF and !0x00 is to actually use that byte and not skip it if component is not fully decoded. But what if jls file do not have escape sequence and we encounter 0xFF 0x00 sequence should we skip 0x00 byte or not?
Would like some clarification on subject of standard ITU T.87 JPEG-LS encoding, and what is the correct procedure. Should we, or shouldn't we, encode escape sequnce 0xFF 0x00 in encoded streams?
The answer :
ITU T.87 - ANNEX A - point A1 Coding parameters and compressed image data - pass 3
Marker segments are inserted in the data stream as specified in Annex
D. In order to provide for easy detection of marker segments, a single
byte with the value X'FF' in a coded image data segment shall be
followed with the insertion of a single bit '0'. This inserted bit
shall occupy the most significant bit of the next byte. If the X'FF'
byte is followed by a single bit '1', then the decoder shall treat the
byte which follows as the second byte of a marker, and process it in
accordance with Annex C. If a '0' bit was inserted by the encoder, the
decoder shall discard the inserted bit, which does not form part of
the data stream to be decoded.
NOTE 2 – This marker segment detection
procedure differs from the one specified in CCITT Rec. T.81 | ISO/IEC
10918-1.
JPEG-LS T.87 overrides T.81 JPEG Standard for encoded data stream to have byte 0xFF followed by byte with value between 0x00 and 0x7F (inclusive).
LDA is a simple opcode that loads to accumulator (register a) the pointed data in intel 8080 processor. In this condition (0x3a LDA addr) it says that op loads the addr to accumulator. But i couldn't recognize what it specifyies as addr.
A <- (adr) is the operation which 0x3a does and it uses 3 bytes of memory. I could store the data in the last 2 bytes of op as hi add and low add in a stack but accumulator is only 1 byte so i can't. Thanks.
LDA a16 instruction reads a byte from address a16 (the 8080 has a 16-bit bus) and stores that value into the A register.
This instruction is encoded as three : 0x3a lo hi, being lo and hi the two bytes that compose the address.
If you want to store an immediate (constant) value into A you should use instead instruction MVI A, x, being x the constant value. This instruction is encoded as: 0x3e x, only two bytes, as you seem to expect.
It looks like you are confusing memory address and memory content. The 8080 has an address bus of 16 bits and a data bus of 8 bits. That means that it can access memory from address 0x0000 up to 0xffff (16 full bits), or 65536 different addresses, but each of these address can store a single byte, with a value from 0x00 to 0xff (8 bits). That adds up to 64 kilobytes of memory.
Now, when you want to read a value from memory you need to specify the address of the value you are reading (remember, the address is 16 bits, the value is 8 bits). So you have to encode somehow the address into the instruction using 2 bytes. Intel CPU use the little-endian scheme, so to encode an address the lower 8 bits are stored in the first byte and the higher 8 bits in the second one. And that is what the LDA opcode does, and that is why it is 3 bytes long.
I am parsing a JPG in java byte by byte. I am then writing same image byte by byte, and I have come across an oddity. I have tried looking at the spec but I see no reference.
At the end of the SOS section there are three bytes that most sources say 'skip'. But if I write 0x00,0x00,0x00 then java(fx) complains about an invalid value. If I write 0x000x3f0x00 then there is no complaint. (the three byte sequence is what was produced by GIMP in the original file)
I came across an indirect reference to this in the GoLang repo
// - the bytes "\x00\x3f\x00". Section B.2.3 of the spec says that for
// sequential DCTs, those bytes (8-bit Ss, 8-bit Se, 4-bit Ah, 4-bit Al)
// should be 0x00, 0x3f, 0x00<<4 | 0x00.
My question is should I just write 0x3f at this position, or does the value depend upon something else?
In a sequential JPEG scan this value has no meaning. The standard says to set it to 63 but that tells the decoder nothing. You have to process all 64 DCT coefficients in a sequential scan.
In a progressive scan this value means A LOT.
I've started to work with the JavaCards and trying to grasp the sense of CLA byte.
If to read RFC 5.4.1 Class byte
5.4.1 Class byte
According to table 8 used in conjunction with table 9, the class byte
CLA of a command is used to indicate to what extent the command and the response comply with this part of ISO/IEC 7816 and when applicable (see table 9), the format of secure messaging and the logical channel number.
So... CLA flag is used for the indication, but what exact? Because, the table and description as for the beginner is rather difficult, I understand that usually are used the next CLA bytes: 0x00, 0x80, 0x84.
For e.g. if to read the content from table:
0X' Structure and coding of command and response according to this part of ISO/IEC 7816 (for coding of 'X' see table 9)
10 to 7F RFU
Reserved for PTS
I understand that for the fine developing - I should read GlobalPlatform specification, the specification about the exact card (mine is NXP one) and other related materials, but I want to admit, that it's difficult to understand the content.
I've expected the following (pseudo-table):
0x00 -> for reading streams from file system
0x01 -> for writing byte buffer to memory blocks
0x02 -> call AES/RSA methods
The CLASS byte is defined in ISO 7816-4. The first bit indicates the interindustry class. Java Card applets shall operate in this interindustry standard. Global Platform is another specification to manage and maintain the card and all commands will have class byte 0x80 - 0x8F. Class byte 0xFF is used for communication with the card reader in some cases and is otherwise invalid for a card.
The interindustry meaning for the CLA serves 3 major functions:
Function 1: Chaining
bit5 = 1 signalizes that the current command is not the last command of a chain, meaning that multiple APDUs all belong together and the card may therefore do additional things
Function 2: Secure Messaging
bit4+3 serve to signalize the secure messaging status of the current command. This means that the APDU is authenticated(e.g. MACed) and the data is encrypted(e.g. block cipher). The command header is never encrypted.
Function 3: Logical Channel
bit2+1 serve to identify the logical channel number. Logical channels are parallel communication interfaces through the card, therefore an applet A can be selected on Channel 0 and an applet B can be selected on Channel 1 while both applets remain in their internal state(no RAM is reset). Most cards do not support logical channels or you have to enable them explicitly.
CLA byte is a typical trap for Java Card beginners and its usually best that you leave at 0x00 for the start.