I2C bus structure

Classic version of the data exchange between any devices is that one apparatus transmits the information and the other accepts it. The devices can , if necessary, switch roles, i. e. the transmitter and receiver can be or conversely the receiver can become a transmitter. But in any case it is important to clarify and determine which device is the master and set the rules of communication sequence and what device is the salve. Devices connected to the I2C bus follow this principle also. That one of the devices will be leading (master), and the rest  – slave. Such bus structure is called master-organization and is the most typical.
Master device is usually assigned by micro-controller. It sets the underlying stream of data on the bus, generates the necessary time slots etc.
Much less frequently is used multi-master, when multiple master devices are connected to a single bus. The complexity of the organization of such connection consists mainly in that the master devices must decide which of them will currently work with a slave devices. Simultaneously, only one master device can transact data and the rest should be disabled. Otherwise, there may be a situation, which is called a bus conflict. Information may simply not reach the destination and the device operation will be violated.
In order to avoid bus conflicts in multi-master mode there are should be contain procedures for arbitration and synchronization established for controlling the operation order of master devices.

I2C sniffer

I2c sniffer can be implemented entirely in software , but it is much more convenient to USI . Mainly because USI has built- Start condition detector, and even with a separate interrupt.
That’s the only problem is that the self – USI in itself a useless piece of the state machine , and the logic necessary to implement the software . On the one hand, it is not convenient, and on the other – it is possible to stir , for example, sniffer , which is the usual TWI can be done.

By the logic of the protocol i2c communication , the transmission byte goes in two directions. If we pass the bytes, the need to transfer 8 bits of “there” , and read one bit “out there .” If we read that on the contrary .
In the case of same – sniffer , there is no “there” and “there” . There is only one direction – ” past .” It is somewhat easier task. We need only to listen to the line and put the data into the buffer. From this buffer, they are transferred to the computer .

All dvizhuha line is divided into four types:
0x1 – Start detekted
0x2 – Stop detekted
0x4 – + ACK Byte
0xC – Byte + NACK

For each event entry is 4 bytes . First (Senior ) bytes – this is the event code (those most – 0x1, 0x2 …). In the second data . For the first two events data is not needed, then the second byte = 0. The last two bytes – the value of the timer. It starts as soon as the first to be caught start-condition, and is reset by a command from the computer. Period of one ” tick ” timer – 1ms . It can be considered a little more than a minute , more than enough to capture any repeats and other unknown things that are happening on the line sometimes .

If we decided to catch the Start condition in software, then , would have had to start on the leg of SDA interrupt , and there is already starting to define it , or just switched SDA . And with USI such problem is simple: include interruption of USI START and wait …

Here is the interrupt handler :
procedure USI_Start; org 0xF;
begin
 asm / / Clear the flag and counter = 15.
 in r16, USISR
 andi r16,% 11110000
 ori r16,% 10001111
 out USISR, r16
 end;
 USI_recv_state: = 2 ;

 / / Timer is started up
 if TCCR0B = 0 then
  begin
   Timer: = 0 ;
   TCNT0: = 0 ;
   PSR10_bit: = 1 ;
   
   TCCR0B: = 4 / / prescaler 256
  end;
  
 / / Pushes the data to the clipboard
 push_to_buffer (f_start, 0);
end;

The first thing we reset the flag USISIF. This must be done as quickly as possible , for as long as the flag is raised , USI will clamp the line SCL. We then pushed into counter USICNT 0x0F, and write to a variable USI_recv_state 2 . This is a preparation for the reception of data ( I know, now looks like black magic , but then it becomes more clear ) . Check if the timer is not running , then reset it and run.

To Identify the stop-condition we have provided almost the same as that for a start. Only interrupts greedy . Therefore it was necessary to add to the cycle of the program checks the flag USIPF.

   if USIPF_bit = 1 then
    begin
     USIPF_bit: = 1 ;
     push_to_buffer (f_stop, 0);
    end;

Here, I think , do not have anything new . Reset flag (for this you need to burn it edinichku ) and stuffed into a message buffer that caught the stop .

The most interesting – catch data . As many as 9 bits . USI we have configured :
USICS1 = 1 ; USICS0 = 0 ; USICLK = 0 – this means that for every positive edge on the SCL, the data register USIDR will shift , and it will be recorded with a bit line SDA. A counter USICNT is ticking on each edge of SCL.

Sniffer / emulator I2C and 1-wire

This is the first version of the device , and it is not without drawbacks. Including sometimes the device freezes for no apparent reason . To be honest I was lazy to catch this bug . Not often freezes and Restarting .

Often , when debugging devices , it is necessary to validate the data exchange between modules. In the simplest cases , in order to find a bug , is quite simple to determine whether or not there is an exchange . On the multimeter , and it’ll do .

But more often than is necessary to understand at what stage of the exchange failed. Whether the transfer fell through , even at the stage of preparation of the data , or maybe prevented the exchange of another device hanging on the line. The situation becomes especially complicated when data exchange is implemented for the most part in software. Here multimeter will not help.

And so , in order to simplify / speed up the process of debugging , I decided to make i2c sniffer . Initially, the problem was this: listen I2C line and send the log to your computer. When this was done , it became clear that there is still Tiny2313 free full flush. Therefore, additional functionality was coined .
That’s what eventually happened :

His appearance is not the most glamorous , nor is it was not necessary.

– Communication with PC via UART. Now connected to the COM port that is not very convenient (you have to separate hem power) . In the second version will make the USB connection on the basis of FT232.

– In i2c sniffer works confidently in the exchange rate ( the frequency of SCL) up to 50 kHz . In this mode, it records all activity on the line in the log that is in the background is thrown out on the PC . Together with each entry written to the log time .

The first thing I ‘ll tell you about what ‘s inside i2c sniffer , for this is the functionality for which the device was intended . Sniffer I’ll describe a little more than the rest of the functions . It is implemented on the basis of USI, and is another example of this pribludy (otherwise USI will not name) .

Then I will discuss the master mode . i2c master is also implemented on the USI. 1 -wire software completely , and nothing particularly interesting in itself is not .

But first , the total excursion :
For power converter is responsible for 78L05. Or , as I said , you can pull up to 5V device debugging . In general , it is certainly inconvenient. The next version will be USB. On power diodes are so difficult to burn the device .

In touch with us max232. My layout may seem too small (so16 and 0805 Conder almost vlotnuyu to it) , but in another way it does not fit there .

20MHz quartz . One would take less, such as 16. High speed is needed for fast operation state machine i2c sniffer . The case of quartz I grounded, so to the ” safe side “.

ATTiny2313 reigns . First, it’s one of the few owners of USI. Second, it can be dispersed up to 20MHz . Connector for software that I gave , so you have to fluster posting.

On the lines SDA and SCL ( it PB5 and PB7, respectively ) is the pull-up resistors on the 4.7k . They are connected to pin PB6, which , on command from a computer connected to the power supply , providing an internal lift .

There is still room for four LEDs, which , as a result of any use .