When we want to transfer a single byte we send it as described in this screenshot.
When we transfer data in multiburst mode, we send address (of starting register) right after the acknowledge from slave instead of data. Then we send data and register address is automatically increment as shown in this book.
My question is that:
How Slave recognize that the byte, right after the first acknowledge, is address or data?
Hint: I used Google a lot but I couldn’t find an answer that would have satisfied me.
The slave can recognize the fact that the address spans over two bytes by checking the first address byte for a special bit pattern. A slave address beginning with the bit pattern of 1111 0 indicates a 10 bit address (as opposed to the regular 7 bit addresses) which spans over two bytes on the bus as defined in the I2C Bus Specification:
3.1.11 10-bit addressing
[...]
The 10-bit slave address is formed from the first two bytes following a START condition
(S) or a repeated START condition (Sr).
The first seven bits of the first byte are the combination 1111 0XX of which the last two bits
(XX) are the two Most-Significant Bits (MSB) of the 10-bit address; the eighth bit of the
first byte is the R/W bit that determines the direction of the message.
If the first address byte does not match the special bit pattern, the second byte would have to be treated as data.
So, in your example
| START | slave address | R/W | ACK | slave address | ACK | data | ...
| S | 1111 000 | 0 | A | 0000 1111 | A | 0000 0001 | ...
the master is reading multiple data bytes from a slave identified by the 10 bit address 00 0000 1111.
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.
First off, please forgive my complete lack of knowledge in this field. I got some time ago a couple of really cheap wifi ip cameras that I was hoping to use on my local network. Unfortunately, it turned out the manufacturer (zmodo) had introduced about a year ago their own streaming protocol and had done away with the rtsp port present in previous models. The manufacturer supplied apps are only cloud based, which doesn't put me at ease. Luckily, people have been trying to come up with solutions to this and have been fairly successful with older models. So I tried to see what I can do myself.
In essence, the camera listens on port 8000 for 12 byte long commands. One of these commands triggers a stream of data. The data looks a little bit like a sequence of AVI chunks that start with either 00dc or 01dc. Just like in AVI, these tags are followed by a four-byte size (let's call it S) and 24 bytes that look like a time stamp (but could also contain more info). The total number of bytes between 00dc or 01dc tags is exactly 32 bytes more than S. So, we have something like this
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... S bytes of data that seems encrypted...
30 31 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 00 00 00 01 61 .... S - 5 bytes of data...
The second type of chunk, prefixed by 01dc seems to contain unencrypted B- or P-frame NAL units (if my basic understanding is correct), but my question is about the first type. The first type probably contains I-frames but I cannot find a NAL delimeter or type byte. Additionally, the first 32 bytes of the S bytes of actual data are the same for every unit, i.e. I have
30 30 64 63 S[0] S[1] S[2] S[3] ....24 bytes for a time stamp? ... 32 constant bytes ... S-32 bytes of data
The camera also provides a 128 bit key which I naturally assumed to be for stream encryption (although it could be for cloud authentication or TLS or who knows what). So my question is, in your experience, which (encrypted) version of h.264 is this closest to? Any idea what the 32 constant bytes are?
EDIT: I am not sure that the keyframes are encrypted, I am only speculating. Actually, they seem to contain large areas of constant bytes at the end (although the bytes change from one unit to the next, i.e. e4 e4 .... e4 in one, then 93 93 .... 93, which rules out AES I think)
Initially, I used a eBus SDK which supports 8 bits registers for the I2C. This SDK does not support 16 bits register address for I2C. Is there any alternative to this sdk that support 16 bit register address for the I2C?
Best wishes and thank you in advance
There are a few concepts to clear up based on the other comments. All I2C devices ONLY support 7-bit (8 with the read/write) and 10-bit Slave Addressing. This, however, was not the concept asked about in the topic.
I2C, per the protocol specifications, reads/writes in sets of 8-bits followed by an Acknowledgement (ACK/NACK) from the device receiving the data. How the device interprets the bits read/written to it can vary greatly from device to device.
From my personal experience, I have found that often a larger register address -- such as 0x1234 -- simply means that you need to read/write from registers 0x12 and 0x34. Both registers will hold 8-bits of information which together form the actual 16-bit word referenced by the hexadecimal 0x1234.
As I mentioned though, this can vary per device. You will likely need to read through the Data Sheets/Manuals for your specific I2C device for more information on its register addressing to ensure you read/write from the right registers and assemble the individual 8-bits into the correct order to extract the corresponding 16-bit word.
As MrHappyAsthma perfectly pointed out the I2C is organized in 8-bit transfers.You must study documentation of your device. Search for something like setting internal 16-bit address with writing two bytes, and later do the read (as you mentioned one or two bytes). It would look something like this:
// register read scenario (first 0x12 will be your 8-bit API address, and you attach the 0x34 to the data part of your API)
DO WRITE: |S| slave address |W| write 0x12 | write 0x34 |S| (be careful with ordering)
DO READ: |S| slave address |R| read 1'st byte | read 2'st byte |S| (if 16-bit data)
// register write scenario (first 0x12 will be your 8-bit API address, and send 3-bytes of data, where first byte is your LSB address)
DO WRITE: |S| slave address |W| write 0x12 | write 0x34 | write data 1'st byte | write data 2'st byte |S| (if 16-bit data)
Check documentation for you slave device. If you are able to use your API to force such transfers you can trick the device to give you what you need.
It seems to be impossible for some to understand what difference is between I2C external address, internal address and data.
The original question is simply "How to read/write to a I2C register, whose INTERNAL ADDRESS is 16bit ?"
smbus handles only 8 bit internal addresses. So it is impossible to read/write but first 256 bytes of a I2C EEPROM.
There is a lot of talk about at24, but so far I have not found anything describing how to use it or even install.
Nine years gone after the original question and still there has been no way to address 16bit REGISTER addresses. Everybody understand allready the difference between device and register addresses. Please stop repeating the comments about '7bit address and one R/W bit', when somebody asks about 16bit addressing.
This should be handled by the Linux kernel specialists, because there is so much large I2C memories. For example I myself am fighting with a bed of FeRAM chips.
The next thing is to move the bed to general IO-pins of RasPi and write the whole program from scratch.
This paragraph if from UNP,
chapter 21.3 page 555
A host running an application that has joined some multicast group whose
corresponding Ethernet address just happens to be one that the interface
receives when it is programmed to receive 01:00:5e:00:01:01 (e.e., the
interface card performs imperfect filtering). This frame will be discarded
either by datalink layer or by the IP layer.
I just don't know which special case is the author talking about. Could you help me explain it clearly?
IN IPV4. A multicast Address (old class D) consists of 4 bits fixed for identifying it as multicast(1110), and the remaining 28 bits to Identify the group.
Since there are only 23 Bits available in a MAC Address (the high order 25 bits are fixed), when you map the lower order 23 bits of the multicast address into the lower order 23 bits of the mac you lose 5 bits of addressing information. So multiple Multicast addresses all have the same MAC address.
for example
237.138.0.1
238.138.0.1
239.138.0.1
all map to MAC address: 01:00:5e:0a:00:01 (There are more, this is just a subset to illustrate)
so if you join group 237.138.0.1, your ethernet card will start sending frames up the stack for that MAC. Since it is an imperfect match (since we discarded those 5 bits), the ethernet card will also send 238.138.0.1 and 239.138.0.1 up the stack as well. But since you are not interested in those frames they will be discard at Layer 2 (data link) or Layer 3 (Network) when they can be matched exactly.
So the special case is that if you have multiple multicast streams that occupy the same lower 23 bits of address space, all hosts on the network segment are going to have to process the packets higher up in the stack and thus do more work to tell if the packet they got is one they are interested in).
normally you just need to make sure when planning your multicast deployments, that you try to avoid overlapping addresses.
Hello i have made a program for my old windows mobile phone to send gps data ,temperature etc every 5 seconds just for experimental reasons to create a fleet management system.
I noticed that within one hour 350kb were consumed although i sent only 20kb of data...
As i dont have deep knowledge in networks ,how much does a tcp connection cost in bytes?
Maybe i should keep the socket alive because i close and open it every 5 seconds.Would that save bytes?
Also does MTU matter here?
Any other idea to reduce the overhead?
thank you
Let's do some math here.
Every 5 seconds is 720 connections per hour plus data. 20K / 720 is about 28 bytes of payload (your GPS data) for each connection.
IP and TCP headers along are 48 bytes in addition to whatever data is being sent.
3-way handshake connection: 3 packets (2 out, 1 in) == 96 bytes out and 48 bytes in
Outbound Data-packet: 48+28 bytes == 76 bytes (out)
Inbound Ack: 48 bytes (in)
Close: 48 bytes (out)
Final Ack: 48 bytes (in)
Total out per connection: 220
Total in per connection: 144
Total data send/received per connection: 220+144 = 364
Total data usage in one hour = 364 * 720 = 262K
So I'm in the ballpark of your data usage estimates.
If you're looking to reduce bandwidth usage, here's three ideas:
Scale back on your update rate.
Don't tear down the socket connection each time. Just keep it open.
Given your GPS coordinates are periodically updated, you could consider using UDP instead of TCP. There's potential for packet loss, but given you're retransmitting fresher data every 5 seconds anyway, an update getting lost isn't worth the bandwidth to retransmit. IP and UDP headers combined are only 28 bytes with no "connection" overhead.
UPDATE
When I originally posted this, I erroneously misunderstood the connection close to be a single exchange of FIN packets between client and server. In practice, the client sends a FIN as part of it initiating the CLOSE. Then server ACKs the FIN. Then the server sends its own FIN that is ACK'd by the client. In other words, an additional 96 bytes per connection. Redoing our math:
Total data send/received per connection =
220+48 + 144+48 = 460
Total data usage in one hour = 460 * 720 = 331K
So my revised estimate of 331KB in one hour is a bit closer to what the OP saw.