I’ve written a tutorial on character LCD displays and how to drive them with Android Things. It’s on Hackster.io, check it out here.
Tag: Android Things (Page 1 of 2)
Experiments with Google’s Android Things IoT platform
In this post I will demonstrate how to use an LED matrix display with Android Things. I want to use an LED matrix display for my bus stop sign project. I have been using a character LCD which doesn’t give much visual impact. LED matrix displays are big and bright and can be seen clearly from a greater distance than character LCD displays.
That’s better
Hardware
The hardware for this project consists of:
- An Android Things development board
- an stm32 development board (Blue Pill)
- 3 32×64 LED dot matrix boards daisy chained together
- a 5V power supply
Configure Android Things using BLE
In my last experiment I used the Android Things developer console to create a factory image for my bus stop project. I then created an OTA update to update the bus stop apk ‘in the field.’ I concluded that experiment wondering how I was going to get my network credentials onto the device (without using adb). If your device doesn’t have a touchscreen or keyboard how are you going to get it onto your end user’s network. One possible solution to this problem is to use a companion app on the user’s phone to collect configuration information. With a companion app you get all of the UI niceness provided by that platform for ‘free.’ You still need to get the configuration from the phone to your Android Things device. This is where Bluetooth Low Energy comes in.
Bluetooth Low Energy
Bluetooth Low Energy is exactly the kind of short range wireless technology that can help out here. It’s relatively easy to implement using Android APIs and there’s no need for the device to be on a network to configure it. I can start with the BLE sample for Android Things that has almost everything I’m going to need.
For my bus stop project I have two things to configure that require end user input. I need to configure which stop number I want to display bus data for. I also need to get it onto a network to get real-time bus schedule information from a web API.
Hello Android Things Developer Console
This week Google released the developer console for Android Things. With this release, another piece of the puzzle is in place. The terms and conditions of the developer console it make clear that this is a developer preview, the number of devices you can push updates to is limited to 500, and you can use the console “for the sole purpose of internal development and testing of devices.” Don’t go out and try to sell anything yet. It looks as though actually distributing a product will require an additional, commercial agreement with Google.
I used the developer console to create an image for my (now deprecated) iMX6UL Wandaboard (bought especially for Android Things development, not that I’m bitter about it being deprecated so soon). The process is simple enough. The hardest part is figuring out how much of the device’s memory to reserve for an OEM partition. I went for a wildly pessimistic 128MB partition size, which is over kill for a 2MB app, but once set the partition size cannot be changed so I erred on the cautious side.
I created a product based on my bus stop project.
In this experiment I will demonstrate how to use an external MCU to manage tricky time-constrained tasks on behalf of Android Things. Using an ATTiny85 microcontroller I’ll interface a Dallas 1-wire temperature sensor, the ubiquitous DS18B20, to a Raspberry Pi running Android Things.
The DS18B20 temperature sensor
Background (why)
Since the introduction of Android Things some have questioned the limits of Android Thing’s GPIOs. Collecting data from the Raspberry Pi running Raspbian or similar will show that GPIOs on Android Things are too slow for some applications. Discussions about GPIO speed highlight a point about operating systems in general and Android Things in particular. Android Things is not a real time OS. It will miss deadlines. It will not respond to interrupts predictably enough to satisfy some of the tasks that people may be expecting it to perform. The problem here is not the OS, but the expectations.
As mentioned in this SO answer one possible solution to this problem is to have an external helper MCU handle the hard real-time stuff. Great, but what is all this real-time stuff about?
This week Google released developer preview 3 of Android Things. In it they added support for USB-Serial UARTS. I have previously shown how to add USB-Serial ports to android things using the NDK. It seems this is no longer necessary.
With developer preview 3 the list of available UARTs returned by getUartDeviceList() will include connected USB-serial devices. My QUAD UART from FTDI was detected by the kernel but the peripheral manager culled all but one of the UARTs as described in this issue. Single FTDI devices seem to work OK.
In a previous post I signed off with questions about the functionality of the pfc8574. What is all this ‘quasi-bidirectional’ stuff in the data sheet about? It prevented me from implementing a getPin() method in my Android Things things-drivers library. I didn’t know what would happen when I set a pin value making it an output, then read the pin state. Would it be the value I wrote, or the pin state based on the electrical biasing of the pin.
Now that I have the pcf8574 test jig I can see what actually happens when I set pcf8574 pins high or low, and Raspberry Pi pins high or low. I can make a truth table of pin states to see if it would be OK to implement the readPin() method that’s missing from the driver.
The Hardware
The hardware for this experiment is the pcf8574 test jig setup that I used in the test jig experiment.
The PCF8574 Test Jig
In this experiment I will connect a colour sensor to Android Things. The Colour sensor is a TCS34725, a red, green, blue and clear light sensing light-to-digital converter. I’ll connect the sensor to a Raspberry Pi 3 running Android Things preview image 1 and display the sensor readings on a Character LCD display.
The TCS34725 module and LCD display
UPDATE: 12 March 2017
Android things developer preview 3 adds support for USB-serial devices, making this method redundant for single USB-Serial adapters. This may be still useful for the QUAD UART used in this post. Read more about it here.
There’s nothing quite like the good old fashioned UART for connecting things together. It’s a technology that persists because it’s simple and it works. The Raspberry Pi has one UART. With it you can connect to exactly one peripheral. That’s not enough. We need more UARTs.
One solution to the ‘not enough UART’ problem is to use a USB-Serial converter. There’s been a Linux kernel driver for the FTDI USB-serial converters for years now, these are a well supported, mature technology. The aim of this experiment is to see if I can get an FTDI USB-Serial converter working with the Raspberry Pi 3 running the Android Things preview image 1.
4 port FTDI UART
In this experiment I’m going to add buttons to Android Things using the user space input driver extension mechanism provided by the platform. I’ll be using momentary push buttons connected to a Raspberry Pi running the Android Things preview image. The buttons will be connected via an I2C IO port, the PCF8574. I’ll use one GPIO on the Raspberry Pi as an ‘interrupt’ line to detect a button press, then I’ll read the button states and report button presses to the framework as input events.
The setup with buttons