XU208 questions about port usage

[smiba]

Hi,

I honestly don't have much previous C++ or xcore programming experience so everything is somewhat new to me, my bad if I ask a stupid question :)

Anyways, since the discontinuing of the XHRA-2HPA I've been working with the project to migrate this to a XU208-128-TQ64 and I feel like I'm getting close to having all my changes with the GPIO and I2C moved over.
There are just a few things I'm having some questions about that I can't figure out. Could anyone help me out?

1. In xhra_core.xn port "XS1_PORT_16B" is being used and named as "PORT_MCLK_COUNT". However port 1L, 1M, 1N, 1O and 1P are also being used while these overlap. Is this normal? What is the purpose of PORT_MCLK_COUNT?
2. in addition to the question above, would I be able to use XS1_PORT_4F, which also does overlap with XS1_PORT_16B? I would love having some more I/O Avaliable
3. Probably simple for those who know, but how do I make this device use UAC1 as fallback when a system doesn't support UAC2 (Especially windows XP/7/8 which do not include UAC2 drivers by default). In my XHRA-2HPA PCB setup I had a little switch users could flip to switch between those. Is the UAC code in this project smart enough to regognize when a device can support UAC2, if not, what would be the best way to read out the HIGH/LOW value of a pin on boot and changing UAC modes?
4. Is modifying the HIGH/LOW value of a 1-bit pin like this ok?:

Code: Select all

out port p_gpo_stream_LED = on tile[0] : XS1_PORT_1D;
p_gpo_stream_LED <: 1;

Thank you in advance.

[mon2]

Hello and welcome. Let me try to answer some, not all, of your questions.

1. In xhra_core.xn port "XS1_PORT_16B" is being used and named as "PORT_MCLK_COUNT". However port 1L, 1M, 1N, 1O and 1P are also being used while these overlap. Is this normal? What is the purpose of PORT_MCLK_COUNT?

A> Best to start your review with the spreadsheet for the XCORE-200 series from here:

https://www.xmos.com/published/xcore-20 ... es-portmap

From a quick glance, do not see that port P1L0 is overlapping the 16B port.

But, ports P1M0, P1N0, P1O0, P1P0 - do overlap.

With XMOS processors, the LEFT column of ports has priority over the respective right column(s). Think of this assignment like going to a spa for waxing. You start off with a 16 bit port for your project but then while coding, you decide to make use of a single bit port or smaller port width than the original(perhaps for a clock function which demands that only a single bit port be used). Then, rip (wax) that single bit port away from your original 16 bit port!! This means, that for example, P1M0 in the above spreadsheet, if used, is a single bit port. This will result in the 16 bit you started with missing out on P16B8 on X0 tile. So you will not see any activity during on P16B8 with a R/W to P16B on X0 tile. However, if you R/W to P1M0, then the physical pin X0D36 will be available. Note that X0D36 is noted as "X0" so this pin is on Tile[0].

2. in addition to the question above, would I be able to use XS1_PORT_4F, which also does overlap with XS1_PORT_16B? I would love having some more I/O Avaliable

A> Yes. However, if you plan to use the _16B port then the overlapped regions will be "waxed" away by the _4F ports as the _4F ports have a higher priority :) So you will be missing out of the same region on the _16B port if you access the _16B port as a group. Likewise, _4F is available as you wish but again, in groups of 4 bits at a time. In general, all bits should be in the same direction on that group (ie. input or output at the same time). There are some tricks you can do with the XCORE-200 to work around this but personally have not attempted such ideas.

3. Probably simple for those who know, but how do I make this device use UAC1 as fallback when a system doesn't support UAC2 (Especially windows XP/7/8 which do not include UAC2 drivers by default). In my XHRA-2HPA PCB setup I had a little switch users could flip to switch between those. Is the UAC code in this project smart enough to regognize when a device can support UAC2, if not, what would be the best way to read out the HIGH/LOW value of a pin on boot and changing UAC modes?

A> Not really sure about audio as we are not (yet) audio developers but it should be pretty straight forward to read out a value from a GPIO pin.

Check this document:

https://www.xmos.com/published/xmos-pro ... =B&page=26

See the details on how to input / output data.

4. Is modifying the HIGH/LOW value of a 1-bit pin like this ok?:

out port p_gpo_stream_LED = on tile[0] : XS1_PORT_1D;
p_gpo_stream_LED <: 1;

A> Yes. If your format of code raises an error then try:

Code: Select all

on tile[0]: out port p_gpo_stream_LED = XS1_PORT_1D;

The above will output a value of "1" (High @ 3v3 CMOS levels) onto the single bit port 1D which is mapped to Tile[0].


Here is a good article on working with XMOS processor (the older XS1 series) that you may like (based on the EOL startkit):

https://www.element14.com/community/gro ... e-programs

but the concepts are the same for the newer XCORE-200 series.

[smiba]

Thanks for your detailed response.

Hello and welcome. Let me try to answer some, not all, of your questions.
From a quick glance, do not see that port P1L0 is overlapping the 16B port.

You're totally right, I overlooked it

Check this document:

https://www.xmos.com/published/xmos-pro ... =B&page=26

See the details on how to input / output data.

Thank you, I guess reading out data is just as easy as outputting it :)

A> Yes. However, if you plan to use the _16B port then the overlapped regions will be "waxed" away by the _4F ports as the _4F ports have a higher priority :) So you will be missing out of the same region on the _16B port if you access the _16B port as a group. Likewise, _4F is available as you wish but again, in groups of 4 bits at a time.

Neat. This would make 16B² - 16B⁵ useless due the overlap/waxing. I'm slightly worried what the impact of this will be however:

Code: Select all

//p_for_mclk_count is connected to 16B

/* Attach mclk count port to mclk clock-block (for feedback) */
set_clock_src(clk_audio_mclk2, p_mclk_in2);
set_port_clock(p_for_mclk_count, clk_audio_mclk2);
start_clock(clk_audio_mclk2);

It seems the 16B port is being used as "feedback", but I sadly lack the knowledge of the module_usb_audio code to understand why this is coded in.
Is it possible I damage the functionality by "waxing" away the _4F ports, since this will only leave the first 2 bits? (and 16B⁶, 16B⁷, I guess)
Is just code simply just copying the clk_audio_mclk2 clock and outputting it again to p_for_mclk_count? Will this output it to all bits that are left or only the first bit (since the clock input is also 1-bit?)?

Thanks again for your time and knowledge

[mon2]

Hi. Wish to make sure but have you seen this thread?

http://www.xcore.com/viewtopic.php?t=6375

[smiba]

Hi mon2,

Yeah, that's the project I've downloaded and am importing my changes into. In their code they do not use _4F and just leave it alone as a part of _16B, so I can't be sure that the ports that would overlap with _4F aren't required for operation.
I used the XHRA-2HPA's limited customizability to the max, so I have to move a bunch of things and code over.

So far I would assume its not an issue, judging the code and the purpose of the _16B port. Just would like it have to confirmed by the expert* :)

* As far as you know by judging the code I quoted.

[mon2]

Hi. From the port map posted by fabriceo:

http://www.xcore.com/viewtopic.php?t=6375

The P4F & P4E or if you wish to state, P8C are not physically connected to anything on the original XRHA design so this would imply that the same groups are free for your use. Put another way, the physical pins X0D28..X0D31 are not connected to anything in the design so these are free for your use.

Best to have you post your "final" schematic for a final review before locking down anything on a PCB. Keep it simple and use only the pins and ports XMOS is suggesting so that you can quickly move to the latest firmware when supplied by the factory. Ok to then merge in a few minor tweaks for your secret sauce.

Q: Any special reason that you are using the TQFP128 pin package over the recommended 64 pin TQFP package of the XU208? Do you need the extra ports for your widget?




Hope this helps.

[smiba]

Glad to have your insight on it, thank you. I'm confident I have the code working now.

Q: Any special reason that you are using the TQFP128 pin package over the recommended 64 pin TQFP package of the XU208? Do you need the extra ports for your widget?

I'm using the XU208-128-TQ64 as recommended, using a larger package would only bring in more changes to the PCB. Sorry for not being clear on that in my OP, I just didn't add the full name.
I haven't touched the XHRA-2HPA ports and the GPIO ports are mostly the same as well, so it should work with minimal PCB modification. Thankfully still in prototyping so other then some delays it isn't too inconvenient :)

[taita]

This will result in the 16 bit you started with missing out on P16B8 on X0 tile. So you will not see any activity during on P16B8 with a R/W to P16B on X0 tile.

So, if I perform a READ upon P16B with the afore-mentioned 1b port P1M0 "waxed" away as described, should I still expect a 16-bit value to be returned? And, would bit8 of this 16-bit word always equal 0?

Or, would the returned value be truncated somehow?


Thanks in anticipation.

[mon2]

So, if I perform a READ upon P16B with the aforementioned 1b port P1M0 "waxed" away as described, should I still expect a 16-bit value to be returned?

yes.

And, would bit8 of this 16-bit word always equal 0?

yes, but to be safe, mask off bit 8 after this read.

so:

Code: Select all

read_value=read_value & 0xfeff; // mask off bit8

Just keep in mind that any activity on P1M0 will not be read during this P16B read if you make use of P1M0 as a 1 bit port. This single bit port has been muxed away from the large P16b port.

However, either way, you should test to see if the read results are as expected.