PM GetLEDPattern*

# PM_GetLEDPattern*

## Syntax

      #include <nitro/spi.h>

      u32 PM_GetLEDPattern( PMLEDPattern* patternBuf );

      u32 PM_GetLEDPatternAsync( PMLEDStatus* patternBuf, PMCallback callback, void* arg );

## Arguments

patternBuf | Buffer that stores the value of the LED pattern to be obtained.
callback | Callback that is called when the command finishes.
arg | Argument that is used when calling the callback.

## Return Values

If `PM_RESULT_SUCCESS`, the command execution has succeeded (for synchronous functions), or the command was successfully sent to the ARM7 processor (for asynchronous functions).

If `PM_RESULT_BUSY`, the SPI was occupied by other processing and unable to process this function.

## Description

Gets the LED state of the console.

The patternBuf argument is a buffer that stores the `PMLEDPattern` list type values. It takes a value that indicates the state of the LED when it is not `NULL`. It will take one of the following values.

`Value Stored in patternBuf` | LED State
--- | ---
`PM_LED_PATTERN_ON` | The LED is illuminated.
`PM_LED_PATTERN_BLINK_LOW` | The LED is blinking at a high speed.
`PM_LED_PATTERN_BLINK_HIGH` | The LED is blinking at a low speed.
`PM_LED_PATTERN_BLINK1` | The LED is repeating a lit/unlit pattern every 1 frame.
`PM_LED_PATTERN_BLINK2` | The LED is repeating a lit/unlit pattern every 2 frames.
`PM_LED_PATTERN_BLINK3` | The LED is repeating a lit/unlit pattern every 3 frames.
`PM_LED_PATTERN_BLINK4` | The LED is repeating a lit/unlit pattern every 4 frames.
`PM_LED_PATTERN_BLINK5` | The LED is repeating a lit/unlit pattern every 5 frames.
`PM_LED_PATTERN_BLINK6` | The LED is repeating a lit/unlit pattern every 8 frames.
`PM_LED_PATTERN_BLINK8` | The LED is repeating a lit/unlit pattern every 8 frames.
`PM_LED_PATTERN_BLINK10` | The LED is repeating a lit/unlit pattern every 10 frames.
`PM_LED_PATTERN_PATTERN1` | The LED is blinking in a predetermined pattern.
`PM_LED_PATTERN_PATTERN2` | The LED is blinking in a predetermined pattern.
`PM_LED_PATTERN_PATTERN3` | The LED is blinking in a predetermined pattern.

The "high-speed blink" and "low-speed blink" are blink features that are implemented on the hardware. Although the term "high-speed" is used, the blinking speed is actually slower than the blinking speed that is caused by the software that repeats the lit/unlit pattern in a fixed number of frames.)

This function uses PXI to send a command to execute the operation in question on the ARM7 processor. Once it receives that command, the ARM7 executes it by manipulating the PMIC. Therefore, this function may not operate instantly after you call it. A synchronous function that waits for the operation to finish, as well as an asynchronous function that only sends commands to the ARM7, are provided. Use either of the functions depending on your operational requirements. (The asynchronous function has "Async" appended to the function name.))

When an asynchronous function is called, the specified callback is called when processing on the ARM7 side finishes. The callback type `PMCallback` is defined by:

> ``typedef void ( *PMCallback )( u32 result, void* arg )`;`

This callback is called from inside the PXI interrupt handler.

The callback's first argument, result, indicates the result of the command. This is either `PM_RESULT_SUCCESS` or `PM_RESULT_ERROR`. The second argument in the callback returns the value arg.

Before you use this function, initialize the PM library with the `PM_Init` function. (The `PM_Init` function has to be called only once. Also, when you call the `OS_Init` function, there is no need to call the `PM_Init` function separately because it is called from inside `OS_Init`.)

This function can be used from an interrupt handler. This function cannot be used in interrupt-prohibited states other than interrupt handlers.

About `PM_RESULT_BUSY`

The SPI is used for various other processes besides power management. If you call this function while another process is using it, this function sends a command to the ARM7. There, the SPI is determined to be BUSY, and `PM_RESULT_BUSY` is notified to the ARM9 without actually processing this function. Likewise, if you call this function while another PM process is running, that fact is determined on the ARM9 side, and this function returns `PM_RESULT_BUSY`. (In this case, the determination is made before notification is sent to the ARM7.)

Accordingly, if you want to ensure that this function succeeds, make it loop until it succeeds as shown below. (This example does not take into account mistakes such as wrong arguments.)

> Example
> `while( PM_GetLEDPattern( ... ) != PM_RESULT_SUCCESS )
> {
> }`

## See Also

`PM_Init`

## Revision History

2008/12/05 Added a note about use in interrupt-prohibited states.
2008/08/23 Quit using `PM_RESULT_ERROR` and elaborated on `PM_RESULT_BUSY`.
2005/07/07 Elaborated on the return value `PM_RESULT_ERROR`.
2005/06/02 Clarified the caller of the callback.
2004/08/26 Initial version.

CONFIDENTIAL