USB Audio EVM

Technical questions regarding the XTC tools and programming with XMOS.
Lorien
Active Member
Posts: 33
Joined: Wed May 19, 2010 9:07 am

USB Audio EVM

Post by Lorien »

Hi there,
I'm Lucian and I'm a newbie on this forum for about 5 minutes or so :) and I've allready a couple of unanswered questions for you guys. So, let's keep it simple:
* I'm interesed in buying two USB audio development kits. If it's from XMOS or Digikey, doesn't matter now. Reason: bit-perfect, asynch audio data over USB for my "sensitive ears". I guess I've said it all! BUT now comes the big problem: drivers and supporting XC/C-language firmware (I'm referring to source code, not those bin files because I don't intend to start doing reverse engineering nor reinvent the whell). So, if someone know such sensitive details and wants to share its wisdom with me (and perhaps with all guys who - accidentally - reads this message), it's welcomed to do so! Main targets are source code written in high-level language... doesn't matter which one - I can adapt AND continuously updated drivers for XS1-L1 chip. If I have to signs some NDAs or pay a license fee.. it's ok.
Otherwise, some advices regarding this matter would be more than good.
For now, I can only thank you for spending your time reading my post,
Lucian


User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

Start with requesting the source-code from XMOS.
You will probably have to sign something, but you will not need to pay anything to receive it.
If you receive the code - you can order the cards.

A thing to consider prior spending your money on the cards is that it has one common ground-plane that shares both dual USB ground and the CODEC analog ground including line-in ground. Any external connection that introduces any ground loops will heavily effect the audio quality to levels far below "sensitive ears".

PS. I think Ali at XMOS has done a good work with the ver. 1.50 of the source code. It's based on different modules so it's easy to start working with it.
Very easy to add some DSP code in the Audio path for an example. DS
Probably not the most confused programmer anymore on the XCORE forum.
Lorien
Active Member
Posts: 33
Joined: Wed May 19, 2010 9:07 am

Post by Lorien »

Hi lilltroll,
first of all I want to thank you for your kindness to answer to all my questions!
Start with requesting the source-code from XMOS
I've allready done that using Contact form on Xmos site, choosing (from seven queue options) the "Apps - Technical question on how to integrate software defined silicon products into your applications"... or something like that.
I don't know if it was the appropiate one but if not, I hope they will not just ignore my message :)
If you receive the code - you can order the cards.
That IF in front of your statement scares me a little bit. Judging from my perspective (since I'm not TI nor National Semi), it's possible not to receive the source code?
A thing to consider prior spending your money on the cards is that it has one common ground-plane that shares both dual USB ground and the CODEC analog ground including line-in ground. Any external connection that introduces any ground loops will heavily effect the audio quality to levels far below "sensitive ears".
Thank you again for telling me this before aquiring those boards! For now, what I hardly want is to make that chip working and after that, designing a proper PCB will be a different story. In the end, I don't have any intention of using XMOS development boards in final product... just for development :)
I've also opened a ticket and I'm waiting for a response.
--------------
I guess source codes are protected by a NDA so it's impossible to have those files without contacting XMOS, isn't it? Please don't take me wrong, just that I've a dead time who's pressing me hardly.
Kind regards,
Lucian

P.S. Is here anyone who allready have this source code and drivers for these boards and app?... just to know if there's hope for me to also have them from XMOS :roll:
ashleyb
Member
Posts: 14
Joined: Sun Dec 20, 2009 1:08 am

Post by ashleyb »

Lorien wrote: P.S. Is here anyone who allready have this source code and drivers for these boards and app?... just to know if there's hope for me to also have them from XMOS :roll:
Hi,
I personally have the source and drivers. The XMOS people were very helpful and it only took a few days (negotiating the time difference between England and Australia). Once they had the signed software licence agreement I had the code in a matter of minutes.

They had no problem with setting up a software licence with me personally rather than a company.

Ashley
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

If you check out this group http://www.xcore.com/groups/usb-audio-20-group
To be straight; as far I know everybody that wanted the source finally got it, but some of the users started complaining topics on this forum after they thought they waited too long for a response from XMOS regarding the source.

XMOS introduced a new system that handles licenses some months ago - so I can just login at xmos.com and access the newest release of all licensed code that I have access to anytime.

Since that was introduced, I had received very few complains from users (since I'm the supervisor of the group - people tends to ask me about it)

Another good thing to know is that the L1-128 chip has a lot of free pins - but when using USB ULPI many pins are used internally (My guess is that they are used for 32-bit parallel data conversion)
Check out 2.10 in http://www.xmos.com/system/files/xs1-l-des-check.pdf

That means that the USB Audio EVM card is almost maxed out regarding free available ports.
It is possible to free an XLINK to another L-chip with a different PCB layout.
If you move the buttons to the 32bit's port it might be possible to free 2 1-port pins for I2C communication to the CODEC - which isn't supported on the ref. design.
So if you know that you will build something "larger" that just a USB thing with 2 buttons - I would advice you to go for the L2 chip.

Today XMOS doesn't sell any L2 boards - but I would be very surprised if we don't see L2 boards with Audio available from XMOS in the near future. The L1 board is good training anyway - and to find out if you need more resources or not.

(Myself I just moved from the Audio ref. board to the XAI board, that gives me much more possibilities to explore possible solutions)

A very good thing with the XMOS solution is that the data buffer for the async. USB data is in the XMOS software.
Increasing the channel count or fs/bit-depth is limited by the available RAM of any ASIC designed USB to I2C chip solution. With XMOS you can probably plan how much on chip RAM that will be needed for buffers deepening on how many channels you will use. (USB 2.0 Audio burst out data 8000 times per second, and you must cache all data from each burst)

Please feel free to improve my knowledge if something written here is incorrect.
Probably not the most confused programmer anymore on the XCORE forum.
Lorien
Active Member
Posts: 33
Joined: Wed May 19, 2010 9:07 am

Post by Lorien »

Hello lilltroll,
after some time spent on getting those source codes, I finally have them so, I can only confirm what you've said earlier:
To be straight; as far I know everybody that wanted the source finally got it, but some of the users started complaining topics on this forum after they thought they waited too long for a response from XMOS regarding the source.
Now, next thing to do is the hardware part... perhaps a harder task for me than just aquiring licensed source codes :) because of lack of useful informations regarding XMOS processors. Don't get me wrong, I'm a guy who starts with old PIC12C/F microcontrollers and finishing with PIC18.. when I've concluded that those chips have too many HW bugs and, as some friend of mine told me a while ago: PICs are good only for flashing LEDs and read buttons :) still, what I really like about Microchip is that they put all the information related to a specific uC family into one big and, I might say 'heavy' .pdf file. I really don't care too much about the esthetics, just to have all the informations I need about memory, ports, signals, registers, etc. into one place. Still, I've noticed that L1 instructions can be found in one separate .pdf file - I didn't search for the rest of uP. Anyway, I'm sure that XMOS can make it happen... perhaps they need additional time... it's OK by me!

Back to XMOS chips! My intention is to make a custom board and adapt the source code to it. I also have in mind to switch to L2 BUT my real problem is lack of knowledge regarding XMOS architecture. That's the reason why I'll stick with L1 and USB Audio ref design built around it... to gather some experience.
I've noticed that you have knowledge about XMOS chips so I might have few short questions for you:
* It's realy hard to port these USB source codes to L2 chips? I'm allmost sure that it would take more than a "copy and paste" procedure... though, on the other side, adapting/redesigning the code from scratch isn't an alternative for me either.
* Could you give me an avice as a starting point in searching/reading L1 documentation and XC implementation so I could reduce the learning curve and required amount of time reserved for this app?

Thank you in advance,
Lucian
User avatar
lilltroll
XCore Expert
Posts: 956
Joined: Fri Dec 11, 2009 3:53 am
Location: Sweden, Eskilstuna

Post by lilltroll »

* It's realy hard to port these USB source codes to L2 chips? I'm allmost sure that it would take more than a "copy and paste" procedure... though, on the other side, adapting/redesigning the code from scratch isn't an alternative for me either.

The L2 is two pieces of L1 chip in the same IC. That software emigration may be rather easily done.
As long you do not split the most time-critical channel transfers over the two different cores I do not think you will have timing problems either. (The latency may be longer between Xcores compared to channel com. between threads on the same Core)

The most easy but a very stupid way would be to just change to existing chip to the L2 in the PCB design, and run everything on one core as it is done today.

Documentation: Ohh I really do not know. In some of the docs there is some annoying errors - and never trust the documentation regarding the registers in the ASM manual or the instruction manual. They are often mixed up. Try to understand some existing USB Audio2.0 code and search answers in the docs where you cannot understand the code.
Probably not the most confused programmer anymore on the XCORE forum.
Lorien
Active Member
Posts: 33
Joined: Wed May 19, 2010 9:07 am

Post by Lorien »

Sorry for this delay!
I have one job which takes almost all the time... so no free day offs for playing with Xmos processors.
@Lilltroll: I've noticed your vast experience with Xmos. I wish could have your experience in this matter :) It could help me a lot. I've tried to read and gather as much informations as I can about Xmos proceesors... but it's spread on different documents! Huh! hard to understand but not impossible :)
I have one simple question to everyone:
In the past days, I've working to design one simple PCB based on USB audio reference design. No firmware changes only HW "upgrades". My very first and obvious intention was to change the stock oscillators used by above-mentioned application with Crystal based oscillators, namely: 22.5792 Mhz (to allow 176 fs) and 24.576 Mhz.
Consulting various forums and posts, I've come to conclusion that, among other valid (?whatever it means valid!) options, NDK's NZ2520SD parts are (from theory) the best I can have for this purpose. After over one week of emails and questions... I came to conclusion that my chances to aquire these parts in EU zone are minimal to zero. So, here is my question: There si anyone who knows how to aquire these crystal - based oscillators? Or: there are other alternatives equivalent to this one (regarding phase noise / voltage supply and perhaps price). Please note that the package dimensions aren't important!
Thank you for your time reading my post,
Lucian