Armadillo 開発者サイト

The i.MX25 processor incorporates five UART modules, UART1 to UART5. On the Armadillo-400 Series, by default UART2 is used for Serial Interface 1 (CON3), UART3 for Serial Interface 2 (CON9), and UART5 for Serial Interface 3 (CON9). Also, UART3 and UART4 can be assigned to CON11 by altering the kernel configuration. When using UART9 or UART11, CTS/RTS hardware flow control can be selectively enabled or disabled.

The UART driver has the following functionality.

Each serial interface and their corresponding device files are shown in 表8.1「Serial Interface Device Files」.

Kernel configuration options related to the UART functionality are shown in 表8.2「UART Configuration」.

The Armadillo-400 Series Ethernet driver has the following functionality.

The i.MX25 processor incorporates two SD/MMC/SDIO host controllers (eSDHC). On the Armadillo-400 Series, by default eSDHC1 is used for the microSD slot (CON1). Also, eSDHC2 can be assigned to CON9 by altering the kernel configuration.

The Armadillo-400 Series SD/MMC/SDIO host driver has the following functionality.

When a card is inserted in the microSD card slot, it will be registered as /dev/mmcblkN (N is 0 or 1).

Kernel configuration options related to the SD/MMC/SDIO host functionality are shown in 表8.3「SD/MMC/SDIO Host Controller Configuration」.

The Armadillo-400 Series USB 2.0 host driver has the following functionality.

When a USB device is detected, it will be mapped to /dev/sd*.

The video out function on Armadillo-440 is implemented as a frame buffer device.

The frame buffer device driver has the following functionality.

The default settings on the Armadillo-440 LCD Model are shown below.

The frame buffers and their corresponding device files are shown in 表8.4「Frame Buffer Device Files」.

The LED backlight function on Armadillo-440 is implemented as a backlight class driver.

The backlight can be controlled with the files under the /sys/class/backlight/pwm-backlight directory.

The brightness can be adjusted with the brightness file. Write a value between 0 (off) and 255 (full brightness) to the brightness file to change the brightness.

The current brightness can be obtained by reading the value from the brightness file.

The backlight on/off can be controlled with the bl_power file. Write 0 to bl_power to turn the backlight off and write 1 to turn it back on.

The touchscreen function on Armadillo-440 is implemented as an input device and offers an event interface to userland programs.

The events sent by the interface are shown in 表8.5「Touchscreen Events」.

On the Armadillo-440 LCD Model, by default the touchscreen event device is mapped to /dev/input/event1.

	The event device file numbers are determined by the order the input devices are detected. Therefore, if another input device such as a USB keyboard is detected at boot time, the event device number of the touchscreen may change.

The audio function on the Armadillo-400 Series is implemented as an ALSA device driver. The ALSA device driver has the following functionality.

The audio device can be controlled via the ALSA library (libasound2).

	The Armadillo-400 Series audio driver cannot record and play sound at the same time.

On the i.MX25, it is possible to select what pins to assign the audio function to with the audio multiplex function. On the Armadillo-400 Series, the audio multiplex settings can be changed in the kernel configuration. By default, the audio multiplexing is set to use AUD6, with the audio function connected to CON11. By altering the configuration, it is possible to connect the audio function to CON9 by using AUD5.

Kernel configuration options related to the audio functionality are shown in 表8.6「Audio Configuration」.

The GPIO on the Armadillo-400 Series are implemented as generic GPIO.

There are two interfaces available to manipulate GPIO from userland: GPIO sysfs and an Armadillo-200 Series compatible GPIO driver. The GPIO sysfs driver is enabled by default.

Pins that do not have any other function assigned to them in the kernel configuration are all set to be GPIO.

#include <stdio.h>
#include <unistd.h>
#include <poll.h>
#include <fcntl.h>

#define GPIO_DIR "/sys/class/gpio"
#define GPIO_NAME "CON9_1"
#define GPIO_PATH GPIO_DIR "/" GPIO_NAME "/"

int main(void)
{
        int fd;
        int i;

        fd = open(GPIO_PATH "direction", O_RDWR);
        write(fd, "in", 2);
        close(fd);

        fd = open(GPIO_PATH "edge", O_RDWR);                                 
        write(fd, "falling", 7);
        close(fd);

        for (i=0; i > 3; i++) {
                char val;
                struct pollfd pfd;

                fd = open(GPIO_PATH "value", O_RDWR);                        
                read(fd, &val, 1);                                           

                printf("waiting for interrupt..."); fflush(stdout);

                pfd.fd = fd;
                pfd.events = POLLIN;
                pfd.revents = 0;
                poll(&pfd, 1, -1);                                           

                lseek(fd, 0, SEEK_SET);                                      
                read(fd, &val, 1);
                close(fd);

                printf("OK (%c, %s)\n", val, val == '0' ? "Low" : "High");
                usleep(100000);
        }

        return 0;
}

8.9.2. Armadillo-200 Series Compatible GPIO Driver

With the Armadillo-200 Series compatible GPIO driver, GPIO are manipulated by issuing ioctl function calls to the driver specific device file.

	The Armadillo-200 Series compatible GPIO driver is not enabled by default. To enable the driver, in the kernel configuration enable the CONFIG_ARMADILLO2X0_GPIO option after disabling the CONFIG_GPIO_SYSFS option and then rebuild the kernel.

The GPIO names and corresponding GPIO pins for the Armadillo-200 Series compatible GPIO driver are shown in 表8.10「Armadillo-200 Series Compatible GPIO Driver GPIO List」.

表8.10 Armadillo-200 Series Compatible GPIO Driver GPIO List

GPIO Name	GPIO Pin	Initial I/O Direction	Initial Output Level
GPIO0	CON9 pin 21	Input	-
GPIO1	CON9 pin 22	Input	-
GPIO2	CON9 pin 23	Input	-
GPIO3	CON9 pin 24	Input	-
GPIO4	CON9 pin 25	Input	-
GPIO5	CON9 pin 26	Input	-
GPIO6	CON9 pin 27	Output	LOW
GPIO7	CON9 pin 28	Output	LOW
GPIO8	CON9 pin 11	Input	-
GPIO9	CON9 pin 12	Input	-
GPIO10	CON9 pin 13	Input	-
GPIO11	CON9 pin 14	Input	-
GPIO12	CON9 pin 15	Input	-
GPIO13	CON9 pin 16	Input	-
GPIO14	CON9 pin 17	Input	-
GPIO15	CON9 pin 18	Input	-

	With the Armadillo-200 Series compatible GPIO driver, the GPIO names and the corresponding GPIO pin positions are the same as those on the Armadillo-200 Series. Because of this, only a subsection of the GPIO available on the Armadillo-400 Series can be used with the Armadillo-200 Series compatible GPIO driver.

The details of the device file are shown below.

表8.11 Armadillo-200 Series Compatible GPIO Driver Device File

Type	Major Number	Minor Number	Device File
Character device	10	185	/dev/gpio

The file descriptor of the device file is specified as the first argument to ioctl, and the command to manipulate the GPIO is specified as the second argument.

表8.12 Armadillo-200 Series Compatible GPIO Driver ioctl Commands

Command	Description	Third Argument Type
PARAM_SET	Configure GPIO with the state specified in the third argument	struct gpio_param
PARAM_GET	Get GPIO state by following the details specified in the third argument	struct gpio_param
INTERRUPT_WAIT	Wait for GPIO interrupt by following the details specified in the third argument	struct wait_param

The structures "struct gpio_param" and "struct wait_param" defined in (kernel source)/include/linux/armadillo2x0_gpio.h are used for the third argument. "struct gpio_param" can be linked with its "next" member to form a singly-linked list in order to control multiple GPIO at once. Be sure to set the "next" member of the last structure of the list to "0 (NULL)". For detailed usage information, please refer to the source code of the GPIO control application (atmark-dist/vendors/AtmarkTechno/Armadillo-440/gpioctrl).

There are two LED drivers for the Armadillo-400 Series: a LED class driver and an Armadillo-200 Series compatible LED driver. The LED class driver is enabled by default.

8.10.2. Armadillo-200 Series Compatible LED Driver

With the Armadillo-200 Series compatible LED driver, LEDs are manipulated by issuing ioctl function calls to the driver specific device file.

	The Armadillo-200 Series compatible LED driver is not enabled by default. To enable the driver, in the kernel configuration enable the CONFIG_ARMADILLO2X0_LED option after disabling the CONFIG_LEDS_GPIO option and then rebuild the kernel.

The details of the LED device file are shown below.

表8.14 LED Node

Type	Major Number	Minor Number	Device File
Character device	10	215	/dev/led

The file descriptor of the device file is specified as the first argument to ioctl, and the command to manipulate the LEDs is specified as the second argument.

表8.15 LED Manipulation Commands

Command	Description	Third Argument Type
LED_RED_ON	Turn LED3 (red) on	None
LED_RED_OFF	Turn LED3 (red) off	None
LED_RED_STATUS	Obtain state of LED3 (red)	Buffer to store state (1 byte min)
LED_RED_BLINKON	Start LED3 (red) blinking	None
LED_RED_BLINKOFF	Stop LED3 (red) blinking	None
LED_RED_BLINKSTATUS	Obtain blinking status of LED3 (red)	Buffer to store state (1 byte min)
LED_GREEN_ON	Turn LED4 (green) on	None
LED_GREEN_OFF	Turn LED4 (green) off	None
LED_GREEN_STATUS	Obtain status of LED4 (green)	Buffer to store state (1 byte min)
LED_GREEN_BLINKON	Start LED4 (green) blinking	None
LED_GREEN_BLINKOFF	Stop LED4 (green) blinking	None
LED_GREEN_BLINKSTATUS	Obtain blinking status of LED4 (green)	Buffer to store state (1 byte min)

For detailed usage information on the LED device driver, please refer to the source code of the sample LED control application (atmark-dist/vendors/AtmarkTechno/Armadillo-440/ledctrl).

The button input function on the Armadillo-400 Series is implemented as an input device and offers an event interface to userland programs.

On the Armadillo-440 LCD Model, the Armadillo-440 has one on-board tact switch and the LCD Expansion Board has three buttons mounted.

The buttons and their corresponding events are shown in 表8.16「Armadillo-440 LCD Model Button Events」.

On the Armadillo-440 LCD Model, by default the button event device is mapped to /dev/input/event0.

	The event device file numbers are determined by the order the input devices are detected. Therefore, if another input device such as a USB keyboard is detected at boot time, the event device number of the button function may change.

A real-time clock is incorporated on the Armadillo-440 LCD Expansion Board and the Armadillo-400 RTC Option Module.

The real-time clock is registered as /dev/rtc0. When using the RTC Option Module with the Armadillo-440 LCD Model, the real-time clock on the RTC Option Module is registered as /dev/rtc0, and the real-time clock on the LCD Expansion Board becomes /dev/rtc1.

The i.MX25 processor on the Armadillo-400 Series boards includes an internal watchdog timer.

The default bootloader on the Armadillo-400 Series enables the internal watchdog timer straight after the board is powered on. It is set to time out after 10 seconds by default.

The watchdog timer is kicked automatically by the Linux kernel.

If for some reason the Linux kernel freezes and as a result is unable to kick the watchdog timer and a time-out occurs, the system will reset.

The i.MX25 processor includes three I2C controllers: I2C1 to I2C3. On the Armadillo-400 Series, by default I2C1 is used as a board internal bus, I2C2 is assigned to CON14 and I2C3 to CON11.

The I2C bus driver has the following functionality.

In order to use a slave device connected to an I2C bus, a chip driver for the appropriate device must be enabled. Also, if the chip driver is written in "new style"^[18], struct i2c_board_info must be configured appropriately. For the Armadillo-400 Series, please add the details to the armadillo400_i2cN_board_info array in linux-2.6.26-at/arch/arm/maxh-mx25/armadillo400.c (where N corresponds to the bus number).

Kernel configuration options related to the I2C functionality are shown in 表8.17「I2C Configuration」.

The i.MX25 processor includes three SPI controllers: CSPI1 to CSPI3. On the Armadillo-400 Series, CSPI1 and CSPI3 can be assigned to CON9 in the kernel configuration.

The SPI master driver has the following functionality.

The SPI master driver is not enabled by default. In order to use a slave device connected to a SPI bus, both the SPI master driver and a driver for the slave device must be enabled. Also, a struct spi_board_info must be configured appropriately. On the Armadillo-400 Series, please add the details to the armadillo400_spiN_board_info array in linux-2.6.26-at/arch/arm/maxh-mx25/armadillo400.c (where N corresponds to the bus number).

Kernel configuration options related to the SPI functionality are shown in 表8.18「SPI Configuration」.

CON9_2 and CON9_26 can be used as one wire masters on the Armadillo-400 Series. The one wire controller included in the i.MX25 processor provides the master functionality for CON9_2, and the GPIO one wire driver provides the same for CON9_26.

The one wire master drivers are not enabled by default. In order to use a slave device connected to a one wire bus, both a one wire master driver and a driver for the slave device must be enabled.

Kernel configuration options related to the one wire functionality are shown in 表8.19「One Wire Configuration」.

The i.MX25 processor includes four PWM modules: PWM1 to PWM4. On the Armadillo-400 Series, by default PWM1 is used for the LED backlight (CON11_12). PWN2 can be assigned to CON9_25 and PWM4 to CON14_3 by altering the kernel configuration.

With the i.MX25 PWM driver, configuration can be changed by writing an appropriate value to the files under /sys/class/mxc_pwm/(PWM_NAME). Files used for configuration are shown in 表8.20「PWM sysfs」.

Kernel configuration options related to the PWM functionality are shown in 表8.21「PWM Configuration」.

The i.MX25 processor includes two CAN controllers (FlexCAN): CAN1 and CAN2. On the Armadillo-400 Series, CAN2 can be assigned to CON14 by altering the kernel configuration. The CAN driver is not enabled by default.

The CAN functionality is provided by the SocketCAN framework. For information on SocketCAN, please refer to linux-2.6.26-at/Documentation/networking/can.txt.

The CAN driver has the following functionality.

Configuration can be changed by writing an appropriate value to the files under /sys/devices/platform/FlexCAN.1/. Files used for configuration are shown in 表8.22「CAN sysfs」^[19].

Transmission speed is determined by the following formula.

src_clk = 66,500,000 (br_clksrc = bus condition)
src_clk = 24,000,000 (br_clksrc = osc condition)
Transmission Speed[bps] = src_clk / br_presdiv / (1 + br_propseg + br_pseg1 + br_pseg2)

Kernel configuration options related to the CAN functionality are shown in 表8.23「CAN Configuration」.

The i.MX25 processor includes a keypad controller. On the Armadillo-400 Series, the keypad can be assigned to CON11 by altering the kernel configuration. The keypad driver is not enabled by default.

	When the keypad driver is enabled, the event device will be mapped to /dev/input/event0. This will cause the default button and touchscreen event device numbers to change.

Kernel configuration options related to the keypad functionality are shown in 表8.24「Keypad Configuration」.

To set what ROW and COL range is used for the keypad, specify the appropriate values in the armadillo440_keypad_data variable in linux-2.6.26-at/arch/arm/maxh-mx25/armadillo400.c. Specify the button to event key mappings in the armadillo440_keymapping variable.

The Armadillo-400 Series support the Linux power management sleep functionality. In the sleep state, the execution of applications is paused and the kernel enters the suspend state. Power consumption is kept at a minimum during the sleep state as the operation of external devices is halted. When returning to the normal execution state from the sleep state, the kernel's resume logic is run and applications are returned to a running state.

Sleep mode can be entered by writing either "standby" or "mem" to the /sys/power/state file. The system will return to the normal execution state from sleep mode when a wakeup interrupt occurs.

The differences in state of each mode are shown in 表8.25「Sleep Modes」. The suspend-to-RAM sleep mode provides for a greater reduction in power consumption compared to the power-on suspend mode.

For devices that can be used as a basis for wakeups, whether or not they do trigger a wakeup can be specified with their power/wakeup sysfs entry. Write "enabled" to the power/wakeup file and the device will function as a basis for wakeups, and write "disabled" and they will not.

Please refer to 表8.26「Wakeup Basis Designation」 for details.