Assigning all tasks to CPU1, while letting CPU0 handle high speed timer interrupts
Added by Panagis Vovos about 1 month ago
Thanks to Waijung2 support team I can use this fabulous kit to execute some high speed sampling and calculation tasks, needed for power converter applications, using timer interrupts up to 0.0001s!
Of course, another collection of low speed control tasks must operate in parallel, in order to collect data from the system sensors and produce appropriate modulation signals. However, in order to have such a balance between control and actual execution someone has to specify the core that this fast-triggered piece of code is executed, so the rest (e.g. control) works undeterred at the slower rate.
As I have already being informed by Dhanika in Waijung , timer interrupts are handled by CPU0. That leaves CPU1 available for the execution of the control code.
So, in theory, for this application I would just have to use Waijung2 xTaskCreate block to create a separate task for the control algorithm and assign it to APP_CPU (CPU1). However, currently (waijung2_20.11b) xTaskCreate block does not have the functionality to assign the task which it creates, to a specific core.
Is there something you can do about that block, since there is such a functionality in the original xTaskCreate command.
That would be awesome and would make this fabulous tool complete for such applications.
Thank you for your time, anyway,
RE: Assigning all tasks to CPU1, while letting CPU0 handle high speed timer interrupts - Added by Dhanika Mahipala (ดานิก้า) 25 days ago
Please download the ZIP file attached and follow the steps below to install the patch for xTaskCreate block to your current waijung2 installation.
1. Close Matlab (which the waijung2 is installed in) if it is running.
2. Unzip the attached file (esp32_timer_interrupt_block_patch.zip) and copy and paste the content to replace the files at the location,
[ your waijung2 installation directory ]\waijung2_20.11b\waijung2\targets\esp32\src\blocks
3. Restart Matlab.
I created a simple demo test_xTask.slx to demostrated how you can accomplish your objective. Please let me know if you want to any details about this. I tested the setup in this demo for a short period of time and it seems to be working as expected.
Please test and let me know whether this resolves your issue.Here are the attachments mentioned,
- Patch file for the block - esp32_xtaskcreate_block_patch.zip
- Model file to test the the new block - test_xTask.slx
RE: Assigning all tasks to CPU1, while letting CPU0 handle high speed timer interrupts - Added by Panagis Vovos 20 days ago
First, I had to change your Simulink model a bit (attached TaskMux.slx), in order to accommodate the design requirments.
The final aim of the test case is to have two separate tasks:
- One running at "max speed" , i.e. with the 0.0001s period and
- another one performing some "control" by manipulating the results of the other, but at a much slower pace.
The original model did not "exchange" data and results between tasks, which is a fundamental operation in power converter control.
So, I kept the 0.0001s interrupt that increases the counter (as we had in previous models) BUT created a task, per your advice/model, on CORE 1 that just checks the output of the counter every 0.1s and if this is above a threshold (i.e. halfway) then switches on the LED/GPIO2.
Good news is that the task on CORE 1 has absolutely no effect on the timer interrupt precision and vice versa. I tested it by changing the counter with an ADC block (model TaskMuxADC.slx) and some more calculations with the existing conter. The new model executed the same way as the previous, simpler one. So, the fast sampling rate with the timer interrupt serviced by CORE0 has not been affected by the primitive control of that sampling on the task running on CORE1.
However, it seams like the 1.5s/h delay noticed from the timer interrupt at 0.0001s rate in our previous communication, seams to have increased to 2s/h. Of course this half a second does not cause a serious problem to the control part of the code, which is needed anyway. However, it makes me worried whether the code is actually split between cores 0 and 1 as mentioned above. In order to add more to the confusion, I have changed the CPU assigned to the Ctrl_Algo to 0 in TaskMuxADC.slx. In other words, I assigned both timers/codes to the same core and it worked again just fine! Is the TaskX core selection still inactive and it assignes all tasks to Core 1 by default, indifferent of the selection within the block? Is there any chance that by mixing calculation flows between tasks/cores everything is assigned to one Core, indifferent of our initial intention?
I hope I did not confuse you more than helped with my tests. Thank you for your time and effort.
RE: Assigning all tasks to CPU1, while letting CPU0 handle high speed timer interrupts - Added by Dhanika Mahipala (ดานิก้า) 16 days ago
The behavior you have explained is strange. Please give me sometime to look into your model files and hopefully give you a proper explanation.