Your understanding is correct.  If a higher priority thread is available to run, then a preemptible thread will yield to that thread at every scheduling point.

I'm not quite sure what you are trying to mitigate, exactly.  This is the desired behavior.  You WANT your two custom threads to run instead of  your main thread, that's why they're higher priority.  I think you might want to revisit the priority design in your app, basically.  The priorities you've assigned to your threads don't reflect what you want them to do.

If you just need the custom threads to get out of the way at startup, why not just have them sleep a bit, or (much better) block on a semaphore or whatever waiting for main to signal them to begin.  Or you can change priorities at runtime -- have main start at a very high priority but then lower itself, for example.  Or launch the threads dynamically via k_thread_create() at runtime once you know it's safe for them to run...

Andy

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj

Hi,

 

This is a question related to thread scheduling. Imagine you have 2 custom threads in addition to the “main thread”. The custom threads are created static (K_THREAD_DEFINE) and are cooperative threads (let’s say the priority is -5) whereas the main thread is preemptive (priority 0). Now, as soon as the main thread is handed control (via switch_to_main_thread), it is possible the scheduler gets triggered and one of the cooperative threads gets scheduled. This may be undesirable since main thread may need to get some stuff done before the cooperative threads take over.

 

Is my reading of the above situation correct? If yes, I would like to see how this can be mitigated. One easy thing is to make main thread also cooperative (say, a priority of -6). The other is to lock the scheduler as soon as the main thread is entered and unlock only after the relevant stuff is addressed. Please let me know your views.

 

Regards,

Raj

------------------------------------------------------------------

发件人：Stephanos Ioannidis <root@...>

发送时间：2020年5月11日(星期一) 09:50

收件人：曹子龙 <caozilong@...>; devel <devel@...>

主　题：RE: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

Hi,

 

You need to specify the correct ABI type through `-mabi` alongside the `-march` flag.

 

Try `-march=rv64i -mabi=lp64` for instance.

 

Regards,

 

Stephanos

 

From: devel@... <devel@...> On Behalf Of "??? via lists.zephyrproject.org
Sent: Sunday, May 10, 2020 9:28 PM
To: devel <devel@...>
Subject: [Zephyr-devel] How to compile riscv64 program with 0.10.3 sdk "riscv64-zephyr-elf-gcc" toolchain?

 

I try to compile program with "zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin/riscv64-zephyr-elf-gcc " to compile my program,

 

but it seems the result still be 32 bit program:

czl@czl-Vostro-3268:~/zephyr-sdk-0.10.3/riscv64-zephyr-elf/bin$ file a.out

a.out: ELF 32-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, with debug_info, not stripped

 

and i event try to compile with rv64 flag -march=rv64i

./riscv64-zephyr-elf-gcc -g main.c  -march=rv64i

cc1: error: ABI requires -march=rv32

 it seems still dont work 

 

at the beginning i guess it mybe use a ilp32 abi based on rv64 toolchan, so i try a program like that:

 20 unsigned long long foolbar2(unsigned long long a, unsigned long long b)

 21 {

 22         return a + b;

 23 }

whch unsigned long should be compile to "ld" and "sd" pare means ilp32 abi on RV64ISA ARCH.

but

  95 {          

  96    10194:       fe010113                addi    sp,sp,-32

  97    10198:       00812e23                sw      s0,28(sp)

  98    1019c:       02010413                addi    s0,sp,32

  99    101a0:       fea42423                sw      a0,-24(s0)

 100    101a4:       feb42623                sw      a1,-20(s0)

 101    101a8:       fec42023                sw      a2,-32(s0)

 102    101ac:       fed42223                sw      a3,-28(s0)

 103         return a + b;

 104    101b0:       fe842783                lw      a5,-24(s0)

 105    101b4:       fec42803                lw      a6,-20(s0)

 106    101b8:       fe042583                lw      a1,-32(s0)

 107    101bc:       fe442603                lw      a2,-28(s0)

 108    101c0:       00b786b3                add     a3,a5,a1

 

it purely total no!!!

 

so why? now that an rv32-zephyr-elf-gcc exist, if the iscv64-zephyr-elf-gcc  cat compile the 64 bit program, why it here ? 

 

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址：广东省珠海市高新区唐家湾镇科技2路9号

TEL：13824125580

Email：caozilong@...

网址： http://www.allwinnertech.com