Compile of USB Audio project fails at link stage

[pstnotpd]

OK. I found the bug, it comes from marketing...

Marketing bug. :o)

Guess it's in the same league as the sun to oracle renaming bug in java that reportedly brought down lots of application servers.

[JohnWilson]

I can't *believe* I'm this dumb, but, how does one include XMOS's canned library code into a program? The projects I've done so far have been all homegrown assembly language so this hasn't come up before.

"USED_MODULES = module_usb_shared module_xud" only causes an error (since it hasn't heard of those). I've been through all the menus and can find no way to officially inform xTIMEcomposer (or XDE 11 either) that there's lurking library code. I would assume I want to add a "-llibxud_s.a" to a "ld" command line somewhere, but I can't find that either in the Makefile or in any of the build options menus.

I tried the File => Import function to see if it what it really wants is to copy the USB code in as a subtree of my project, and that made an awful mess (and generated zillions of errors since now it thought the sample code was part of my project so I had two main()s).
Is xSOFTip supposed to replace zipped library kits with some automated package manager? I guess that would be OK, but the only mention of USB I can find in there is a place-holder for a nonexistent host library. There's no sign of the device library that already exists.

And of course -llibxud_s.a (which I'm sure should be libxud_u.a after the renaming, but the updated data sheet still says libxud_s.a) brings me to the next thing: is it just me or is there no XS1-U version of the XUD library. Seriously?!?!?! USB is the whole point of the XS1-U. This code *must* exist internally -- please release it XMOS!

[segher]

Hi John,

If you do not like IDEs you can just use the commandline tools
(xcc, xmake, xrun/xgdb) and cobble together your own trivial
Makefile. Much easier if you are used to it, and certainly less
painful and frustrating. No dead rodents needed!


Segher

[JohnWilson]

That's certainly how I'd prefer to do coding (I already use an external non-mousy editor, yes written in assembly) but I've never really liked gdb for debugging. Still, it would make this kind of thing entirely un-mysterious. I find it very odd that all the examples I've looked at (UART etc.) just talk about which XC functions you can call w/o mentioning how you make Eclipse pull the code in in the first place. Which I suppose means it's obvious to C/Java programmers but not to me...

[segher]

but I've never really liked gdb for debugging.

Neither do I, that's why I use printf()s instead; much more efficient.
To inspect the state of everything when I've made it crash (or loop,
or eat itself, etc.) I use my JTAG tools; I don't know if the XMOS tools
have something similar. Well xrun can do some of it I think?

[JohnWilson]

Dumb suggestion about the original question of building old code on V12 -- maybe it would work to add a .S file which defines UsbTestModeHandler_asm.maxthreads etc. in terms of .maxcores or whatever the new names are? I forget whether that has to go both ways (the idea is that the linker accumulates resource usage, right?) but it seems like it ought to be possible to kludge around it.

I still can't believe XMOS hasn't released a version of the XUD library for the -U, let alone recompiling the existing -L and -G code to work on the new IDE (which you'd think would be an automated part of rolling out new IDE versions?). The -U data sheet gives a few register layouts but it doesn't look like enough to write my own USB driver.

[Ross]

Version 6.1 of the USB Audio codebase should now be available at xmos.com. It is built with the 12 tools and there is support for the "U".

We'll be updating the simpler examples (for U and L) very soon.

[Caleb]

Please post a link to the Version 6.1 of the USB Audio codebase.

Also, please upload photo of the responsible party in stockade.