Portable Game Console Project - Clock Control and Power Saving

As I've mentioned in my previous blogpost, the clock control mechanism were implemented. But I've been too busy to blog about that. Now I've got a moment to do a write-up of the game console project about that.

Clock Control System Design Rationale

The microcontroller STM32F030F4P6 is capable for running at 48Mhz. The 48Mhz system clock is generated from 8Mhz HSI clock. It's multiplied with PLL by up to 12 to generate a system clock of up to 48Mhz.

Reducing Power Consumption

The game console will be battery-powered. Power consumption is critical to the battery life. To minimize the power consumption, we allow the game to enter sleep mode. With frame limiting, it's highly probable for the game to have some idle time before it is required to process the next frame. During that period of time, the game would enter sleep more to save power. Of course we'd disable the PLL in sleep mode to further reduce the power consumption. And that'd cause the system clock to be limited to 8Mhz when it's sleeping.

Sound Distortion Problem: Modification of Timer Prescaler

And here's a problem. There're many clocks derived from the system clock in the microcontroller. Most of them aren't very time-critical. However, for sound generation, timing is very important. Otherwise the sound generated would be distorted.

There're two causes of sound distortion. One is the selection of using, or not using PLL. Another is modification of timer prescaler. It's empirically determined that the sound distortion caused by toggling the state of usage of PLL is negligible. However, changing the timer prescaler does affect the sound quality for quite a bit.

The Compromise between Sound Quality and Performance

Since changing the timer prescaler would affect the sound quality, we'd want to avoid that. Unfortunately, if we want to preserve the value of the timer prescaler, and if we still want to enter sleep mode to save power, the maximum possible clock would be limited 32Mhz instead of 48Mhz.

Here's the reason behind it: The timer clock can be calculated with this (overly simplified) equation:

(timer clock) = (system clock) / (APB1 prescaler [including the x2 mechanism]) / (timer prescaler + 1)

Timer clock has to be a multiple of 8. APB1 prescaler has to be power of two. Timer prescaler can be any integer.

Since we need to enter sleep mode, we have to set the system clock to 8Mhz at some point of the program. Let's assume that we set the APB1 prescaler=1 and timer prescaler=3 at 8Mhz. So (timer clock) = 8Mhz / 1 / (3+1) = 2Mhz.

If we want to maintain the same timer clock without changing the timer prescale at 32Mhz, we could easily do that by just changing the APB1 prescaler to 4. So we get (timer clock) = 32Mhz / 4 / (3+1) = 2Mhz, that's still 2Mhz. Therefore, the sound quality would be good at 32Mhz.

However, things get tricky if we want to maintain the same timer clock as 8Mhz at 48Mhz. If we aren't changing the timer prescaler, we'd need to pick APB1 prescaler=6. However, APB1 prescaler has to be a power of two. So it has to be rounded to APB1 prescaler=8. Then we'd be forced to change the timer prescaler from 3 to 2 in order to maintain the timer clock. So we get (timer clock) = 48Mhz / 8 / (2+1) = 2Mhz. However, the switching of timer prescaler will cause noticable sound distortion as shown below:

32Mhz without frame limiting, no sound distortion:

32Mhz with frame limiting, negligible sound distortion:

48Mhz without frame limiting, no sound distortion:

48Mhz with frame limiting, noticable sound distortion:

Solution: Let the developer decide

Our solution is to let the game itself decide to use 32Mhz or 48Mhz clock. If the game prefers higher sound quality, then it should stick with 32Mhz. If it wants performance, it should choose 48Mhz. If the game has sound, it's recommended to use 32Mhz as possible and switch to 48Mhz only when doing computation-intensive stuffs.

I've made a minimalist breakout game. At clock rate of 32Mhz without frame-limiting, it can achieve 40fps with around 80 bricks, and 250fps with no bricks. The recommended fps is 8~10fps because of the hardware limitation of the update rate of LCD. Since the max fps is much higher than the target fps, the game console can save quite a lot of power by doing the frame-limiting to 8~10fps with the use of sleep mode. :)

Clock Control System Design and API Calls Listing

It's very simple. There's just one API call that modifies the clock system. That's:

• void systemSleep(unsigned int milliseconds, bool wakeUpToBoostMode);

If wakeUpToBoostMode is true, it'd enter 48Mhz mode after the end of the sleep. Otherwise that'd be 32Mhz.

And it has a few other API calls for querying the status of the clock system:

• unsigned int systemGetTick(void);
• bool systemIsBoostMode(void);

Typical Usage of Clock Control System

Clock Control System is mainly used for frame-limiting and saving power. In the game, there's a main loop. The game should call systemSleep() after the end of processing of each frame.

Here's the typical usage inside the main loop:

1. Get the current tick in millisecond by using systemGetTick(). Save it to the variable previousTick.
2. Process the game frame and draw the stuffs onto the graphical buffer
3. Calls systemSleep() with the sleep duration being (1000/fps)-(systemGetTick()-previousTick). If the sleep duration calculated is negative, then do not sleep.

Other Progress to be Blogged in the Future

The following features were implemented. But I'm saving them for the coming blogpost:

• Removal of EXTIF in favor of using existing function calling convention
• Sample game (minimalist breakout game)

What's next?

I'll be working on the following stuffs:

• Tweaking the storage API by adding "offset" parameter to it
• Second prototype of the Game Console, with microcontroller upgrade, LCD upgrade and GPIO!

Stay tuned. I'll make another blogpost soon! :)