Lindus Embedded

Compile Android’s kernel tree

This generates a file named arch/arm/boot/zImage

Compile Android’s emulator kernel

This generates a file named arch/arm/boot/zImage

Both the standard and emulator kernels are provided precompiled in the SDK at ${SDK_ROOT}/prebuilt/android-arm/kernel.

You can now run the emulator as:

Note that as a convenience, if the name of the kernel image ends with -armv7, then the cortex-a8 emulation will be turned on automatically. Otherwise you would have to pass the flags manually (-qemu -cpu cortex-a8).

Reportedly the qemu emulator included in the Android SDK doesn’t support ARMv7 emulation properly.

RS232 focusses on the connection of DTE, data terminal equipment (computers, printers, etc.) with DCE, data communication equipment (modems).RS232 cables can use DB25 or DB9 connectors. DB25 connectors have provision for two RS232 connections, but the single connection DB9 is most commonly used.

RS323 DB9 pinout

DTE to DTE connections through a null modem cable (PC to PC)

The purpose of a null-modem cable is to permit two RS-232 DTE devices to communicate with each other without modems or other communication devices (i.e., DCEs ) between them.

A null modem cable is an RS232 serial cable where the transmit and receive lines are crosslinked. In some cables there are also handshake lines crosslinked. In many situations a straight through serial cable is used, together with a null modem adapter. The adapter contains the necessary crosslinks between the signals.

Null modem without handshaking

Null modem with loop back handshaking

Null modem with partial handshaking

Null modem with full handshaking

Software flow control (XOFF/XON)

When one end of a data link is unable to accept any more data (or approaching that point), it sends XOFF to the other end. The other end receives the XOFF code, and suspends transmission.

Once the first end is ready to accept data again, it sends XON, and the other end resumes transmission.

Requires less wiring and is slower, as sending XOFF requires at least one character time to transmit, it may be queued, has to be done in software and has the overhead of escaping the control codes so that they are not confused with data.

XOFF/XON representations in ASCII

Hardware flow control

In common RS232 there are pairs of control lines:

• RTS flow control, RTS/CTS
• DTR flow control, DTR/DSR

Hardware flow control is typically handled by the DTE or “master end”, as it is first raising or asserting its line to command the other side.

In case of RTS control flow, DTE sets its RTS, which signals the opposite end (the slave end such as a DCE) to begin monitoring its data input line. When ready for data, the slave end will raise its complementary line,

CTS in this example, which signals the master to start sending data, and for the master to begin monitoring the slave’s data output line. If either end needs to stop the data, it lowers its respective “data readyness” line.

For PC-to-modem and similar links, the case of DTR flow control, DTR/DSR are raised for the entire modem session (say a dialup internet call), and RTS/CTS are raised for each block of data.

Testing serial ports with stty

Print configuration

Set to 38400, no flow control, one stop bit, odd parity, 8 bit, disable special characters

On target,

On host,

To turn on the hardware flow control, do:

What are GPIOs?

GPIOs are very common in embedded hardware, representing pins connected to ball grid array (BGA)
packages.They are commonly used to provide flexibility in System On Chip (SOC), and
it is common for pins to be multiplexed and shared for different functionality. As such,
GPIOs are specific to each platform and we can only speak in generic terms.

Usually they can be used as writable output and readable inputs which can also be used
as IRQs.

Generic GPIO API

Linux platforms that support GPIO conventions declare GENERIC_GPIO, and drivers use the
interface in linux/gpio.h. GPIOs are identified by platform specific integer
numbers, with negative numbers being invalid.

int gpio_is_valid(int number);

Check whether a given number is a valid GPIO.

int gpio_request(unsigned gpio, const char *label);

Request a GPIO returning 0 on success or a negative error value.

void gpio_free(unsigned gpio);

Frees a previously requested GPIO.

int gpio_direction_input(unsigned gpio);
int gpio_direction_output(unsigned gpio, int value);

Set the direction of the GPIO returning 0 on success or a negative error value.

int gpio_get_value(unsigned gpio);
void gpio_set_value(unsigned gpio, int value);

The getter return 0 or 1 (high or low), and the setter sets 0 or 1 (high or low).

Most GPIO controllers are accessed withouth the need for sleep and can be safely
accessed through IRQ handlers. Some use message buses like I2C or SPI which may sleep,
and this should be accessed by the following accessors:

int gpio_get_value_cansleep(unsigned gpio);
void gpio_set_value_cansleep(unsigned gpio, int value);

Platform code will have defined the mapping between the GPIOs and IRQs number
namespaces, so we can use the following functions to swap between them.

int gpio_to_irq(unsigned gpio);
int irq_to_gpio(unsigned irq);

Not al GPIOs can be configured as IRQs and in that case they will return a negative
errno.

GPIOLIB

An optional framework to support diferrent GPIO controllers (packaged as a “struct
gpio_chip”) with the same API. With debugfs available, /sys/kernel/debug/gpio lists all
registered controllers and the state of used GPIOs. The platform will define
ARCH_REQUIRE_GPIOLIB to compile the framework in, ARCH_WANT_OPTIONAL_GPIOLIB to let the
user built it into the kernel optionally, or none if GPIOLIB is not supported.

SYSFS support

When using GPIOLIB, a sysfs interface can be enabled to control GPIO directon and value
from userspace. The control interface lives in /sys/class/gpio.

echo 19 > /sys/class/gpio/export

Will create a gpio19 node and request the GPIO number 19.

echo 19 > /sys/class/gpio/unexport

Will free the GPIO 19.

echo "in" > /sys/class/gpio/gpio19/direction
echo "out" > /sys/class/gpio/gpio19/direction

Will configure it as input or output.

cat /sys/class/gpio/gpio19/value

Will read from an input GPIO.

echo 0 > /sys/class/gpio/gpio19/value
echo 1 > /sys/class/gpio/gpio19/value

Will write to an output GPIO.

echo rising > /sys/class/gpio/gpio19/edge
echo falling > /sys/class/gpio/gpio19/edge
echo both > /sys/class/gpio/gpio19/edge
echo none > /sys/class/gpio/gpio19/edge

If the GPIO can be configured as IRQ,the above configure the signal edges.

Drivers can also make GPIOs available through sysfs using:

int gpio_export(unsigned gpio, bool direction_may_change);
void gpio_unexport();

And the following can be used to symlink to a different sysfs location to provide the
interface under a different device.

int gpio_export_link(struct device *dev, const char *name,unsigned gpio)