Migrating from XHRA to XU208

Sub forums for various specialist XMOS applications. e.g. USB audio, motor control and robotics.
dm1
New User
Posts: 2
Joined: Mon Oct 28, 2019 3:58 pm

Re: Migrating from XHRA to XU208

Postby dm1 » Mon Oct 28, 2019 4:08 pm

Hi,

I have made breakout board for XU216-512-TQ128 and i wanted to use it as basic USB->I2S converter. Now its time to port software, but I must confess, I am newbie in regards to MCU programming and i have real trouble with that. Could someone tell me how to change XU208-XHRA software to run on XU216?

I appreciate all help :)
alexjaw
Active Member
Posts: 34
Joined: Wed Jan 24, 2018 9:13 am

Postby alexjaw » Mon Oct 28, 2019 5:31 pm

Attached project is an usb2i2s bridge working on explorerkit XE216-512-TQ128. I have used an01027 as a guide to port from app_usb_aud_mc to explorerkit. You will have to adapt the code so that you can switch between 44.1k and 48k sample rates. That's goes into src/audiohw.xc. I have tested it with Si5340 and adau1467 dev boards.

i2s signals are on (see XCORE-200_EXPLORER.xn file for port details)
x0d23 bclk
x0d22 lrclk
x0d13 mclk audio
x0d36..39 i2s data
x1d35 mclk audio

Hope that it helps you a little bit.
workspace-xmos14.2.4_.zip
You do not have the required permissions to view the files attached to this post.
dm1
New User
Posts: 2
Joined: Mon Oct 28, 2019 3:58 pm

Postby dm1 » Mon Oct 28, 2019 5:59 pm

Hi, thank you very much!

Do I need to provide MCLK for both pins?
alexjaw
Active Member
Posts: 34
Joined: Wed Jan 24, 2018 9:13 am

Postby alexjaw » Tue Oct 29, 2019 7:54 am

Yes. Each tile needs its own mclk audio.
syeric
Member
Posts: 10
Joined: Wed Jan 08, 2020 8:34 am

Postby syeric » Fri Jan 17, 2020 3:42 am

Hello!
I'm trying to port the old XHRA design to XU208 hardware. I followed all the steps but I get a build error when building the project:

Code: Select all

xmake CONFIG=Default all 
Checking build modules
Using build modules: module_dfu module_i2c_shared module_i2c_single_port module_spdif_tx module_usb_audio module_usb_device module_usb_shared module_xud module_locks
Creating app_usb_aud_xu208_xhra.xe
cd .build && xcc  -DFLASH_MAX_UPGRADE_SIZE=64*1024*3 -fcomment-asm -Xmapper --map -Xmapper MAPFILE -O3 -report -fsubword-select -save-temps -g -DXUD_SERIES_SUPPORT=4 -march=xs2a -DUSB_TILE=tile[0] -DQUAD_SPI_FLASH=1 -lquadflash   -L "E:\XMOS\sw_usb_audio-[sw]_6.15.2\sc_xud\module_xud\lib" -lxud_x200 @_obj.rsp "..\.\src\core\xhra_xcore.xn"    -o "..\bin\\app_usb_aud_xu208_xhra.xe"
xcc1: terminated due to internal unrecoverable error
For bug reporting instructions, please see:
http://www.xmos.com/support
xmap: Error: Failed to compile multi-tile main.
xmake[1]: *** [bin//app_usb_aud_xu208_xhra.xe] Error 1
xmake: *** [bin//app_usb_aud_xu208_xhra.xe] Error 2
Anybody got an idea on how to fix this?
syeric
Member
Posts: 10
Joined: Wed Jan 08, 2020 8:34 am

Postby syeric » Sat Jan 18, 2020 2:50 am

syeric wrote:
Fri Jan 17, 2020 3:42 am
Hello!
I'm trying to port the old XHRA design to XU208 hardware. I followed all the steps but I get a build error when building the project:

Code: Select all

xmake CONFIG=Default all 
Checking build modules
Using build modules: module_dfu module_i2c_shared module_i2c_single_port module_spdif_tx module_usb_audio module_usb_device module_usb_shared module_xud module_locks
Creating app_usb_aud_xu208_xhra.xe
cd .build && xcc  -DFLASH_MAX_UPGRADE_SIZE=64*1024*3 -fcomment-asm -Xmapper --map -Xmapper MAPFILE -O3 -report -fsubword-select -save-temps -g -DXUD_SERIES_SUPPORT=4 -march=xs2a -DUSB_TILE=tile[0] -DQUAD_SPI_FLASH=1 -lquadflash   -L "E:\XMOS\sw_usb_audio-[sw]_6.15.2\sc_xud\module_xud\lib" -lxud_x200 @_obj.rsp "..\.\src\core\xhra_xcore.xn"    -o "..\bin\\app_usb_aud_xu208_xhra.xe"
xcc1: terminated due to internal unrecoverable error
For bug reporting instructions, please see:
http://www.xmos.com/support
xmap: Error: Failed to compile multi-tile main.
xmake[1]: *** [bin//app_usb_aud_xu208_xhra.xe] Error 1
xmake: *** [bin//app_usb_aud_xu208_xhra.xe] Error 2
Anybody got an idea on how to fix this?
Hi, all. This problem is solved. I rebuild this project on windows7 and then success with some warnings... So, it is just a bug that xtimecomposer maybe not stable in windows10...
I used oracle jre8u212 and xtimecomposer 14.3.3.
rlim
Member++
Posts: 16
Joined: Wed May 12, 2010 10:00 pm

Postby rlim » Sun Feb 02, 2020 1:09 am

Can someone explain what the following code means:
/* Put DAC in reset. All LEDs off */
set_gpio((1<<P_GPO_DAC_RST_N), 0);

I think the value 0 goes to P_GPO_DAC_RST_N, and something is shifter to the left?

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

Postby mon2 » Mon Feb 03, 2020 5:12 pm

Can someone explain what the following code means:
/* Put DAC in reset. All LEDs off */
set_gpio((1<<P_GPO_DAC_RST_N), 0);

I think the value 0 goes to P_GPO_DAC_RST_N, and something is shifter to the left?
@rlim, you are very close on your understanding.

In your project, search for the definition (define) for the label P_GPO_DAC_RST_N. Note this value.

Let us assume it is a value of 3, the following line of code will:

Code: Select all

/* Put DAC in reset. All LEDs off */
set_gpio((1<<P_GPO_DAC_RST_N), 0);
become:

Code: Select all

/* Put DAC in reset. All LEDs off */
set_gpio((1<<3), 0);

Which means take the bit value of "1" = "0000 0001" and shift it to the LEFT by 3 bits so this will result in:

Code: Select all

/* Put DAC in reset. All LEDs off */
set_gpio((000100b, 0);
or simplifying to:

Code: Select all

/* Put DAC in reset. All LEDs off */
set_gpio(4, 0);
meaning to set_gpio bit 3 (since we start with bit position 0 in the digital world) to a value of "0" = make that GPIO pin LOW. Used to park the target device (DAC) into a RESET state. If you review the schematic, the #RESET pin of the DAC should be connected to the GPIO pin this code is attempting to toggle. Again, just assuming that the P_GPO_DAC_RST_N is defined to be 3 - please do confirm the actual value.
rlim
Member++
Posts: 16
Joined: Wed May 12, 2010 10:00 pm

Postby rlim » Tue Feb 04, 2020 5:31 am

Thanks mon2. I do appreciate your time. P_GPO_DAC_RST_N is indeed defined as 3, and it's tied to the MSB of P4D. Could it be that you are one bit off, meaning shifting 1 to the left by 3 results in 1000b? I am just going by inference, because P4D0(the lsb) is P_GPO_LED_A, defined as 0. And if we want to set that high, then it would be set_gpio((1<<0,1). Am I making sense?

Who is online

Users browsing this forum: No registered users and 0 guests