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.
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
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.
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
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 for this experiment is the pcf8574 test jig setup that I used in the test jig experiment.
The PCF8574 Test Jig
So you’ve written your first device driver for Android Things. You think it does what it’s supposed to. I mean, it seems to work. Hardware can be complicated. How can you be sure you’ve implemented your driver correctly? Are you sure you’ve understood the device’s data sheet? How do you test all of your driver features? How can you prove it’s working properly?
One thing you can do to verify your driver works correctly is to make a test jig. A test jig is a physical representation of the device your driver is written for. It may be an actual device or as close an approximation as you can find or make. The closer it is to the real thing the better.
Test jigs come in all shapes and sizes, and all levels of completeness. The test jig allows you to verify your driver on actual hardware. It can also make the development and testing of your library easier, saving you a lot of development time. Sparkfun have a tutorial on using pogopins to make test jigs. It’s well worth the time to read if you want to see production testing in action.
PCF8574 Test Jig
Making a driver test jig
I’m going to make a test jig for my pcf8574 driver. I’ll use a Raspberry Pi with an expansion board containing a pcf8574. I’ll create a test application that uses the driver to exercise the hardware and I’ll use the Raspberry Pi’s GPIO pins to confirm the driver does what I think it does. The concepts are the same as those described in the Sparkfun article, but I won’t go as far as making a dedicated PCB. The test jig is part of a two pronged strategy to device driver testing: unit tests verify that the logic of my driver is correct, and the test jig verifies that my driver manipulates the physical world as expected.
Picture this. You’ve seen a thing on the Internet. Someone has made something. It’s cool. There’s a fritzing diagram and the source code on github. You want to make the thing yourself. You collect the parts needed to reproduce the thing. You study the diagram. You hook everything up carefully. You run the software, and, and, nothing. It doesn’t work. Why, dammit, why?
Before you turn to StackOverflow, or submit a bug report, you need to collect information about the problem you’re having. But how? Where do you start? What can you do?
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