I've code across an elf file with dwarf information produced by a tricore-gcc compiler from HighTec. It contains dwarf attribute encoding 0x05 which isn't mentioned in the standard version 4 which reads
DW_AT_sibling 0x01 reference
DW_AT_location 0x02 exprloc, loclistptr
DW_AT_name 0x03 string
DW_AT_ordering 0x09 constant
and in the standard version 5 it's "reserved". Didn't find it in any older standard either.
Anyone knows what coe 0x05 is?
It was part of DWARF1, see dwarf.h of libdwarf:
#define DW_AT_sibling 0x01
#define DW_AT_location 0x02
#define DW_AT_name 0x03
/* reserved DWARF1 0x04, DWARF1 only */
/* AT_fund_type 0x05, DWARF1 only */
/* AT_mod_fund_type 0x06, DWARF1 only */
/* AT_user_def_type 0x07, DWARF1 only */
/* AT_mod_u_d_type 0x08, DWARF1 only */
#define DW_AT_ordering 0x09
#define DW_AT_subscr_data 0x0a
And according to DWARF 1.1, AT_fund_type means Fundamental Types:
A fundamental type is a data type that is not defined in terms of
other data types. Each programming language has a set of fundamental
types that are considered to be built into that language.
Related
Unable to get any response from CoreNFC when NDEF length is over 256 bytes and therefore requires the use of a 3-byte field versus a 1-byte field. I should note that tags can both be read on Android.
Can anyone else confirm this behavior or help me understand how to specify the file so CoreNFC will recognize and read the file?
So this works,
// TLV header
// Start of Type (T) field
0x03, // This message contains an NDEF record
// End of Type (T) field
// Start of Length (L) field
// Length = payload length + length of value field
0xFE, // Length field, adds 3 to account for length of value field when SR:1
// End of Length (L) field
// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:1,IL:0,TNF:101
0xD5, // Short record false SR:1, 1-byte payload length, unknown type
0x00, // Type set to zero, as specified for unknown type
0xFB, // Payload length
// End of Value (V) field
// End of TLV header
But this does not,
// TLV header
// Start of Type (T) field
0x03, // This message contains an NDEF record
// End of Type (T) field
// Start of Length (L) field
// Length = payload length + length of value field
0xFF, // Always 0xFF for SR:0, indicates length is between 256 and 65535
0x01, // MSB of length field
0xF2, // LSB of length field, adds 6 to account for length of value field when SR:0
// End of Length (L) field
// Start of Value (V) field
// Record head byte, MB:1,ME:1,CF:0,SR:0,IL:0,TNF:101
0xC5, // Short record false SR:0, 4-byte payload length, unknown type
0x00, // Type set to zero, as specified for unknown type
0x00, // MSB of payload length, should be the exact size of the payload (data)
0x00,
0x01,
0xEC, // LSB of payload length
// End of Value (V) field
// End of TLV header
It turns out the issue was caused by a setting in the Compatibility Container. Apple can read both types of NDEF with CoreNFC, if you set the bit for "IC supports ReadMultipleBlocks Command" to false, it works without issue. We had it set to true. Here is an example of a CC that works with CoreNFC.
// Start of Compatibility Container
0xE1, // CC0, "Magic Number", NDEF message is present in memory
0x43, // CC1, Version number 1.0, Read access enabled, Write access normally disabled
0x40, // CC2, Memory size of data field and CC field in bytes divided by 8, 0x40 = 64, 64x8=512 Bytes
0x00, // CC3, IC supports ReadMultipleBlocks Command
// End of Compatibility Container
Reading more from the IC documentation, although it does support ReadMultipleBlocks command, it does so in 128 Byte blocks. This may have been what caused the strange behavior we saw.
I still do not understand why Android handles it without issue, and Apple cannot read it. But changing the setting fixes the issue for CoreNFC.
I need help calculating the checksum (crc-16:X16+X15+X2+1) for BYTE6 and BYTE7 of this data string. I have read some examples but I have no idea how and where to start. What does the X16, X15 etc means? What should I put in BYTE6 and BYTE7?
Byte0: 0x55
Byte1: 0x80
Byte2: 0x06
Byte3: 0x02
Byte4: 0x00
Byte5: 0x00
Byte6: MSB of the checksum word (CRC-16)
Byte7: LSB of the checksum word (CRC-16)
The CRC polynomial (x16+x15+x2+1) is necessary but not sufficient to define the CRC. You can see this list of 16-bit CRCs, in which you can find seven different CRC's that use that particular polynomial (poly=0x8005).
Once you have the full description, you can use my crcany code to generate C code to compute the CRC.
I am very new to this mqtt-sn stuff. So my question is - how does a mqtt-sn message look like. So I mean the raw data format. I do not clearly understand what octet means. So as I understand an octet is a byte.
So is the data transferred binary?
Or what means octet exact?
Please can someone give me a sample message. It is really bad that there is not example message in the specification.
Thanks,
Mathias
An octet is just a collection of 8 bit so just another name for a byte
So a message consists of a header made up of 2 or 4 bytes and the the message body.
The header is sub divided into 1 OR 3 bytes for the length and 1 byte for the type. If the first byte is 0x01 then the next 2 bytes are the length, else the value of the first byte is the length.
The next byte is a type, a table of valid message types can be found in sections 5.2.2 in the spec
The Message body varies depending on the type.
But to publish a message with payload HelloWorld on Topic ID of AB (0x41, 0x42) would look something like this:
0x0F - length (15 bytes total, including length)
0x0C - msg type (publish)
0x02 - flags (QOS 0, topic name)
0x41 - topic ID 1
0x42 - topic ID 2
0x00 - MsgID (00 for QOS 0)
0x48 - H
0x65 - e
0x6C - l
0x6C - l
0x6F - o
0x57 - W
0x6F - o
0x72 - r
0x6C - l
0x64 - d
Where the topic id is the output from a topic register message (Section 6.5 in the spec)
An octet is a byte.
There isn't an example payload because the spec doesn't dictate a payload format. You can use whatever you want.
Hi I am trying to read and write data from the i2c bus on the beagle bone black. But I keep reading 0x00 whenever I try to access the Who Am I register on a MMA84152 (or any other register for that matter), which is a constant register which means its value does not change. I am trying to read i2c-1 character driver located in /dev and I connect the sda and scl of the MMA852 lines to pins 19 and 20 on the p9 header. The sda and scl lines are both pulled high with 10 k resistors. Both pin 19 and pin 20 show 00000073 for their pin mux which means it is set for i2c functionality and slew control is slow, reciever is active, the pin is using a pull up resistor, and pull up is enabled. I ran i2cdetect -r 1 and my device shows up as 0x1d which is its correct address. I also ran i2cdump 1 0x1d and 0x2a shows up under 0x0d which is the register I am trying to read from my device and contains the correct value according to the datasheet. But when I read it it returns 0x00 for me. I am also running the latest angstrom distribution and I am logged in under root so no need for sudo.I'm lost now. Here is the code:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <linux/i2c-dev.h>
#include <linux/i2c.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string>
using namespace std;
int main(int argc, char **argv){
int X_orientation=0;
char buffer1[256];
string i2cDeviceDriver="/dev/i2c-1";
int fileHandler;
if((fileHandler=open(i2cDeviceDriver.c_str(),O_RDWR))<0){
perror("Failed To Open i2c-1 Bus");
exit(1);
}
if(ioctl(fileHandler,I2C_SLAVE,0x1d)<0){
perror("Failed to acquire i2c bus access and talk to slave");
exit(1);
}
char buffer[1]={0x0D};
if(write(fileHandler,buffer,1)!=1){
perror("Failed to write byte to accelerometer");
exit(1);
}
if(read(fileHandler,buffer1,1)!=1){
perror("Failed to read byte from accelerometer");
exit(1);
}
printf("Contents of WHO AM I is 0x%02X\n",buffer1[0]);
}
It is likely that your I2C device does not support using separate write() and read() commands to query registers (or the equivalent i2c_smbus_write_byte() and i2c_smbus_read_byte() commands). The kernel adds a 'stop bit' to separate your messages on the wire, and some devices do not support this mode.
To confirm:
Try using the Linux i2cget command with the -c ('write byte/read byte' mode, uses separate read and write messages with a stop bit between) flag:
$ i2cget -c 1 0x1d 0x0d
Expected result: 0x00 (Incorrect response)
Then try using i2cget with the -b ('read byte data' mode, which combines the read and write messages without a stop bit) flag:
$ i2cget -b 1 0x1d 0x0d
Expected result: 0x2a (Correct response)
To resolve:
Replace your read() and write() commands with a combined i2c_smbus_read_byte_data() command if available on your system:
const char REGISTER_ID = 0x0d;
char result = i2c_smbus_read_byte_data(fileHandler, REGISTER_ID);
Alternatively (if the above is not available), you can use the the ioctl I2C_RDWR option:
const char SLAVE_ID = 0x1d;
const char REGISTER_ID = 0x0d;
struct i2c_rdwr_ioctl_data readByteData;
struct i2c_msg messages[2];
readByteData.nmsgs = 2;
readByteData.msgs = messages;
// Write portion (send the register we wish to read)
char request = REGISTER_ID;
i2c_msg& message = messages[0];
message.addr = SLAVE_ID;
message.flags = 0; // 0 = Write
message.len = 1;
message.buf = &request;
// Read portion (read in the value of the register)
char response;
message = messages[1];
message.addr = SLAVE_ID;
message.flags = I2C_M_RD;
message.len = 1; // Number of bytes to read
message.buf = &response; // Where to place the result
// Submit the combined read+write message
ioctl(fileHandler, I2C_RDWR, &readByteData);
// Output the result
printf("Contents of register 0x%02x is 0x%02x\n", REGISTER_ID, response);
More information:
https://www.kernel.org/doc/Documentation/i2c/smbus-protocol
https://www.kernel.org/doc/Documentation/i2c/dev-interface
This expression is taken from an inbuilt function "l_setDataByte" in Leptonica(an Image-Processing library).
Here is the link: http://tpgit.github.io/Leptonica/arrayaccess_8c_source.html (Line-260 here)
*(l_uint8 *)((l_uintptr_t)((l_uint8 *)line + n) ^ 3) = val;
My guess:
line is a pointer to unsigned 8bits (byte) (l_uint8 *)line
one manipulates the n-th byte in the line: (l_uint8 *)line + n --> y (y is a pointer)
however one also XORs the last 2 bits of the address after casting as an unsinged integer pointer: (l_uintptr_t)y ^ 3 --> z (z is a pointer)
lastly one casts back to a unsigned byte points and writes the value val there: *(l_uint8 *)z = val
Edit:
The ^3 is to address the arrangement of the bytes (i.e. little vs big endian). The number 0x12345678 can be put in consecutive bytes in two ways: 0x12, 0x34, 0x56, 0x78 (this is big endian) or 0x78, 0x56, 0x34, 0x12 (little endian). The XOR will switch from big endian addressing (see line 274) to little endian (line 276). This is processor dependent and the source is compiled one way or the other.