- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
PSoC 5LP Architecture TRM, p.159, Figure 19-8 shows Mapping of DSI Control Signal to Port Pin Output Enable.
I have a design where an 8 bit Port is used.
Each Port pin should go either to DSI_OE[0] or DSI_OE[1], depending on the value of the corresponding PRT
When using schematics entry, I cannot use 2:1 input multiplexer for DSI_OE[1:0] DSI signals, one for every Port Pin and place all the pins into the same 8 bit Port.
I there a workaround, please ?
In other words, can I somehow instantiate DSI_OE[1:0] DSI output in the schematic and then use software to write to PRT
(Note what I need: There are 8 port pins which must be on a single Port and each of them is controlled either by DSI_OE[0] or DSI_OE[1]. )
Anybody knows the trick ?
Example file attached.
Solved! Go to Solution.
- Labels:
-
PSoC 5 Architecture
-
PSoC 5LP
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
Thanks for attaching the project. I have a better understanding.
It is pretty trivial to control the PRT
I believe I might have a solution for the assignment of the DSI_OE[0] and DSI_OE[1] for port 4.
You can see I hard-assigned the PadOeMux[0] to the first four bits of the port and PadOeMux[1] to the last four bits of the port. This forces the Application Builder to assign these as DSI_OE[0] and DSI_OE[1] of Port 4. You can then write SW to control which DSI_OE gets selected per pin using PRT4_OE_SEL0
Question: In your TopDesign schematic you used Bidirectional digital pins. Did you intend that when it the pin is OE enabled that it was in a float high, drive low mode?
The schematic I shown above uses the OE directly on the pin and the pins are a STRONG push-pull drive when OE is enabled and input when not enabled. This eliminates the need for bufoes and many of the Status and Control registers. Just a thought.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
ivpa,
I believe that OE consumes extra pin, so only 4 pins with OE are available per port.
Maybe there are other solutions to your goal. Can you describe what is the goal ?
Do you really need pins in Hi-Zin state?
/odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BoTa,
there are only 4 OEs for any given 8 bit port. However, it should be possible to control that 8 bit port with 2 OEs, because I only need some ports as outputs and some ports as inputs. It is not known in advance which port pins are outputs and which are inputs so it should be flexible. So e.g. OE1 will be used for port pins 0,3,4 and OE2 for port pins 1,2,5,6,7.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
If high-speed switching is not required, then changing Pin mode (digital input / output) can be done with software API calls.
/odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, that is the case.
But e.g., how will the Pin 1.3 know that it is connected to the OE1 and Pin 1.5 to the OE2 ?
Register PRT
But I need to control that OE1 and OE2.
How to draw it in the schematics ?
- 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
This is for PSoC 4 and I am using PSoC 5LP.
The other thing is that I want DSI to generate OE1 and OE2 and Register PRT
In other words, PSoC 5LP does have 4 OEs but it lacks formal way of using them efficiently.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
You can set pin directly to HiZ / StrongDrive (ignore output enable, use regular digital pins)
// Set P3[6] to Digital HI-Z
CyPins_SetPinDriveMode(CYREG_PRT3_PC6, PIN_DM_DG_HIZ);
//Set P3[6] to Strong Drive mode
CyPins_SetPinDriveMode(CYREG_PRT3_PC6, PIN_DM_STRONG);
Or direct API
PINNAME_SetDriveMode(...)
/odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
BoTa, thanks.
However, this does not solve my problem as it is too slow.
I really need those two OEs to be mapped statically by means of software and then they are toggled by means of DSI UDBs.
I think the formal method of doing that is not available - if yes, please, correct me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
Do you need OE driven by hardware signal? I believe that only 4 pins with OE per port can be hardware-driven. Each hardware OE connector consumes one extra pin, so 8 pins with OE are not possible per port.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I need OE1 and OE2 driven by hardware signals, i.e. by DSI.
Then I need to assign either OE1 or OE2 to 8 pins on a single port (e.g. Port 1) by means of Register PRT
However, OE control is time critical and must be done by HW DSI UDB signals.
Thanks for your help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
Does it absolutely has to be a single port?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it must be in a single port !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Where to send project bundle archive, please ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
You can attach Archive to the post: Edit->Attach (in the lower right corner).
To create archive bundle: (1) Build->Clean; (2) Select project name in Explorer panel->File->Create Archive bundle; (3) in created zip file delete Generated_source folder to reduce archive size.
//odissey1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lepo,
your interpretation is correct. Please, look into my files which I have attached.
I need a HW solution and I need to somehow route OE1 and OE2 and select one of them by means of PRT
In other words, PSoC 5LP silicon offers excellent 4 OEs, but PSoC Creator does not have a method how to fully use them.
Are there any plans to add that in the future release of PSoC Creator ?
My product is dead without that possibility.
Or I have to decode bit stream bit assignment and generate my own bitstream, brrrr, no way.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Here is an example of what I need. The selection of OE1, OE2 assignment to the actual port pins is done in SW.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
Hi. Maybe I'm missing the true question here. Can you draw in TopDesign what you want even if it doesn't compile?
Here's my understanding of what I think you want all on one contiguous port. This compiles.
You should be able to change the Control_Reg for some other logic component or routing of an input pin.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You cannot group 8 pins into 1 block if you want to use more than 1 OE signal.
Each port pin must be kept and controlled separately.
There are 4 OEs coming from DSI UDB for each 8 pin port.
So I am using the PSoC 5LP up to its limits but not exceeding them.
I will send you some example of schematics bit later.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
I think I understand better. The errors I receive are probably the errors you receive.
Error: apr.M0039: IO "Pin_8_bit(4)" cannot be placed into "P0[4]" because it would require more output enable signals than the port has. Pick a different place for this IO. (App=cydsfit)
Error: apr.M0039: IO "Pin_8_bit(5)" cannot be placed into "P0[5]" because it would require more output enable signals than the port has. Pick a different place for this IO. (App=cydsfit)
Error: apr.M0039: IO "Pin_8_bit(6)" cannot be placed into "P0[6]" because it would require more output enable signals than the port has. Pick a different place for this IO. (App=cydsfit)
Error: apr.M0039: IO "Pin_8_bit(7)" cannot be placed into "P0[7]" because it would require more output enable signals than the port has. Pick a different place for this IO. (App=cydsfit)
Question: Does your design require that the pins be assigned "Contiguously"? The only real reason you would need to do that is to simplify controlling the port pins from SW. If this is not a consideration, you can assign the pins with common OEs across ports. For example, the following schematic compiles without error.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
Thanks for attaching the project. I have a better understanding.
It is pretty trivial to control the PRT
I believe I might have a solution for the assignment of the DSI_OE[0] and DSI_OE[1] for port 4.
You can see I hard-assigned the PadOeMux[0] to the first four bits of the port and PadOeMux[1] to the last four bits of the port. This forces the Application Builder to assign these as DSI_OE[0] and DSI_OE[1] of Port 4. You can then write SW to control which DSI_OE gets selected per pin using PRT4_OE_SEL0
Question: In your TopDesign schematic you used Bidirectional digital pins. Did you intend that when it the pin is OE enabled that it was in a float high, drive low mode?
The schematic I shown above uses the OE directly on the pin and the pins are a STRONG push-pull drive when OE is enabled and input when not enabled. This eliminates the need for bufoes and many of the Status and Control registers. Just a thought.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, that looks like a good workaround.
I will use pins as you suggested.
Question: When to use tri-state buffer then (as you recommend to use pin only) ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IvPa,
It is best to use a tri-state STRONG drive as long as you can guarantee that there is no collision with other tri-state drives on the system. you have to guarantee that only one drive on the line will be OE active at a time. Using the tri-state STRONG drive minimizes the rise and fall times of the switched digital signal. This maximizes the operating frequency allowed.
If your protocol cannot guarantee that the drivers on the line will not collide in time, then using a BIDIRECTIONAL or Drive Low-only might be a good choice. In this case the fall time is very quick but the rise time is totally dependent on the total bias resistance and the line capacitance. This increased rise time will limit your maximum operating frequency. That is why in this configuration, a longer wire length (added line capacitance) lowers the operating frequency.
In either the tri-state or Drive Low-only configuration you should have some pullup on the line to prevent false input triggers in the case that no drive is actively driving at that time. With tri-state, your pullup can be a higher value.
Len
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks all for excellent reply. I can now compile my design and I know the tricks to finalize it!