lib_i2s TDM - which version for xTIMEcomposer

[aclassifier]

I am porting my present project from the single MIC ARRAY board I have over to the xCORE-200 Explorer board. I have five new ones of them.

I have been using lib_i2s 2.2.0, but for some reason my installed 3.0.0 I haven't used. I still use xTIMEcomposer, and will only port to XTC tools (or whatever it's called then) when I get the the promised RISC-V on a board. I will be using i2s and TDM (Time Division Multiplexing).

I see that lib_i2s 5.0.0 now is around [5]. I see that xC is gone, only assembler S files.

QUESTIONS: May 5.0.0 be used with xTIMEcomposer? If yes, would there be any good reason to? Is there anything about TDM that I need to be aware of?

Off Topic

Aside, but might be of interest: For the xCORE-200 board I will be using NW-AUD-ICS52000 [1-2] containing four ICS-52000 all-in-one mics, and I can let lib_mic_array and the sw decimation go, since ready data is delivered over TDM. I also found a headphone I2S output board from Pimoroni, containing a PCM5100A stereo DAC with PLL [3-4]. (This has also been discussed here at XMOS microphone boards or alternative? and Using a PLL for mic clock(s)).

Øyvind

[1] NW-AUD-ICS52000
[2] ics-52000
[3] PIM544
[4] AudioStereoDAC with PLL
[5] lib_i2s

[akp]

Yeah the library you linked should be fully compatible with xTIMEcomposer 14 tools. It's all XC callable with the interface feature and everything. Most of it isn't even assembly, the assembly just implements the feature that allows you to use 4 bit ports in addition to 1 bit ports for i2s. I suspect they couldn't meet the desired timing to enable the use of 4 bit ports at reasonably high sampling rates without using assembly; honestly it's pretty straightforward dual issue assembly but the compiler is poor at generating highly optimized dual issue code.

Generally speaking the best way to get really high performance from XS2A chips is to implement critical inner loops in hand optimized dual issue assembly. You can let the bulk of your code be compiled single issue (to reduce code size since XS2A chips have somewhat limited memory per tile).

[aclassifier]

Thank you, akp!

You made me realize that the .h files also do contain XC source code. What's the idea here? I have only done that when I needed to extend an interface like "extends client interface i2c_master_if".

Also, how is the library like lib_i2s resolved in the XTC Tools? I guess they keep xcc in there? Or are they ready-built to binary in Bristol (by xcc?).

In the "xTIMEcomposer User Guide for tools version 14.0.x" ch. 46.6.18 it looks like "issue_mode single" is a param for xasm, so I tried
XCC_ASM_FLAGS = -single
in the makefile. I got no message that it was wrong, and all sizes stayed the same.

[akp]

If you don't use 4 bit ports the .S files won't get linked into your binary, you could probably delete them altogether and it would make no difference.

I don't know how the new XTC toolchain works but it's supposed to support all the old XC code. I use the xTIMEcomposer 14 IDE.

I am pretty sure the reason they have the impl.h files is so when the file compiles it inlines the actual i2s code rather than calling it from a function call to save function overhead.

[aclassifier]

I don't know how the new XTC toolchain works but it's supposed to support all the old XC code. I use the xTIMEcomposer 14 IDE.

Would this mean that I could in fact just import my XC projects into XTC Tools and that I don't have to rewrite them into C + lib_xcore. I did try to find that out when XTC Tools arrived, and I though that I found out at the time that XC had been discontinued. I see in XTC Tools XCC Description that

XCC is deliberately analogous to GCC and imitates many of its behaviours. XCC is a wrapper around a collection of tools to make the use of those tools simpler. Those tools perform the steps of preprocessing, compilation (both C/C++ and XC), assembly and ‘mapping’. Those tools may be used individually, but are more easily used via xcc.

and in the list below that quote XC certainly is also included. Have I been wrong all the time? Nothing would have been better! In that case then C plus lib_xcore black-boxes xC would certainly need an overhaul.