PSoC5LP - Options for receiving data over SI2C without any address from the master?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

Hey all,

I'm looking into interfacing a PSoC5LP to a bit of a strange I2C Master.  Rather than being designed to run on a bus, I have to interface using SDA/SCL and an INT pin in a "point to point" configuration.  The idea is easy enough, it gives a edge on the INT line, I catch it with the PSoC, and read the 9 data bytes that it sends, but there's a twist. 

The catch is this device does not send an address, just the raw data bytes.  How can I adjust the SI2C to account for this?  I see I can use either Software/Hardware address decoding.  Hardware is probably out of the question since there's just no address at all.

This leaves me with software decoding, in which case it seems like modifying the ISR in SI2C_INT.c to just drop bytes immediately into the buffer rather than doing a check on the address might work.  Maybe some custom code placed in the SI2C_SW_ADDR_COMPARE_interruptStart code block in the ISR?  I could maybe set the "expected address" to something that should never occur as the first byte received (would need to see if this is possible, it only has 1 bit of data, the rest are "Reserved", so maybe they'll read all 0?  That would make it easy.) so it will drop into the address compare where I can drop my custom code to place the data in the receive buffer rather than use it as an address?

An easier option after looking further may be just to use the SI2C_ISR_EntryCallback(); and have it perform essentially a modified version of the stock Slave I2C code.

I'd be interested if anyone out there had any better options, maybe even something that just works in hardware?

Thanks!

0 Likes
1 Solution
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

So it's been some months, but I did finally receive the touch controller hardware, along with the missing information I was looking for.  Luckily this thread never got locked so I can give an update (it's not very exciting, for better or for worse).

Turns out I was worrying over what ended up being nothing.  The touch controller acts as an I2C master and will call out a slave I2C Address of 0x32 (0x19).  The only gotcha ended up being we need to provide the pull-up resistors for SDA/SCL on our end.  I also got some scope shots of how INT looks in relation to the I2C transmission, which was very helpful. 

INT goes high 100us before the touch data transmission begins, and it goes low as soon as the final byte is done being sent, so I was able to just set up a nice falling edge interrupt on the PSoC to know when there is a packet that should be completed and ready to process.  I've got it running nicely on my CY8CKit-050 based test setup.

View solution in original post

0 Likes
9 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

Kyle,

Are you sure the Master is I2C?  If it's not sending an address it could be SPI which does not require an address.

Len

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

When I spoke with the manufacturer about the interface, they described it as a Master I2C device, with an interrupt line that goes active when data is about to be sent.  But now that you mention, that does kind of sound like SPI with their "Interrupt" signal maybe being the "SS" signal in SPI terms.  I guess it's a question of if it's expecting a 9th ACK/NAK bit or not.

Once I get an actual sample in I will be able to just scope it out and say for sure, but for now I have to go with what I was told by the manufacturer, which was I2C.

0 Likes

Kyle,

If you pass on a link to the device's datasheet, I can take a look.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

I don't have a datasheet yet (I might see one later today/this week?  We have asked for one).  The only thing I have to go on at the moment is the description I received verbally from the manufacturer and a packet format (Device is a touch controller):

KyTr_1955226_0-1643044104593.png

 

0 Likes

Kyle,

If you're allowed to pass on the datasheet/programming manual, I'll take a look at it.

The table you provided looks like a Touch matrix.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Right I'm not worried about parsing the bytes, the packet format is fine.  I have code all set to translate this touch data to the form I need it in.  Mainly just concerned with how I am going to actually receive raw bytes over I2C with no address and do it with the existing PSoC SI2C API/component.

0 Likes

Hi Kyle.

Has the manufacturer mentioned the data rate?
Or the transmitted bit order?  We all know real i2C, but an i2C-ish interface could be backwards.

I'm guessing this could be a synchronous USART scenario where data is valid at the INT strobe.  INT triggers a counter to start a shift register and you grab each 8-bit block.

If INT turns out to be a byte mask (or 9 byte mask), like SPI SS, all the better.

Given this is used for Touch, I would not expect the clock to run continuously (to save battery power).  But, some SPI implementations do always run the clock.

Can't wait for your next installment.
Bill

0 Likes
KyTr_1955226
Level 6
Level 6
250 sign-ins 10 likes given 50 solutions authored

So it's been some months, but I did finally receive the touch controller hardware, along with the missing information I was looking for.  Luckily this thread never got locked so I can give an update (it's not very exciting, for better or for worse).

Turns out I was worrying over what ended up being nothing.  The touch controller acts as an I2C master and will call out a slave I2C Address of 0x32 (0x19).  The only gotcha ended up being we need to provide the pull-up resistors for SDA/SCL on our end.  I also got some scope shots of how INT looks in relation to the I2C transmission, which was very helpful. 

INT goes high 100us before the touch data transmission begins, and it goes low as soon as the final byte is done being sent, so I was able to just set up a nice falling edge interrupt on the PSoC to know when there is a packet that should be completed and ready to process.  I've got it running nicely on my CY8CKit-050 based test setup.

0 Likes

Good deal Kyle!

I'm glad you resolved your issue.

If it makes sense you can select your last post as the solution.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes