Click here to Skip to main content
14,974,167 members
Articles / Programming Languages / Kotlin
Article
Posted 8 Sep 2020

Stats

5.3K views
38 downloads
7 bookmarked

Using Windows 10 for Development with DragonBoard 410C and Android

Rate me:
Please Sign up or sign in to vote.
4.75/5 (5 votes)
22 Sep 2020CPOL27 min read
Unboxing a DragonBoard 410C, setting up a Windows 10 PC for development, and using Android Studio
A beginner LED circuit project using the DragonBoard 410C with Android 5.1 and Kotlin. From unboxing the DragonBoard 410C to an overview of setting up a development environment and a first project with LED control using the legacy sysfs GPIO functionality of the Linux kernel.

Introduction

I purchased a DragonBoard 410C and power supply from Arrow recently with the intent of using it for exploration into using the board for Internet of Things (IoT). This article is to capture my first work from unboxing the device to writing and trying out my first application.

I purchased my device from Arrow.com from this link to Arrow Development Tools: DragonBoard 410C which also has links to various manuals and documentation. The materials available from this page have documentation for Android and Linux. The device also can run the Windows 10 IoT Core OS, see An overview of Windows 10 IoT Core and the links there.

For my work with the device, I'm using Android Studio with a Windows 10 Pro Dell laptop. This seemed to me to be the simplest and easiest way to get started.

Why this Article

With this article, I wanted to capture my experience and research on using the DragonBoard 410C with Android. I hope that anyone else who is interested in this device and needs a starting place will be able to find this article to be a useful quick start without having to spend the time I've spent learning what I have learned.

Resources

There is an introductory online course in Coursera, Internet of Things: Setting Up Your DragonBoard Development Platform which I am finding to be helpful.

See as well the online course in Coursera, Internet of Things: Sensing andActuation from Devices which has information about using the GPIO and other DragonBoard peripherals.

Arrow Electronics has documentation and links to resources available on the DragonBoard product description and purchase web page.

96Boards has reference information as well as several operating system alternatives (Android and Linux) available on the 96Boards DragonBoard 410C product description page.

Qualcomm has information and resources through the DragonBoard 410C Development Board section of their developer portal. The DragonBoard 410C Projects page has a number of different projects to see what others are doing.

Google Android Studio is available through their developer portal which also has a link to resources for learning Kotlin.

The GitHub repository IOT-410c at https://github.com/IOT-410c contains a DragonBoard 410C GPIO library written in Java.

The Instructable Development of Applications Using GPIO Pins on the DragonBoard 410c With Android and Linux Operating Systems has a basic review of the GPIO pins of the 40 pin low power connector of the DragonBoard 410C along with helpful pin diagrams. The GPIO naming convention varies between Android and Linux and using the SYS file system approach to manipulating GPIO pins requires knowing which GPIO pin number goes with which physical pin number.

Background and Initial Unboxing

The DragonBoard 410C is a small credit card sized computer similar in size and form to the Raspberry Pi 3. It has WiFi and Bluetooth built in and a low speed 40 pin connector similar to that of the Raspberry Pi 3 (the pin voltage is 1.8v). It has a micro-USB connector for connection to a host computer and a barrel power supply connector in addition to the full size HDMI connector and two USB 2.0 connectors for peripherals such as keyboard and mouse (the Pi 3 has four USB connectors). There is a GPS receiver built into the board.

The device has 1GB of RAM and a 8 GB eMMC persistent storage and a microSD 3.0 slot as well. Out of the box, the DragonBoard 410C had a generic Android 5.1 installed into the eMMC. Other operating systems can be installed and I plan to go with Windows 10 IoT Core later.

image of DragonBoard 410C from top.

The Android 5.1 build does not have the Google ecosystem which means no Google applications such as the Play Store. However, there are a number of alternative Android app stores. For application development and testing, I will be sideloading apps anyway.

My initial DragonBoard setup was using an HDMI monitor along with a USB keyboard and USB mouse to see what the device looked like. The user interface is similar to an Android phone with the mouse rather than a finger being used to select with a click and to swipe doing a click/drag. I used the Settings app to connect the device to my cable router allowing access to the internet. The FireFox browser was already installed allowing me to read the Washington Post. There was a bit of delay at times when the browser displayed new content.

Next, I replaced the initial setup with a development testing setup using an ASUS multi-touch touchscreen HDMI monitor that I had purchased on sale about a year ago to replicate a touchscreen phone interface. The touchscreen monitor HDMI cable went into the HDMI connector on the DragonBoard 410C and the USB cable went into one of the two USB ports on the board. The keyboard I removed, relying on the Android screen keyboard instead.

Using the touchscreen monitor, I was able to use swipes and touches to navigate and to start up applications. The onscreen keyboard was available as well with the keyboard removed. This was the kind of setup I wanted for using the DragonBoard, something similar to a phone interface.

Simple LED Circuits

A simple LED circuit for experiments with microcontrollers is one where the output voltage of a GPIO pin drives the light output of an LED. The circuit requires a breadboard with two connecting wires, an LED, and a resistor. See as well the Instructables article Simple Basic LED Circuit (How to Use LEDs). See as well this sparkfun article, Light-Emitting Diodes (LEDs), which describes a number of characteristics of LEDs.

One note about LEDs. An LED is a Light Emitting Diode which means that current can flow through the LED in only one direction. An LED has polarity so the LED must be inserted into the circuit allowing current to flow from the anode to the cathode by connecting the pins of the LED correctly. If the LED is wired into the circuit with the direction or polarity incorrect the LED will not light.

For most hobby types of LEDs, the two pins of the LED are different lengths with the anode being the longer pin. The anode needs to be connected to a voltage source such as the GPIO pin of a microcontroller or a battery and the cathode needs to be connected to a ground (normally the GND or ground pin on the microcontroller low power connector) See this article Light-Emitting Diode (LED) which describes polarity and how to identify the polarity of an LED.

The amount of light emitted by the LED depends on four things: the output voltage of the GPIO pin, the amount of current the GPIO pin can deliver, the voltage drop of the LED and any other components in the circuit, and the amount of resistance of the resistor.

The more current flowing through the LED, the brighter it will be. However, should the amount of current exceed the tolerance of the LED, it will burn out. We want to create a circuit that will allow enough current through the LED for the brightness level desired while also limiting the amount of current below the tolerance level of the LED so that it will not burn out. We limit the amount of current by limiting the voltage applied to the circuit and by using a proper valued resistor.

The voltage drop of an LED varies depending on the color of the LED as well as the materials used in the LED. A red LED has less of a voltage drop than other colors. You can experiment with different colors by replacing the LED in the circuit with different colors while making no other changes and you can see the level of brightness vary depending on the LED color. You can also swap out different resistors to see how the lower the resistor value is, the brighter the LED.

The GPIO pins of the low power connector of the DragonBoard 410C provides 1.8 volts, less than the voltage of 5 volts supplied by the GPIO pins of an Arduino Uno. The voltage drop of a red LED is typically around 1.7 volts to 2 volts. A 10 ohm resistor should be sufficient for a simple LED circuit using a red LED connected to a 1.8v GPIO pin of the DragonBoard 410C. And it appears from some documentation I have seen that no resistor is required due to the low voltage of the GPIO pins.

With multiple LEDs, you can use a common ground on the breadboard with each LED cathode connected to the common ground and then a single connection from the common ground to a GND or ground pin on the DragonBoard 410C low power connector. Each LED will need its own GPIO pin if you are wanting to blink the individual LEDs at different rates. I have not tried tying several LEDs to a single GPIO pin and I don't have sufficient electronics knowledge to predict whether that would work with more than a couple of LEDs.

Checking an LED Circuit

Since the DragonBoard 410C has both a 1.8v and a 5v power pin, a quick way to check if the LED is inserted properly, with the correct polarity, is to connect the circuit to the 1.8v power pin and the ground pin of the connector and the LED should light up. If it doesn't, check your circuit that the wiring is correct. A quick check on the LED polarity is to just pull the LED from the breadboard and turn it around and reinsert into the circuit.

Another possible reason for the LED to not light if the LED polarity is correct is the resistor has too much resistance for the amount of power being supplied to the circuit. The size of the resistor depends on the voltage applied to the circuit and an LED circuit powered by 1.8v requires a smaller valued resistor than a 5v voltage source.

Setting Up Windows 10 Development Environment

I am using a laptop with Windows 10 Pro installed for my development environment. The laptop has a copy of Android Studio installed. My development environment is as follows:

  • Dell laptop with Windows 10 Pro
    • Android Studio installed (Android Studio requires Java JDK)
    • Android SDK Platform Tools installed (for the adb application)
    • Git installed
  • ASUS touchscreen monitor with HDMI and the touch USB connections to the DragonBoard 410C
  • DragonBoard 410C with a power supply (I purchased both from Arrow Electronics)
  • Phone charging cable with USB A on one end and micro USB connector to connect DragonBoard to PC

The Android Debug Bridge (ADB) software is installed separately from Android Studio. See the ADB section below where I provide links to some articles about ADB. My first experiments did not require the adb application and I was able to do simple application development concentrating on User Interface changes without installing the Android SDK Platform Tools. However, once I started looking into blinking an LED, I had to make changes to the DragonBoard boot script which required using the adb tool to pull and push the script to/from my development PC.

As a test of the development environment, I created a simple test application with Android Studio. The test application was generated from what looked to be a simple template offered by Android Studio for a new project in the Create New Project dialog, the Basic Activity template. The generated project was a combination of Java and Kotlin source code along with a number of .xml files containing the code for the windows and user interface. I was able to switch between Design presentation and Code presentation of the user interface layout in Android Studio.

I connected the PC to the DragonBoard using the phone charging cable. Windows 10 saw the new Android device and set up the necessary drivers for me so that the device was available to Android Studio. I then downloaded the test application to the DragonBoard where it appeared in the apps folder.

I was able to start the app up and manipulate the simple controls using the touchscreen monitor with a feel much like an Android smartphone.

Basic Procedures with DragonBoard

Power Up and Down

When the power supply is plugged into a wall socket and connected to the DragonBoard, the board powers up. The power up does take perhaps 30 seconds to a minute with a Qualcomm Snapdragon logo flash screen displayed on the attached monitor followed by the Android 5.1 User interface

There is a power button on the DragonBoard that can be used to power off the device or to power it on.

To power off the DragonBoard, press and hold the power button until a prompt shows on the display allowing you to confirm the power off at which point the device shuts down.

Note: During my research into the device, I have come across the suggestion that the device should always be powered down before unplugging it in order to do an orderly shutdown. It is also suggested that once powered down, it should be unplugged and not kept plugged in since the device may perform a restart.

Connecting to a PC Host

The two USB A connectors are host connectors to be used with peripherals such as a keyboard or mouse. To connect the DragonBoard to a PC host, you will connect a USB cable that has a USB A connector on one end and a micro B USB connector on the other into the micro B USB connector on the device. The cable that comes with the charger for most Android smartphones such as my Samsung Galaxy 7 Edge works fine.

What I have noticed is that when the DragonBoard is connected to the PC host, the HDMI display goes blank. I'm not sure why that is. However, when I disconnect the device to host USB cable, the display redisplays and shows the Android user interface.

ADB (Android Debug Bridge)

Documentation talks about installing software in addition to the Android Studio. The most important component is the adb application. This is part of the SDK Platform Tools package which is a separate install from Android Studio.

There are a number of articles and guides on the web. Most of what I found was out of date. Here is my experience as of August 2020.

See this article from the developer.android.com about ADB. Android Debug Bridge (adb). In the article, there is a link to the platform tools.

Quote:

adb is included in the Android SDK Platform-Tools package. You can download this package with the SDK Manager, which installs it at android_sdk/platform-tools/. Or if you want the standalone Android SDK Platform-Tools package, you can download it here.

From the SDK Platform Tools release notes article, there are operating specific links to download the SDK Platform tools. Since I am using Windows 10 for development, I chose that link which resulted in a .zip file being downloaded. Inside the zip file was a directory platform-tools. I copied that directory and the directory tree from the .zip file to the folder C:\Program Files\Android which is the folder where Android Studio was already installed.

Also see this article, What is ADB? How to Install ADB, Common Uses, and Advanced Tutorials.

The adb application requires a USB cable connecting the development computer to the DragonBoard. I used the Windows 10 command shell to navigate to the folder where adb was located and then used the command line.

When setting up my DragonBoard GPIO pins, I used adb to pull a copy of /etc/init.qcom.post_boot.sh to my PC, modified it using the Notepad application, then pushed the modified version back. I will explain the procedure in a bit.

I've also used the command adb shell to open up a remote shell into the DragonBoard where the standard Linux commands of ls and cd can be used to look at the file system. I've used the adb reboot command to reboot the DragonBoard.

Using Android Studio

I haven't done any Android application development before so Android Studio is new to me. However, while the interface is unfamiliar, the basic functionality and process of application development reminds me of using Visual Studio 2019 Community Edition to develop UWP applications. The source code is Kotlin or Java along with various .XML files that contain user interface markup and resources such as text strings.

There are a selection of device emulators that you can use within Android Studio that allows you to see what the user interface looks like and how it works. With the host PC connected to the DragonBoard, Android Studio will create the necessary .apk file and download the application to the device where it will appear in the selection of apps.

The DragonBoard 410C ships with Android 5.1 and the default SDK installed with Android Studio is the latest SDK which at this writing in Android 10.0 so you will need to install the Android 5.1 SDK. This is done through the SDK Manager from the Tools menu of Android Studio which provides a list of all of the available Android SDK versions. You can install several different ones.

You can also add additional emulators and change the version of Android that the emulator uses with the ADV Manager from the Tools menu of Android Studio.

Additional Thoughts about Android Studio

My understanding is there is a native C/C++ development that can also be done, however it requires using the SDK Manager of Android Studio to install the necessary components. I've also seen articles and videos that describe using Python for applications as well.

Rather than using Android Studio, Eclipse can also be used (see How to Setup Eclipse for Android App Development), however I haven't tried it. And it looks like Visual Code can be used as well. However, read this article, Why Android Studio is Better for Android Developers Instead of Eclipse.

Also, see this article, Android Navigation Drawer Example using Fragments, to get an idea of using Android Studio. The article gives a feel for the basic process of creating a new project and the basics of using Android Studio.

I've used Eclipse in the past and to me. using Android Studio is not as complicated nor did it require effort to install. Most importantly, I was able to download Android Studio, install it on my Windows 10 PC, and within ten minutes, had my first demo app running on my DragonBoard.

Using Kotlin with Android Studio

Android Studio encourages the writing of business logic source code in the Kotlin programming language (see the Kotlin programming tutorials on kotlinlang.org). There seem to be quite a few YouTube presentations on learning the basics of Kotlin as well as Android development (for instance, see this short, 10 minute video Make Your First Simple Android App with Kotlin).

Android Studio offers code completion as well as a couple of helpful tools built in that help with understanding and correcting errors. One helpful tool is the one that will automatically convert Java source to Kotlin source code as a number of source code examples for Android are written in Java.

Linux Kernel Pseudo Files and Using GPIO Pin

As part of learning about how to access the GPIO pins of the 40 pin low power connector, I spent a bit of time learning the basics of how to use the sysfs functionality and Linux kernel pseudo files of /sys/class/gpio.

One of the first things I did was to post a question in StackOverFlow, what is the /sys/class/gpio/export and /sys/class/gpio/unexport mechanism and what is the underlying sysfs functionality?, to request assistance and to provide place to put any research notes that I discovered during my search for understanding.

Operating Systems

The DragonBoard 410C arrived with Android 5.1.1 installed. When I checked the Kernel version was 3.10.49 and the Build number was 90.

My initial work was done with this version. Once the 32 GB microSD card I ordered arrived, I used a Windows 10 PC with a SD card reader to install the latest Android 5.1.1 image from 96Boards onto the card and then installed it into the eMMC of the device. The Kernel version was also 3.10.49 however the Build number is 99.

The 96Boards web site has a number of different operating systems available with Android, a couple of different Linux distros and Windows 10 IoT.

See the Using the DragonBoard 410C page and the documentation and operating system offerings there.

Using the Code

The first Android Studio app I created for my DragonBoard 410C with Android 5.1 was nothing more than the app generated by Android Studio from a basic template selected from the New Project dialog. I made no changes to generated project, merely compiled it and then ran the resulting app on the device.

Once that was successful, I began exploring the code and getting a feel for Android Studio by making small changes to the UI such as adding a button, modifying text strings, etc.

The first extension to the application was to access the GPIO pins of the low power 40 pin connector to blink an LED. After success with that task, the second extension was to blink multiple LEDs.

Access and Use the 40 Pin Low Power Connector

The first thing that I had to do was to find a library that would allow me to access and manipulate the GPIO pins on the 40 pin low power connector. There are several approaches to doing this.

For older embedded Linux, the sysfs interface approach in which files located in the directory "/sys/class/gpio" represent the actual pins is usable though slow. See the kernel.org article, GPIO Sysfs Interface for Userspace which provides a description of the interface.

There are a couple of libraries available which work more directly with the hardware. One such library, libgpiod, requires the Linux GPIO character device interface introduced in Linux 4.8. According to the table in this android.stackexchange.com posting, Which Android runs which Linux kernel?, Android 5.1 uses Linux version 3.16.1 which seems to rule out any alternative other than using the sysfs interface.

While learning how to access the GPIO pins on the 40 pin low power connector of the DragonBoard 410C, I posted this question into stackoverflow.com which contains the final solution I worked out, accessing GPIO low power connector on DragonBoard 410C running Android along with links to background material.

Boot Script Change for sysfs

I needed to modify the boot script, /etc/init.qcom.post_boot.sh, so that the necessary sysfs special files would be created and the necessary access permissions changes were made. This required the use of adb to pull a copy of the file from the DragonBoard, modify it, and then push it back. Once the DragonBoard was rebooted, the special files were created by the boot script.

To use adb, you will need to restart the adb daemon as root user and then remount the files system so that it will be writable. Once you've done that then you can use the adb pull command to pull a copy of the /etc/init.qcom.post_boot.sh file from the device, make the changes, and then use the adb push command to push the modified /etc/init.qcom.post_boot.sh file to the DragonBoard 410C. After pushing the edited file, I then used the adb reboot command to reboot the device.

One thing I did to make it easier for me on Windows 10 was to create a folder C:\adbtempfiles which I could use as a place to put any files that I pulled with adb.

adb root
adb remount
adb pull /etc/init.qcom.post_boot.sh /adbtempfiles/init.qcom.post_boot.sh

Edit the init.qcom.post_boot.sh file, then use adb to push the modified file and reboot the device. After rebooting, you can use the adb shell command to start a remote shell and then navigate to the /sys/class/gpio folder to check that the GPIO pseudo files have been created.

adb push /adbtempfiles/init.qcom.post_boot.sh /etc/init.qcom.post_boot.sh
adb reboot
adb shell
cd /sys/class/gpio
ls
exit

The following shell script addition to /etc/init.qcom.post_boot.sh, creates the special device entries in the file system that allows for the manipulation of the GPIO pins of the 40 pin low power connector. This source can be added to the end of the file retrieved from the DragonBoard 410C so that when the device reboots, the initialization script will create the necessary special device files.

WARNING: The GPIO pin numbers are for Android. Linux GPIO pin numbers are different.

set -A pins 938 915 1017 926 937 930 914 971 901 936 935
for i in 0 1 2 3 4 5 6 7 8 9 10
do
    echo ${pins[i]} > /sys/class/gpio/export;
    chmod 777 /sys/class/gpio/gpio${pins[i]};
    chmod 777 /sys/class/gpio/gpio${pins[i]}/value;
    chmod 777 /sys/class/gpio/gpio${pins[i]}/direction;
done

The chmod command is setting the read/write/execute permissions for these files allowing anyone to access and manipulate these special device files. There could be a security problem with doing this on a product device so consider this to be for testing and development only.

The description from kernel.org from GPIO Sysfs Interface for Userspace has this to say about the attributes such as value and direction:

Quote:
“direction” …

reads as either “in” or “out”. This value may normally be written. Writing as “out” defaults to initializing the value as low. To ensure glitch free operation, values “low” and “high” may be written to configure the GPIO as an output with that initial value.

Note that this attribute will not exist if the kernel doesn’t support changing the direction of a GPIO, or it was exported by kernel code that didn’t explicitly allow userspace to reconfigure this GPIO’s direction.

“value” …

reads as either 0 (low) or 1 (high). If the GPIO is configured as an output, this value may be written; any nonzero value is treated as high.

If the pin can be configured as interrupt-generating interrupt and if it has been configured to generate interrupts (see the description of “edge”), you can poll(2) on that file and poll(2) will return whenever the interrupt was triggered. If you use poll(2), set the events POLLPRI and POLLERR. If you use select(2), set the file descriptor in exceptfds. After poll(2) returns, either lseek(2) to the beginning of the sysfs file and read the new value or close the file and re-open it to read the value.

“edge” …

reads as either “none”, “rising”, “falling”, or “both”. Write these strings to select the signal edge(s) that will make poll(2) on the “value” file return.

This file exists only if the pin can be configured as an interrupt generating input pin.

“active_low” …
reads as either 0 (false) or 1 (true). Write any nonzero value to invert the value attribute both for reading and writing. Existing and subsequent poll(2) support configuration via the edge attribute for “rising” and “falling” edges will follow this setting.

See also poll(2) — Linux manual page from man7.org as well as poll(2) - Linux man page from linux.die.net for an explanation of the poll() system service in Linux. Both articles have similar information though the man7.org document has a short example C program as well. See as well select(2) — Linux manual page from man7.org and lseek(2) — Linux manual page from man7.org.

Thus far, I have not been able to determine how to do access the poll() function from Kotlin source code.

Boot Script Change to Access User LEDs

The DragonBoard 410C has a group of four user LEDs located between the two USB A connectors. These user LEDs can be accessed through the sysfs interface though which user LEDs are available will depend on the operating system, Android (user LEDs 1, 2, and 3) or Linux (user LED 4 only).

These user LEDs are located in the folder /sys/class/leds and see the StackOverflow post How to toggle LED on-board on Dragonboard 410c running Linux . The post describes how to manipulate the user LEDs as well as which of the user LEDs are allocated to the Android and Linux operating systems to use for indicators.

You can modify the post boot script /etc/init.qcom.post_boot.sh to make the user LEDs available through their pseudo files using the sysfs interface.

# Set the permisions of the user LED pseudo files so that
# we can use the sysfs interface to turn them on and off.
# The following LED names are from Andoid which allows
# three of the four user LEDs, located between the two
# USB connectors of the DragonBoard 410C, to be used.
set -A pins led1 led2 led3
for i in 0 1 2
do
    chmod 777 /sys/class/leds/${pins[i]};
    chmod 777 /sys/class/leds/${pins[i]}/brightness;
done

You can then turn on an LED by writing 1 to the brightness pseudo file or turn it off by writing 0 to the brightness pseudo file as in:

echo 1 > /sys/class/leds/led1/brightness

echo 0 > /sys/class/leds/led1/brightness

Each user LED also has a trigger pseudo file associated with it which allows you to assign a kernel event to trigger the LED to turn on and off. Just remember to modify file permissions if you intend to make changes to the trigger characteristic The following shows querying the trigger characteristic of several LEDs that are in the /sys/class/leds folder:

root@msm8916_64:/sys/class/leds # cat boot/trigger
none bkl-trigger [boot-indication] usb-online mmc0 mmc1 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid wlan-indication-led
root@msm8916_64:/sys/class/leds # cat led1/trigger
[none] bkl-trigger boot-indication usb-online mmc0 mmc1 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid wlan-indication-led
root@msm8916_64:/sys/class/leds # cat wlan/trigger
none bkl-trigger boot-indication usb-online mmc0 mmc1 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid [wlan-indication-led]

Kotlin Source for using sysfs

While researching methods for manipulating the GPIO pins of the 40 pin low power connector, I came across an Instructable article that had attached to it files containing Java source implementing a simple library that used the sysfs functionality to manipulate the GPIO pins.

I started with that Java source, converted it to Kotlin source, and made some modifications. There appear to be several similar Java source libraries for use with Android floating about the internet. The source files for the GPIO library contain a comment with a link to the original article from which I retrieved the Java source.

One thing to note about this GPIO library is that it is designed for digital pins only, that is pins that are either high and providing voltage or low and not providing voltage.

Sample Kotlin Code Getting/setting Value of GPIO Pin

The following excerpt from the file Gpio.kt shows the Kotlin code for getting/setting the value of a GPIO pin whose direction is set to output. There are two functions pinHIGH() and pinLOW(), one to turn on the pin by setting the value to 1 and the other to turn off the pin by setting the value to 0. The value is set by writing to the special device file for the GPIO pin.

For instance, if the GPIO pin is physical pin 23 on the low power connector, then under Android 5.1 that is GPIO 938 so to change the value you need to write to /sys/class/gpio/gpio938/value.

var value: Int
    get() {
        println("Getting Value")
        var line = ""
        try {
            val br = BufferedReader(FileReader(MakeFileName(pin, "/value")))
            line = br.readLine()
            br.close()
        } catch (e: Exception) {
            println("Error: " + e.message)
        }
        return line.toInt()
    }
    private set(value) {
        println("Setting Value")
        try {
            val out = BufferedWriter(FileWriter(MakeFileName(pin, "/value"), false))
            out.write(Integer.toString(value))
            out.close()
        } catch (e: IOException) {
            println("Error: " + e.message)
        }
    }

/**
 * Set pin as high.
 */
fun pinHigh() {
    value = HIGH
}

/**
 * Set pin as low.
 */
fun pinLow() {
    value = LOW
}

Points of Interest

While researching how to access the GPIO pins under Android, I posted this question into StackOverflow accessing GPIO low power connector on DragonBoard 410C running Android which has discussion about several alternatives to using sysfs were the Linux kernel a later version.

Being able to use Android Studio to convert Java source to Kotlin has been handy. Android Studio itself has been reasonably easy to pick up, at least the basics. GitHub as the Version Control System is available via the VCS menu of the UI.

The layout designer of Android Studio is not always intuitive and the component/widget constraining system seems a bit arcane and difficult to predict the actual layout outcome from changes. I've ended up using the emulator as a basic check on a layout before downloading to the device.

I've had difficulty with learning how to do remote debugging with Android Studio when I'd like to install and run an application on the DragonBoard 410C and debug it from my PC. When the micro B USB cable is connected between the host PC and the DragonBoard 410C, the display the device is connected to does not display anything. I'm not sure why that is. What I do is to use the Debug app menu item of the Debug menu which does a build and then installs to the device from the host PC with the cable connected, then unplugs the cable from the host PC allowing me to then interact with the application.

History

  • 8th September, 2020: Initial version
    • With this first version of this article, I want to discuss the basics of manipulating LEDs through the GPIO pins of the 40 pin low power connector of a DragonBoard 410C. The basics include changes to a simple UI with additional buttons and text fields and linking the buttons to Kotlin source code which provides different behaviors from a set of LEDs on a breadboard connected to the GPIO pins.
  • 9th September, 2020: Revision 9
    • As part of updating to the latest Android version available from 96Boards, I found that I needed more detailed instructions about using the adb utility to update the /etc/init.qcom.post_boot.sh so I've updated that section.
  • 22 September, 2020: Revision 10
    • added section Boot Script Changes to Access User LEDs describing how to access and use the user LEDs located between the two USB A connectors.

Future Plans

I intend to update this source to look at being able to handle inputs into GPIO pins from simple devices such as a push button switch.

Following that, I intend to look into using additional pins on the low power connector with devices that use I2C and SPI communication protocols.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Richard Chambers
Team Leader Georgia Southern University
United States United States
Team lead for a point of sale software application written in C and C++. Previous experience with Nortel Networks on software for telecommunications products as well as Program Management.

Education:
BS Computer Science
MBA
Masters in Project Management

Comments and Discussions

 
QuestionLinux Pin
Member 1172068126-Sep-20 5:46
MemberMember 1172068126-Sep-20 5:46 
AnswerRe: Linux Pin
Richard Chambers28-Sep-20 11:01
MemberRichard Chambers28-Sep-20 11:01 
QuestionVery nice article .. well written, I learned a bunch Pin
Member 1172068124-Sep-20 9:42
MemberMember 1172068124-Sep-20 9:42 
AnswerRe: Very nice article .. well written, I learned a bunch Pin
Richard Chambers25-Sep-20 9:39
MemberRichard Chambers25-Sep-20 9:39 
GeneralMy vote of 5 Pin
BillWoodruff11-Sep-20 6:14
mveBillWoodruff11-Sep-20 6:14 
GeneralRe: My vote of 5 Pin
Richard Chambers11-Sep-20 10:39
MemberRichard Chambers11-Sep-20 10:39 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.