Video
Slides
Summary
On February 23, 2017, Sanrio Alvares provided a deep dive on the Android Things* Peripheral IO Manager at the Embedded Linux Conference + OpenIoT Summit in Portland. The following is a transcript.
Transcript
Sanrio Alvares: Hello, you guys can hear me? Okay. I'm going to start right away. Well, this is a presentation on Peripheral IO. It's a part of Android Things*, and it's the second part of a two part series. The first of which was presented by my colleagues Geeta and Anisha earlier today. It was a prerequisite, but if you were not there I'm going to spend a couple slides, just two minutes, at the beginning to go over what's Android Things and then deep dive into Peripheral IO right away.
My name is Sanrio Alvares. I am an engineer with Intel®, and mainly focusing on enabling Intel's startup boards on Android Things. The agenda is very small today. It probably won't take most of the time here. At the end we can, you guys can come over, I'll show you the boards and how the connections are made, so ... Go over through the introduction of Android Things. What are the differences?
The Things Support Library, we'll see what it's made of. The User Drivers being one thing, Peripheral IO being the other. What APIs are available to the application developers. I'll also introduce a couple of open source libraries, UPM and MRAA. They are part of the Intel IOT Dev Kit, and open sourced, and how we are planning to leverage what's available there and for Android developers, Android Things developers. Take questions at the end and a few take-away links, and if I have time, I'll also go through those links so it's, so you can ask me questions at that time.
If you have heard the news, Android Things was released back in November last year. It's a developer preview and three boards made the cut. Intel's Edison, Raspberry Pi 3, and NXP's Pico and Argon. Intel's Edison is available on three different kinds of boards, the Arduino, the SparkFun Blocks, and Mini Breakout. I have those boards here. Two weeks ago DP2 came out, and Joule was released at the time. It is the most powerful of the lot, and it's mainly focused, with the computing power, it's mainly focused for autonomous robots and IT applications that require edge processing.
If you're not familiar with starter boards, starter boards are just boards with GPIOs and buses that are available on the boards exposed, so that you can connect sensors and actuators and communicate and configure them.
[inaudible 00:02:55] direction, Google's tackling the IOT market with Android Things, but leveraging as much work they've done on Android as possible. Although it is Android-like, there's differences and certain things that are not available like system apps and content providers. Framework APIs is a subset of Framework APIs, like activity and maybe location, but not all. Common intents, contacts, telephony is not available. The download manager is not available, so you can't install APKs by using Google Play. Also, no APIs for input authentication, which keep in mind that Android Things is also made for devices without displays, so there's no user input there for now at least, it's just DP2. The rest of it stays the same.
The Linux kernel is the same Linux kernel port on Android devices. They're using the same port. HAL with very little or no modifications, we have been able to use on our Intel boards. Certain C libraries, native libraries, are available, and I've mentioned OpenMAX. It maybe didn't make the cut for DP2 graphics, or did it? We did a lot of work there, but it is coming if it hasn't yet. Android runtime is available. So very much like Android, but few things missing. So keep in mind if you're looking for content providers and stuff like that, you have to make sure it is available.
This is simple stack. The thing I'm going to talk about is the Things Support Library. The orange block there. What it does, it extends the framework to communicate and integrate with devices that are not available on mobiles and SOCs. It is also a streamline for a single application use, which means at the end of boot up, you don't have the home screen, and you can go from one application to another. It's a subset of what the window manager can do.
So the end, you have to make sure you have you have the IOT launcher in the application, and that's the application that will be launched at the end of boot up. Mainly that is the application that is meant for that particular device. For example, a toaster. Just one application at the end of boot up.
All right. Let's focus on Things Support Library, break it down. It's made of two parts, the Peripheral IO APIs and the User Driver APIs. The Peripheral IO APIs basically help you communicate with the device using standard protocols like UART, SPI, I2C, et cetera. The User Drivers is a extension of the framework, and it helps applications inject hardware events into the framework so that other apps can register and act on them.
For example, if you have a GPS module, and you're connecting it to your device, if write a User Driver for it, you can make it part of the framework and another application can use that to gather location data through the User Driver APIs. That is one part of it. User Driver communicating with the applications. The User Driver also needs to communicate with the GPS module, and that it does via PI/O. PI/O provides the UART APIs, the SPI APIs, and the low-level APIs. So to get the communication flow right, application registers for events using the User Driver APIs. User Driver API communicates with the device using PI/O APIs.
What are the benefits of having User Drivers in the framework? Well ... Yeah?
Speaker 2: I have a question for the PI/O [inaudible 00:07:10]. How does it work exactly? Does it simulate the protocol? Because if you use the PI/O, basically you are using the actual [inaudible 00:07:22] right?
Sanrio Alvares: Yes. So you mean to say-
Speaker 3: Would you repeat the question please?
Speaker 2: What I am saying is that basically, if you are using the PI/O API, you are using [inaudible 00:07:37]. So basically the User Driver that sits on top has to in a way simulate possibly some of the [inaudible 00:07:46]-
Sanrio Alvares: Yeah, so take the GPS module for example. For a GPS module, you might have UART communication. The GPS module that you write, the User Driver that you write, uses the UART APIs that are available by PI/O. Now the UART APIs that are available on PI/O, I'll come to it ahead in the slides, has to talk to the Linux sysfs UART nodes, the TTY. That's what PI/O really does. It manages communications and communicates with the sysfs nodes. If it's GPIO, it's sys class GPIO. If it's PWM, def PWM, and SPI [inaudible 00:08:27], stuff like that. That is what really it does. It's a thin layer, but there are advantages that I'll come to, why PI/O makes a difference. You could write directly talking to the sysfs node, right? But there are advantages of having this layer, and it abstracts quite a few things. It also ... I'll come to it.
Before that, User Drivers. What are the advantages of having User Driver? It's easy integration, it's part of the framework, you know what APIs to expect and to write. Since it's part of the framework, it is also ... Applications can call in to those APIs and use the driver. It is also reusable. What it means, is if there is a User Driver available online somewhere, and is not part of your framework, you can pull it and install it in the framework, and reuse it in your application.
Now, what is this beneficial to? Mostly, the device sensor manufacturers. They could write a User Driver for their sensor, and put it somewhere on a github maybe. What that does, is just one implementation of the User Driver. They don't have to take care of if it's running on a Intel platform or a ARM platform. All of that is abstracted by the Peripheral IO layers. They just have to have one implementation. Also, you get the benefit of portability. If you are connecting the GPS module on UART 1 of your Raspberry Pi 3, you have a User Driver and an app for it, you would remove the module and put it on a UART 1 of Edison. Without any changes you can run the same app and same User Driver, and you'll be able to communicate with it. That's the benefit of having a User Driver in framework.
So how does the UART 1 from one to the UART 1 to another platform ... How is it done? It's done using the Peripheral Manager Client. This is the architecture of it. Now, the Peripheral Manager Client has a central class, and that class exports methods to all peripherals that it supports like GPIO, I2C, et cetera. Now, these are only five protocols that are supported right now on Android Things. Each protocol has a manager and a shim driver layer associate with it, not to be confused with the User Drivers. It's just a layer that communicates with the Linux sysfs. Also, all of this is above the SE-Linux layer, so on Android devices and on Things devices, you cannot go to the shell and just start configuring on production devices. You have to go through the Peripheral Manager Client, and it gives that security.
Also, when an application is asking for a GPIO for one pin ... This architecture creates a connection between the physical pin and the app. It provides serialization and mutual exclusion of the resource. Why is it necessary? Multiple processes on a Linux machine, just running Linux, can go and write to the GPIO. If the GPIO has I2C on it, a different process can come. There is no safe way of managing which process is doing what on the sysfs node. The Peripheral Manager Client gives that benefit. It maintains that communication, and unless that communication is not deleted, it does not allow a different process to configure that particular pin for something else, so it provides mutual exclusion.
This layer also abstracts the low level C interface, or shell interface, and you can write applications in Java and C++, and NDK support is now available, so you can write C++ applications and Java applications to communicate with low level hardware.
Another part of it, major part of playing with a meta device is the muxing. Each platform has its own different configurations. If you want to get a GPIO on an Edison or a Joule, you have to look at its data sheet. You have to look at its layout, and wonder what you need to do. All of that is abstracted in the device HAL. That device HAL is given by the vendors. So we order the device HAL for Intel's Edison separately, and Dell Joule separately. The PINMUX Manager is standardized APIs, it calls into it, and every time you want a GPIO, it goes to the device HAL, configures it, and hides all that complexity from the app developer. That's mainly the benefit of having this structure.
Now suppose you have a board, you have the layout. This is an Intel Edison's Arduino layout. You have the layout of the pins, and you want to blink an LED. You look at what GPIO is available. You see there's ... Some GPIOs have multi-functionality, so they have to be multiplexed between different functions. Some of them don't, but you don't need to worry about it. What you do, is you just ask for a particular GPIO.
I don't know if it's clear, but a 12 I think it is, sorry, 13, IO 13 is where the LED is powered through, and the ground is connected right next to it. When you're writing the application, all that you have to do is get a Peripheral Manager service instance. It gives you a lot of APIs for all Peripherals. For GPIO, you can get the GPIO list, so all the GPIOs that are available. Since you know it's connected on IO 13, you ask for it using manager.openGpio. When you do that with the GPIO name as IO 13, it does the muxing underneath it, and it also forms a connection to the GPIO so others cannot use it for I2C, SPI, et cetera. Those are the methods available right now for GPIO. You could set a direction, you could active type, get value, set value. It also, if the GPIO is capable of interrupts, then you can set the trigger on the edge, and register for a GPIO callback. Now in case of the LED, you would go setDirection as DIRECTION_OUT, and then using setValue true and false, you could toggle it.
Here's a pressure sensor that's connected to the Arduino. You look for, it's an I2C base, so you look for the I2C bus. It's the same bus here. So there's two signals coming out – SCL, SDA. You connect to those, and you power it using the 5 volts I think here. So that's all you need to figure out. You also need to check where this I2C is, like what bus it is, what address it is. Once you know that, and that's all you need to know, you can give that information as a device name in the address, and the open I2C device will create a connection for you for I2C. You can get a list of I2Cs that are available on the device, read and write to it, the normal I2C APIs.
Similar thing with SPI. There's full duplex and half duplex available for communication right now. And different boards, make sure when you are writing to it, you always do the bus list, SPI bus list. Sometimes what happens is, even if it's listed and you're running the Android Things, if something is wrong with the SPI, it might just show you that SPI 1's available. So it's very sure, because the SPI bus list goes and communicates with the device, so you know what's on it. Then you choose the device that you want to connect to and configure it and stuff like that.
UART is also available. You can configure the UART. I think two UARTs available on the Edison as well as the Joule. Make sure if you have the console connected, sometimes the console, the kernel logs can tend to come on this device, so make sure you're configuring it in the right way. And PWM. Any questions on this code?
Speaker 4: Isn't there a C++ interface for all this?
Sanrio Alvares: Yes, so DP1 was just Java applications. DP2 provided NDK support. So the libraries that I'm going to talk about; UPM and MRAA, are actually written in C, C++, so we were waiting for the NDK support. You could write C/C++ native cord and in fact, the Peripheral IO Manager is written in C. Just that in the DP1, there was no APIs available for it.
Speaker 5: Java is mandatory for [inaudible 00:18:58]
Sanrio Alvares: Not anymore. With the NDK support, you can write-
Speaker 5: You can't run and write things without Java at all.
Sanrio Alvares: No, Android Things has the Java framework available, but you can write applications that are not in Java.
Speaker 5: Right, but you still need [inaudible 00:19:16]
Sanrio Alvares: Yes. Okay. So UPM, Useful Packages and Modules, is a collection of a sensors and actuators. This effort was started a couple years ago, maybe three years ago, and Intel was leading it. There's a lot of support in the community for multiple sensors. Some of them are just makers. Right now they're going into industry protocols and sensors, so there's support available for this, open source support available. Now, we are planning to integrate this, very close to it, to make it available on Android Things.
Before that, these are all the benefits you have. You can write applications in C, C++, Java, all different things. You can write three lines of code and get the sensor code available. All these protocols available, but because we are on Android Things, only part of it is available right now. It has multiple sensors and multiple OSs that it's supported on. And 250 different makers and industry sensors.
I don't have an architecture slide for this, but the way UPM and MRAA used to work before Android Things is, you have a MRAA layer that used to act the same way the Peripheral IO works on an Ubuntu system, for example. And you have an UPM on top of it, so the MRAA would provide you with GPIO, analog, and all these, and the UPM sensors would provide you what is now User Drivers on Android Things. What's happened now is, since the Peripheral IO is available, the MRAA is just a shim that is calling into Peripheral IO APIs, and you have all the goodness that's available on UPM in Android Things.
These are the landing pages. I'd like to open a couple of them and show you how to go and get about and better find information. Let me go to that. Oh, you wanted the picture? I'll come back to it. Okay, the first link is basically Google's landing page for Android Things. There's two sections to it, Hardware and SDK. The Hardware section provides you with all the boards that are presently supported. Also, this is where you'd get the system image downloads. If you were part of the previous presentation, Anisha mentioned that, but these are the two links that you can find what the device pinout looks like, so you don't have to go and look at the data sheet. All that you need to do it look at the Arduino pinout and the SparkFun pinout. It just shows you what's available. Same thing on Joule and the rest of them.
In the SDK part, the main things that I'd like to point out are all these that are supported. So the native PI/O just came in two weeks ago, and there are User Drivers. These are drivers written by Google, and they are available on their GitHub. This is their GitHub, and concept drivers are the User Drivers that are available right now. There's a bunch of them, like 10 of them. But if we were to utilize UPM and all those sensors that are available, then there's 250 of those available here, and I think we will come out with a, maybe a white paper shortly, of how to integrate these as natives, because this is all C/C++ code, or even through Java, so you can just pull the AR and start using it. So these are the links.
Also, another link on how different these boards are and how they ... These are the boards available, so Joule having different ... The rest of them are pretty much similar, but the Joule is much stronger. Also right now, TensorFlow was introduced on Raspberry Pi, but soon I think, you can run it on Joule, and you can have edge processing on Joule. So those are the things that are coming up. There is a lot happening very quickly. Peripheral IO, I try to give as high level information on Peripheral IO, because they are changing things underneath it very quickly.
Speaker 6: AT the beginning of the presentation, you mentioned that there was a new board out.
Sanrio Alvares: This is it. The Joule was the new one.
Speaker 6: Was it the Joule? All right
Sanrio Alvares: That's already released, but we are already working on another one.
Speaker 6: And, can you post his deck onto the IOT later?
Sanrio Alvares: Yes. I think I have. I just did it today.
Speaker 6: I didn't see it there.
Sanrio Alvares: Didn't see it? Maybe ... I'll check it again.
Speaker 6: Okay, thank you.
Sanrio Alvares: Yeah. All right, any more questions? Feel free to come and ask me any questions on the boards. How to connect them. I play with them every day so. Also, there is a demo going on upstairs. I think it's there until 1 PM. There's a home-
Speaker 3: [inaudible 00:25:58]
Sanrio Alvares: Yeah, smart home kit that is running Android Things. So that's only up til 1 PM. All right. That's that.
END
Learn more about Android Things on Intel Architecture.