android.geek.nz

Making Things do stuff

Category: Electronics

LED matrix displays and Android Things

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

Continue reading

Android Things IO Port Driver Update

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

Continue reading

Android Things Driver Testing

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.

Continue reading

Hardware or Software?

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?

Continue reading

© 2018 android.geek.nz

Theme by Anders NorenUp ↑