- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The I2C component in PSoC4 was able to write the contents of a modest OLED display (1kB data) in one transaction, easily. It is not possible with a PSoC5. Both are 'fixed function' SCB resources.
The PSoC4 component datasheet quotes the following API for the write:
uint32 SCB_I2CMasterWriteBuf(uint32 slaveAddress, uint8 * wrData, uint32 cnt, uint32 mode)
Description:
Automatically writes an entire buffer of data to a slave device. Once the data transfer is initiated by this function, further data transfer is handled by the included ISR.
Enables the I2C interrupt and clears SCB_ I2C_MSTAT_WR_CMPLT status.
Parameters:
uint32 slaveAddress: Right-justified 7-bit Slave address (valid range 8 to 120).
uint8 wrData: Pointer to buffer of data to be sent.
uint32 cnt: Number of bytes of buffer to send.
Now my project doesn't fit in a PSoC4M anymore, so I 'upgraded' to a PSoC 5LP. Everything seemed bigger and better, except that my display code was buggy.
The PSoC5 component datasheet says:
uint8 I2C_MasterWriteBuf(uint8 slaveAddress, uint8 * wrData, uint8 cnt, uint8 mode)
Description:
This function automatically writes an entire buffer of data to a slave device. After the data transfer is initiated by this function, the included ISR manages further data transfer in byte-by-byte mode. Enables the I2C interrupt.
Parameters:
uint8 slaveAddress: Right-justified 7-bit slave address (valid range 0 to 127).
uint8 wrData: Pointer to the buffer of the data to be sent.
uint8 cnt: Number of bytes of the buffer to send.
This seems like an enormous retrograde step. I was under the assumption the 5LP was designed to be technically superior to the PSoC 4 series. What is the reason for going from 32-bit capability to 8 on such a common interface? If there is an option to specify the size of this buffer in the 5LP I2C component configurator I haven't found it.
Interestingly the return value of this API function also has been reduced, as has the 'mode' parameter type. Both the PSoC4 and 5LP return values (from this particular API function) require 3 bits. The PSoC4 expects uint32, and the PSoC 5LP expects uint8. Eight bits for this is reasonable; was the change of cnt to uint8 possibly a mistake made while rationalising the API return value (and 'mode' parameter) type?
Any explanation or suggestion for a workaround with 5LP would be really appreciated.
Paul
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may (when solution is working) create a new component which will not prevent overwriting the code, but will generate the required code as all the other components do.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Historically the PSoC5 was designed BEFORE the PSoC4. So the change is from 8 bit to 32 bit.
Will not be too difficult to divide a larger buffer into several smaller chunks.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Bob,
I take your point about the chronology of the PSoC families. However the work-around you suggest is not something I'd like to do. Think about how the Horizontal or Vertical addressing schemes work with an OLED display, particulary when you are not writing to the entire display area. Imagine updating a 'speedo dial' graphic in a box which fills 2/3 of the screen area. Now consider the index calculations required in user code to keep updating the OLED display with the new start position for the subsequent data block, it would require an ugly melding of OLED hardware boundary checking and PSoC user code boundary checking. That's a processing bandwidth hit, not to mention the I2C bandwidth hit due to additional overhead.
Having read similar posts, I believe the modification of the generated code is the best approach. I will attempt to copy out the generated to user code and modify that, so it's not overwritten every build cycle.
Paul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may (when solution is working) create a new component which will not prevent overwriting the code, but will generate the required code as all the other components do.
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That's a really good idea, Bob. I haven't had the need to do that before, but this issue is the prompt I need to have a crack at it. Thanks for the suggestion. It is a wonder Cypress haven't addressed this yet, there are community posts going back 2+ years on this issue.
Cheers,
Paul