I think you cannot remove blocks and their routing during runtime. But you can route the SPI outputs through a MUX, and the switch during runtime between the SPI pins and a control register.
That seems different than the PSoC4 Architecture document TRM_001-85634_0C. Looking at Top Level Architecture drawing (Figure 1-2), it shows the High Speed I/O Matrix with the DSI and GPIOs in parallel. Using that drawing, it seems that even if I completely configure the SCB to be a SPI and P0 and P0 to outputs, I should still be able to use the HSIOM to switch back and forth between GPIO and SPI functions. Setting the HSIOM_PORT_SEL0 register to 0 says "0x0: GPIO: Pin is regular firmware-controlled I/O or connected to dedicated hardware block (Opamp inputs/outputs, SARMUX, SAR reference, LPCOMP inputs) .See the device datasheet for details. Proper configurations of corresponding GPIO_PRT registers are required to use dedicated hardware
The MUX that you mentioned...could that be internal to the chip, or would it need to be an external mux?
I didn't realize you were talking about the SCB SPI block. For that the pins are hard-routed to the physical pins, so you cannot use an internal mux (which you could use with an UDB SPI block).
Yes, you can meddle with the internal routing registers. But doing so relies on that the routing never changes 8which is can during a recompile, or a new Creator version). Its also not really documented.
You could try whether you can make a copy of the SCB SPI component, and can add a mux component between the SCB block and the output pins (I don't think it will work, but it is worth a try).
When in doubt, raise a support case with Cpyress and ask them directly - they should know best. (and please come back and tell the solution here...)
By changing the HSIOM register it should be possible to reclaim the pins as GPIO. I think you may have to change the drive mode of the pins. The MOSI pins may be in high impedance digital( I am expecting your psoc is slave), which you should change to strong drive. The drive mode change API can be found in SPI_1_mosi_s.c file. And while writing values on HSIOM register make sure that you are not changing any bits not corresponding to the pin you need.
I tried making changes to the HSIOM register, and it didn't work. (i.e. masking bits I was interested in, and setting to the correct value as GPIO inputs). The SPI that I am using is a SPI master (uses the SPI data bits to drive neopixels). In a second case I use those pins as inputs. (Read a sector in flash to determine whether it is a SPI master, or GPIO inputs at initialization time, it never switches between these two cases). After exhausting all fo the different possibilities of the HSIOM register, I've decided to try and fix this at a later date by maybe creating a UDB SPI block as suggested by hli. I need a deep FIFO because that provides me with the interrupt latency that I need. When I figure it out, I will post back a solution.
Finally got back to this problem and took the necessary time to figure out an answer. So originally I was using the SCB SPI to update NeoPixels. That solution required 3x the SRAM since the a 1 had to be prepended, and a 0 had to be appended to each bit. To reduce the amount of memory, I changed to using UDB FIFOs (24 bits wide) and a state machine. (Refer to this post for how to do that - Re: UDB shift output not getting correct values )
In my project, I need to enable NeoPixels in some static configurations, and disable them in other static configurations. When NeoPixels are disabled, the SerOut pin (normally attached to the data pin of the NeoPixels) acts as an input. The code automatically sets the pin as an input by default. To over-ride, and switch to use the UDB generated signal, I did the following:
- Change appropriate pin in the HSIOM_SELx register to 0x3 (DSI_DR). In my case: data = *HSIOM_PORT_SEL2; data &= ~0x0000000f; data |= 0x00000003; *HSIOM_PORT_SEL2 = data;
- (Here is the tricky one) Enable the output of the pin by setting the bit in the port DR. In my case: *PORT2_DR |= 0x00000001; In this case, the DR doesn't represent the outputted data, but instead is the OE signal for the pin. (The cy_pin (v2.2) on the schematic is configured with digital output and HW connection boxes checked.)