Use of dual core

[WiFive]

I.e. no parallelism.

This is actually a bit weird as I just did a test and if the parent task is pinned to core 0 the child tasks seem to run in linear time and in fact each task runs as if pinned on core 0. But if the parent task is pinned to core 1 they run in parallel in nonlinear time and can run on both cores.

Is there a problem starting an unpinned task from core 0 that does not properly achieve no affinity?

Code: Select all

I (1752) tasks: Starting parent task on core 1

I (2912) tasks: Num Tasks: 1, Time: 1163329
I (4092) tasks: Num Tasks: 2, Time: 1176318
I (5852) tasks: Num Tasks: 3, Time: 1759933
I (8192) tasks: Num Tasks: 4, Time: 2339933
I (11102) tasks: Num Tasks: 5, Time: 2913288
I (14592) tasks: Num Tasks: 6, Time: 3493296
I (14592) tasks: Finished

Code: Select all

I (1747) tasks: Starting parent task on core 0

I (2907) tasks: Num Tasks: 1, Time: 1163335
I (5237) tasks: Num Tasks: 2, Time: 2327679
I (8727) tasks: Num Tasks: 3, Time: 3488639
I (13377) tasks: Num Tasks: 4, Time: 4657502
I (19197) tasks: Num Tasks: 5, Time: 5819879
I (26177) tasks: Num Tasks: 6, Time: 6981584
I (26177) tasks: Finished

[WiFive]

Ok I think I figured it out. You have to run a pinned task on core 1 before a no-affinity task will run on core 1. Not sure why.

Code: Select all

I (1369) tasks: Starting parent task on core 0

I (1369) tasks: Nothing task was here.

I (2529) tasks: Num Tasks: 1, Time: 1163977
I (3709) tasks: Num Tasks: 2, Time: 1169934
I (5449) tasks: Num Tasks: 3, Time: 1746808
I (7779) tasks: Num Tasks: 4, Time: 2330023
I (10689) tasks: Num Tasks: 5, Time: 2910224
I (14199) tasks: Num Tasks: 6, Time: 3502629
I (14199) tasks: Finished

[Olof Astrand]

Something is not right about the initial scheduling on the app cpu, anyways.

I think it matters if you have made a call to nvs_flash_init() or not.

I made a complete example here that logs on which core the task last was running.
https://github.com/Ebiroll/qemu_esp32/b ... ain/main.c

[ESP_Sprite]

Hmm, I think I may know where this problem originates. Will try to fix it up after the holidays.

[Olof Astrand]

OK. Good.
In my tests scheduling on the app cpu did not start until after about 10 seconds.

Also a delay before calling nvs_flash_init(); did help.
Otherwise I got no scheduling at all on the app cpu, at all.

vTaskDelay(500 / portTICK_PERIOD_MS);
nvs_flash_init();

https://github.com/Ebiroll/qemu_esp32/t ... 4_schedule

[Olof Astrand]

Hello again Mr Sprite,
One more thing worth noticing from my tests.
https://github.com/Ebiroll/qemu_esp32/b ... creenlog.0
Even tasks run on APP
Task8 - tick: 2748
Task4 - tick: 2782
Task0 - tick: 2807
Task2 - tick: 2792
Task6 - tick: 2764
Task1 - tick: 572
Task3 - tick: 565
Task5 - tick: 572
Task7 - tick: 575
Task9 - tick: 568
Is cache active on the app cpu?
In this example it takes 4 times as long to perform same task on the app cpu. I configured the app to be running on 240Mhz.
To improve test I should have done the printout Running on APP CPU! before the gettimeofday(&start); call

[BakerMan]

Hello Again,

as i promised, here are the results of my effords in the last days.

What i wanted to do is to transfer data from a non standard kind of pcm interface over uart to pcu. Between the pcm interface and the uart is a buffer. With enough speed on the uart i have a comfortable time to serve the pcm interface. Data on the Interface have to be send and recieved at the same time. My programm worked pretty well until i tested the uart rx-communication during running pcm communication. For some reason the recieving of data on the uart interrups the "realtime infinity loop programm" running on cpu1 with disabled sheduler. I suppose the reason for this can be the rx-recieved isr routine on cpu0 and/or the previously described cache miss, which may block the cpu1 for small periods of time. If there is no work around, this renders my idea impossible and i wasted much time. But i learned a lot! At the moment i have two options:

1) Try to solve the interruption of cpu1. I did not succed now. Tried a lot by varing the buffer size, disable the tx-isr, changed the uart speed, changed the uart parameters, tried to push the routines in different memory areas, and last but not least tried to chance the cpu1 init method. No Success! Does anybody have an idea? Maybe i can readout incomming data without the driver?

2) Connect the clk and ws lines of the two i2s interfaces, configuring them as slaves, and use one to send and the other to read out the data at the same time. I tested the i2s in combination with my "pcm interface" before. Without success. It has an unusual format. There is a 32Bit frame single chanel an a sample rate of 8kHz. But only 13 Bit of the frame will be used. Ive configured one i2s of the esp as far as i could to this conditions. Maybe it works. But i have to invert the ws-signal, because my interface needs a high pulse for syncing instead a low pulse.

I appreciative any help you could provide me!

Kind regards!

[ESP_Sprite]

Again - what exactly are you trying to do on CPU1? I'm 99% sure you can (ab)use another peripheral for that which uses DMA or some other kind of buffer to offload the actual timing-sensitive work.

Wrt the interruption of the task on core 1: Do you know how long this is? I'm thinking it may be an issue with burst DMA hijacking the memory bus. Do you happen to DMA from/to a 32K region that core1 also uses?

[BakerMan]

Good Morning,

i want to implement a slow speed pcm slave interface capable of transfering 32bit frames with 8kHz In- and Output at the same time. When i got my ESP32 i tried to (ab)use the I2S interfaces for that. I made more ivestigations Friday. There is my open thread you can find under: http://www.esp32.com/viewtopic.php?f=2&t=819 The idea was to use both I2S Interfaces as slave devices with connected ws and bclk, ones as Input and one as output. The slave mode didnt work, so i tried to make the pcm part for my self.

I created 2 buffers like this:

Code: Select all

 char *outBuf = pvPortMallocCaps(DATA_BUFFER_SIZE, MALLOC_CAP_8BIT); 

These buffers i uses in between the "self implemented" pcm interface and the uart. The uart itself does not use the output ringbuffer or interrupts, data will be written directly to the from the buffer above. All incoming data from the uart will be written the dma input ringbuffer and the copied to a buffer i declared like the output buffer above. But it does not matter if the data will be copied to this buffer or not, a random interruption of about 125us will occur in the moment the uart recieves any data. So its pretty possible that the DMA transfer to the uart ringbuffer may block the memory bus. I dont know if my buffers will be created in the 32k region which cpu1 also uses.

I think its a way bether solution to try on with I2S. Maybe i did something wrong, but at the moment this interface does not react on external clock signals in slave mode. I dont have a master clock. Only ws, bclk, din and dout from an other device.

Kind regards

[WiFive]

Hmm, I think I may know where this problem originates. Will try to fix it up after the holidays.

Any update? Saw you made small change to tasks code but it did not resolve this.