Invalid I2S example, but still compiles, but not...

[NiclasH]

The examples/peripherals/i2s/main/i2s_example_main.c contains invalid code;

Code: Select all

    i2s_config_t i2s_config = {
        .mode = I2S_MODE_MASTER | I2S_MODE_TX,                                  // Only TX
        .sample_rate = SAMPLE_RATE,
        .bits_per_sample = 16,
        .channel_format = I2S_CHANNEL_FMT_RIGHT_LEFT,                           //2-channels
        .communication_format = I2S_COMM_FORMAT_I2S | I2S_COMM_FORMAT_I2S_MSB,
        .dma_buf_count = 6,
        .dma_buf_len = 60,
        .use_apll = false,
        .intr_alloc_flags = ESP_INTR_FLAG_LEVEL1                                //Interrupt level 1

The enums are not supposed to be forced to invalid values, and it seems that when I put this in C++ code, the construct is simply rejected, no matter what. And I get;

Code: Select all

error: invalid conversion from 'int' to 'i2s_mode_t'

In general, the I2S subsystem is substandard, overly complex, doesn't really support low-latency streaming (xQueue is slow) and way too poorly documented, at "hardware", "ll" and "hal" levels. Even some suspect code, for instance; why is `i2s_hal_enable_master_mode()` setting the RX to Slave??


Does a complete example exist, where an I2S ADC/encoder streams data to ESP32 which does some processing and streams the data out to same/different I2S DAC/encoder??

[PeterR]

The esp examples are "C". Try compiling with a COBOL compiler and you will see what I mean. So why do you think a C++ compiler will work?
C++ is a lot more fussy on type safety and also structure initialisation crops up.
Personally I would also appreciate it if ESP provided a raw api, the RTOS/queue producer/consumer gig adds latency but I don't think that makes the offer totally 'bust'.

If you want to use C++ they try:
extern "C" {

around the ESP stuff.
Or wrap! All the cool kids try to be target neutral.

PS
'll' and 'hal' levels are the inner workings. You should not be peeking there & that why you don't get the document. Seriously the hal level contains errata & detail you just should not stress over.
Step back, let us know what you want to achieve, what you tried and how that did not work for u.

[NiclasH]

The sarcasm and derogatory attitude are not appreciated. Claiming C and C++ are not related any more than C and COBOL is outright offensive (and `extern "C" {}` doesn't save the day, but code would need to be placed into .c file).
On top of that, explicitly not supporting C++ can not possibly be a "requirement" or be "desirable", considering the extra work required for any user. The handwaving about "can't look inside" is not an argument, esp-idf/ is open source and "looking inside" is definitely part of one's workflow, and requiring that for instance arduino-esp32/ has to provide wrapping for no other reason than exploiting a C "decision" to allow non-enumerated values in enums.
Furthermore, I am not afraid to access the hardware directly, rather than going through layers of generalized (hence slower) code.

As for what I am trying to do, very simple... A low latency (preferably no buffer and reading/writing directly from/to FIFO without DMA) stream from external I2S input encoder, processing the stream, and output to the same external I2S encoder. Encoder I am trying on is TLV320AIC3104 but that is less relevant.

[PeterR]

Hey! Its not sarcism, its an argument intended to establish limiting case(s) by presenting an obvious trueth. We then go on to discuss similarity and differences. We agree on COBOL so why not C++? Its difficult to explain isn't it?

ESP IDF 'supports' C++. Also supports COBOL (if you find a compiler) & Javascript (that one is true) etc. Just don't expect one compiler to compile the other's language cleanly.

explicitly not supporting C++ can not possibly be a "requirement" or be "desirable,

That realy does seem an unfair argument. ESP had a choice. Build IDF on C or C++ (or COBOL). Once that choice was made the rest is determined by the standards people.
Many will tell you that C++ is slower than C (I would disagree as an absolute) but for many your complaint would just not seem fair.
In my experience most drivers are C & if speed is your target then arduino would seem a strange choice.

The handwaving about "can't look inside" is not an argument, esp-idf/ is open source and "looking inside"

I said best not & for the reasons at the heart of your complaint. It will probably be painful. There will be a lot of detail but it can be done.

A low latency (preferably no buffer and reading/writing directly from/to FIFO without DMA) stream from external I2S input encoder

if this is what you want to achieve then you will probably have to dig deep into the driver.

I would rather that the IDF provided low level RTOS free drivers BTW. Should not be too hard for you to locate the queue write and replace that with a callback though.

[PeterR]

PS
Whats the application, tone changer?
Looking at other I2S posts then I think you will have your hands full.
One problem you will have considered is ISR latency from other IDF functions.
If you can run your stuff on core 1 and launch ESP stuff from core 0 then that works much better latency wise.
I believe that IDF 4.1 picked up significant latency issues e.g. Ethernet ISR @2mS+. I am not real time like you so have just masked FTM.
Anyway keep in mind that other ESP functions and ISRs may cut across, that might change in each IDF version but that core ISR hygine is easy enough to achieve.