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.
“Create Workspace Bundle”
Are the channels totally async to each other, or could you share
one UART across several channels ?
I would file a CASE on this, seems real odd the results going t0
To create a technical or issue case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.
So you file a case or I should?
You file the CASE and hopefully you will post back the results.
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)
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)
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.
I once had a project that changing the name of a component(UART I think, but not really sure) and failed to build. Changing the name back to what it was, and all fine. Cypress said that they will have it fixed in the later release, and I have no problem using the workable name. I think it should be fixed with the new creator. I think(but can't remember 100%) It is something to do with how the internal routine changes due to changing of name causing the change of placement sequence.
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.
1 of 1 people found this helpful
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.
Thanks hli, I will file a case on this hope to solve this.
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.
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.