- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am working with cy8ckit-001 with psoc5 module cy8c5868axi-lp035
My design uses most of the resources.
in my design I have 3 full duplex uart blocks.
When I tried to switch them to half duplex mode
I had an error that said that there is not enough UDBs left
Which is weird because the half duplex should take less resources vs the full duplex.
What can I do to solve this?
Thank you
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When looking at thne placement report (the *.rpt file), in the 'Digital Placement' section, one can see that not all UDBs / PLDs / Datapaths are used. I think your problem is that Creator cannout route all the connections that are needed between the different components.
Introducting the half-duplex UART seems to increase the number of product terms that are needed (probably because now the same UDBs have two functions that need to be switched), and together with the address match feature then the PTerms cannot be placed. (Just look at the product terms and input nets of the UART PLDs)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Seems odd in light of resource table in datasheet, but
one cannot tell w/o looking at entire project. If you can
post an archive.
“File” Creator
“Create Workspace Bundle”
Are the channels totally async to each other, or could you share
one UART across several channels ?
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would file a CASE on this, seems real odd the results going t0
1/2 duplex.
To create a technical or issue case at Cypress -
“Support”
“Technical Support”
“Create a Case”
You have to be registered on Cypress web site first.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So you file a case or I should?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You file the CASE and hopefully you will post back the results.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can confirm the problem with Creator 3.1 (you still seem to use 3.0) - switching at least one UART to half duplex makes it not compiling.
But I can resolve that by disabling the hardware adressing feature, that you are using. Do you really need that? It seems quite odd given that the UART is half-duplex, since in that mode it might not be receiving when its address is sent. You even have not enabled the 'on address match' interrupt...
(And I find a bit rate of 110 Hz rather slow, though I know its a standard one)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When looking at thne placement report (the *.rpt file), in the 'Digital Placement' section, one can see that not all UDBs / PLDs / Datapaths are used. I think your problem is that Creator cannout route all the connections that are needed between the different components.
Introducting the half-duplex UART seems to increase the number of product terms that are needed (probably because now the same UDBs have two functions that need to be switched), and together with the address match feature then the PTerms cannot be placed. (Just look at the product terms and input nets of the UART PLDs)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hli, I am curious as to why you think the routing is challenged. Most connections
being made are to muxes which effect route reduction. What am I missing ?
In the error example 100% of the PLDs used, why do you think that was happening ?
Maybe I just do not understand what it takes logically to make a UART. I looked at
FPGA and equiv gate count for a Tx + Rx ~ 5K. Seems pretty small to me.
I did not catch the 110 baud, makes one think a super simple UART done in
verilog and muxed between channels a solution. Even using the DFB Assembler
and using the engine to effect the framing. Even a bit banging UART at that datarate.
Regards, Dana.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
I do need the addressing because on each channel there is about 3-4 terminal on the same differential lines, the uart outputs are connected to rs-485 transceivers.
I dont use the interrupt because it didnt work so good as it failed to detect, i will try it in the future again.
About the slow baud, the terminals are located far apart and in a noisy environment, so from signal integrity consideration i used the lowest standrard rate.
the terminals are "slaves" they only respond when the master addresses them, they are waiting in receive mode so there is no situation were the slaves misses their address.
Thank you very much for your time.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Regarding the routing: the digital placement report doesn't list any resource as 100% (or higher), but the PTERM count is missing. Also, when looking at the placement and the details for the UDBs, I see many man inputs and pterms.
When using the half-duplex UARTs, the same UDBs / Datapaths / PLDs are used, and their configuration is switched (by an API call). This state is probably in a control register. So any functionality now has an additional parameter (the currently enabled function). I guess that, together with the complexity of the hardware adressing, this makes one part of the UART too complex.
But I guess Cypress could solve that mystery, since from the data sheet it should work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks hli, I will file a case on this hope to solve this.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi. Nice neat program.
I do a lot of rs485 both long distance and very noisy environment. Your really low baud rate will cause you many problems.
If you cant mount your device on an ac drive, run the cable thru a kilometer of cable within a cable bundle and have it work well at 9600, then something else is wrong.
You have delays in the 1/4 second range....... Why??
You don't need both DE and RE pins. Just tie them together and go high on transmit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi scas,
i cant change the cables...
My system connected in parallel to a network of p2p lines that used to broadcast sound signal.
the system monitors the lines untill the broadcast is over
and then wait for a few seconds to make sure the broudcast is finished.
only then it moves from tri state to tx\rx mode so i cant connect
DE and RE...
Hope it makes sens to you now
What do you mean "mount ac drive"?
and why slow rate will cause problems? It worked well on 1km lines.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Update:
Here is the answer to the case i have opened:
Hello Shimon,
Here is the reason for this problem.
There isn't that much logic difference between Half Duplex and Full Duplex. The same basic logic needs to be done. Because the Half Duplex only has to either do transmit or receive at a specific time that allows us to use fewer datapaths for the Half Duplex mode. Basically we reuse the same datapath to do both transmit and receive. That does however require more complex control logic to switch between the two modes. Macrocells are basically a count of the number of hardware signals in a design. PTerms are basically a count of the complexity of the logic in a design.
In the half duplex case we have slightly less hardware signals to control the smaller number of datapaths (we have fewer datapaths) but the logic to control that is slightly more complicated. That results in slightly fewer macrocells and slightly more PTerms. You don't really care about the number of PTerms unless it starts to exceed the number of macrocells by a factor or 2 (there are 8 PTerms available for each 4 macrocells). In the half duplex case it does, so you may not be able to use all the macrocells in a PLD due to the lack of available PTerms. Hence the error message for you.
I need to check if there is any workaround for this.
Thanks,
Keerthi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is a "Software Transmit UART" which doesn't need any hardware components exept the IO-Pins. Wouldn't save that your design?
Bob
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, bob
I know about the sw transmit uart
but it's no good to my use because
a. I want to parallel the sending and receiving as much as I can, in the sw version I will need to wait for the end of the transmit.
b. the minimum baude rate is 9600, and I need to work with slower rates
c. I can't muliplex the sw uart, the output goes directly to the pin.
d. and most importent the API is very minimal, there is no adderessing mode
thanks, shimon
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Software UART does not offer 110 baud nor does it have APIs to control the clock or baudrate.
From the datasheet -
The supported baud rates are achieved using a combination of pin writes and software
delays, implemented with the CyDelay function. If the CPU clock is changed from the
configured frequency, then the CyDelayFreq API must be called before any
data transmission
Regards, Dana.