- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Need advice on which part(s) to choose to be able to do the following:
- Two Type-C jacks, both supporting DRP & power: Source/Sink (in any combination with DFP/UFP)
- I might have need for one proprietary alt-mode (via SS pins)
Two questions:
1. Part options
- 1x CCG4 vs CCG5
- what exactly is the difference between these two?
- 2x CCG3 or CCG6
- same here, what is the difference between these two generations?
- pros/cons having two PD IC's vs one dual like CCG4 or 5
2. Drivers / serial-control
Main CPU is an ARM running Linux
- Are there drivers available in linux for these parts?
- if yes, plans to have them mainlined?
- Does all CCGx parts support standard TCPC / TCPM ?
Please advice
/David
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello David,
1. Part options
- 1x CCG4 vs CCG5
- what exactly is the difference between these two?
CCG5 is a more integrated SoC as compared to CCG4, with integrated VBUS LDO, more SRAM, integrated USBHS and SBU switches and legacy charging support. The VBUS LDO enables CCG5 to be powered directly from VBUS voltages on both ports. You will be saving a lot of BOM with CCG5, but make sure the additional features will also be of use to you.
- 2x CCG3 or CCG6
- same here, what is the difference between these two generations?
This is again the same, CCG6 is more integrated. What's missing in CCG3 is an integrated VBUS load switch controller, more SRAM, support for Thunderbolt ports, integrated crossbar switch for USBHS; while missing on CCG6 but present in CCG3 is an integrated billboard device (which is useful for alt mode) and HPD processing for DP alternate mode.
If you need more details on each feature, you can refer to the respective datasheets (first 8-10 pages).
pros/cons having two PD IC's vs one dual like CCG4 or 5
Pro's:
- Less BOM and circuit complexity.
- Single firmware handles both ports hence no need of an I2C interface between two independent CCG's, reducing delay and resources to communicate between two state machines. The code development will be a lot easier because of this.
- Easier power management (USB-PD).
Con's:
- Two seperate IC's might give some level of redundancy.
2. Drivers / serial-control
Main CPU is an ARM running Linux
- Are there drivers available in linux for these parts?
- if yes, plans to have them mainlined?
The interface to a Main CPU / Host processor is via I2C for these CCG's. A mutual NDA gives you the interface specification from Cypress.
- Does all CCGx parts support standard TCPC / TCPM ?
Yes. The stack is complete with TCPM, TCPCI and TCPC as per USB-C specifications.
No, we do not support TCPC / TCPM in our solution stack.
Regards,
Rajath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello David,
1. Part options
- 1x CCG4 vs CCG5
- what exactly is the difference between these two?
CCG5 is a more integrated SoC as compared to CCG4, with integrated VBUS LDO, more SRAM, integrated USBHS and SBU switches and legacy charging support. The VBUS LDO enables CCG5 to be powered directly from VBUS voltages on both ports. You will be saving a lot of BOM with CCG5, but make sure the additional features will also be of use to you.
- 2x CCG3 or CCG6
- same here, what is the difference between these two generations?
This is again the same, CCG6 is more integrated. What's missing in CCG3 is an integrated VBUS load switch controller, more SRAM, support for Thunderbolt ports, integrated crossbar switch for USBHS; while missing on CCG6 but present in CCG3 is an integrated billboard device (which is useful for alt mode) and HPD processing for DP alternate mode.
If you need more details on each feature, you can refer to the respective datasheets (first 8-10 pages).
pros/cons having two PD IC's vs one dual like CCG4 or 5
Pro's:
- Less BOM and circuit complexity.
- Single firmware handles both ports hence no need of an I2C interface between two independent CCG's, reducing delay and resources to communicate between two state machines. The code development will be a lot easier because of this.
- Easier power management (USB-PD).
Con's:
- Two seperate IC's might give some level of redundancy.
2. Drivers / serial-control
Main CPU is an ARM running Linux
- Are there drivers available in linux for these parts?
- if yes, plans to have them mainlined?
The interface to a Main CPU / Host processor is via I2C for these CCG's. A mutual NDA gives you the interface specification from Cypress.
- Does all CCGx parts support standard TCPC / TCPM ?
Yes. The stack is complete with TCPM, TCPCI and TCPC as per USB-C specifications.
No, we do not support TCPC / TCPM in our solution stack.
Regards,
Rajath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rajath,
Thanks for detailed answer. Follow-up questions:
- Regarding TCPM/TCPCI/TCPC, I couldn't find anything in the "NDA docs" about this.
Is this specified somewhere public / or any open source implementations in say FreeRTOS, mbed or Linux?
- Can you explain a bit how it works with the PD stack running on the actual CCG.
- Is this open source or closed binary?
- Can we add our own code running on the CCG device?
(i.e. to utilize the additional gpio's for house-keeping tasks etc)
best David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
Sorry, I would like to correct the last point, we do not support TCPCI/TCPM.
Regarding the PD stack as we have now, it is closed source library. But fimrware customization is possible on a high level, using the CCGx Host Software Development Kit.
Regards,
Rajath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you please explain a bit the strategy behing not doing standard TCPCI?
as you might know, this is implemented in Linux mainline so adding a CCG would be very little work if the USB-IF defined protocol was supported.
I get that the CCG's runs the full state machine locally as opposed to more simple CC/PD PHY IC's.
But when building a DRP device with full "PD flexibility" (source/sink) the amount of events and meta-commands will be quite extensive so the question is how much of this would be replicated in a similar state machine on the application CPU that talks to the CCG.
Another option is of course to add code on the CCG itself to manage the application-specific needs, so that anything time-critical or connection-event based can be handled within the CCG to reduce the command-set needed over I2C (and the mirrored implementation on the host cpu)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
please note that there seem to be some support in linux FYI:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi David,
Since our CCGx is inclusive of all the functionalities in its stack, it would become difficult to make a standard TCPCI implementation when the implementation inside the EC (or host IC) is not known (even if done, it would seem redundant to a generic customer). What we suggest generally to customers is to make use of the CCGx + USB-Serial HPI model and port it to a different environment/wrapper. USB-serial API's are all available.
Regards,
Rajath
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rajath,
Makes sense. Most of the abstraction levels are taken care of locally in the CCG's.
I haven't compared how extensive the TCPCI inteface is vs the CCG API protocol.
Do you happen to have a reference implementation running on say another PSoC / ARM (rtos or baremetal)
best David
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
David,
Unfortunately we do not have an implementation on other PSoC / ARM.
Regards,
Rajath