Proton BASIC Community

Hi !
I find PIC18F25K22 has 2  I2c port.

1st is on portc.3 & portc.4

2nd is on portb.1 & portb.2

I know how to use i2c on portc

but how can i use it on portb


I tried with HBUSIN2 but it create error with PIC18F25K22

Thanks

In facts there's no such command. There's much written and explained on the manual. To make the second port working, I suppose you need to swap the pins related to the I2C connection and thus you send the commands.
Look at page 136, for the current manual (or likely around that page).

Sir,

Thanks for help, but i want to use both i2c  at the same time.

Thanks

Only supports a single i2c

Quote from: Roshani on Aug 05, 2022, 01:29 PMSir,
 i want to use both i2c  at the same time

The MCU don't work simultaneously, in no cases. But there are no basic commands to allow you to achieve your purpose. You may send a data to one I2C bus, and switch to the second set  of pins. At the MCU speed that will resemble simultaneous. But the internal CPU does only one task a time. That's it.

Keytapper,
I haven't checked the datasheets but remember the hardware I2C peripherals have a hardware single byte buffer. Assuming the peripherals are independent (and they might not be) and if the data from each can be inserted into separate software buffers it MIGHT just work especially if the data is only a byte or two in a fast PIC and the I2C is slow speed.
Something to consider.
I'm happy to be shown wrong. I like to think laterally and prove the impossible may be possible
Cheers
John

I would go for a software i2c. Its not going to take any more time as the whole process either in HW or SW will be the same, unless your running it in an interrupt.

You can have SW i2c on just about any channel. I even have code running using a shared data line and just the CLKs are unique

Tim

Quote from: TimB on Aug 06, 2022, 06:08 PMI would go for a software i2c. Its not going to take any more time as the whole process either in HW or SW will be the same, unless your running it in an interrupt.

You can have SW i2c on just about any channel. I even have code running using a shared data line and just the CLKs are unique

Tim

@TimB As he's running as a slave a HW connection will always be faster. Two ways to do it, (a) in an interrupt or (2) checking the SSPxStat.0 = 1 for buffer is full or SSP1IF(or SSP2IF) = 1 for the interrupt bit. You know interrupts better than most and know all this but others might not.
The peripheral works apart from the main processor so it can be receiving a byte in the background while other code is running whereas with software I2C the processor has to deal with receiving (or sending) the byte. It works but in speed dependent applications I always use hardware.
Also for slave operation I would always use hardware and just plan ahead for the correct pins.
Software is the only choice if you want flexibility of pins as you know.
John

Roshani
PS here's a sample of how I run a slave in MSSP1 in a PIC18F25K22. I don't use HBUS but access the registers direct. Much of the code was drawn from work by Les. You might be able to gather some ideas from it.
'------------------------------------------------------------------------------------
' Here begins the interrupt routine
' I2C slave subroutine

BringInI2C:
    Context Save
    If SSP1IF <> 1 Then GoTo EndIntRoutine
    SSP1IF = 0                               'Clear interrupt flag
    If R_W1 = 1 Then GoTo i2cWr              'Data for bus (not address)
    If BF1 = 0 Then GoTo EndIntRoutine       'Nothing in buffer so exit
    If D_A1 = 1 Then
       GoTo i2cRd                           'Read data from bus
    EndIf
    If SSP1BUF <> SSP1ADD Then EndIntRoutine     'Clear the address from the buffer
    GoTo EndIntRoutine
'------------------------------------------------------------------------------------
' I2C write data to bus
i2cWr:
    btmp2 = SSP1BUF                              'required for a PIC18F25K22
    SSP1BUF = DataKey                            'Put data into data to be sent
    CKP1 = 1
    DataKey = 0
    GoTo EndIntRoutine
'------------------------------------------------------------------------------------
' I2C read data from bus
i2cRd:
    Index_in = (Index_in + 1)                   ' Increment index_in pointer (0 to 63)
    If Index_in > (Buffer_size - 1) Then Index_in = 0    'Reset pointer if outside of buffer
    If Index_in = Index_out Then Buffer_error   ' Check for buffer overrun
    Temp = SSP1BUF                              'Get data from datain
    CKP1 = 1
    DataIn = Temp                               '*********added as test used in voice commands
    If Temp> 0 Then Buffer[Index_in] = Temp     ' Read MSSP and store character to next empty location
    If SSP1IF = 1 Then GoTo i2cRd               ' Check for another character while we're here
    GoTo EndIntRoutine                          ' Return to program
   Buffer_error:
    Errflag = 1                                 ' Set the error flag for software
'Move pointer back to avoid corrupting the buffer. Min insures that it ends up within the buffer.
    Index_in = (Index_in - 1) Min (Buffer_size - 1)
    Buffer[Index_in]=SSP1BUF                      ' Overwrite the last character stored (resets the interrupt flag)
EndIntRoutine:
    SSP1IF = 0
Context Restore
'------------------------------------------------------------------------------------
'end of high interrupt routine


If you want to use multiple HW I2c on multiple busses (Not simultaneous) then consider using a device with PPS and remap the pins.  Alternatively use one HW and 1 SW i2C, if you recode the 12c in a procedure you can run it pretty fast on a 25k22.  You can definitely recode I2c routines to work on multiple busses simultaneously.

"@TimB As he's running as a slave a HW connection will always be faster."

Ahh my bad, I missed that!

The I2C commands, both hardware and software, within the compiler, only act as masters, and not slaves.

As John has shown with his excellent code snippet, I2C slave requires an interrupt to get fired when the device receives a signal from its MSSP peripheral setup as I2C.

I did create an I2C slave a few years ago, actually quite a few years ago :-) , but I was never happy with the way the 8-bit PIC microcontrollers performed as an I2C slave. They always require clock stretching, and can sometimes go out of sync, so the interrupt code must look for "when" it goes wrong, and not "if" it goes wrong, and re-sync itself and dump what was previously received and reset flags etc... The same with SPI slave, which is actually quite good in 8-bit PIC microcontrollers. A bit slow, but quite good.

QuoteAs he's running as a slave a HW connection will always be faster

I agree with the HW being faster part but I don't see where the OP says he's running as a slave.
I took his post to mean he wants 2 master ports.

You are right tumbleweed, I cannot see the word "slave" either in the original post.

The 8-bit PIC devices are now using an independent I2C peripheral and not the MSSP peripheral, and Microchip keep changing how they operate on different devices, so the HBus commands are now "Legacy", and no new HBus commands will be created. However, there is nothing stopping a person from creating a library for the I2C peripherals, because, with some study, they are a sequence of setting/clearing SFR bits and waiting for some bits to set or clear. This is OK for a library of procedures, but not for a dedicated command that has to take as much as possibly can be thrown at it and still try to work or, at least, not block. :-)

But the software I2C commands work just as well and are a lot more flexible because they work on any device, with or without MSSP or I2C peripherals.

You're right. I jumped to a "confusion".
We octogenarians have an excuse.
John

QuoteWe octogenarians have an excuse.

So what excuse can us "Sextarians" use John. LOL. "Ooooooooh, missus, that sounds like a rude word, are you sure I can say it?", to put it coming from the mouth of the wonderful, and sadly passed, Frankie Howard. LOL

Unfortunately, age can bring other problems with the brain, but take it from me John.... You have a fine brain that has stood the test of time, and I would not falter in taking advice from you. :-)

And also.... Many thanks for the donation. It means so much to me that people do actually care in these days of greed and malis. :-)