Custom i2s in with simultaneous S/PDIF & USB out

[infiniteimprobability]

Hi,
I started writing this to say that, yes I2C transactions with no slave to ACK them will be an issue, although what you reported previously means the chip is out of reset, code loaded and running and USB is working/enumerated, which is 99% of the way there.

However, I just noticed from your last post (which arrived as I was answering) that you have it all working. Good stuff!

What was happening was this: By default, I2C master is set to 100KHz with 2000 retries on NACK (see i2c_conf.h).

This will mean that EP0 control transactions will take at least 3 x 9 x 2000 / 100e3 = 540ms per 8bit register write. You will quickly exceed the NAKing time for USB control transactions and the host will get upset because the device is effectively frozen for a while.

When doing the port of the USB reference design, of course you need to modify audio_hw.xc to match your hardware setup. Mostly this is I/O toggling and I2C writes to configure the clock source and DAC/ADC as needed. In your case, it was deleting rather than writing new HW setup.

Most basic ports of the reference design can be done just by changing customdefines.h and audio_hw.xc, and possibly the Makefile to remove redundant configs. It is very rare that you have to delve into any module other than sw_usb_audio, unless you are doing advanced stuff.

When things gets stuck, it's time to fire up the debugger. Either use xTimecomposer or GDB command line to find out where stuff is getting stuck. Lots of info available on this including https://www.xmos.com/download/private/U ... 8590A).pdf

Anyhow, glad it's all working! When do we get to see the final product!?

[yes2i2s]

Well we're currently having a hard time finding a good 3d designer for the housing as we lost our existing one. once that's done we'll be close to launching minus a few tweaks on the PCB. Pretty pleased so far with how the XMOS rig has behaved and a relatively complex reference design fired up no issue.

I think we would do well to use a simpler xmos design now though as we've altered the product and at present only need it to behave as a 2 channel USB DAC. Which for the XE216-512-TQ128 is a waste of silicon and power supplies.

What would you recommend? This? https://www.xmos.com/support/boards?product=18340

[yes2i2s]

Will it work out much cheaper in parts? As I'd need to justify the re-design time :)

[yes2i2s]

we've currently got the XE216-512 and it's power supplies and start up timers with SPDIF out and I2S to our DAC.

So we'd only be saving on silicon and possibly a power supply? Wondering if it's worth doing when this appears to work fine? As in I've done the code tweaks and all that jazz and it works fine. So prob some hours to switch to the XHRA-2HPA-TQ64

[infiniteimprobability]

What would you recommend? This? https://www.xmos.com/support/boards?product=18340

Yes - that's a good ref design. The big difference though is that this is based on the fixed function XHRA chips rather than the general xCORE200 programmable devices. These are tweakable (to allow sample rates, different audio HW etc.) but you can't compile/add in any of your own code.

The board uses an ESS 9018 and the xmos device is configured to be I2S slave. It has SPDIF out.

If that all works for you then all good. If you need more flexibility, a XU208-256-TQ64-C10 can be configured to be pin compatible with the XHRA chip.

[infiniteimprobability]

So we'd only be saving on silicon and possibly a power supply? Wondering if it's worth doing when this appears to work fine? As in I've done the code tweaks and all that jazz and it works fine. So prob some hours to switch to the XHRA-2HPA-TQ64

I guess that comes down to the cost of your time vs. cost of the BOM (with the Xmos chip being a good chunk of it). The power supply cost would be similar (just lower current needed on 1v0) and you will need to learn how to use the configuration script to generate the binary image for programming into the flash etc. for the XHRA device. The design flow is different because it's not a general device. This is all well documented though and straightforward (see xCORE-AUDIO configuration utility / xCORE-AUDIO configuration guide pdf file).

[yes2i2s]

I might just stick with what we've got. I like it and will be a good platform for future expansion with more complex products on the road-map. I have customised the timings, master / slave and bits and bobs. The BOM is around £80 as we have expensive RF and USB isolation gear plus balanced 32 bit DAC and other analog parts, lithium and charger etc. So all in all it's not most of the BOM as for a small device it packs a lot.

Thanks for the detailed support so far, very helpful!