How does sample time in Simulink translate into generated code for hardware?

Hi,

I am attempting to wrap my head around what sample time actually means in the real world. I am trying to use Simulink to write firmware for a new product that my company is designing. It runs on an ARM Cortex-M3 processor, so I'm having simulink generate code for that target. My boss is working on a Simulink model that is essentially a state machine which is supposed to control the timing of things. I've done some tests on hardware to try to get the interfacing done, but I am unable to wrap my head around what is actually controlling the timing of things as they run on the processor.

There doesn't seem to be any timer interaction, nor does there seem to be another mechanism for controlling how long a specific process takes to execute. The only mechanism I've been able to identify is that the rt_OneStep() function selects whether it will execute a function during a particular step or not.

So for example, let's say that I pick the default sample time to be 0.1 and I set some S-Function's sample time to 0.2, then essentially there's an infinite loop running and the second function will be executed once for every two times the first function is executed. Do I have a grasp of the situation? Is there some other method of timekeeping at play here that I'm not aware of?

If I do have the time step idea correct, what is the best method for using Simulink to control timing of things in an environment that is interrupt driven and in a low power mode where the processor is asleep most of the time? Thanks in advance for your help.

-Chris Hack

[Walter Roberson]

I believe that what you explain about sample time is correct.

I wonder if stateflow is more appropriate for your situation?

Answer 1

[Drew Davis]

Assuming you are generating code with the ert.tlc file, you must associate the 'rt_OneStep' function in the generated 'ert_main.c' file with a real-time clock or interrupt service routine to allow your application to run in real time.

The function 'rt_OneStep' is always associated with the base rate of the model where subrates are managed by the base rate from within the generated code.

In the case of many hardware support packages (such as the Simulink Arduino support package), the generated code automatically handles the application timing where the necessary code is automatically latched to an interrupt service routine.

With regards to which timing method is best, this is dependent upon your specific application and the hardware you plan to deploy the code onto, therefore I cannot comment.

[Daniel Klisiewicz]

Does the Fixed-step size (fundamental sample time) field in the Solver Configuration need to match the rate that rt_OneStep is called at by the real-time clock?