PORT_MCLK_COUNT port in USB Audio

Technical questions regarding the XTC tools and programming with XMOS.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

X0D40 P8D4 P16B12 RST_X_AD_DA
X0D41 P8D5 P16B13 RST_X_D
X0D42 P8D6 P16B14 LED_BLANK_X_L
X0D43 P8D7 P16B15
Your understanding is correct in that by using the P8D assignment, you are obligated to use P8D7 (P16B15 is lost due to overlap by a higher priority port) in the same 8 bit access.

Can you explain what is the purpose of PORT_MCLK_COUNT? If output, you could just bit stuff P8D7 prior to outputting the 8 bit value to the port pins.

Another idea is to not use the P8D definition but rather

P1M0 (instead of P8D0)
P1N0 (instead of P8D1)
P1O0 (instead of P8D2)
P1P0 (instead of P8D3)

then review your code that would have made use of P8D0..P8D3 and access those port pins using the single bit mode as defined above.

This approach will then allow you to use P16B12..15 as you wish. The definitions are simple and mostly static GPIO (actually output only) functions so very easy to manipulate using the P16B12..15 access.

That is, build up your bit map before forcing this map to the port pins for (RST_X_AD_DA, RST_X_D, LED_BLANK_X_L and now also PORT_MCLK_COUNT).

Not sure if this solution is any better than leaving as P8D7 and stuffing the bit as required.

Are there any other free pins in your design that you can use? For clock i/o, best to stick to single bit port pin mappings. Double-check the XMOS docs but pretty sure that is required.


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

XCORE-200 have some exceptions like the one you just noted over the XS1 series of the CPUs.

Here, on Tile 1 - the yellow background color denotes that USB can be used. If USB is enabled on this Tile then ALL the ports with the YELLOW background are NOT available for your use. These ports will be used by the USB IP to enable this connectivity.

However, moving to the LEFT, the background is WHITE and these ports ARE available for your use. In short, internal multiplexers use the YELLOW background ports to make the USB function but in return, the smaller width ports are available physically on your CPU.

To rephrase, you can have your USB PHY enabled and also you will be able to use the port pins that overlap (ie. but only P4C & P4D in this specific case - keep in mind the Tile # when coding else you will be shooting "blanks"). We have validated this when XMOS first released the XCORE-200 kits but pulsing the smaller ports and they worked fine for our LED blinky code yet we still enabled the Ethernet or USB PHY.

So if you have WHITE background on the port pins - they ARE available for your use even if you enable the USB or Ethernet PHY, etc. Non-white background = NOT available if that function is enabled by your IP.

Same rules apply for the other tile numbers as shown in the XCORE-200 port spread sheet.

Hope this is clear.
genap
Experienced Member
Posts: 99
Joined: Sat Aug 31, 2013 11:23 pm

Post by genap »

mon2 wrote: Thu Aug 01, 2019 7:50 pm Can you explain what is the purpose of PORT_MCLK_COUNT? If output, you could just bit stuff P8D7 prior to outputting the 8 bit value to the port pins.

Another idea is to not use the P8D definition but rather

P1M0 (instead of P8D0)
P1N0 (instead of P8D1)
P1O0 (instead of P8D2)
P1P0 (instead of P8D3)

then review your code that would have made use of P8D0..P8D3 and access those port pins using the single bit mode as defined above.

Are there any other free pins in your design that you can use? For clock i/o, best to stick to single bit port pin mappings. Double-check the XMOS docs but pretty sure that is required.
I don't know how PORT_MCLK_COUNT is used and I don't access it. There is no XMOS documentation on it's use.
Unfortunately, I don't have 1-bit ports available - all of them are used by audio signals and clocks.
I also need to use practically all available ports for interfacing (SPI, chip selects, UARTs, buttons, resets for external components etc.).

By this reason I have another question:
According to the port mapping for xCore-2000 port P8B (yellow) can't be used to interface external signals.
In a reference design it's used as USB port:

Code: Select all

<Port Location="XS1_PORT_8B"  Name="PORT_USB_RXD"/>
The port P8B is also overlapped with 4-bit ports P4C and P4D, which can be addressed.
So does this case follow the same priority rule for overlapping ports -
meaning that if both ports P4C and P4D are assigned, port P8B can't be used as assigned above (PORT_USB_RXD) ?
genap
Experienced Member
Posts: 99
Joined: Sat Aug 31, 2013 11:23 pm

Post by genap »

mon2 wrote: Thu Aug 01, 2019 11:03 pm
To rephrase, you can have your USB PHY enabled and also you will be able to use the port pins that overlap (ie. but only P4C & P4D in this specific case - keep in mind the Tile # when coding else you will be shooting "blanks"). We have validated this when XMOS first released the XCORE-200 kits but pulsing the smaller ports and they worked fine for our LED blinky code yet we still enabled the Ethernet or USB PHY.

So if you have WHITE background on the port pins - they ARE available for your use even if you enable the USB or Ethernet PHY, etc. Non-white background = NOT available if that function is enabled by your IP.
I believe you just answered my question -
I can use port P8B as PORT_USE_RXD, and at the same time use ports P4C and P4D for interfacing?
That is great news and it solves my problems by using port P4A in parallel with P8A and ports P4C, P4D in parallel with P8B.

Thank you very much for helping me.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am

Post by mon2 »

Small typo:

Code: Select all

I can use port P8B as PORT_USE_RXD, and at the same time use ports P4C and P4D for interfacing?
should read as:

Code: Select all

I can use port P8B as PORT_USB_RXD, and at the same time use ports P4C and P4D for interfacing?
Correct. P8B will be assigned for the USB internal function and the P4C and P4D are available for your i/o interfacing.

Glad you can move forward. When ready, do post the relevant parts of the schematic for a quick review to avoid any known errors early on.

Try to use a 4L PCB for your layout and review the documents from XMOS and internet on USB layout practices with impedance control. All good shops can assist with this. Post back if you need some good PCB shops in Asia who are fine to handle small volumes.
genap
Experienced Member
Posts: 99
Joined: Sat Aug 31, 2013 11:23 pm

Post by genap »

Thank you again.

I''ll post the schematic in a few days.
We have a HW engineer, and the board is actually ready. I will examine it before posting.
genap
Experienced Member
Posts: 99
Joined: Sat Aug 31, 2013 11:23 pm

Post by genap »

I thought my troubles with ports assignment are over.
Unfortunately I've stumbled upon another roadblock.

Below is part of a port map for xCore200

Code: Select all

P4A0	P8A0
P4A1	P8A1	
P4B0	P8A2		IO2 QFlash
P4B1	P8A3		IO1 QFlash
P4B2	P8A4		IO2 QFlash
P4B3	P8A5		IO3 QFlash
P4A2	P8A6		
P4A3	P8A7	

	P8D4	P16B12	user IO
	P8D5	P16B13	user IO
	P8D6	P16B14	user IO
	P8D7	P16B15	user IO
Port P8A is reserved for PORT_USB_TXD, port P4A is available.
According to our conversation I was going to move IOs from port P8D (P8D4..P8D7) to the port P4A in order to use P16B (P16B12..P16B15) for PORT_MCLK_COUNT.
Unfortunately, I've found out that port P4A does not have assigned pins on XUF208-256-TQ64 :(.
Replacing TQ64 by TQ128 is impossible at this stage of a project.

So I have 2 questions:
1. What is the size of PORT_USB_TXD? Should it be 8 bit?
If not, I can probably use P4A as PORT_MCLK_COUNT (leaving P8D for IOs) and P8A (P8A2..P8A5) as PORT_USB_TXD.
2. If size of the PORT_USB_TXD is mandatory 8 bit, then is it still possible use P4A as PORT_MCLK_COUNT (no external IOs).
Can these 2 internal ports (P4A and P8A) work in parallel?