 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Ttelmah
Joined: 11 Mar 2010
Posts: 19529
|
|
 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... |
|
|
 |
allenhuffman
Joined: 17 Jun 2019
Posts: 552
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 11, 2024 8:34 am |
|
|
After having this code run well on multiple PIC24 types, some recent work has revealed it can lock up for a different reason: apparently missing the "stop bit" in that loop.
Analyzing the I2C traffic using a Saleae shows some unusual things with clock pulses and such, which may be issues related to the FTDI Windows driver (which acts as a master).
I have temporarily reverted to the "less than 128 byte" message code (CCS i2c_isr_state method) to get past this until I can figure it out later.
What is odd is that my test code did a bunch of read/write with huge messages and it works. I ran in to this issue with code that repeatedly requests a message (sending a 5 byte message) that is less than 80 bytes in size. It will chug along and screw up after just a few, or after a few thousands.
This very well may be a hardware issue on the Windows FTDI chipset side, but I wanted to mention this in case anyone used my approach and has run in to this.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
