Embedded systems have some form of scheduling mechanism. These mechanisms may include an RTOS, a Cyclic Scheduler, one or more Interrupt Handlers, and others. Scheduling Tasks in an MxVMC enables you to build an execution model for your test environment.

The Execution Model is the name given to the approach you take in modeling the execution of code in the actual microcontroller. If your TestCases are to provide meaningful results, you must have a realistic Execution Model. Execution Models in many cases are quite simple.

In some cases, you may create different Execution Models to test different features of the system. The Execution Model is usually fixed throughout the execution of scenario, but it does not have to be! Some examples of creating the Execution Models for different circumstances are provided below.

hmtoggle_plus1Simulating a Simple Cyclic Scheduler

Many systems have a single initialization task which is called once, and one (or more) periodic tasks which are called at a set intervals. This is easily modeled.

1.First, connect to all the functions (task signals) that you will want to invoke from MxVDev.

2.Create a new TestCase and call it SystemInit (or something similar). Add the initialization task Signal to this TestCase, and schedule it to run once by adding one pulse to the task Signal.

3.Add a second TestCase and call it ExecModel (or something similar). Add the other tasks to this TestCase. Set the Test Step Interval to that of the most frequent task. Add a single pulse to the most frequent task Signal, and stretch the pulse to the full width of the TestCase. This causes this task to be executed at every step. Add pulses for the other tasks to cause them to execute at lower frequencies. If the task frequencies are not harmonic, you may need to choose a different Test Step interval or add another TestCase to the execution model.

4.Create a new Scenario and add a job for each of the two test cases.  Set the SystemInit job to be a precondition to the ExecModel job.  Set the ExecModel job to run forever.

This simple Execution Model may work for all your Test cases.

hmtoggle_plus1Simulating Interrupts

Within a cyclic scheduler Execution Model, simulating the occurrence of an interrupt at a certain step in a TestCase is easy. They cannot be preemptive. They occur between ticks of the main scheduler.

1.First, attach to the Interrupt handler function (task signal) using the Connecting Signals dialog or Data Routing.

2.View the TestCase where you wish the Interrupt to occur, and use the TestCase‑>Pick Signals menu item to add the Task to the TestCase.

3.Double-click the Task Signal to insert a task-execution event. The Interrupt handler is scheduled at that step in the TestCase.

Example

Suppose you have an interrupt handler called void Handler(void)

1.Add 'Handler' to the TaskDefs array in the AppIF.c file.

2.Rebuild the C code.

3.In a TestCase, select Pick Signals.

4.Find 'Handler' under Stimulus->Standard and add it to the TestCase.

5.Double-click on the Signal in the TestCase to cause Handler to be invoked at that point in time.
hmtoggle_plus1Simulating an Event-Driven Scheduler

Often real time systems have few or no cyclic tasks and are driven primarily by Interrupts and event queues. This is easily modeled by simulating Interrupts as described above.
hmtoggle_plus1Simulating an RTOS

An easy way to simulate the operation of an RTOS is to just call the tasks that the RTOS invokes. One benefit is that you have full control of timing, and you can write test cases to explicitly test many of the combinations. If the RTOS has some built-in features (such as enabling and disabling Interrupts), you have to mimic those features in the AppIf.c file.

An alternative is to port the RTOS to run on the PC. This has proved successful where the RTOS provides many features (mailboxes, event queues, preemption, and other features), and is not difficult if the RTOS is designed to be portable. The Execution Model is then responsible for initializing the RTOS, and invoking the real time clock entry point to the RTOS.