MPC5xx: TurboOSEK - Question to resources + scheduling

[ThomasKintzel]

Hello,

I'm using CodeWarrior V8.1 / Turbo OSEK 2.3 for MPC 5xx. I 've got 2 questions from my current work. I guess that I do not understand something

1) Scheduling in Turbo OSEK

If I have a C - statement with a global integer "data1" like this

   data1 = data1 | 0x01;

The compiler generates from this C code at least 3 assembler operations something like

read data1 to register
modify register
write register to data1

Is it correct to assume that a task switch from OSEK can interrupt the read/modify/write operation?


2) Resources

I want to control the access to memory using a resource.

the access with the 1st and 2nd tasks works as expected. If a third task tries to call "GetResource()" the system crashs with Machine Check Exception 0x200. Is it possible that a ressource can be shared only between two tasks?

If this is helpful: The debuggers shows the current line as

    StatusType OSGetResource( ResourceType resId )
    {

    ...

    #endif /* defined(OSRESOURCEISR) */
    {
-->   if (OsRunning->taskId resId->prio )
      { /* or resource with lower priority */
        OSRETERROR( E_OS_ACCESS, OSServiceId_GetResource, resId );
      }

      ...

Thanks for your help
Thomas

Message Edited by Thomas Kintzel on 2006-10-0610:14 AM

Message Edited by CrasyCat on 2007-04-13 01:42 PM

[ThomasKintzel]

I know already that it is not the number of task accessing the resource that cause the call to GetResource() crash. Of course I have assigned the resource to each task which requests it. Is there any idea that else I could do wrong?

Is it ok then I call GetResource ( Resource_A ) in a function which is called by different tasks?

func1 ( )
{
   GetResource ( Resource_A )
   ...
   Release Resource ( Resource_A )
}

TASK ( TASK_1 )
{
   ...
   func1 ()
   ...
}

TASK ( TASK_2 )
{
   ...
   func1 ()
   ...
}

Thanks
Thomas

Message Edited by Thomas Kintzel on 2006-10-0902:27 AM

[J2MEJediMaster]

1) Yes, you can assume that a context switch will occur at any time while you're updating global information. So, you either need to bracket the update operation with calls to DisableAllInterrupts() and EnableAllInterrupts() to ensure a context switch doesn't occur, or designate the global as a shared resource, which is what you're doing.

2) It's not clear to me what that if statement's doing. I don't see any logic operator. Is that a typo, or have I missed something?

---Tom

[ThomasKintzel]

Tom, thanks for your reply.

The first question is clear now for me. But your suggestion does rise another qestion: Is it - more in general - ok to use enable/disable interrupts instead of GetResource()/ReleaseResource() to avoid resource conflicts? What is the common way here? The interrupt latency time is not so important to me.

2)
You are right. The sample is not complete. There was a "<" lost by formatting the text.

I'm not sure but I guess that I have there a problem with the stack and not so much with OSEK. I now try to understand how OSEK builds the stacks of extended tasks. I'm looking for a documentation of the compiler's output. Do I find something on the freescale web site?

regards
Thomas

[J2MEJediMaster]

DisableAllInterrupts() and EnableAllInterrupts() are supposed to use very few instructions, if latency is an issue. Since it's not, the cleaner way would probably be to use GetResource()/ReleaseResource() pairs.

There may be some documentation on the Freescale Web site, as I've tracked it down before. I can't recall where I found it, so instead I'll e-mail the OSEK docs that I'm using, which are mostly specifications docs. However, I find that they provide valuable insights into the architecture of the OS. As for the stack problem, you can assign an extended task a bigger stack within seconds by changing its STACKSIZE attribute. The attributes are described by the OSEK implementation language (OIL), which you can graphically modify using the OSEK Builder app. (Or, double-click on the osdef.oil file in the CW project window to launch OSEK Builder.) Pick the OIL Objects tab, click on your task, and in the Attributes window change the value for STACKSIZE from AUTO to, say 100. Then rebuild the application. If you're using events or ISR, the AUTO (default) settings isn't sufficient.

---Tom

Message Edited by J2MEJediMaster on 2006-10-09 03:45 PM

oil25.pdf

os223.pdf

Message Edited by t.dowe on 2009-10-15 01:24 PM

[ThomasKintzel]

Thank you, this helps.