Hi All,
I'm new to the XMOS community and would appreciate any guidance here. I'm trying to read xScope values in the audio reference design for the U16 slicekit, but have no idea where to put the xscope_probe_data() function. I'm not sure which .xc file to place the function, so if anyone could help show me the way to get real time scoping working on the reference design, I'd greatly appreciate it.
Pat
xScope in Audio 2.0 Reference Design
-
- Junior Member
- Posts: 4
- Joined: Thu Jul 10, 2014 3:27 am
-
- Member
- Posts: 13
- Joined: Thu Jul 03, 2014 3:48 pm
Hello!
Folknology helped out here:
https://www.xcore.com/forum/viewtopic.p ... it=#p17839
and general documentation (including xscope):
https://www.xmos.com/support/documentation?secure=1
Folknology helped out here:
https://www.xcore.com/forum/viewtopic.p ... it=#p17839
and general documentation (including xscope):
https://www.xmos.com/support/documentation?secure=1
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
That would depend on what it is you want to monitor.. Some parts of the reference design are best left alone (unless you know XMOS and the UAC2 spec inside-out) but if you wanted to look at stereo audio output samples then you could put the probe calls here in audio.xc, at around line 450, something like:I'm not sure which .xc file to place the function
Code: Select all
#pragma loop unroll
for(int i = 0; i < NUM_USB_CHAN_OUT; i++)
{
int tmp = inuint(c_out);
samplesOut[i] = tmp;
}
}
xscope_int(LEFT, samplesOut[0]);
xscope_int(RIGHT, samplesOut[1]);
-
- Junior Member
- Posts: 4
- Joined: Thu Jul 10, 2014 3:27 am
Thank you both for your replies, I'll check that out now.
Yes I wanted to analyze the audio inputs/outputs, so thats a good place to start. I was wondering (since it's sort of on the same topic) if one of you could answer another question I have.
You're right in saying it's best not to alter any of the code too much, as it was created to work extremely well as I've found out through testing. However, I'm looking to add some SPI functionality to the audio USB interface code in order to read inputs and write outputs (to their respective Shift Registers: hc165 and hc595), although the code will not be manipulating the interface, moreso running parallel to it. I used the app_spi_master_demo code as a starting point and have successfully modified it to control the registers. However, the complexity of the usb audio interface code is well above the app_spi_master_demo code and apparently my knowledge (I'm very new to XMOS). For example, I've been trying to work on the main function of the audio interface's main.xc code, but it's comprised of only chan initializers and #ifdef / #endif statements. I'm sure I could figure out the code some more if I spent several days on it, but I was wondering if one of you could point out some potentially easy things.
First off, I'm using a U16 SliceKit, so I have more than enough ports to use. Currently I'm using the same SCLK and MISO / MOSI lines that go to the flash IC, and using two free 1-bit ports (1G and the other TBD) as the Slave Selects. As I said, the SPI code can be run parallel without having any interaction with the audio usb interface. So where would be the best place to insert the code found in app_spi_master_demo (a couple of void functions and then the main function which calls on the voids), since the main.xc in the app_usb_aud_skc program doesn't seem to be formatted the same? I've included the module_spi_master in my Makefile for the audio app, but am unsure of where to go from here. Thanks in advance for any help!
Pat
Yes I wanted to analyze the audio inputs/outputs, so thats a good place to start. I was wondering (since it's sort of on the same topic) if one of you could answer another question I have.
You're right in saying it's best not to alter any of the code too much, as it was created to work extremely well as I've found out through testing. However, I'm looking to add some SPI functionality to the audio USB interface code in order to read inputs and write outputs (to their respective Shift Registers: hc165 and hc595), although the code will not be manipulating the interface, moreso running parallel to it. I used the app_spi_master_demo code as a starting point and have successfully modified it to control the registers. However, the complexity of the usb audio interface code is well above the app_spi_master_demo code and apparently my knowledge (I'm very new to XMOS). For example, I've been trying to work on the main function of the audio interface's main.xc code, but it's comprised of only chan initializers and #ifdef / #endif statements. I'm sure I could figure out the code some more if I spent several days on it, but I was wondering if one of you could point out some potentially easy things.
First off, I'm using a U16 SliceKit, so I have more than enough ports to use. Currently I'm using the same SCLK and MISO / MOSI lines that go to the flash IC, and using two free 1-bit ports (1G and the other TBD) as the Slave Selects. As I said, the SPI code can be run parallel without having any interaction with the audio usb interface. So where would be the best place to insert the code found in app_spi_master_demo (a couple of void functions and then the main function which calls on the voids), since the main.xc in the app_usb_aud_skc program doesn't seem to be formatted the same? I've included the module_spi_master in my Makefile for the audio app, but am unsure of where to go from here. Thanks in advance for any help!
Pat
-
- XCore Legend
- Posts: 1126
- Joined: Thu May 27, 2010 10:08 am
Glad to hear it - a lot of man years have gone into it and hundreds of products use the codebase.You're right in saying it's best not to alter any of the code too much, as it was created to work extremely well as I've found out through testing.
By far and away the best idea is to add a new logical core. Cores run independently and have their own register set, so do not interfere with each other (the compiler ensures you don't do anything non threadsafe)However, I'm looking to add some SPI functionality to the audio USB interface code in order to read inputs and write outputs (to their respective Shift Registers: hc165 and hc595), although the code will not be manipulating the interface, moreso running parallel to it. I used the app_spi_master_demo code as a starting point and have successfully modified it to control the registers. However, the complexity of the usb audio interface code is well above the app_spi_master_demo code and apparently my knowledge (I'm very new to XMOS). For example, I've been trying to work on the main function of the audio interface's main.xc code, but it's comprised of only chan initializers and #ifdef / #endif statements. I'm sure I could figure out the code some more if I spent several days on it, but I was wondering if one of you could point out some potentially easy things.
Add another task in main inside the par. That will create a new hardware thread (aka logical core). This doc is a great place to start and explains the basics:First off, I'm using a U16 SliceKit, so I have more than enough ports to use. Currently I'm using the same SCLK and MISO / MOSI lines that go to the flash IC, and using two free 1-bit ports (1G and the other TBD) as the Slave Selects. As I said, the SPI code can be run parallel without having any interaction with the audio usb interface. So where would be the best place to insert the code found in app_spi_master_demo (a couple of void functions and then the main function which calls on the voids), since the main.xc in the app_usb_aud_skc program doesn't seem to be formatted the same? I've included the module_spi_master in my Makefile for the audio app, but am unsure of where to go from here.
https://www.xmos.com/node/17653?page=23
The only thing to watch out for with the USB audio ref design, is to only use 6 core maximum on tile 0 (this is due to USB needing 80 MIPS - 500/6 = 83, so 6 max). You can use the full 8 on tile 1.
When you compile - look at the report to see how many cores you have. If reporting is not turned on, add -report to the command line.
Eg. this uses 6:
Code: Select all
Constraint check for "tile[0]" (node "0", tile 0):
Cores available: 8, used: 6 . OKAY
Timers available: 10, used: 9 . OKAY
Chanends available: 32, used: 19 . OKAY
Memory available: 65536, used: 31540 . OKAY
(Stack: 11768, Code: 15536, Data: 4236)
Constraints checks PASSED.
Build Complete
-
- Active Member
- Posts: 35
- Joined: Wed Jan 24, 2018 9:13 am
Testing xscope and the code above:
Added config.xscope to app_usb_aud_xk_216_mc:
When app is started LRCLK freq starts at 44.1 kHz (checking with oscilloscope), but goes low after approx 1s. Realtime xSCOPE window remains in the disconnected state. App is still running (according to the console window in xtimecomposer), but it's not possible to play anything through usb.
In order to find what might cause the problem, I replaced with
With that change app and xSCOPE connects and app can play usb audio.
Is there some issue with inuint(c_out) or have I missed something?
Code: Select all
// Placed inside deliver(chanend c_out, ...) in audio.xc
#pragma loop unroll
for(int i = 0; i < NUM_USB_CHAN_OUT; i++)
{
//int tmp = 0;
int tmp = inuint(c_out); //problem?!
samplesOut[i] = tmp;
}
xscope_int(LEFT, samplesOut[0]);
xscope_int(RIGHT, samplesOut[1]);
Code: Select all
<xSCOPEconfig ioMode="none" enabled="true">
<Probe name="left" type="CONTINUOUS" datatype="UINT" units="Value" enabled="true"/>
<Probe name="right" type="CONTINUOUS" datatype="UINT" units="Value" enabled="true"/>
</xSCOPEconfig>
In order to find what might cause the problem, I replaced
Code: Select all
int tmp = inuint(c_out);
Code: Select all
int tmp = 0;
Is there some issue with inuint(c_out) or have I missed something?
-
- Active Member
- Posts: 35
- Joined: Wed Jan 24, 2018 9:13 am
Aah.
The "#pragma... code is existing code in audio.xs. The only thing that needs to be added are the xscope_int functions. Nice!
The "#pragma... code is existing code in audio.xs. The only thing that needs to be added are the xscope_int functions. Nice!