Forum : ST7/STM8
Post Information | Post |
---|---|
March 4, 2010 - 5:14pm
|
Hello, I am porting the ChibiOS/RT RTOS to STM8 using your excellent development environment. The work is almost finished and I am really enjoying Ride7, I am thinking to make a Ride7/GCC version for ARM too. While debugging the new port, I ran into an unexpected problem. Please consider the following code: /** * @brief Evaluates to TRUE if the thread has pending messages. */ #define chMsgIsPendingI(tp) \ ((tp)->p_msgqueue.p_next != (Thread *)&(tp)->p_msgqueue) /** * @brief Returns the first message in the queue. */ #define chMsgGetI(tp) \ ((tp)->p_msgqueue.p_next->p_msg) msg_t chMsgWait(void) { msg_t msg; chSysLock(); if (!chMsgIsPendingI(currp)) chSchGoSleepS(THD_STATE_WTMSG); msg = chMsgGetI(currp); chSysUnlock(); return msg; } The pointer "currp" does not change after invoking chSchGoSleepS() but the data pointed by "currp" does change. It is a queue of incoming messages for the currently running thread. The compiler generates the following code: ; FUNCTION ?chMsgWait (BEGIN) ; SOURCE LINE # 74 0000 5206 SUB SP,#006H ; SOURCE LINE # 77 0002 9B SIM ; SOURCE LINE # 78 0003 CE0000 F LDW X,rlist + 0DH 0006 1C0013 ADDW X,#00013H 0009 1F03 F LDW (003H,SP),X 000B FE LDW X,(X) 000C 1F05 F LDW (005H,SP),X 000E 1303 F CPW X,(003H,SP) 0010 2605 JRNE ?NXT_0003 ; SOURCE LINE # 79 0012 A60B LD A,#00BH 0014 CD0000 F CALL ?chSchGoSleepS 0017 ?NXT_0003: ; SOURCE LINE # 80 0017 1E05 F LDW X,(005H,SP) 0019 EE17 LDW X,(017H,X) 001B 1F01 F LDW (001H,SP),X ; [ msg ] ; SOURCE LINE # 81 001D 9A RIM ; SOURCE LINE # 82 001E 5B06 ADD SP,#006H 0020 81 RET As you can see it seems to not consider that the data pointed by "currp" can change after invoking chSchGoSleepS(), after exiting from that function the queue is no more empty. I am doing simply something wrong there ? If I modify the code as follow: if (!chMsgIsPendingI(currp)) chSchGoSleepS(THD_STATE_WTMSG); msg = chMsgGetI((volatile Thread *)currp); Then everything works and the generated code becomes: ; FUNCTION ?chMsgWait (BEGIN) ; SOURCE LINE # 74 0000 5204 SUB SP,#004H ; SOURCE LINE # 77 0002 9B SIM ; SOURCE LINE # 78 0003 CE0000 F LDW X,rlist + 0DH 0006 1C0013 ADDW X,#00013H 0009 1F03 F LDW (003H,SP),X 000B FE LDW X,(X) 000C 1303 F CPW X,(003H,SP) 000E 2605 JRNE ?NXT_0003 ; SOURCE LINE # 79 0010 A60B LD A,#00BH 0012 CD0000 F CALL ?chSchGoSleepS 0015 ?NXT_0003: ; SOURCE LINE # 80 0015 1E03 F LDW X,(003H,SP) 0017 FE LDW X,(X) 0018 EE17 LDW X,(017H,X) 001A 1F01 F LDW (001H,SP),X ; [ msg ] ; SOURCE LINE # 81 001C 9A RIM ; SOURCE LINE # 82 001D 5B04 ADD SP,#004H 001F 81 RET I am compiling with size optimization level 3. I think the compiler should never assume that the data pointed by a global variable cannot change across function calls. Note that the posted fix is not a solution for me nor I can simply declare the pointer "currp" as volatile, the efficiency of the OS would suffer (it is very critical code) and the kernel is supposed to be portable so it should not contain vendor specific workarounds. Another problem is that I could get an unpredictable behavior in other points of the kernel and simply do not discover them until it is too late. I hope to find a better solution, except for this problem everything else seems to be working perfectly. best regards, |
Hi Giovanni,
We are very glad that you enjoy working on Ride7 and with our Compiler. Thanks a lot!
We tried to reproduce your problem in our labs with no success.
Can you do the following:
Add the following line as the first line of the problematic .C file:
#pragma PREPRINT
Compile you file. The compiler will generate a preprocessed file with the same name as your C file, and extension ".I"
Send me this .I file, along with the compiler listing file which has extension ".LST". You can post these right here.
Using these files we will be able to better characterize and reproduce the problem.
Regards,
Bruno
This is the preprocessed file:
And the generated code:
The whole thing can be accessed here (it is a temporary branch): https://chibios.svn.sourceforge.net/svnroot/chibios/branches/stm8_dev
It contains the R7 project and runs on the REva 3 board.
thank you,
Giovanni
Hi,
I'm currently evaluating the STM8 Raisonance compiler for a commercial product and have been working with this RTOS. Are there any updates to the status of this problem?
Thanks