Ttelmah
Joined: 11 Mar 2010
Posts: 19221
|
|
 Posted: Fri Apr 28, 2023 12:51 am |
 |
|
Your chips aren't ones where this applies. There are a couple of PIC's
(I think possibly only PIC16's), that have a 'smart' i2C peripheral. This
doesn't support direct operation at all, just support a block transfer.
The internal counter for this is 7bit in the hardware. These were the
chips for which I2C_transfer was first added about four years ago.
On your original post you referred to I2C transfer and i thought you
might be using one of the chips with this hardware.
The limit on I2C_ISR_state was just that for 99% of devices transfers
are normally only a few bytes, and the code is smaller to only use an
8bit variable. This is presumably the same reasoning that Microchip
limited the hardware transfers on these chips to this size as well.
| allenhuffman wrote: | | Ttelmah wrote: | If however you are using a PIC with the I2C peripheral,
you have a problem, since this supports 128 byes total in the transfer
(the address byte counts as one, so 127 bytes of data).
The functions abilities were written to support the hardware abilities on
some particular PIC peripherals... |
Very interesting -- Is this 128 byte limit a hardware limit? If I was doing polled mode, could I not i2c_read() as much as I wanted? (Assume FORCE_HW rather than bitbanging.)
Or is it a i2c_isr_stat() software limit? I can see that i2c_isr_state() is not set up to handle more than data bytes 0x1-0x7f, but if you write past that, I don't know what happens.
Time to do some more testing... |
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
