If you hover over the switches in PSoC Creator -> CYDWR -> Analog Tab, you can see the register addresses and masks. Which can be used to write the registers to close the switches. But regarding your use case, if you are using Scan ADC, you may not be able to achieve full speed conversion rate as CPU intervention is needed to update these routes in between.
SARMUX should be able to scan without CPU intervention even with mixed inputs from P10 and AMuxBus, shouldn't it?
The SARMUX only has control to the MUX_SWITCH0 register. Said that, if you have only two pins (single ended) connected to the AMuxBus, you can handle without CPU intervention (one pin connected to AMUX A, and other to AMUX B). If you have three pins (single ended) connected to AMuxBus, then you need to handle the mux switches with CPU.
I've created and attached a simplified project that has the same issue: It uses SARMUX to switch between 4 differential pairs, and one 3:1 pre-mux. This pre-mux is wired to P10 through an external wire, and I want this external wire to become an AMuxBus connection (labeled "A4_n_bus" in the schematic):
I've tried to use a directive but that didn't have any effect at all. Do directives only apply to digital routing?
The analog constraint mentioned in the Net Tie component datasheet is apparently missing in PSoC Creator (why!?), so that approach didn't lead anywhere either.
When going to the smaller BGA, I can only get the fitter to route through AMuxBus if I add an "intermediate dummy" analog pin ("Pin_1"):
It's a start, not perfect (but the extra pin is not necessarily a problem), and might fail in an overall more complex design. Another detail I noticed is that the analog switch for P10.7 is present and used by the fitter, even though the package doesn't provide the pin.
It'd be great if I could assemble the analog routing piece by piece and then somehow export the analog setup into a constraint file.
The problem is that PSoC Creator doesn't allow connecting a mux to another mux. You can trick it by connecting a pin between the muxes, as you did.
Another thing you can do is to not use a mux at all. Just place the default pin from P11 to the SAR MUX directly. Then use DMA or CPU to write directly to the P11 mux switch (PRT11_PORT_SEL0).
Unfortunately, in this application, I want hardware control of the pre-mux to get more slack in CPU and DMA operation.
Isn't there a contradiction between the mux-to-pin-to-mux trick and the limitation that PSoC Creator doesn't allow mux-to-mux? It's still a direct connection, after all.
Another thought: Once I've tricked PSoC Creator to set up the analog part as desired, I can disconnect the extra pin from AMuxBus during initialization and reclaim it for other (digital) purposes. I just need to find out which connections I need to break.
There is no benefit of placing a Control Register to switch the hardware AMux. It would burn a control cell and PLDs. If you have a state machine that controls the hardware Amux, then it is a good idea to use it.
Yes, the control register doesn't make much sense in this simple demo case other than to have DSI control for the analog muxing. However, had I given you the target project in which I actually want to use the analog muxing discussed here, I'm pretty sure you would have wished for something simpler because it takes ages to build, and crashes PSoC Creator (on my computer at least) quite often.
As I had feared, placing the intermediate pin to trick PSoC Creator doesn't work in a more complex design. It does create a connection between P10 and P11, but then fails for the rest of the analog routing.
So again: is there any way to manually enter parts of an analog design other than by placing pins in suitable ports and then hoping for the best?
Don't use a P10 pin as the intermediate pin, use another P11 pin, then repurpose that pin for something else.
Also make sure all pins from P10 are used, so Creator is forced to use the switches from the SARMux and Global Analog Mux.
If it is still failing, can you please share the project?
I've attached two bundles, suffixed good and bad, where the bad one has the direct connection between AMuxBus around P11 and P9/10. The good one doesn't have it, and the application can be generated successfully. I can even route it on the PCB, which is why I couldn't follow your suggestion too closely.
It's not a huge problem though:
- the required internal analog connection can be made manually
- not all pins freed by this are actually needed in the final design
- those pins that are needed can be controlled by software (not by DSI)
Please also check if I'm not mistaken by thinking that I can close the AMux splitter switches manually:
- close AMUX_SPLIT_CTL6 ("outer" switches") to create a bus with P9.4, P11.1, P12.3 P12,1 P12.0 to SARMUX. P9.4 and P11.1 are disconnected manually.
- close AMUX_SPLIT_CTL6 ("inner" switches") to create a bus with P9.5, P11.4, P11.3, P12.5 and P12.4 to SARMUX. P 9.5 and P12.5 are discconnected manually.
To my understanding I just had a bit of luck that the individual AMuxBus segments I want to join aren't "crossed" between inner and outer bus on both sides of AMUX_SPLIT_CTL6.
I hope the zip files contain everything you need to generate the application.