I'm trying to drive a calibration voltage from a VDAC through an op-amp (for higher current drive) and monitor the voltage at the same time (I'm driving a variable load and want to manually compensate it).
I can't figure out how to get PSoC Creator to let me do this. From a routing perspective it's trivial, I can hand-route it, but I'm wondering if there's a way to do it "normally" and just not seeing it.
The pin I'm using (bottom left) is the direct output from one of the uncommitted op amps. When I try to generate this design, Creator complains that the op-amp output is only designed to drive one pin. If I try to use an AMUX (with the intention of connecting both "inputs" to the "output", Creator complains that you can't connect the common of a mux to the input of another. If I rotate the AMUX I get similar errors.
I really don't want to use a "throwaway" pin to feed the signal back. Is there a Creator-sanctioned way to do this?
Did you try to use the SARADC alone (not the sequencing SAR)? It might be (without looking at the data sheets) that the SAR mux want to connect its inputs to pins directly, and that Creator doesn't like that.
Did you specify P3 as OpAmp out manually, or got that assigned by Creator?
Yes, using another ADC solves it, but I am looking for a more generic solution. A future application may require both ADCs and thus not work.
It looks like it can be done by forcing the analog routing to close an additional switch. Is there an "official" way to do this? I tried net ties and net joins without any sucess, and I'd really like to avoid hardcoding it in software.
The mux that is used with the sequebcing SAR is the Analog Hardware Mux and it does not allow for any additional internal connections (see datasheet), so Hli suggestion is completely right: you cannot solve that except connecting external pins.
Alternatively, you can use a normal SAR ADC together with the non-hardware analog mux. It means you lose the automatic sequencing, but should be able to connect the feedback path.
Consider filing a CASE on the original problem, to see if
any of the net components can force a route.
To create a technical case at Cypress -
“Create a Case”
You have to be registered on Cypress web site first.
Thank you all for your ideas and thoughts on this.
For now I've gone the same route that hli suggested which was just to use the second SAR without a MUX.
There are still a lot of "hidden" restrictions when using the various higher level constructs which I suppose is par for the course (trading implemenation speed with flexibility). I'm not completely sure *why* a hardware mux restricts things in this way, since it appears that the actual routing fabric would allow it. This isn't a criticism so much as just a recognition of the learning curve these parts present.
When you switch to "Analog" view in the .cydwr file you can see how the Analog Hardware Mux is realized and how it affects further routing. The analog routing capabilities are a bit reduced compared to the PSoC5.
That's actually my point; I can see clearly that I should be able to close a switch and realize what I want without trouble. This is why I asked how to try to show it to Creator. 🙂