Content originally posted in LPCWare by MarcVonWindscooting on Sun Nov 16 12:25:28 MST 2014
I want to program beep() functionality with CPU in sleep mode.
I planned the following: SCT lower 16bits ("SCT-L"): frequency generator, SCT upper bits ("SCT-H") duration. The output CTOUT0 always has to end with level LOW. Due to the limited range of the match registers, SCT-H runs at a lower frequency to get reasonable durations. For frequency generation I use 1us cycle time, for duration 20us. CTOUT1 is used as communication between SCT-L and SCT-H.
The whole beep runs from the SCT alone without CPU intervention as follows (no sleep mode used so far):
when calling beep(), CTOUT1 is set to 0 (active) and both SCT-L and SCT-H cleared and started.
SCT-H has one match (event EV_END), that causes CTOUT1 to be set and SCT-H stopped.
SCT-L toggles CTOUT0 using mathes at value 0 (clear CTOUT0) ("EV_L"/"EV_HALT") and t/2 (set CTOUT0) ("EV_H") and a bidirectional counter. EV_HALT is configured to HALT [color=#f00]both[/color] SCT-L and SCT-H besides clearing CTOUT0. EV-HALT happens at match value 0, if CTOUT1=1. EV-L at the same match, if CTOUT1=0 (active) and only clears CTOUT0. EV_H sets CTOUT0 and reverses counting direction (limit event).
The observation is: SCT-H ist NOT halted by EV_HALT (SCT.CTRL.HALT_H not set).
Okay, it's stopped already, but I wanted the SCT.CTRL.HALT_H as the single authoritive value indicating, that the next beep can be started.
I assume, it's because of the different clocks/prescalers. Some kind of synchronization problem. But that synchronization is exactly what I'm after ;) Has anybody experienced a similar problem?
I can do a workaround (halting SCT-H in the first place, later checking for both HALT flags). What is the expected behaviour?
The SCT documentation does not clarify this situation.
EDIT: uC: LPC812, later LPC810.
