Is there a better way to code the interrupt? ADC

Ok I can start using tivaware calls. I heard though though that programming like this gives better performance?

Sunny Chan said:

I heard though though that programming like this gives better performance?

Several points

• Have you measured and determined if you need extra performance? If not you are wasting time and resources on useless frills.
• How much extra time have you budgeted for duplicating TIVAWare functionality?
• The performance improvement possible is rather small. The function call overhead on these processors is small to begin with and less on leaf function (those that call no other functions)
  • When you do need performance (measure first), you will likely find that except in quite restricted subsets it's not going to be easy to improve on using the TIVAWare library.
  • And this is why you measure. You need to determine if you are improving and how much. Any improvement might be so small as to make the extra effort involved worthless.
• You don't benefit from library improvements

DRM is a useful addition to TIVAWare for adding capabilities not supported or in specific cases perhaps improving performance (where measurements indicate).

Robert

Thank you for the helpful response. I'll probably start using the Tivaware's API, I'm starting with the wikibook. For future cases when I write interrupt handlers, do I put the if statements inside my interrupt handlers? 

Sunny Chan said:

My goal is try my best to write an interrupt driven program.

Why?

Interrupts are a tool, not a goal.

Sunny Chan said:

Are you suggesting I program a general purpose timer to check the status of my ADC pin?

No. I'm suggesting you match your program structure to the problem. Run the A/D interrupt as frequently as necessary to capture your signal. Run your output at a rate suitable for the output.

Presumably you have other logic than this that you are planning on implementing. It will also have it's own timing requirements. That is why the usual recommendation is to keep interrupts short and do most of the work outside of the interrupts. The obvious choices for you are a super-loop polling loop where you use interrupts to perform time sensitive I/ (A/D input and filtering, ticking clock, serial I/O etc...) while performing the processing in the polling loop as required; or an RTOS, like Free-RTOS, where again the interrupts do the time sensitive I/O and the various threads perform the bulk of the processing. The RTOS gives you the advantage of inter-process communication and control over priorities.

It is possible to write an interrupt driven run to completion tasking system on these processors but that's a bit advanced for your current expertise I think.

Robert

The reason why I want to have a interrupt driven program is to conserve as much processing power from the launchpad as possible. I'd figure it'd be good best practices and saves the resources to do other things. Agreed, interrupts are tools and I'd like to try to use them, I guess that's my goal haha.

I'm not sure what you mean by super polling, and I'm unclear how you filter A/D. The closest thing I can think of could be a hardware solution? But as I'm new is there much point into writing a interrupt driven program or is it the same as with DRM?(Matching the program structure to the problem?) as I've had the overall impression that it was important to make the most out of hardware.

Thank you Robert this has been enlightening, as for writing a interrupt driven run I'm willing to try to approach it, even if it's just a small program so I can get it in as habit. 

Sunny

Hi Sunny,

>I'm assuming I've given it some kind of clock this way?

That directive only does what it says it does, no more than that. How your MCU is working without setting the MOSC likely using default oscillator, (TM4C129xx) PIOSC=16Mhz. Most important to configure MOSC/PLL clock sources for a SYSCLK main source for proper 1-2MSps ADC0/1 -- refer to datasheet main clock tree, ADC section. Again import and or review example projects in the Tivaware library bundle, CCS makes it easy to program your launch pad and run the debug emulator, view peripheral registers, Runtime interrupt actions etc..

http://software-dl.ti.com/tiva-c/SW-TM4C/latest/index_FDS.html

Sunny Chan said:

I'm not sure what you mean by super polling

This is likely to be a long reply. I'm going to try and summarize the various tasking approaches

Loop

The most basic and simplest executive. A simple loop that check inputs, process them and produces outputs.

Inter-Process Communication

There's really only one process so there isn't any IPC. Much information is kept is global variable accessible to all parts of the system

Pros

Simple. Easy to use, easy to create. All you need is to have a working startup and there isn't anything left to write.

Only single stack required.

Cons

Doesn't scale. If the processing for some input is lengthy it block further checking of inputs and setting of output. This is dealt with in an adhoc fashion by inserting checks in the middle of other processing (additional input checking etc...). This quickly become a tangled mess.

Pausing is difficult

Adding Interrupts

Because of the timing issues of a loop interrupts are often added to deal with peripherals that need a low-latency response. This turns into two forms of interrupt processing

Interrupt Light

The interrupts are short and do minimal processing. They might set outputs (for instance shut down in response to a limit) but that will be kept to a minimum. Most interrupts simply service the peripheral, providing it with the next input and/or buffering its output for the main program.

There may still be overflows because the latency of the processing in the main loop will delay the servicing of the interrupts inputs and required outputs.

Interrupt Heavy

Also known as foreground/background.

Most of the processing is done in the interrupts, the main process is either idle or does slow work that does not fit well in an interrupt (like updating EE).

Now because there is so much work done in the interrupts they start blocking each other and increasing the time from when the interrupt is flagged to when the interrupt routine starts (latency). This can be partially dealt with using interrupt priorities but if you start doing the analysis required for that there is another, I think superior, approach; the Run To Completion Executive. More on that later

Example

Most low to Mid-range PLCs use this model for the user programmable portion. The logic runs in a simple loop, it starts at the beginning and runs in a straight line until it reaches the end and then simply goes back to the beginning.

Super Loop

An effort to bring order to the loop is the super loop. The basic concept is to break the program up into separate elements and then each of these elements is broken into small pieces of code that only take a short amount of time. The main portion of the program then simply scans the inputs making them globally available and them calls each element in turn. Each element then executes only one of the small pieces of code before returning to the main.

Inter Process Communication

Communication between elements (at this point we do have separate processes, I've just been calling them elements) is fairly straight forward.  You just use global variables.

Pros

Still fairly simple and does not require an executive

Single stack

Independent processes with private memory are possible

Fits naturally with State Chart processes

Cons

Timing is hard to maintain, breaking each process into small pieces is difficult if the timing doesn't fall at natural boundaries but, say, in the middle of a nested loop.

Easy for a single process to block all others.

Processes have to maintain their state information between successive calls.

Prioritization of processes is difficult

Pausing is difficult

Adding Interrupts

Super loop suffers from the same timing issues as loop but not as severe until the programmer(s) lose control of the breaking of each process into pieces. Interrupts play the same role in a super loop as in the interrupt light version of the loop. An interrupt heavy version is unusual simply because there is usually not enough reason to add that kind of complexity to the background process

Cooperative Tasking

An improvement on the super loop is cooperative tasking. Now each process has its own stack and the program switches between processes by saving the current position of one process on its stack and switching to a second stack and recovering its position from its stack. This switching is done at controlled points in the program either by an explicit call to a yield or a call to a support function that yields (such as pauses, or waiting on a buffer or ...). Cooperative executives can come with or without priority schemes to help schedule processes.

Pros

Each process has its own stack, there is no need to explicitly remember its current state that is now the responsibility of the yield function.

Can be quite efficient

If the executive supports priorities much of the interrupt processing can be split off into a process improving the interrupt latency.

Cons

Added overhead of an executive

Need to sprinkle yields to maintain timing, this can become a maintenance issue. Insufficient yields may increase the latency for a task, too may adds extra overhead.

Pauses and similar timing are now (usually) part of the executive.

Multiple stacks

Inter Process Communication

Usually the executive support several inter process communication types (FIFOs, Semaphores, Buffers, etc...) These simplify communication between processes and now a process may simply wait for information to arrive before running.

Adding Interrupts

Timing issues are often less severe than with a super loop but the same basics drive the use of an interrupt light approach. Communication with the processes in the tasking environment will require special care, often using a restricted subset of the IPC methods.

Interrupt heavy techniques will usually make the systems timing characteristics poorer.

Examples

Novell Netware's Server and early versions of MS Windows were based on cooperative tasking.

Preemptive Tasking

The next step is a move to preemptive tasking.Now the switch between processes (also called tasks) is done outside of the tasks control and can occur anytime during the task execution. An interrupt may cause a task to be stopped or started at any time. In addition (like cooperative tasking) a called to an executive function (pause, read or write FIFO) may also cause a switch.

In real time systems these are usually priority based so that the highest priority available task always runs first. Some systems add time slicing as well where tasks of the same priority will share the process switching tasks at fixed time intervals.

Pros

Timing is now handled by the executive

High priority processes have preference

Cons

Since a task can be interrupted at any time IPC primitives are needed for most communication between processes. This is usually not a big concern.

The executive adds some overhead

There is usually a timer built into the executive. The finer grained the timing interval the more overhead it adds.

Multiple stacks

Inter Process Communication

The executive usually supports a variety of techniques for communicating between processes. These deal with any of the details to prevent problems due to a task switch coming while communication is occurring

Adding Interrupts

Adding interrupts is much the same as for a cooperative tasking executive. There is usually a subset of IPC that can be used. Interrupts are often split into two parts, one that handles the most immediate needs of the interrupt and communicates with the second part. this second part is part of the executive and can run at a different priority. it does the bulk of the work. This improves latency while still allowing fairly complex responses. You can see how this becomes a driver approach.

Example

Free-RTOS. many commercial and free executive available.

Run To Completion Executive

Finally there is the Run To Completion Executive. In this case each process simply runs until it is finished. It is not allowed to wait for any reason. No waiting for an I/O operation to finish, no pauses.

The simple form of this looks like a super loop with worse timing characteristics but less worry about saving state. The interesting form (and the one that makes most sense to use) is the Preemptive Run To Completion Executive. By adding priorities to the tasks and allowing higher priority tasks to interrupt the current task you get a simple and powerful executive.

This has a lot in common with an interrupt heavy version of the loop. Switching to a new task is done by saving the current task position on the stack and starting the new task. When the new task finishes it returns to the previous task where it left off. In this way a task can be interrupted by higher priory tasks multiple times before completing

Pros

Single Stack

Simple (Each process acts like an interrupt)

Fits reactive systems very nicely

Latencies are low for high priority tasks.

Relatively easy to build but it does require experience to do so.

In systems with programmable interrupt priorities the interrupt system can be used as the scheduler. Starting a task then become the equivalent of flagging an interrupt. If is a higher priority than the current task then it will run, otherwise it will wait until all higher priority tasks are complete before starting.

Cons

Some analysis is required to set priorities properly. Hint: see Rate Monotonic Analysis. Despite the name it's really quite simple, Priority is assigned by frequency of task or latency required.

No waiting allowed. If you need to wait the task must exit and then restart when the wait is over (or trigger a separate task for after the wait)

Not may freely available executives available

Inter Process Communication

Can be difficult. Since no waits are allowed conditions like buffer under/overflows must either be ignored (throwing away data) or treated as errors. Most IPC is done is the same fashion as the communication between interrupts and the main process in a loop or super loop.

Communication from a lower priority task to a higher involves blocking at least tasks to that higher priority from running. Managing this can become a burden.

Adding Interrupts

One of the real strengths of this executive. generally there is little no no difference between interrupts and tasks so they fit into the system cleanly. Like co-operative and preemptive tasking systems interrupts may be split into multiple parts at different priorities. This is especially true if the interrupt priorities are fixed, in that case doing this split allows the programmer to effectively re-prioritize a portion of the interrupt response.

Additional Notes

I think I've covered the major executives and techniques used in small systems. Large systems add more variations (especially in scheduling techniques) and you will find many variations on these themes with some systems sharing elements from multiple types. I certainly haven't been exhaustive and I'm sure there are techniques I've missed and certainly there are likely examples for some of the systems that I've neglected.

I did say this would be long and if you've made it this far then thank you for you patience and attention.

Robert

Sunny Chan said:

I'm unclear how you filter A/D. The closest thing I can think of could be a hardware solution?

You must have a hardware filter on the A/D. A simple RC filter low pass filter to keep the input frequencies below the Nyquist frequency is often sufficient. The capacitor acts as the needed charge reservoir (TI calls it a freewheeling capacitor). Look for bookshelf or in the Tags and you will find a reference to TO documentation from their seminars on A/D interfacing with more details.

However, I was referring to SW filtering here. The simplest is an average but that's rather rigid. A little harder to understand but more flexible and using fewer resources is a single pole IIR filter. Some references will tell you that they can only be implemented using floating point but I have done so in integer, you just have to maintain a higher intermediate resolution.

Beyond that filters can get quite complex.

You should at least have a provision for inserting simple filtering and I'd recommend an IIR filter as your default starting point.

Robert

Sunny Chan said:

The reason why I want to have a interrupt driven program is to conserve as much processing power from the launchpad as possible.

I think that goal seems more clear than it actually is. Arguably polling is more conservative of processing power than interrupts.

It does, however, depend on what you mean by conserving processing power and why you want to do it.

There is a story (probably apocryphal and I don't have a handy reference) that in the early mini-computer days a manufacturer want to optimize their instruction set so they profiled a working computer to see what instructions were most frequently executed. They then went and optimized the most frequent instructions. Upon retesting they measured the performance and found it had not improved. Further investigation showed they had succeeded in optimizing the idle loop. The computer successfully sat there doing nothing faster.

Robert

There is a story ...

I might add an appropriate quote from a software guy who's name momentary slipped my mind: "Premature optimization is the root of all evil."

Start thinking about optimization once you got you project running and stable. Doing that before requires a lot of experience, which you not seem to have.

Robert Adsett72 said:

However, I was referring to SW filtering here. The simplest is an average but that's rather rigid. A little harder to understand but more flexible and using fewer resources is a single pole IIR filter. Some references will tell you that they can only be implemented using floating point but I have done so in integer, you just have to maintain a higher intermediate resolution.

If I attempt to average the data I'm getting from the ADC module, I'd figure I'd have to take the raw data, put it into SRAM memory of the tm4c then later fetch the memory from SRAM to average it. Is this the correct method? If it is how would I do it with the tm4c API?

Sunny Chan said:

If I attempt to average the data I'm getting from the ADC module, I'd figure I'd have to take the raw data, put it into SRAM memory of the tm4c then later fetch the memory from SRAM to average it. Is this the correct method?

That's essentially correct.

Sunny Chan said:

If it is how would I do it with the tm4c API?

I don't think the API affects it.

Robert