PDA

View Full Version : Building an I2C monitor ... but i think it is not Slave....



LakisFM1
- 1st March 2012, 15:26
Building an I2C monitor with a 12F1822 and i want to monitor at least 4 addresses.

I use SSP1MSK = 000001 for that , and then i filter the 4 addresses from the SSP1BUFF.

But i think that I2C SLAVE is not the exactly the mode i need.

I need a mode that will be completely transparent , will receive ALL Addreses and Data running in the bus , and never ACK , never reply.

I have done some code so far but is not stable and it gets confused when Data bytes start coming ...

Can you confirm if i am on the right way ?

Charlie
- 2nd March 2012, 11:10
Using master mode or slave mode or even the hardware I2C module won't work. The protocol fundamentally uses handshaking which you want to avoid. Instead, you will need to use standard inputs and clock in the lines, then analyse what you've got - potentially on a bit by bit basis.

languer
- 2nd March 2012, 18:15
I've been looking at something similar (very low on my priority list - but every now and then I get back to it); and I do not think you can use the hardware module on the PIC. You have to bit-bang your way around this. To get the higher rates, you'll need to add some additional hardware to help the PIC.

A few notes that have helped me...
Design Note 48 (I2C Bus Sniffer) - http://www.avrfreaks.net/modules/FreaksFiles/files/566/DN_048.pdf
I2C Bus Sniffer on AVR - http://www.radiolocman.com/shem/schematics.html?di=64837

LakisFM1
- 3rd March 2012, 08:53
Many many Thank you for the replies.

I thought that reading the Addresses and Data but instead of ACK , i would always use byte NACKing (though it was invisible on the bus)
as it is referred in the pdf , would do the job.

The only problem i saw was that because i have to AHEN =1 , DHEN=1 for byte Nacking mode,
i am now forced to CLK streching and have to CKP =1 continously... invisible on the bus...naaaah.

LakisFM1
- 4th March 2012, 09:35
While speed-optimizing an IRQ Bit-bang routine i am working on now , i though it would be useful to use the EUSART Synchronous Slave Reception mode (asuming using the 2 EUSART pins of course).
Eg.

On SDA (P/N) /SCL (P only) port change Interrupt :
1. Check if STARTbit
2. If it is STARTbit then Enable the EUSART in Slave RX mode (and stay in IRQ routine ! , don't leave out!)
3. EUSART gets the 8 bit BYTE (done in hardware :) , no bitbanging and bit-shifting :) )
4. Ignore the 9th (N)ACK bit (i don't need it...)
5. Resume

6. In the next interrupt i will check if i get a STOP or a RESTART ...and so on...

I guess i am not mistaken ....:soap:

LakisFM1
- 6th March 2012, 23:32
I am happy to say that the bit-banging I2C monitor is done.

It is written all in PBP , and uses interrupts for the input-bit sensing using a...12F1822 at... 32MHz of course.

Tommorow i will post the code here , since i dont' have it now here.

Cheers!:excitement:

LakisFM1
- 8th March 2012, 22:22
ASM
__CONFIG _CONFIG1, _FOSC_INTOSC & _WDTE_ON & _PWRTE_ON & _MCLRE_OFF & _CP_OFF & _CPD_OFF & _BOREN_OFF & _CLKOUTEN_OFF & _IESO_OFF & _FCMEN_OFF
__CONFIG _CONFIG2, _WRT_OFF & _PLLEN_ON & _STVREN_OFF & _BORV_19 & _LVP_OFF

ENDASM

DEFINE OSC 32

TX VAR PORTA.0
SCL VAR PORTA.1
SDA VAR PORTA.2

SCLB VAR PORTAB.1
SDAB VAR PORTAB.2
SCLF VAR IOCAF.1
SDAF VAR IOCAF.2

BIT_COUNTER VAR BYTE
STOP_COUNTER VAR BYTE
BYTE_READY VAR BIT
BYTEINT VAR BYTE
BYTEINT2 VAR BYTE
BYTEINB VAR BYTE
BYTEIN VAR BYTE[30]
PORTAB VAR BYTE
BYTE_COUNTER VAR BYTE
BYTES_RECEIVED VAR BYTE
STOPFLAG VAR BIT

OSCCON = %01110000
IOCAN = %00000100
IOCAP = %00000110

ON INTERRUPT GoTo INT ' Declare interrupt handler routine

START:
PAUSE_1000

OPTION_REG.7 = 1 ' DISABLE PORTB PULLUPS

PORTA = %00000110 ' SWAP PORTA.0 /PORTA.2 FOR SMALL PCB
TRISA = %00001110 ' SWAP PORTA.0 /PORTA.2 FOR SMALL PCB
ANSELA = $00 ' MAKE ALL INPUTS DIGITAL I/O PINS
WPUA = $00

BIT_COUNTER = 0
BYTE_COUNTER = 0

INTCON = %10001000 ' Enable GLOBAL AND IOCHANGE interrupts

MAIN_LOOP:

IF STOPFLAG = 1 THEN
'/ Here we have the received bytes in the array BYTEIN(x)
' The size of the array is in the variable BYTES_RECEIVED.
' You have to process them and then ...
BYTE_COUNTER = 0 ' in order to get the next bytes
ENDIF

GOTO MAIN_LOOP



'================================================= ===========================
'================ BIT BANGING interrupt handler ============================
'================================================= ===========================

Disable ' Don't check for interrupts in this section

INT:
PORTAB = PORTA 'Buffer the STATUS OF THE PORT

'------------------------- ignore errory databits ------------------------
'using the I2CWRITE command of PBP i got an errory SDA pulse ...
'using the next line i ignore this error-y line ...
'for other uses you may ommit it .

IF SCLB = 0 THEN IOCAF = $00 : RESUME ' IGNORE WHEN CLK = 0

'-----------------------receive data bit -----------------------------------

if SCLF = 1 THEN 'CLK_FLAG SET : IT IS DATA !

'----------------------- store byte ----------------------------------------

IF BIT_COUNTER.3 = 1 THEN ' IF WE GET 8 BITS RESET BITCOUNTER
BIT_COUNTER.3 = 0

BYTEIN(BYTE_COUNTER) = BYTEINT ' AND STORE THE BYTE
BYTE_COUNTER = BYTE_COUNTER + 1

IOCAF.1 = 0 ' CLEAR INT ON CHANGE FLAGS
RESUME
ENDIF

' ------------------------- receive bit ------------------------------------

BYTEINT = (BYTEINT << 1)
BYTEINT.0 = PORTAB.2
BIT_COUNTER = BIT_COUNTER + 1

IOCAF.1 = 0 ' CLEAR INT ON CHANGE FLAGS
RESUME
ENDIF

' --------------------start bit-----------------------------------------------
IF SDAB = 0 THEN
BIT_COUNTER = 0
IOCAF.2 = 0 ' CLEAR INT ON CHANGE FLAGS
RESUME
ENDIF
'---------------------stop bit ----------------------------------------------

STOPFLAG = 1
BYTES_RECEIVED = BYTE_COUNTER
'BYTE_COUNTER = 0 'nevermind BYTECOUNTER WILL RESET AT THE NEXT START BIT ANYWAY
IOCAF.2 = 0 ' CLEAR INT ON CHANGE FLAGS
RESUME
ENABLE

End

LakisFM1
- 8th March 2012, 22:24
I must note i used a 12F1822 @32 MHz and the I2Cbus was running at slow speed !. I don't think the code is fast enough for a 400KHz bus! :(

languer
- 13th March 2012, 06:04
For those who are interested, I placed my implementation here: http://www.electro-tech-online.com/blogs/languer/212-i2c-monitor-implementation-limitations.html