EECS 373: Design of Microprocessor

download report

Transcript EECS 373: Design of Microprocessor

EECS 373:
Design of Microprocessor-Based Systems
Timers, count, capture and PWM
Some material from Thomas Schmid, Mark Brehob
• HW1/Proj1 Status?
• Ira Glass:
• Background on time and clocking on a
• SmartFusion clocks and features
• How we use timers
• Design of a memory-mapped Pulse-Width
Modulation (PWM) circuit.
Time in Embedded Systems:
Where do we need accurate time?
• Scheduling of computation
– Scheduler in operating systems
– Real time operating systems
• Signal sampling and generation
– Audio sampling at 44.1 kHz
– TV/video generation (sync, vsync)
– Pulse Width Modulated (PWM) signals
• Communication
– Media Access Control (MAC) protocols
– Modulation
• Navigation
Fine grain motion control
Clock generation and use
• Resonating element/Driver:
– Quartz crystal can be made to resonate
due to Piezoelectric effect.
• Resonate frequency depends on length,
thickness, and angle of cut.
• Issues: Very stable (<100ppm) but not all
frequencies possible.
– MEMS Resonator
• Arbitrary frequency, potentially cheap,
susceptible to temperature variations.
– Others:
• Inverter Ring, LC/RC circuits, Atomic clock,
and many more.
Clock Driver
Timers on the SmartFusion
Timers on the SmartFusion
• SysTick Timer
– ARM requires every Cortex-M3 to have this timer
– Essentially a 24-bit down-counter to generate
system ticks
– Has its own interrupt
– Clocked by FCLK with optional programmable
• See Actel SmartFusion MSS User Guide for
register definitions
Timers on the SmartFusion
Timers on the SmartFusion
• System timer
– “The System Timer consists of two programmable
32-bit decrementing counters that generate
interrupts to the ARM® Cortex™-M3 and FPGA
fabric. Each counter has two possible modes of
operation: Periodic mode or One-Shot mode. The
two timers can be concatenated to create a 64-bit
timer with Periodic and One-Shot modes. The two
32-bit timers are identical”
Features of Timers
a.k.a. “terms you need to know”
• Time is kept in the hardware counter
– Resolution: How often the hardware counter is
– Precision: The smallest increment the software
can read the counter.
– Accuracy: How close we are to UTC
– Range: The counter reads a value of (f*t) mod 2n.
Range is the biggest value we can read.
UTC is Coordinated Universal Time (French is Temps Universel Coordonné). I just work here…
Who cares?
• There are two basic activities one wants
timers for:
– Measure how long something takes
• “Capture”
– Have something happen every X time period.
• “Compare”
Example #1 -- Capture
– Say you have a fan spinning and you want to know how
fast it is spinning. One way to do that is to have it throw an
interrupt every time it completes a rotation.
• Right idea, but might take a while to process the interrupt, heavily
loaded system might see slower fan than actually exists.
• This could be bad.
– Solution? Have the timer note immediately how long it
took and then generate the interrupt. Also restart timer
• Same issue would exist in a car when measuring speed
of a wheel turning (for speedometer or anti-lock
Example #2 -- Compare
• Driving a DC motor via PWM.
– Motors turn at a speed determined by the voltage
• Doing this in analog land can be hard.
– Need to get analog out of our processor
– Need to amplify signal in a linear way (op-amp?)
• Generally prefer just switching between “Max” and “Off”
– Average is good enough.
– Now don’t need linear amplifier—just “on” and “off”. (transistor)
– Need a signal with a certain duty cycle and frequency.
• That is % of time high.
Virtual timers
• You never have enough timers.
– Never.
• So what are we going to do about it?
– How about we handle in software?
Virtual Timers
• Simple idea.
– Maybe we have 10 events we might want to
• Just make a list of them and set the timer to go off for
the first one.
– Do that first task, change the timer to interrupt for the next
• Only works for “compare” timer uses.
• Will result in slower ISR response time
– May not care, could just schedule sooner…
Implementation issues
• Shared user-space/ISR data structure.
– Insertion happens at least some of the time in user code.
– Deletion happens in ISR.
• We need critical section (disable interrupt)
• How do we deal with our modulo counter?
– That is, the timer wraps around.
– Why is that an issue?
• What functionality would be nice?
– Generally one-shot vs. repeating events
– Might be other things desired though
• What if two events are to happen at the same time?
– Pick an order, do both…
Implementation issues (continued)
• What data structure?
– Data needs be sorted
• Inserting one thing at a time
– We always pop from one end
– But we add in sorted order.