I am writing my own CANOpen stack, and I want to implement the SDO server using C.
The CiA CANOpen Application Layer Document specified that the SDO Request and Confirm Frames look as follows:
And some explanation provided as follows:
Based on my decoding of this picture, I gather that I am supposed to send 8 bytes in a SDO confirmation frame, but the 7 bytes will contain simply 0.
Is this correct?
PS: Sorry for the images if they are not clear.
Almost correct. An SDO CAN frame always contains 8 bytes, where the unused bytes are 0.
The confirmation frame, however, has 4 non-zero bytes. The first byte is the command specifier (0x60 in this case). The next three are the "multiplexer": two bytes for the object index (little-endian) and one byte for the sub-index.
Related
By MODBUS Application Protocol Specification, when write multiple registers, we need to specify both quantify of registers and byte count.
But this document also say that "Data is packed as two bytes per register". So, we only need one of them is enough? Either quantity of registers or byte count.
In my opinion, data is not always is packed as two bytes per register. It can be three or four bytes. Is that correct? So that, we need both, is it?
Modbus registers are always 2 bytes. For preset multiple registers command, byte count field is redundant. But it seems byte count field has other uses in other commands and it's not always (register count * 2). For example, see the response of the read coil status command (0x01). This response can contain odd number of bytes.
To my understanding, FIFO (in hardware-context) is a buffer which will be managed according to first-in-first-out principle. You put sequentially some bits into it and then you can read them i.e. blockwise when the desired threshold is reached. But I'm confused of the FIFO management of serial audio interface of STM32:
According to datasheet, serial audio interface (SAI) supports FIFO up to 8 words. (8x32bits) The data register (SAI_xDR) of SAI is 1 word (32bits). The documentation explains
A write to this register loads the FIFO provided the FIFO is not full.
A read from this register empties the FIFO if the FIFO is not empty.
How to interpret it?
My guess is: If I make a writing access to this register, it loads the register content(32bits block) into the FIFO as the first word, then at the second writing access, it loads the second word into the FIFO and so on. Then when I make a reading access, it returns the first word on the queue, then the second and so on. Is this right?
If so, what happens, when I write less than 32bits into the register? I.e. I write a 16 bits block. Then I write a 16bits again. Do the both bit blocks share a word or are they transfered to seperate words? If I read a word, would I get both 16bit blocks or only the first 16bit? I'm not understanding how FIFO knows the size of my bit sequence which I fill into the data register. Or does it always take the whole 32bits at each write access?
My guess is: If I make a writing access to this register, … Is this right?
Yes, you are right.
As far as I understand, each FIFO word contains data for/from one SAI slot independently of data size. FIFO connected with 32-bit shift register while shift count depend on data size.
It seems that one can use, for example, 16-bit data access to lower half of SAI_xDR for 8 < data_size <= 16 but anyway a whole 32-bit FIFO word will be used for the transfer and only data_size bits from each word will be shifted in/out.
36.3.9 Serial audio interface (SAI) Internal FIFOs
...
Each FIFO is an 8-word FIFO. Each read or write operation from/to the FIFO targets one word FIFO location whatever the access size. Each FIFO word contains one audio slot. FIFO pointers are incremented by one word after each access to the SAI_xDR register.
Data should be right aligned when it is written in the SAI_xDR.
Data received will be right aligned in the SAI_xDR.
Assume I have defined my own application layer protocol on top of TCP for Instant Messaging. I have used a packet structure for the messages. As I am using symmetric (AES) and asymmetric (RSA) encryption, I obtain a different
packet size for different message types. Now to my questions.
How to read from a socket that I receive a single application layer packet?
What size should I specify?
Thanks in advance.
I have two approaches in mind.
Read from the TCP stream a fixed amount of bytes that represents the
actual packet size, and finally re-read from the stream the former gathered size of bytes.
Read the maximal packet size from the stream. Verify the actual size of
obtained bytes and decide so which message type it was.
Now, a more general question. Should I provide metadata like the packet size, encryption method, receiver, sender, etc.? If yes, should I encrypt these meta data as well?
Remember that with TCP, when reading from the network, there is no guarantee about the number of bytes received at that point in time. That is, a client might send a full packet in its write(), but that does not mean that your read() will receive the same number of bytes. Thus your code will always need to read some number of bytes from the network, then verify (based on the accumulated data) that you have received the necessary number of bytes, and then you can verify the packet (type, contents, etc) from there.
Some applications use state machine encoders/decoders and fixed size buffers for reading/writing their network data; other applications dynamically allocate buffers large enough for the "full packet", then continue reading bytes from the network until the "full packet" buffer is full. Which approach you take depends on your application. Thus the size you use for reading is not as important as how your code ensures that it has received a full packet.
As for whether you should encrypt additional metadata, that depends very much on your threat model (i.e. what threats your protocol wants to guard against, what assurances your protocol needs to provide to its clients/users). There's no easy way to answer that question without more context/details.
Hope this helps!
So I'm reading trying to find more about sockets and I found that the documentation kind of repeats itself without going in any further detail in regards to the way sockets send data:
So what does the {packet, N} do when specifying this in the options (when opening a socket) ? Does it include a header of N bytes before the data or does it break the message into N packets? Or does it include a header of N to all the packets that the message ends up being broken into?
I was reading Joe Armstrong's Software for a concurrent world and I found this paragraph:
The word packet refers to the length of an application request or response message, not to the physical packet seen on the wire.
I can't get my head round the meaning of this. What is meant by the packet seen on the wire.
I tried to look into the documentation and I found little referring to what the option does. The brief explanation that I found is that it prepends the message with a N header however I also found this comment in a code written as an example:
%% Usually, it's a good idea to give up in case of a
%% send timeout, as you never know how much actually
%% reached the server, maybe only a packet header?!
According to this, then, the message gets broken into pieces (a random number I presume?) and each gets sent with a N byte header.
My question is how does the {header, N} option affect the way data is sent.
The excerpt from Joe's book you quote refers to the fact that applications are typically blissfully unaware of how networks arrange data for transmission. Depending on the network type, configuration, and protocols in use, the blocks of data sent over it will vary in size and will be framed with different metadata. Applications typically don't see raw packets, framing information, or the fact that sometimes raw packets are retransmitted due to problems that cause them to be dropped or corrupted.
Your question mentions two options: {packet, N} and {header, N}. These are quite different from each other.
The {packet, N} option allows N to be 1, 2, or 4. It attaches a header of N bytes to the front the message. The header specifies, in network order, the length of the message, i.e. the number of bytes in the message.
If you send a message consisting of X bytes, Erlang will prepend to the data N bytes containing the network order value of X, and send the whole thing. Assuming the receiver has also been configured with the same {packet, N} option, it will read the N-byte header to determine how many bytes to expect, wait to receive that many bytes, and then deliver those bytes, without the length header, to the receiving application. How the underlying networking software and hardware breaks the data into chunks for transmission across the network is a separate matter hidden from your application.
The {header, Size} option delivers the message to the receiver as a list of Size bytes followed by the remainder of the data as a binary. This option makes sense only when the binary option is in effect for the socket.
I used a ts analyzer for a .ts file i have with mpeg-2 codec and i found out that it splits in 7311 packets.
I m trying to find this through matlab by using fopen to open the ts file in binary and fread to read the file but all i get is a column with a huge collection of numbers(way above the number of packets). Does anyone know how can i determine which of these data are the packets? Or if someone knows another way to find the packets would help me a lot.
Thank you in advance
From some quick googling, the MPEG-2 transport stream ('ts') format consists of packets 188-bytes in length, each having a 4-byte header followed by a 184-byte payload. Essentially, you can count the number of packets by counting the number of headers you find - but beware that, if you are only interested in counting the number of, e.g., video packets in the stream, then you will need some deeper analysis of the headers, because the stream may contain any number of interleaved "elementary streams" (which can be video, audio, or arbitrary data). Each elementary packet type in the stream is denoted by a unique "PID" which is contained in the header.
Aside from the above, you will also have to handle synchronisation - each header begins with the "synchronisation byte", which has a value 0x47 (or 01000111 in binary). According to this resource, decoders begin by looking for this synchronisation byte; once they find one, they may have found a packet header. To make sure, they try to find three consecutive synchronisation bytes (188 bytes apart in the stream); if three are found, synchronisation can occur and the packet boundaries may from then on be assumed at 188-byte intervals. Note, however, that the first byte of each assumed header should be checked to see if it is a synchronisation byte - if it is not, then this is called "sync loss" and the syncrhonisation process must start again.
Once you have some code to syncrhonise to a stream, it should be fairly easy to extract the PIDs from the header of each packet and count the number of packets associated with each unique PID you find. You should probably also check the first bit after the synchronisation byte as, if set to 1, this indicates a transport error, and the packet's payload is invalid. Detailed information on the format of packet headers can be found here.