I need to send hexadecimal values to a device through UDP/IP protocol, before i need to send i have to do XOR of the first two bytes with the two bytes of the "message sequence number" problem is that
when and where do i find MSB and LSB of the message sequence number
how do i perform XOR for the first two bytes, if i do so then how to append back to the original?
here is my array const char connectByteArray[] = {0x21,0x01,0x01,0x00,0xC0,0x50};
The below point will help to answer you better i think so
"XOR the first byte of the encryption block with the MSB of the message sequence number, and XOR the second byte of the encryption block with the LSB of the message sequence number"
//Bitwise XOR operator is ^ .
byte msb = (byte) (connectByteArray[0])<<8 //LSB
byte lsb = (byte) (connectByteArray[0]) >> 8 //MSB
Related
I am new to C and programming in general. I am transmitting an ADC value through UART but it is encoded as an ASCII value in the CCS terminal. I want to convert it to a Decimal value in the terminal for easy debugging. When I try to use snprintf or sprintf I get the warning:
"a value of type char* cannot be assigned to an entity of type "unsigned int""
Does this have to do with the way the MSP430 UART Buffer works or more likely is my usage wrong and how?
How large does the buffer need to be for a 16 bit value?
I am receiving a constant value in the terminal not in the ASCII range despite the value in the ADCMEM0 changing as expected.
I am attempting to get my ADC values in a decimal value in the terminal. I am only able to get the correct ASCII values.
Code:
int i;
while(1){
ADCCTL0 |= ADCENC | ADCSC; // Enable and Start Conv
while((ADCIFG & ADCIFG0) == 0);
for(i=0; i<32000; i=i+1 ){
char buffer[20];
int Sensor = ADCMEM0;
snprintf(buffer, 10, "%d", Sensor);
UCA1TXBUF = buffer; //transmit ADC_Value over UART A1 Tx
}
}
I m trying to write the code for on switch board touch sensor which communication with mcu(esp32) using the uart protocol. There we have frame of packet which we have to write to uart to get the reading. Let me share some documentation,
1.
In API frame structure following is the fixed definition of any command frame
Every first byte of frame is fixed 0x7B (“{” in ASCII, 123 in decimal).
Every second byte of frame is ‘command type’ byte, it informs what you need to do with rest of the data. This will act as a frame Identifier in the data received from touch panel (response frame and event frame)
Third byte is length of frame. It is 1-byte value (L - 4) where L is total numbers of bytes of whole frame.
Second Last byte is checksum. Checksum is a lower byte of addition of whole individual bytes of frame except First byte (Start byte), Second byte (Command type byte),
Second Last byte (Checksum byte itself) and Last byte is 0x7D.
Last byte is 0x7D, it is End code to indicate the end of frame. (“}” in ASCII, 125 in decimal).
For Example, consider following frame.
Table 1.1 Frame example 1.
1st Byte 2nd Byte 3rd Byte 4th Byte 5th Byte 6th Byte
0x7B 0x03 0x02 0x05 0x07 0x7D
Start Code Command Length Data Checksum End Code
So the checksum will be lower byte of addition of third byte and fourth byte.
0x02 + 0x05 = 0x07 so we will consider 0x07 as checksum here.
Example 2, consider following frame.
Table 1.2 Frame example 2.
1st Byte 2nd Byte 3rd Byte 4th Byte 5th Byte 6th Byte 7th Byte 8th Byte
0x7B 0x52 0x04 0x02 0xFF 0x14 0x19 0x7D
Start Code Frame Length Data Data Data Checksum End Code
Identifier
In this example 2 the checksum will be lower byte of addition of third to sixth byte.
0x04 + 0x02 + 0xFF + 0x14 = 0x0119 so we will consider 0x19 as checksum here.
2.
Blink LED (All slider LED) control.
1.Command
This package is used to control blinking of LED. Hardware Version 2.0 has dedicated status LED. Which will be used to indicate status of product as on need.
Table 1.6 Blink LED command package detail.
Status 1st Byte 2nd Byte 3rd Byte 4th Byte 5th Byte 6th Byte 8th Byte
Start 0x7B 0x05 0x03 0x01 (Start) (0x01 to 0xNN*) Checksum 0x7D
Stop 0x7B 0x05 0x03 0x00 (Stop) 0x00 Checksum 0x7D
Start Code Command Length Pulse with (x100ms) Checksum End Code
To start status LED blinking, the start command frame is sent with required value of 4th byte as 0x01. For Example, to make status LED blinking as time duration 200ms, the value of 5th byte is 0x02.
And to stop status LED blinking the stop frame is sent
2.Response
Table 1.7 Blink LED response detail.
1st Byte 2nd Byte 3rd Byte 4th Byte 5th Byte
0x7B 0x55 0x01 0x01 0x7D
n 1 point, we can able to see how uart frame should be. In 2 point, I want to read and write the frame command to stop and start blinkin the led.
My question is
how should I send multiple bytes over uart?
Does I need to send make a frame of packets? If Yes then How should I do
that?
Also, how should I read the response of it?
I did research on how frame the packet and send frame over uart but not found any useful blogs and answer.
More Info:
Language: C
Compiler: GCC
MCU: ESP32
Hope I m able to explain it.
Thanks in advance for the help!!
Sending multiple bytes
Sending multiple bytes is straight-forward with the ESP-IDF framework. Let's assume your command frame is in an array called frame and the length (in bytes) of the frame is stored in frame_length:
uint8_t frame[] = { 0x7B, 0x03, 0x02, 0x05, 0x07, 0x7D };
int frame_length = 6;
uart_write_bytes(uart_port, frame, frame_length);
The bigger challenge is probably how to construct the frame in the first place, in particular how to calculate the checksum.
Sending multiple frames
Sending multiple frames is straight-forward as well. Just call the above function multiple times. The protocol has been carefully designed such that the receiver is able to split the stream of bytes into frames.
You should prevent however that multiple tasks sends frames concurrently. That way the communication could get mixed up.
Receiving frames
Receiving isn't a problem either. Just read frame by frame. It's a two step process:
Read 3 bytes. The third byte provides the length of the frame.
Read the remaining bytes.
It could look like so:
#define MAX_FRAME_LENGTH 80
uint8_t frame[MAX_FRAME_LENGTH];
int frame_length = 0;
int read_frame(uint8_t* frame) {
uart_read_bytes(uart_port, frame, 3, portMAX_DELAY);
uart_read_bytes(uart_port, frame + 3, frame[2] + 4, portMAX_DELAY);
return frame[2] + 4;
}
I have a string of characters and want to generate a simple checksum by accumulating XOR on each character, then adding the lowest-order byte result of that to the end of the string as formatted by sprintf(twoCharacterBuffer, "%02X", valueHoldingXOR);.
If I just XOR the characters in the string, putting them into an unsigned char value, the compiler warns me that "'sprintf' output between 3 and 9 bytes into a destination of size 2"
The Arduino documentation is a little vague, possibly on purpose, about the number of bytes in a character. I'd like to just XOR the lowest-order byte, whether it's 1 or 2 or 4 bytes, but am not sure of the correct way to do that. Or can I assume that a char is a byte and just cast it?
I'm looking at some existing code that is generating a salt which is used as input into an authentication hash.
The salt is 16 bytes long, and is generated by first using an OS random number generator to get 8 bytes of random data.
Then each byte in the 8 byte buffer is used to place data into 2 bytes of the 16 byte buffer as follows:
out[j] = hexTable[data[i] & 0xF];
out[j-1] = hexTable[data[i] >> 4 & 0xF];
Where out is the 16 byte salt, data is the initial 8 byte buffer, j and i are just loop incrementers obviously, and hexTable is just an array of the hex digits i.e. 0 to F.
Why is all this being done? Why isn't the 16 byte salt just populated with random data to begin with? Why go through this elaborate process?
Is what is being done here a standard way of generating salts? What's the benefit and point of this over just generating 16 random bytes in the first place?
This is simply conversion of your 8 random bytes to 16 hexadecimal digits.
It seems that someone misunderstood the concept of salt, or what input your hash needs, and thought it only accepts hexadecimal digits.
Maybe also the salt is stored somewhere where it is easier to store hexadecimal digits instead of pure bytes, and the programmer thought it would be good to be able to reuse the stored salt as-is (i.e. without converting it back to bytes first).
Why do messages going through websockets always start with \x00 and end with \xff, as in \x00Your message\xff?
This documentation might help...
Excerpt from section 1.2:-
Data is sent in the form of UTF-8 text. Each frame of data starts
with a 0x00 byte and ends with a 0xFF byte, with the UTF-8 text in
between.
The WebSocket protocol uses this framing so that specifications that
use the WebSocket protocol can expose such connections using an
event-based mechanism instead of requiring users of those
specifications to implement buffering and piecing together of
messages manually.
To close the connection cleanly, a frame consisting of just a 0xFF
byte followed by a 0x00 byte is sent from one peer to ask that the
other peer close the connection.
The protocol is designed to support other frame types in future.
Instead of the 0x00 and 0xFF bytes, other bytes might in future be
defined. Frames denoted by bytes that do not have the high bit set
(0x00 to 0x7F) are treated as a stream of bytes terminated by 0xFF.
Frames denoted by bytes that have the high bit set (0x80 to 0xFF)
have a leading length indicator, which is encoded as a series of
7-bit bytes stored in octets with the 8th bit being set for all but
the last byte. The remainder of the frame is then as much data as
was specified. (The closing handshake contains no data and therefore
has a length byte of 0x00.)
The working spec has changed and no longer uses 0x00 and 0xFF as start and end bytes
http://tools.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-04.html
I am not 100% sure about this but my guess would be to signify the start and end of the message. Since x00 is a single byte representation of 0 and xFF is a single byte representation of 255