View source for PIC code explanation

The PIC(PIC16F1718) is the AXIOM beta device, which allow to communicate with Micro-zed and the MachXO2 at the moment. To understand this communication, it is needed to know how the PIC code is working. The PIC code can be found at [http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.c].
 
The PIC device which we use is PIC16F1718. So, first we will check the main key functions of the PIC code.
 
In the PIC code ([http://vserver.13thfloor.at/Stuff/AXIOM/BETA/ICSP/i2c_slave.c]), at the line 25 to 38 are shown bellow.  

     '''#define SCL_TRIS	TRISBbits.TRISB6'''
     '''#define SCL_RPPS	RB6PPS'''
     '''#define SCL_PPS		0b10000'''
     '''#define SCL_PPSP	0b01110'''
 
     '''#define SDA_TRIS	TRISBbits.TRISB7'''
     '''#define SDA_RPPS	RB7PPS'''
     '''#define SDA_PPS		0b10001'''
     '''#define SDA_PPSP	0b01111'''
 
     '''#define TMS_PORT	PORTCbits.RC3'''
     '''#define TDI_PORT	PORTCbits.RC1'''
     '''#define TDO_PORT	PORTCbits.RC0'''
     '''#define TCK_PORT	PORTCbits.RC2'''

In this #defines, it defines the PIC pins. After this there are some variables which uses on later functions.
 
In line 363, it starts the void main() function. It is the main functions which runs on the PIC device. In main() function, the PIC device set some configurations from line 365 to line 411 and go into a dummy while loop. Therefore, the PIC will be rest on a infinite while loop until the PIC is interrupted. So, when the PIC is interrupted, In line 139, there is an interrupt handler. It handles for the processing interrupts on the PIC. This is the main part of the code, which do the almost every part of the communicating. So, that's why interrupt handler does almost everything on this code. In future, this will be improved. But it requires a redesign and the current drawn currently is not critical.
 
In the line 396 and 397 select the addresses where the PIC shows up on the I2C bus.

    '''SSPADD = 0b10000000;'''
    '''SSPMSK = 0b10100000;'''

Each bit with a 0 in the '''SSPMSK''' is ignored, while each bit with a one is checked against the '''SSPADD''' bits. In this case, we got match on 0x40 - 0x4F and 0x60 - 0x6F. Normally, the least significant bit in an I2C transaction decides about read or write. ‘1’ mean read and ‘0’ mean write.
 
For example, take an I2C address as 0x38. That means, it have two bit values 0x70 and 0x71. So the device address of 0x38 -> 00111000 gets shifted left by one bit to make space for the read/write bit. Then it become 0111000X, where X is read or write bit. 0x70 (if it is a write) gets checked like,
 
    0x70 & 0xA0 (SSPMSK) = 0x20
 
0x20 is then compared with 0x80 (SSPADD), which PIC doesn’t give a match. Therefore, the PIC does not do anything. This ‘&’ operation is normal bit-wise ‘&’ operator in C programming ([https://www.tutorialspoint.com/cprogramming/c_operators.htm]).
 
For example, let's say we write to register 0x42. Then we go to the switch statement at line 155.
 
	'''switch (a & 0x2F)'''
 
Then 0x42 & 0x2F = 0x02. So we goes to line 160.

        '''case 0x02:'''
	'''tms_out(SSPBUF, 8);'''
	'''break;'''
 
it call '''tms_out()''' with the value written to 0x42 (The value comes from SSPBUF).
 
Similarly, when we read from address 0x64 we end up in the switch statement at 265.

	'''switch (a & 0x2F)'''

Then 0x64 & 0x2F gives 0x24. So the SSPBUF is loaded with TRISB in line 308.

        '''case 0x24:'''			
	'''SSPBUF = TRISB;'''
	'''break;'''
 
It is the value read from 0x64.
 
In this way, the PIC will handle the data reading and writing using interrupts at any time.