Pumpkin, Inc.

Pumpkin User Forums

OS_WaitEFlag behavior

If you're having difficulty with Salvo's configuration options, post it here.

OS_WaitEFlag behavior

Postby aek » Wed Oct 29, 2003 1:48 am

Hi Crosby.

First, does SB-14 apply to your particular situation?

If by myEVENT.2 you mean the third bit "above" bit1 and bit0, then no, OS_WaitEFlag() should not be clearing that bit ...

You can grep the Salvo source for instances of ...->eFlag being modified -- they're few and far between ...

Let me know what you find.

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

[This message has been edited by aek (edited October 29, 2003).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: OS_WaitEFlag behavior

Postby cstone » Wed Oct 29, 2003 3:15 am

Hi Andrew,

Yeah, I MEANT myEVENT.1 -- realized it as soon as my finger lifted from the <cr> button

SB-14 note refers to multiple tasks waiting an event flag. My lash-up is somewhat different:

Task_Start
calls SPI_Op( ..
OSClrEFlag(myEVENT,OpOK); /* AKA myEVENT.0 */
OSSetEFlag(myEVENT,OpRequest); /* AKA myEVENT.1 */
<return from SPI_Op>
OS_WaitEFlag(myEVENT,OpOK,OSANY_BITS,OSNO_TIMEOUT,StartSPI1);

... meanwhile over in Task_SPI ...
after returning from:
OS_WaitEFlag(EVENT_GEN,SPIRequest,OSANY_BITS,OSNO_TIMEOUT,SPIWait1);

... i'm wanting to call:
OSClrEFlag(EVENT_GEN,SPIRequest);
... to clear the event flag,
but it's already cleared .. so that's the puzzle.

My interrupt routine
calls OSSetEFlag(EVENT_GEN,0x10); whenever, if that could help explain things.

(I think I figured out that we PIC 18 users don't need to protect the OSClrEFlag and OSSetEFlag calls because we HAVE a sw stack,
right?)

Thanks,

CStone
protect the

cstone
 
Posts: 6
Joined: Tue Jul 08, 2003 11:00 pm
Location: Eugene, Oregon, USA

Re: OS_WaitEFlag behavior

Postby cstone » Wed Oct 29, 2003 3:18 am

whoops AGAIN
think of myEVENT as a typo
it's EVENT_GEN for all the event references..

cs

cstone
 
Posts: 6
Joined: Tue Jul 08, 2003 11:00 pm
Location: Eugene, Oregon, USA

Re: OS_WaitEFlag behavior

Postby cstone » Wed Oct 29, 2003 12:40 pm

Hello,

I'm wondering if it is normal for the call:
OS_WaitEFlag(myEVENT,0x02,OSANY_BITS,OSNO_TIMEOUT,myLABEL);

to (at least sometimes) return with myEVENT.2 cleared?

The manual says that it isn't guaranteed, I realize. I think I'm coming back to the task with the flag bit cleared by RTOS. Is this normal? Possible?

Thanks,

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

cstone
 
Posts: 6
Joined: Tue Jul 08, 2003 11:00 pm
Location: Eugene, Oregon, USA

Re: OS_WaitEFlag behavior

Postby cstone » Thu Oct 30, 2003 3:43 am

Hello Andrew,

Further developments ...

After a little digging in salvo.h, I used
statements in the form:

Flags_RX = (unsigned char) *EVENT_RX.event.efcbP->eFlag;

(I'm sure there's a better way ?)

to get a better look at the actual Event Flag byte values.
Long story short: Tiny RTOS is doing the right thing.

My best explanation for all this is "skidding" on the MPLAB ICD 2 emulator
(I cleared the Event Flag in the call following the breakpoint).

And (with the ICE 2000 emulator) I was not
dealing with the "known issue" of the emulator skipping the instuction following
the return from interrupt [only when the emulator has been stopped since the last
reset]. !!! The work-around is to reset
after EVERY breakpoint, and run from reset
to your current debug breakpoint. (ICE 2000 users beware!)

Thanks,

cstone

cstone
 
Posts: 6
Joined: Tue Jul 08, 2003 11:00 pm
Location: Eugene, Oregon, USA

Re: OS_WaitEFlag behavior

Postby aek » Thu Oct 30, 2003 10:20 am

Hi Crosby.

I'm glad you found the source of the apparent bug, and that it wasn't Salvo.

One thing to keep in mind when debugging Salvo apps is that some Salvo services, esp. OS_Xyz(), are implemented as multi-line macros, but appear in your source as a single line of C. Most debuggers can't really handle breakpoints on these C lines properly ... it's better to place the breakpoint on the disassembly rather than in the C file.

And, of course, the "break at the step after" problem with certain IDEs, etc. is always another potential bugaboo that must be taken into consideration.

Regards,

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: OS_WaitEFlag behavior

Postby aek » Thu Oct 30, 2003 10:26 am

I overlooked this before:
quote:
My interrupt routine
calls OSSetEFlag(EVENT_GEN,0x10); whenever, if that could help explain things.

(I think I figured out that we PIC 18 users don't need to protect the OSClrEFlag and OSSetEFlag calls because we HAVE a sw stack,
right?)


Which compiler?

ISR protection is absolutely required for PICC-18 (and PICC), but is not required for MPLAB-C18 or IAR PIC18C, as they are both reentrant compilers.

Failure to use OSProtect|Unprotect() where necessary with PICC and PICC-18 (see RM-PICC18.PDF) will lead to runtime problems sooner or later -- in most cases, the "window of opportunity" for the ISR to corrupt Salvo's global variables is very small, so it's quite possible that an application will run fine 98+% of the time, but it will eventually break. Using OSProtect|Unprotect() is mandatory, and prevents corruption.

Regards,

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: OS_WaitEFlag behavior

Postby aek » Tue Nov 04, 2003 9:06 am

Follow-up for anyone reading this thread -- the runtime problem was caused by a failure to define OSEVENT_FLAGS in salvocfg.h.

Three event flags were in use, but without the definition, the default (1) was in effect when the application was built. Therefore the applications efcb's were overlaid with the tcbs, and that's a definite no-no. Adding

code:
#define OSEVENT_FLAGS 3

to the project's salvocfg.h fixed it.

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

[This message has been edited by aek (edited November 04, 2003).]

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm

Re: OS_WaitEFlag behavior

Postby cstone » Wed Nov 05, 2003 9:51 am

How about a (future releases) strategy for cases like this where the default value is set to 0 or some safe value that will force a compiler error if the variable/parameter isn't defined in the user's salvocfg.h ?
The advantage would be to force the discovery of the logic error earlier, rather than after significant debugging effort and head scratching. Of course the other idea would be for the user (me) to actually READ the documentation
cstone
 
Posts: 6
Joined: Tue Jul 08, 2003 11:00 pm
Location: Eugene, Oregon, USA

Re: OS_WaitEFlag behavior

Postby aek » Wed Nov 05, 2003 10:41 am

Hi Crosby.

A default value of 0 causes other problems (the relevant parts of the library won't be "active").

For those compiler vendors with Salvo Configurators built into the IDE (currently: ImageCraft), this is taken care of automatically ...

It may be possible to flag if a particular config option is undefined (as opposed to not being properly defined) in the user's salvocfg.h ... I'll look into this.

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

-------
aek
aek
 
Posts: 1888
Joined: Sat Aug 26, 2000 11:00 pm


Return to Configuration

Who is online

Users browsing this forum: No registered users and 2 guests

cron