I'm just starting to look at PSoC 6 after working with 4 for quite a while, and I can't get past this first issue.
There is another post about this, along with a comment saying "we don't have this issue, it's likely to do with the pin configuration."
So I've created a new empty project in PSoC Creator, for a CY8C6247BZI-D54 ... I've put a single output pin on the schematic, and selected "Single-Sync" ... I've done nothing else and I get that warning.
I've experimented with different drive settings etc, but I can't get it to go away.
Similarly if I change it to an input pin (with hardware connection, and attach it to something like a status register) ... it's fine without sync, but with single or double-sync I get the same warning (well, InSyncNeeded.)
So I don't understand how everyone else isn't seeing this?
The family datasheets for the 4200L and the 62 family both contain the same section detailing the sync capability (PA Data Input Logic/PA Data Output Logic) ... so it's not a capability problem??
What am I missing?
Hi @LeEs_793571 ,
We have limited support over the PSoC Creator based solutions. However, I am able to produce the issue on my end and hence, I have narrowed down to seek help from our internal team over this.
Also, we would really appreciate if you could elaborate your application to us, so that we can help you with the alternate suggestions. Please let us know what do you want to achieve with your project?
Thankyou for your response. I must confess I am concerned about the whole "limited support for PSoC Creator" thing, I make extensive use of UDB's and so it's my only option ... it really does feel like you've moved from a really nicely tightly integrated solution, to a half capable one, it's a real shame and will inevitably result in migration away from the devices.
That said, I'm still a fan for now at least ... this project is a GPIB interface, using ethernet and PoE (and USB as an option), I have it fully working on PSoC4200L but am looking to migrate to the 6 so that I can make use of the extra memory and SMIF so I can introduce other features and capabilities.
The GPIB handshake is done in the UDB's making use of a datapath and supporting logic along with a hardware timer to support timeouts independent of the CPU. It all works really nicely.
I did have a timing issue previously which I think is actually related to the timing calculator not understanding the independent nature of the bi-directional pins and therefore complained about timing when I don't think it was actually an issue ... regardless though, this was solved using sync on the ports, and actually that probably makes sense to do anyway (as suggested by the documentation for when pins are used for UDB connectivity.)
I find UDB's, and specifically the datapath to be an absolutely amazing feature, I've used it for quite a few projects ... it would be a sad thing to lose. If I want a ARM core with some analog then there are loads of choices out there, but the UDB's make your products really stand out!
Hi @LeEs_793571 ,
We deeply regret for the inconvenience caused to you but I assure that I have forwarded this request to the higher management . I will keep posted in this thread, once I receive any update on the resolution or a workaround in the ticket.
Simultaneously, I just wanted to inform you that there is a 'SYNC' component available in PSoC Creator. With the help of this component, a set of input signals can be re-sychronized to the rising edge of the clock signal. I have shared an image of the component below.
Through this, the input signal at pin_2 can be synchronized with the HFCLK (this can be changed as per the user's need) and the final output signal can be obtained through pin_1. Here, on changing the Output mode for pin_1 to Single Sync does not yield the warnings.
Please let us know in case of further queries. Apologies for the inconvenience.
Thanks and Regards,
Thanks for the suggestion Aashita ... however this approach uses a status block for every 4 signals, I have 16 signals that are bidirectional (i.e. I would need this on input and output), so that's not an option -- also the capability is built into the device, this is a software issue with Creator -- we shouldn't have to increase project complexity to work around it!