 Just so you guys know, I want you to try to keep the hardware in the kits until the second half. It's a little bit different. I usually run this a lot more time constrained and I try to just jump people onto the hardware, but I actually want you to try to pay attention to me. Crazy thoughts, but. Because the hardware is far more interesting than I am and I'll completely review. Pre-requisites included Linux laptop, with 100 gigabyte like all this stuff in the brand. Other than that, you just talked to beyond about getting the hardware. There's Wi-Fi in here, it shouldn't be required for that. Believe it or not, I get to cheat. The hardware is far more interesting than I am, so I'll try to bore you to. Actually, I was pushed to this latest version of Akin-Kreidner, a Skunkworks thing. At this point, TI just spends 90 states that allow me to just focus on it completely. Benefit for TI is obviously people's support and all the kids and everything, so they're all public. The basic structure, other big components, picked up these boards, brand new, closer to the development of myself, exercising the bacon bits case mostly, and then take a step back and talk to what I expect. I consider and talk about the cool things that people have made out of Deagle for a week. Just get a little dive into the lab where you'll get started and do all the stuff that I did yourself. Questions about if it's possible? How many of you have already done the Linux before? This is a good, has a top Linux. Makes my foundation so you make it. I want to call that, and where a lot of our community is surrounded by industrial automation type of tasks. So I meet a lot of people that do, that build a lot of industrial systems and stuff using. So inspiration about how we want to go about that comes from my own personal, what way back when, when I got into a computer. In front of that computer and, you know, the life of things that you could do on a computer, it was all extremely hackable. If I could do anything I wanted to except take a pledge hammer to it. Or she didn't actually want me to take a screwdriver to it at that time either. But, you know, that came later on. But, you know, because she could take all of her important stuff and put it away in the safe, I'm gonna mess it up first by using that to that computer. So, want to get inspiration. And for me, I got into, I couldn't use the computer without typing in programs. You actually had to sit there and type them in in order to get the computer to actually do anything. So I wanted to play a casino game and I had that sort of osmosis computer typing these things in. You kind of understand what some of this is actually saying. Just some of this, the odds for cheating at all the casino games. And, you know, my dad never knew one. I was always winning. That's because I changed the code. And it really got me going about computers, all of my video jacks, following these. So I want to try to reproduce for other people of any age. But in this, so much to learn now, right? You know, they don't teach them more, right? They teach them how to use office programs. And, you know, it's using computers and not actually understanding anything about how they actually work or what they do. And there's a lot of ground to cover. And a lot of intimidation factor. We really choose to focus on Linux, a lot of which because of the way it's maintained. I think a lot of you may know it's maintained with this thing called Git, which keeps all the version history. Every time somebody makes a line of, change in a line of code, it's documented in the Git repo as a patch. And so we can go back and explore all that history. And it's really trying to understand where all these things come from. You know, having that documented history is a huge point of building understanding. So we can understand about elevator algorithms. You know, why do people introduce new ones and own all the crazy fun things that make up an operating system and really make up modern computing if you really want to understand computers as they are today. Making things affordable means that it's hackable, taking out the critical information that you can't live without. Somebody crashes the hard drive, making it where you're not scared of breaking it. It's replaceable. Making sure things are open all the way from boot. If you're attending all the different talks, you're gonna be doing the run, actually compiling the boot loaders and actually building it from mainline open source boot loaders right from the very beginning. So you can understand things very early in the system. Getting to high level languages I think is really important for building understanding. I really like what a lot of people are doing with microcontrollers today. And you know, it's interesting to see some of them actually start to integrate high level languages in the target. But the nice thing about Linux is you basically, whatever language you want, it's there. Right, if you want Python, if you want Ruby, whatever that kind of fits your cognitive model that you can be productive in and understand, you can approach it with that. Still straight, if you're doing anything embedded, learn C. How many of you have programmed in C in the past? Yeah, so you know, that's the language you have to know, but the others are important in useful as well. Let me see some of them. And to motivate people with hardware, right? It's hard to compete with this idea of halo. Or like if somebody wants to create an application today and they're doing things on their desktop computers, they see very, very rich experiences that are very, very hard to reproduce or to really augment. Yes, there's some great tool engines and stuff that kind of help, but it's hard for them to sit down and create their first program and have it be halo. Where it's not so hard for blinking an LED, or maybe turning a motor, starting to get some things, interactions of the physical world that kind of be that drug that hooks people on to computing, so they want to understand more. Sword vision is to try to get things as simple to play with electronics as creating a web page. How many of you have written HTML? You know, it's easy. And we'd like to try to fill in enough gaps so that making with electronics can be that way. One of our big beliefs about starting up a Beagle, for us and just kind of being on somebody else's platform, I think is an important enablement for us. You know, yes, we can put apps on our computer or apps on our phone, but it's really somebody else's platform and it's got a multitask and do all the things that it's also supposed to do for a phone where if we make it an embedded appliance, we can really dedicate it to the task that we wanted to do and not have it be distracted with other things. It can do what we want, where we want, how we want it and we're in control. So I think that creating apps is great, but better to create an appliance that actually makes the technology more welcoming in your life rather than an extra distraction or an extra burden. And to do all that with open source as the catalyst. All right, so open source helps enable collaboration on what's a pretty big problem I think when we look at what the scope of Beagle board is trying to solve, we're not gonna solve it ourselves. So collaborating on the problem of making, embedded computing easier, making it more complete in what you can do and it allows people to coming in, by doing everything and very much in the open, it allows people to come in and kind of understand where you're at and get engaged and improve on the basics. Everybody can make a difference. So hopefully we're gonna recruit many of you over the next three days. Yes? There are github.com slash e-a-l-e and then it's flash slides. If you go into there, there's each of the different presentations, there's slides. So this is the Pocket Beagle presentation. Are you doing USB sticks? I don't know if it'll have the latest. Okay, so these slides will be on the USB stick. I think, I hear myself on the microphone now. Who would do the audio here? Is Tom walk out? There's no, they're complaining about a buzz. There's a, he turned up my game. Maybe I should move the mic closer. Sure, but yeah, if I'm louder on the mic. What's the Wi-Fi? Pasadena is the password, there you go. All lower case. So that's kind of the vision, but we're still a ways from saying that making with electronic disease is making a webpage, right? And there are things that we could kind of try to jump to the end point a little bit to try to make things closer, but not far enough along to say, like if we want to just boot to the browser, kind of make that be the user's experience. It's just too limiting for people today and there's too many places where the people that we're collaborating with are moving in different vectors in different, different places. So instead of just doing, jumping to a developer solution, here's your ready prompt, right? On this computer, we boot into Debian, right? So we've got a huge community of people helping to advance the status of software and a lot of different ways. And actually doing, like making the programming itself being collaborative, there's a lot of different projects that have tried to create examples on like user space interfaces, all these sensors, right? So a lot of the problem we're trying to solve is being able to control motors, read sensors, you know, talk to different things. There's a lot of different places where people kind of go off and do some of the stuff on their own. The place where there's really great collaboration, the place where we can actually all really work together is the Linux kernel, right? It's very organized. We want to talk to a new device. A lot of people have this instinct to go and create a user space thing that goes and talks to it or, you know, to otherwise kind of find a way around it. But if we put it in the kernel, we all have it. And then we have it on every platform that Linux runs on, which as you know is massive, right? So rather than trying to make a Beagle library to go and talk to different sensors and motors and different things, where we really are successful collaborating is when it goes into the kernel. And we'll kind of, as we get into some of the programming details, you kind of see some of the hacks and trade-offs where you kind of do some stuff in user space and kind of do some stuff in the kernel. And there's really not one amazing development environment today for what you want to do because a lot of it starts to get really domain-specific pretty quick. So some people are really happy with command line SSH for doing development. I happen to like the Cloud9 IDE. It gets me into the browser. I can actually run VI in my web browser. But there's no bread. There's pure data, super quiet. All these graphical programming tools, LabView, MATLAB. But all of these are possible to do with Beagle, right? So these are all different ways that you could be doing embedded development. Scratch and block leave, more about learning, but potentially you could make some physically interactive things even with high-level graphical programming tools like that. And the different domain-specific approaches, so we find a lot of people in our community are going and they have other distros or other things, focus points based on what they're trying to do, like machine kit is a mill controlling. So people use it for controlling mills but also things like laser cutters or pick-and-place machines. And things like there's different PLC software frameworks. So people doing this latter type of programming is something that a lot of people know in an industrial control system. So people have like toolkits for that. And then when you look at like how to actually do the physical interconnect stuff, there's a whole bunch of different approaches for that. The add-on boards for BeagleBone are called CAPES. We're kind of leaning towards calling the add-on for the Pocket Beagle Pocket CAPE, a Mini CAPE. And then, but there's all sorts of other standards like Microbots we'll talk more about. There's the Grove, which is this four wire connectors for I2C and URs and GPIOs and analogs. There's PMOD, which has a bug, right? There's dozens and dozens of these out there. And then there's like when you start trying to build up all the other stuff around it, there's a whole lot of different approaches. So those are kind of some of the barriers that kind of keep us from kind of just solving the problem as a whole, trying to give one a single point solution. But we don't want to try to go and solve all of those problems ourselves either. What we want to do is try to engage developers within the open source community to go and try to address all those needs. We try to get engaged where we really think we can help. We work with seed so that if you have a BeagleBone Blue, they have little adapter cables. You can directly connect the Grove connectors to the connectors on the BeagleBone Blue. There's patch cables for that. We made Pocket Beagle so that you actually, the pinouts are such that you can place two micro bus clicks on it. And there's over three. So each of these has like hundreds of different add-on things that you can, sensors and controls that you can add on, either the Grove system or the micro bus system. The Pocket Beagle, you can connect those directly. And then we have a growing ecosystem of people making derivative hardware and actually like working with us to make sure our software images run on that target hardware so that people have a common developer experience and kind of take that to different platforms. Things like the BeagleLogic, which is essentially a logic analyzer built around a Beagle. There's a new 3D printer controller coming out called Revolve. That should be launching later this month. That's based around a Beagle but has all the stuff for doing machine control for 3D printers or mills. Integrated into it. So that's kind of how we generally try to approach. There's some of the things that we do to try to approach the problems that we're trying to solve. And so back in 2008, we started the original Beagle board and that was $150. Our goal was to try to get it down to below 100 so we managed to do it at 150. And then we updated it with a higher speed processor in 2010 with the Beagle board XM. Also in 2000, I think it's 2011, we launched that white board, which is the Beagle bone. And that one was launched at $89. And then the Beagle bone black was launched in 2013. And we were able to get it down to $45 at the initial launch. And that was really the big difference was getting from building in batches of 10,000 to getting our first order for 100,000 boards. So what really helped us right there was the launch of the Raspberry Pi, which built a lot of attention for single board computers. And so it actually increased the demand for Beagle bones quite a bit. We've taken the base Beagle bone design. We worked with a company on table systems to put the bulk of it into a system and package. And we were launched a Beagle bone black wireless at $69. Unfortunately, it's a little bit more expensive, but it has the wifi built in and it's using the SIP. But we took that base design and we integrated everything that you need for robotics control and then created early last year the Beagle bone blue. And it skipped in actually 2016. We launched the Beagle board X15, but it wasn't until kind of mid last year that it actually started being available in quantities. So that's the really high end board PCI Express, data, it's got two gigabytes of RAM. It's got a dual gigabit ethernet to USB three on it. So it's got all kind of the everything in the kitchen sink thrown in there. So we've got that as kind of our desktop replacement line like Beagle board is a kind of like, you know, fanless low power desktop replacement style to get you kind of into embedded development. And the Beagle bones are in this mint tin form factor, right? So it's all the sides of an outside mint tin and the maintaining that fact form factor with the cape support. So we're also doing some things specifically on application areas where we see a lot of users like mobile robotics, it's a huge application area. So put the motor controllers in here, battery management so that there's Wi-Fi and Bluetooth and there's sensors on here. So it's got the accelerometer gyro, compass and everything are all built in there. That's a ready to go flight controller essentially. And then the new cool fun thing is the pocket Beagle. So again, working with the folks at our table on the packaging, they took it down from a 27 millimeter package down to a 21 millimeter package. And we just stripped everything away to make the pocket Beagle. So over our objective with making the pocket Beagle, we wanted to get it a lot simpler. So actually leveraging how much stuff is inside that system and package, it actually makes creating a Linux computer really easy because it's almost all integrated. Essentially you could probably dead bug one and make it run because all you need is a crystal power and power can be very pretty flexible because it has its own integrated power management. So you could take a LiPo battery and just connect up to it and a crystal and you need some sort of boot medium. You need some way to feed it data. It has a lot of, you need to kind of bootstrap the, there's pins that set what the boot mode is, to need to pull those in some direction to tell it what boot mode it is and it's gonna go off chip to try to fetch its code to run it boot. And that's all you need. It's got the RAM integrated. It's got the power management integrated, the processor, all the decoupling caps and everything you need. So we wanted to try to make pocket Beagle really leverage that simplicity and demonstrate that simplicity. Make it something where people can actually take it and really modify the design, right? Really open it up to having a richer ecosystem of people making more targeted things like the 3D printer board or the Beagle logic. And the, we also wanted to simplify the user experience. One of the biggest headaches for users with starting with the Beagle loan is it's too flexible. And so what I mean there is the, each of the different pins on the header, there's a pin mark. Each of the digital pins can have one of eight different functions. And in order to set those functions, you may have to write a little bit of device tree code or mess with a bunch of scripts and all of the instructions have kind of changed. So it can be complicated to start doing that IO because the defaults aren't well known. And so you have to kind of try to work your way and to try to get it configured the way you want it. So with the Pocket Beagle experience, we put right on the still screen and said, okay, this is the function that's gonna boot up and run at startup and you can just start interacting with it. So we kind of predefined the functions. Yes, you can still overwrite them and we'll overwrite them here in this class and change it so it's still flexible. We wanted to try to make it as simple experience as possible. I really wanted to try to improve the flexibility. We put USB on the headers now because that's a nice way to do a lot of expansion on board. Signal integrity, you know, when you go across there it can be a challenge but we've not had any real issues. You know, a lot of people have been able to successfully make USB connections on add on board or Pocket Cape. And, you know, one of the other challenges with the Beaglebone Black was that we reused between the original Beaglebone and the Beaglebone Black we used some of the pins on the header actually on the board itself for the LCD interface for the HDMI interface and for the EMMC flash that were both added between the white and the black and that meant that you had to disable those in order to use those pins. When nothing on the Pocket Beagle is actually consumed on the board, they're all free for you to use in their mode. So no on board board consumption. And we also didn't put the header on there by default. All your boards are gonna have headers soldered on them but if you buy a board, it won't have a header on it. It'll be just the bare seat. You can put the headers on top or bottom or even if you wanted to, you can solder it directly onto another PCB. You can actually just reflow it onto another PCB without even a header if you wanted. I mentioned adding the support for the two-click boards that the pin out and the spacing is such that you can place two clicks onto those boards and I'll show off some of those later. Stuck with the Mint 10 theme. Just went from the large Mint 10 to the small Mint 10. We have my, so now we've, so the Pocket Beagle is in the size of this Mint 10. That's where it gets its form factor from. Cause this is, I don't know if you've seen survival kits built on the Mint 10. So the theme here is that computing is a necessary part of survival. This is part of, this is your survival kit. So this is something that goes in your survival kit. And we try to get things down low as cost as possible. There are a lot of cheap Linux computers out there. There's a lot of cheap Linux computers out there that are sold below cost. Pocket Beagle is not one of those. Everybody in the chain makes a little bit of money. Yes, we don't want them to get too greedy, make too much money, yes. But if it's the end of the day, if they're not making money, they might stop making it someday. And I don't want that to happen, right? We're built for longevity. So the price isn't gonna go crazy. It should stay around that $25 point for 10, 20 years. So people can actually choose to use that, create courses like this and use them and reuse them for years, things in universities and things like that. We wanna make sure these are available for everybody. And if you decide to create some training, you're not gonna be wondering how am I gonna get boards now because they stopped making them because they weren't making any money out of them. So this is sustainable. It's not you go into, yes, Micro Center was selling them for $20, but that's not where it's at, right? So, but it's not that you go places, you can only buy one, maybe you're familiar with another Linux board out there, you can only buy one of, unless you buy the $70 kit. Anyway, key features, it's a gigahertz ARM Cortex A8 processor. So it's ARM V7 filter issue bit processor. But it runs at a gigahertz, it's dual issues super scalar. It's reasonably quick. It's not gonna blaze the blaze new trails, but it far exceeds what you need for most embedded industrial type of applications. The really cool thing, of course, that's kept this processor around for a really long time is that it's got these other microcontrollers in it. The two 32 bit peer use are really, really powerful and flexible. They give you single cycle access to iOtens, and they don't have any tasks that they're doing while you're running Linux, they're doing whatever they're supposed to be doing in hard real time without distraction. So they're there, and a lot of people forgot really fancy cool ways to do things with it. They create other types of protocols that they implement, soft peripherals. They get them to do a whole lot of stuff. I need to speed up a little bit. There's a Cortex M3 in there as well, not a lot of people program it, but it's there for power and security. You could do all sorts of other things with it. It's got a 512 megabytes of RAM, it's got USB, and a whole boatload of stuff in the expansion connectors that we'll talk more about. This is what the Pocket Beagle looks like. There's a couple of headers. You have the boot medium off the Micro-C. I talked about the boot config on there before. Those are the resistor packs that tells it what mode to come up in. There's the clock, the crystal. There's a power button. So if you're power up off a battery, you actually need to press the power button to tell it to come up. If you press the power button while it's running, it creates a system event to tell it to shut down. So it'll be shut down gracefully. If you hold the power button for 10, 12 seconds, it'll do a hardware shutdown. So the PMIC that will detect it, if it tells long enough, will actually shut down directly rather than waiting for the software to do it. The USB is on the go. There's four user LEDs, a power LED, and not a whole lot of other stuff. There's no backside component. So it's all one side assembly. This is what the backside looks like. I mentioned earlier about the silk screen defining the different functions. You'll see things like, here's my spy port. It's got chip select, clock, and everything. There's another one. I will mention that which chip select isn't actually noted there. It happens to be chip select one on spy one and chip select zero on spy zero. You've got the, if it's meant to be a GPIO pin by default, there's the GPIO, the internal GPIO number. So you can just directly reference that there. The UARTs are used and their port number and the transmitter C pin. There's analog pins on here. These are all 1.8 volt noted right there in the silk screen. There's a couple of analog pins that have resistor dividers and are connected up to GPIOs as well to do 3.3 volts. Part of that is to provide the micro bus compatibility since it needs analog and GPIO and 3.3 volt analog on the same pin for some of the clicks. There is a mistake on the silk screen. That actually should be GPIO 44. My fault, bad email. Same reason you don't have USB hubs, bad email. Anyway, this is more the detailed view kind of showing some of the more useful things. Each pin actually has eight different modes, but I think we've summarized the most critical ones just looking at three of the different modes for the pins. So the analog pins are dedicated, but there are some other pins that are more flexible. Like if you wanted to use a quadrature encoder, it's available on like a quadrature encoder too. It's available, there's the A, there's the, where's the B for, here's the B for quadrature encoder too. You can do hardware pulse counting if you want feedback for motor position. There's the peer U-pins that has the ultra latency. The peer U can actually access either way directly through its GPIOs or through, it can go through the on-ship peripheral bus and actually connect all the GPIOs or all the peripherals for that matter as well. Ethernet is not brought out, so that's not broken out at all on the expansion header. Part of my thinking was that I wanted to reserve it so that if we did any derivatives, I wasn't making, potentially having people consume those pins on an add-on board. So none of the EMMC signals were largely not brought out, so if we wanted to do a version with flash, we wouldn't have to break the header compatibility and as well as the Ethernet signals, we wanted to use those for something else. So I avoided bringing those out. I can't flip the slides, oh, slow flipping slides. Okay, it seems to get stuck on that slide for some reason. So this is the basic pin out of the micro bus. So this is from the micro bus standard. You can see that it's got an S5 port, an I2C port, a UR, PWM analog, all these things, as they're kind of their standards to announce. There's over 300 different boards that match this configuration and the way we did the headers is it maps out the two of these on our pin headers. So if you look at the inner rows on each side, those directly map out to micro bus. So you can put one click on that side and one click on this side. They're both, they're done from the top. Some debate whether or not we've, some thought of whether we should put them on top or bottom and looking back on it, maybe I probably would have flipped it over. But my sensibility at the time was to keep all the components facing the same direction. So bacon bits. So that is this add on board. So I have one of the kits. It is a pocket beagle on the bottom and a bacon bits pocket cape on top. That was designed specifically for this class. When did we start this development? Like maybe Michael, you, so Michael back there designed the pocket, the bacon bits. When did you get started? Like eight weeks ago, six, eight weeks? Yeah, so maybe five, six weeks. I picked up the board Tuesday. So, but this is all done specifically for this class. We started looking at like, okay, we want to wire this up and that up in order to talk about these all the different types of interfaces. It just looked like it was gonna be a lot cheaper for us to put it everything on a board and build it and you wouldn't have to worry about loose wires running all around. You should be able to plug it in and go. And that was essentially the same concept as the bacon cape that sat on the beagle on black that Dave Anders had designed. So the name bacon bits was discovered. And bacon also came from another board that was called a beacon. Which is just, you kind of gave you something really quick to just hack an RGB LED in order to start learning some embedded Linux stuff that Dave Anders had designed. And then when he wanted to come up with something a little bit more complete as a cape, he decided that, well, dogs love bacon. So, it's the bacon cape. And now we have the bacon bits. And so it provides us a common target for talking to all these different cool buses and avoid buying a whole bunch of different modules. So these are the key features. It includes the USB to zero. So you can see the boot console. So you can even see things that are coming up, you are zero, write a boot. It has a USB host port on it using the USB on theirs because we don't have that host port built into the, to the pocket beagle itself because we reserve it for expansion. It satisfies it by bringing a host, a USB host port. It remaps, it also brings out the power reset button. So you can do a hardware reset. And because the cape covers up the power button, it also puts the power button on top so you can reach it. Thankfully, it goes to the header. There's also another, there's a third button, which is the GPIO push button. It's the one, when you get your board, it's the one closest to the seven-segment LED. So that's the one you wanna hit. It's the one next to the seven-segment LED and not the other two. Otherwise, you're gonna have to wait for your code to reload. There's a thumb wheel on there for doing interaction with the ADC. There's a tricolor, a big tricolor LED that's currently going blue for me that is connected to PWM pins. So you can learn about PWMs. There's the seven-segment LEDs are controlled by a spy device. So you can learn how to do spy. And then there's an accelerometer connected up over I squared C. So you get to learn how to do all of those different interfaces with this one board. Cool? I've got some stuff in here in the slides that I think is gonna help for some reference. I'm gonna kind of go back and forth with actually showing you some of this stuff working. I think I'll actually just do it right here rather than... So this is where the GPIO button is connected. It's connected to P233. It's got a pull-up on it, which is really not necessary because there's pull-ups within the processor. You can turn those on and off, but it avoids you from needing to configure it. So if I go to... I'll show you later how to get into this, but I wanted to just show you some actual live interactions with the board for each of these different interfaces. Let me hide the rest of this stuff for now. So just say that I'm logged in, right? Because I'm happy to be using my web browser. I'm now logged into the board. There's this tool called config10. We said it was P233. So I can use config pen to give me some basic information about that pen. Are you asking me a question? Well, it depends on... That amount, I mean, it's designed to handle that amount of current for sitting at them. I wouldn't drive more than five milliamps. I wouldn't make your design do more than five milliamps on these IOs. So if you just think about it as that, that's kind of where I put the limit. Left edge. Good? All right. So P233 is where the button is placed. I can see that. So I can go to... In Linux, everything is a file. And that's an exaggeration, but part of what the kernel does in terms of abstraction is it gives you that some standard interfaces. Read, write, control, and IOC dole, right? They're kind of how you talk to devices. And those things can ultimately map to the directory structure so that I can read and write these devices just through virtual files. So SysFS, I mean, have you heard of SysFS? You used SysFS? A bunch of you haven't. So SysFS is a virtual file system. So there's nothing sitting on my disk itself. So it's not on the microSD card. It's just something in RAM. So I'm only talking to the kernel by talking anything into the Sys directory. I can get a list of some of the different things that are mounted. So some things when I get mounted in location. In Linux, there's a single hierarchy for a, like there's a single root hierarchy for any environment. So like there's one, in any place, there's only one root. There's only one slash. And everything builds on top of slash. So mounts tells me like, what is it going on top of slash? So, and also tells me what slash is, right? I can find, should be able to find the root file system somewhere. Here we go. So DevMMC block zero partition one is my root file system, right? That's the disk that I'm actually running as my root file system. And mounting other types of things on that. I've got a SysFS entry that's handled by the kernel, mounted it, slash disk. Anyway, so that's just talking to the kernel. When I read and write these files, it's not actually touching the disk. Like, so it's not having the kernel talk to the disk, it's having the kernel talk to other hardware. So there's a GPO class, in SysClass GPO. And we saw, let me do this config pin thing again. So config pin is a purely Beagle specific app, but it gives you some useful information about the different IO pins. And here I'm just using it for quick reference, right? So it's telling me that the kernel GPO ID is 45. So I need to kind of map those two together because I was looking at that location. So inside of that directory, I'll see a number of other files, including direction. We should see the direction is in. And I'm not pressing the button. Anybody guess what the value should be? Okay, I didn't hear anybody said zero. You're right, one. It should be one. That's what, we got one. Good. So that's because of that pull up, right? So the voltage should be sitting at that 3.3 volts. And then when it reads over that IO pin, I'm seeing that the value is in fact a one. Now if I press this button, that should ground that pin. So it's shorting the connection between the IO pin and ground when I'm pressing this button. So it's a normally open button. When I press it, it closes it, it shorts it to ground. The voltage should now be zero. Voltage should be zero. And the GPO value will read back back to zero. Yay, we read a GPIO. You get your first hardware, real world hardware interaction. But that's pretty significant, right? And Linux makes that really easy by turning everything into a file. The hard part for us was just mapping the numbers, right? Figuring out what the IO pin maps to actually and to the software. So GPO 45 and to the Linux kernel. Well, that was easy. Let's try a little bit harder one. So this is the thumb wheel. I mean, if I'm doing my demos, I want to do one other trick because this is going to help me on this next time. I want to introduce you to this program called watch. So watch is just going to continuously issue this command over and over again, so I can see. So the command I want it to do is value. So watch is going to clear the screen and run this command every so often. I don't know exactly how often, I don't remember, it's like every 0.1 seconds, apparently. So every 10th of a second, and it's going to keep running that read the cat. Cat is the program that's just reading the file. And so again, most of you are familiar with Linux, I don't have to say that. But now if I press the button, it goes to zero, I release the button, it goes to one. I wanted to do watch on the GPIO because when I started doing the analog, it gets to be more interesting. All right, because we're going to be changing it, changing it constantly. Now this one I'm just going to kind of jump, there's, where that happens to live is in the subsystem called IIO. That's the industrial IO subsystem in Linux. So analog to digital converters, a lot of the sensors, a lot of those things live in this IIO world. So a whole lot of things are going to come up for you in IO. It's a really interesting subsystem to learn more about. So I'm going to look at what devices are in IO and I'm looked at, I only have one. That's my only IO device currently installed. I look at the directory and it looks pretty straightforward right, because there's a number of different in voltage raw signal or file. Now I think that's a little bit of a misnomer. Just so I put in a little extra note in here, connected to P119, that happens to be AIM-0. All right, so if you looked at the header map, this one I don't have a nice, maybe config 10 might tell me that actually. I don't know if config 10 will tell me that. P1, was it P119? Oh it does, it tells me it's AIM-0. So config 10 would have told me this anyway, but I actually put that one on the slide. So that's zero. So the one I want to look at is in voltage zero raw. I think it's a bit of a misnomer, because it's actually just right now on what the driver's doing, is actually giving it a 12-bit A to D. So you have a 12-bit number going from zero to 4095. At 4095 you're at 1.8 volts, at zero you're at zero volts. So you just divide by, the division to convert the scale to 4096. So 4095 being the maximum value. So if I, you know, obviously I don't want to sit here and turn that, so I want to just do watch, run that watch command. I don't have to keep typing every time I want to see the value change. So now I can turn the scroll wheel. So I'm going to turn all the way to one way, 4095, turn the wheel all the way, the other way, watch it changing as it's going, and it goes down to zero. All right, cool. So now we've done the ADC. Questions? Is this the type of stuff you were hoping to see and learn a little bit about? Yeah? Hope I'm getting into the meat of stuff right here. That's just, if it's not, I'm concerned. If this isn't the meat of what you really were hoping to see. Now this one's a little bit, again, a little bit more complicated, right? So the last two have just been inputs where we're just reading a file. There's an existing driver handling it. So here, there are drivers for the RGB LED. But just sit there and try to poke everything at the command line. There's a whole bunch of different steps. And when the labs will try to spend some time, I'll actually try to walk you through some of all those individual steps that go on. But I'm going to jump up to JavaScript here. And I don't know why I have that one before. Oh, yeah I do. So these are the labs that are checked in during this EL code PWM, there we go. I don't know if my font's readable back there. Not, can you see the screen at all? That's too small, I'll make it bigger. So here I'm going to use JavaScript. And all of this is still just doing essentially the same stuff that I was showing you. Peek and poking, reading and writing files. But here I'm just using JavaScript to do all the reading and writing of files for me. And it kind of understands some of the different things it has to set up in order to actually enable the PWM. And there's actually a bug in my code as well that we get to see. So this is my program. I'm going to actually run it from the command line. So it's in, I put it in the EL, there we go, EL code. And it's in the Resources Pocket Beagle when you go and look at the GitHub. So I'm going to use Node, which is a JavaScript interpreter. Everybody knows from the command lines, the first word is just the, I don't have to tell you that, is that. So Node is the interpreter that I'm going to run. And PWMJS is the program, so it's this program. That program is going to set each of the different pin to be analog output, which is just terminology for a PWM. And then this analog write function, this analog write function takes first argument as a pin, the second argument is a value between zero and one to say what the duty cycle of the PWM output is going to be. Now the first time I run it, I think it should fail. Because there's a, what has to happen is when we have to enable the PWM, initially its permissions come up as root only. And I'm actually running this as the Debian user. Did it just work for me? Oh, it just worked. How beautiful is that? So initially that it comes up as a root user. So we've created a Udev role. How many of you know what's Udev? Some bunch of you aren't. So Udev is a way that the kernel can notify user space of device attachments. All right, so things that have changed state. So it can notify user space so that you can do things like run script. And so what we've set up in the default distro is when the PWM devices, when you enable one and all the other stuff shows up in the SysFS directories for it, it all comes up initially as root. We have Udev role that actually runs a script to change the permissions to make it accessible by Debian. The JavaScript code doesn't have a good point where it waits for that. So it'll try to go and access the directories that are supposed to be created and sometimes the first time you run it, they're not available. They're not accessible as the Debian user. So that's just something to be aware of when you're running these little JavaScript apps with the PWM, that there's a bit of a race condition because that Udev role has to run to change all the permissions so that you can actually get access to Debian. That kinda makes sense? Okay, in the labs we can kind of dive a little bit deeper into it. Actually, I'm over my time from getting into the lab. Are you just waiting? I'm gonna wrap this up real quick. I'm gonna do a couple more interfaces that I'm gonna show you and then I'm gonna turn it over to you to actually do some hands-on and I'll show you how to get started with your board. Let me just do a couple more of these before I flip it over. I will notice that, I will note, and Michael, I'll point this out to you live here now, the red and green are swapped. So because a different LED was used in what shows up on the schematic, red and green are actually swapped. So just be aware, found that out in actually writing code. Yes? Why is there PWM red and PWM red alt? We had some debate in making the board whether or not we could just use those microcontrollers to control essentially one of the levels for the LED because I wanted to try to save that pen to make the, we could still add a click board. But anyway, we did it without being a click board support because the non-alt is a hardware PWM. The one's actually being used, let me flip back to the slide so I can answer your question there better. The one is actually, you see there's a no-pop on the alt. So there's actually not connected. So the one that's actually connected is the one that's on P2 pen one. That pen happens to be used by the micro bus header. So it prevents you from being able to use a connected, a click that uses that pen. So we just built it as a, so Michael just added it as an option, but it's all populated so it's just the red one that's using. So there's also a seven segment shift register. So similar to the way everything else in Linux is exposed to this file, there's also this thing called spydev. So here's where all the different pin connections are. So this thing looks like a spy device, an SPI device, and the protocol, the wire protocol is essentially a data bit per clock. So you'll have a clock that goes up and down and then you'll provide data out on the pins. The MOSI and MISO terms, that's master out slave in and master in slave out. That's the direction of the data line. So there's one data line going from the processor to this device and there's another data line coming from this device back to the processor. We won't be using the return data line for this example, but we need to toggle the clock. And then the chip select tells it that this device is currently active. You could potentially have multiple devices on the same spy bus, but each of them would need to have their own chip select to tell them when they're active. It also tells you when you're starting a command. So if you get to the chip select falls low, you know that you're actually starting a new command. So I've got some more examples in here. I'm gonna just, I'm gonna show you, let me open spydev.out. So this is the spy device, we don't have a Udev role to make it accessible by Debian right now. If you want to use spydev, which is the user space interface to the spy controller, then you'd have to run it as root. And so each of these different slash X lines, that's the command that you wanna write to the controller. So you have to look at the datasheet for that spy device and try to figure out what that is. So the first one is essentially the address of the controller. You always put 40 on this particular spy device. The next one is the address within the controller itself so which register you're writing inside that controller. And then the third byte is the data value. So the four different commands that I've got up there, the first two turn on the output for each of the different groups. So they're grouped in groups of eight. So the first one turns on the output to the first eight 10s and the next one turns on the output to the next eight 10s. And then the last two commands actually set the value on those 10s. So if this works right, I should be, oh, I did not wanna do that. I should be displaying the value zero, zero, because you set the IO 10s here to zero in order to turn on the LED. I know for one thing I checked in the wrong version because I didn't have this as bin bash, but best laid plans, right? So I've got a little bit of demo items here. So one of the things I haven't pointed out is so what config 10 is actually doing underneath the scenes a little bit. If you, well, you can use config 10. So it provides information, but you can also use it to actually set the pinmux mode. If I did something like config 10 dash, let me query p225, it says it's in spy chip select mode. I can actually use it to change it as well. I can go config 10 and set it to GPIO, right? And the valid modes, you can get them with the dash i. So that's the list of the different modes that you can use. The way it's actually doing it, there's another thing, it gets exported to the sysfs entries, which are these pinmux helpers that we have loaded that we use to try to switch the different modes, right? So there are these files where the state of the pinmux is actually kept in there. A helper function, a device driver that we can use to change those different modes. So these functions are setting the different pinmodes. That number's wrong. Yeah, wow, how did this code get checked in? The chip select is 31, and that turned off in certain mode somehow. So a chip select is 31, s clock is 29, and most is 25. That will probably make a world of difference, and it did. So I've now got my zero zero on the display, right? So I've now done a user space spydev access. I also have another example in here. We'll just save that all for labs. Let me finish up the lecture. We got another 10 minutes beyond, so for the break, you wanna do another 10, 15 minutes in the break? Yeah, that's perfect. When we come back, we should be ready to do the lab. Please come back, because now you actually get to play with the hardware. Yeah, yeah, I will, absolutely. I'll do that right now, actually. It's the one called Pocket Beagle. Straight from where? SSH? Yeah, you don't have to go to, you don't have to use the ID. Yeah, it just gives you. Oh, where'd that file go? Hmm, sure. I just saved it, exported it, and I don't know where it went. That's probably not good. Okay, we put it in the right direction. Oh, that's really wonky. Right, that's what we're having trouble with. They were far from perfect. No, I agree. No, that's not good. No, no, they're correct, they're opposite. Oh, you're right, okay. I should be responsible by forcing it, is that the? I don't know, I think Tom was trying to make a point, but I think you just made your point. So, yeah, basically, it should work. Okay, cool, thank you. Basically, it's a through-all pin, it's a very good one. Through-all pin, right? What's the meaning of that? Offering is kind of pre-downloaded. No, no, the disk should be all set up and ready to go. What's the stuff for the lab? You need, like, Linux? You need to have Linux. I have Linux, yeah. Okay, and I don't think so. Okay. Yeah, you don't need a VM for this. If you have Linux, you can just run everything and install it natively. Okay. And I'm not gonna have you install any stuff. I think for the other classes, they will. Okay, thanks. Everything I'm doing is on the board, as well. You're definitely built-in to set up the app. Or is that you can leave that up to the application? Anything built-in to debounce it. Like, if it's a bit of a momentary question. There's, you can do software debouncing in the Linux kernel. I don't think Michael put any, we talked about putting in, like, a cap or something to kind of smooth it out. It depends, yeah, absolutely. And it just depends if you need that clean of a signal. I really, my expert, I do a lot of, just GPO keys with zero debounce and with just regular buttons, but I use the internal pull-ups. And I haven't had any problem with just using that directly to generate key event. E-ALE, E-ALE. So why are my power not, why are? Here's some, well, is everybody back now? No, everybody is back. Everybody back and everybody have kits. Well, we're working on the kits now. That's what it is. Hi there. Yeah, I know, did you register? Pre-registered? Yeah. Okay, you, and the guy you want to see. He's on his knees, or he's bent down in the back. Everybody who paid for the kit, yes, everybody. Anybody not have their kit, who paid for it? Okay, we got one person back there. We got one person right there. Okay, thank you. Maybe, well, they left their computers, so we think they're gonna be back for too long. Maybe when you're started, we'll catch them up. So inside your kit, I don't, I needed a slide for this. Inside your kit is the pocket beagle with headers soldered on, so it doesn't normally come like that. A bacon bit, mini cape or pocket cape. There's also an SD card that should already be inserted. That's also something that doesn't normally come with the pocket beagle, so the micro SD card is added to this kit. There may also be an SD card adapter. You'll have a baggie back behind with two USB cables. One for the pocket beagle, the other one's for the bacon bit. So you can interface this to your report. So as you talk to the debug console on the beagle for this, we won't be using the second USB cable or the USB connection on the bacon bits. We're only gonna be connecting up over the USB on the pocket beagle itself. So on the bottom board is the two stack. You don't want to connect these things hot. There's a potential for frying, it's very unlikely, but I would encourage you, especially if you're new to hardware, to always power off the hardware before making any modifications of connecting up the board. USB, you can hot plug, it's designed for hot plugging, but for connecting the daughter board, leave it unpowered, connect it together. The orientation, I don't have a good orientation picture, but the micro USB's go in opposite direction. So the thing that I use when I'm connecting this to determine it, there's actually a silk screen on here that has the numbers one and one and two and those match to the numbers one, the number one on the headers on the pocket beagle. So that's how I figured out the orientation is just matching up the silk screen and lining them up. We can get started in things with just the pocket beagle, but if you want to connect up the bacon bits, feel free. So the developer experience is a little bit like this. We provide, beagle board provides Debian Images built by Robert Nelson, and that you can get it, beagleboard.org slash latest images or this short vanity URL. We do everything, we try to enable everything to be self-hosted. A lot of people do professional development a lot of different ways, cross-building, you know what you're gonna learn, a lot of cross-building and the rest of these days, but for the rest of this class itself, we're gonna use the self-hosted tools. There's tools on there for both the arms, both of the arms, the A8 and the M3. We won't do any M3 code and the PRU. And there's libraries for the various high-level languages. The maintainer of the Python, Adafruit underscore BBIO library, which is the general Python libraries in the back wearing the purple shirt works at Oshpark, Drufasini. So if you have any questions about the Python library, see him. If you have any questions about the JavaScript library, see me. If you have questions on Go or a billion other different languages, there's other people. There's scripts for doing a bunch of common tests. We're gonna walk through some of ops script and then there are sources on there if you're going to ops source once you're logged in and there's servers running on there for getting access. So again, the way we look at doing development here is a single cable that USB cable is gonna power. Provided network connection as well as giving the interface for developing. I know it's been worth it to switch into PDF. But you can of course add network and a whole bunch of different ways and get untethered. So normally I would say the first step is to download an image. So in addition to the two USB cables, you also have a USB to SD card adapter in there. That's what allows you, you're gonna plug it and you don't have to do it today because the SD card's a free program. But when you go home, you wanna get the latest image. You go and download the image off of, this is the latest images site. Then you use a tool. I like Etcher with Linux. You can also just do DD, which is a block by block copy of the image, but you need to uncompress the image first. First of all, I just teach people use Etcher, kind of all in one. It helps try to prevent you from overriding your own hard drive with the image. It won't expose your hard drive as one of the options to select. With DD and you have to run it as root, you can very much do that if you specify the wrong disk image, you're overriding your hard drive and while your host computer won't run anymore. You lost it, so bad news, don't do that. Use Etcher if you're at all, squeamish. It takes the compressed images and it writes those to the SD card itself. And then once you've got that SD card program, this is where we're actually gonna actually start doing the steps together. So the SD card is actually inserted. It's okay to plug in your pocket beagle. So one into the USB cable into your computer, the other into the pocket beagle. And with or without the cape, the bacon bits connected. Cause it's useful just to get into the ID and kind of poke around with some of that stuff first. You can always unplug it. Some people always do a soft shutdown to make sure they don't have any crop files. I always just pull the power. It's an EXT4 file system. It's pretty robust. I almost never have any, I've never had any problems. I'm only occasionally to hear problems of people corrupting the EXT file system. And so I would just pull the plug when I'm done. So you can always pull the plug, connect the cape and reboot it. But anyway, we wanna get booted up. Cause what we wanna really solve in here for you, that's kind of the first real lab problem for you to solve is to connect up to the USB network. So the way this whole thing looks is it looks over the USB connection, it looks like there's a network device on the Beagle and there's a network device on your computer. So that's what it looks like to your desktop computer. So when you plug it in, it's gonna think that you've connected a network device. So it'll have an adapter and it's gonna try to say, oh well, it's plugged into a network so I'm gonna do a DHCP request in order to try to get my IP address. That's what your computer should normally do when you have a new Ethernet adapter. Some of your computers may not be configured to do that automatically. So that's where, you know, having this nice interaction point is good because we can look at your system and say, okay, let's tell it to actually go in DHCP on that new adapter. And then over that network, so the Pocket Beagle is the one providing you the address, the IP address. So it has a fixed address. It's just always gonna hand you the same address. There's actually two of them because for working with different operating systems, there's some of them work with different types of network devices better. But anyway, the one that we want is the 192.168.6.1 for our computer and 6.2 for the Pocket Beagle. And the Pocket Beagle will give your computer that 192.168.6.1 address. And it'll keep for itself 192.168.6.1. So when you connected it, did anybody see a flash drive show up? Some sort of no, no. Some people saw it, some people didn't. If you didn't see this, it won't happen immediately. It needs for Linux to boot up. There's enough bloat at this point that it could take a minute or so to boot up. If it's taking more than a minute, it's taking too long. But it could be a minute or so to get that. And the device will show up. You can open that up and click the read me. I thought it was pretty obvious for people to read read me, but apparently a lot of people don't read read me. Which is why we also have another copy of the same file on there called start. Just the exact same file. Just encourage you even more. Is there another word we can come up with to get you to open up the file? Open or die. I like that one. So open up that one. So that's on the left-hand side over there for you, is that opened up that start.htm or read me.htm. Which is really just gonna tell you to type in this magic address into your browser. If everything just worked, the network adapter showed up and you got your IP address to your computer. You should just be able to type in this magic address 192.168.6.2, and it should be there. And all the other words are just ways of trying to debug if that didn't just happen for you. It should just magically happen. Has anybody already been able to browse to 192.168.6.2? The number of you have. So the magic number is too small on the screen. Let me, so that's the other one. So there's two, if you're using a Windows machine, it's gonna be seven. Or a Linux machine will also see seven as well. Linux machine will actually see both of them. The 192.168.7.2 and 192.168.6.2. Linux will see both of them. So the one is an Rindus driver that loads nicely on Windows. The other one's a CDC driver that loads nicely on Mac. And also Linux, but on newer Linux kernels, you'll actually see both of them. It'll also have the driver that automatically gets loaded for our Rindus. In the browser. Yes. You can SSH into it. You can also go over the serial port, which you'll be doing. There's a virtual serial port. There's a number of different ways, but the magic number is in the readme. So if you haven't heard it, the 192.168.6.2 yet, it's in the readme. So when you plug it in, you should see that flash drive. Things like people are kind of, who is not, I know you haven't gotten the network access. Who else has not gotten the network access up yet? So we have a number of people. Let me give everybody else something to do, which is to open the IDE. So the only trick right now, the trick to opening the IDE is to put colon 3000 after the IP address. So you put colon 3000 and you get into the IDE, you get to the shell. Yes, SSH is really simple. For people that are on other crazy things and not smart enough to use Linux host, this is, gives them a way to get in real easy. Who did not have network connections? Sorry, so that's running Debian. Did the network device show up? Can you just go to your... Oh, we do need to share the network device? Cause you're running in a VM, okay. Yeah, it doesn't need to know. It'll see, but I'm sorry. Yeah, it told me it didn't. You did? Oh, but it only, that only, but it needs to do each of the devices. So there's, that's only the mass storage device. There's also a serial device. There's also a network device. When you, the VM needs to export each of them individually. For my stuff, why is it saying not connected? Maybe you can disconnect it from the VM, I don't know. That or the VM might be getting in the way. But it didn't say, it said there was no cable connected. So the... But it's a thought, right? It's thought, and then maybe it took it away into the VM. So where's the control for the VM, as well as what devices are in which? The other thing is this, for my stuff, you don't need Linux. You can just take it out of the VM and just use the Mac. Let's show what you want. Okay, let's just, just shut down your VM. And we'll just, we'll just use your Mac first. And you can, you can move ahead with that. And then we can worry about your VM for the next class. Are you, are you gonna do the same? Okay, anybody else not getting a network? So the people having network problems is the VM so far. Anybody else having network problems getting connected? Right, that's good, they're your network connection. So the magic at this point is just to, well, I shouldn't do it for you because I want to, you won't remember. But that's, you can click that and it'll take you, you actually click that link, it's actually, yeah, you can click right there and it'll take you in. Just waiting and, there it goes. Who else is not in the IDE at this point? You just got here, okay, if you signed up for the class, make sure you get a board from in back. Okay, yeah, I'm gonna go ahead and move on, but I think you should be able to catch up just following the readme. So there's a lot going on here with this USB thing, so I slow down and try to spend some time on this. I think it's kind of novel and fun and interesting, but there's certain integration challenges. So what's happening here is we're using a gadget driver on the Linux, so that you have your, the Pocket Beagle is a Linux computer, but it's running on gadget drivers, and gadget's just a term that Linux uses for things that aren't the host, right, there's a device, right, there's a device or the slave, and we can emulate a whole bunch of different types of devices. So Linux has a huge selection of gadget drivers, and in this case, we're running a multifunction gadget on top, so we can actually load a whole bunch of different types of gadgets kind of layered underneath it, and so all these different gadgets, most of them fall into classes, so there's classes like mass storage for a USB memory disk or a camera for your webcam or audio for your speakers or printers, hid for your keyboard or USB keyboards or mice, you can actually, if you wanted to, you could do key injection and have your Pocket Beagle look like a keyboard and drive things on your host computer, look like a mouse and take it over, it's very, very possible. So leave that as a longer exercise for the reader. There's some great Python scripts for doing exactly that. The session on USB is gonna talk more about the USB technology and some of those, I believe it's gonna cover some of the gadgets and the host drivers as well, so some of the drivers that are available, but I haven't looked over that presentation yet. So by default, we actually set up three gadgets, so there's a mass storage gadget that sets up that readme, so there's a file in the disk of the system, it shares that file and makes it look like a disk on your host computer, and that serves up the readme. There's a virtual serial port which is useful in case you have any of the networking problems on your host, actually that's a good workaround, you can actually log in over the virtual serial connection and kind of peek and poke on the device and kind of try to figure out both ends, and then there's the virtual network that we're using. I've got a whole bunch of stuff in here on booting that's really, really useful, but I'm not gonna do that stuff now. I did wanna show, I wanna go some things on the tour here before diving into the programming, so let's look around the IDE a bit. Mine looks a little bit different because I have some of the EL code installed. Oh, that was also playing with the Python scripts for doing HID stuff, but you should have something that largely looks like this. So the bottom is the command line, so this is running Tmux, I don't know how many of you have run Tmux, it's like screen, but it's kind of a modern version of screen, so it's running that here in your browser. So it's curses, cursters. It's Tmux is what we're running, I don't know what curses is, I don't know what cursters is. Anyway, so there's a Tmux window in here, and every time you, you could open up new shells in this, you could do new terminal, and you can open up new Tmux sessions in here, and then you've got the text editor pane and then a file for it. All of this is mounted on the disk at barlib cloud nine. So that's where it sees where cloud nine is pointing. And so we've got a number of examples thrown in there. Was there a question before I go on there from there? You need to log in as Debian and the password is temp password, T-E-M-P-P-W-D. And if you happen to go over the, like if I really log out, this is the serial session. If you happen to connect up to the serial session, it'll actually tell you on the console what the password is. So, yeah, just for future reference, let me, what's the magic for increasing the size? What is it? Control plus? Anyway, that's over the serial. This is screen, right? So I got to the serial terminal by using screen, right? I could use pseudo screen and then the name of the device that showed up. Found the device by doing a dmessage grep tty. Now there's too much junk in my log. So Chromium is overrunning my log. Anyway, we don't need to do that. So the text editor allows you to kind of see things really quickly. There's also, there's a run button up here. So there's a number of different, I'm gonna show some of the hidden files here. So, so hidden files. There's this integration here with C9 through these runners. So I can actually define what, when I click run for different file types, what it does. It's kind of a fun integration with IDE. And you'll see an auto run folder. There's a daemon running. If you drop a script in that folder, it'll run it on boot. So for people really, really unfamiliar with Linux, give them a nice handy way of just running scripts on boot up. And then there's the example. Under the examples, we're gonna look at the Pocket Beagle. And there's a number of JavaScript examples in there that you can run. The other thing I want you to look at is under extras. There's this. So to kind of try to turn you loose on the lab, there's this bacon cape lab. And I haven't finished transitioning all of these labs from Beaglemon Black and the bacon cape into the Pocket Beagle yet. But I think that it should be something with the information that we've given that should be fairly straightforward for you to actually go and do. So we can see, you can see different ways that you can go and access all these, the different interfaces through there. So those are the two things I want to highlight for you. Examples, examples, extras, bacon cape, bacon cape lab. And then the other one is this, anything's in the Pocket Beagle directory. So we'll go and do, the other item that we have is the code that we checked in through the eail. But so those won't be on your drive. So I'm trying to point to things that you can, but we can reproduce them. So the first one is there's a push button demo, push button demo and examples. I'm sorry, so this is examples of Pocket Beagle. There's pushbutton.js. Able to find that okay? But the button is wrong, right? The button is wrong, right? So we need to go back to our slides and maybe this will work better. Oh, there it is. I got lucky. This button is P233, not P233. It's just a generic example. It's not to save that. And if you put a dot or a dash, those will work as well. It also doesn't care about K. And you can click run. Unfortunately, node takes a really long time to start up. But when it says interrupt handler attached, you can see now I can press the button and we'll see the volume toggle. Yeah, so if you haven't, if you don't have your bacon bits attached, that's to go ahead and, you did the important thing, which I wanted you to do is that without the bacon bits, which is to get into the IDE, you should now be able to unplug and connect your bacon bits and get back into the IDE. Okay, now everybody's asking orientation. The orientation, the silkscreen match and match up, but the easiest way visually is the micro SDs go in opposite direction. I'm sorry, the micro USB connectors go in opposite directions. So there's a micro USB on the bacon bits and there's a micro USB on the pocket beagle. So the micro USB should go opposite of each other. So the big host connector goes on top of the micro USB on the pocket beagle and the micro USB connection goes the opposite. I don't know, I'd have to ask GHI. GHI soldered these together. And I think they must have hand soldered the headers. I don't know. I don't think it'll load up. Michael, have you looked at how the things map? If you plug it in backwards, it's not gonna hurt anything, is it? It could. I mean, the power in grounds actually are symmetric. I think when you flip it, except for the one ground for USB, because of the way they're lined for clicks, they're actually symmetric when you flip them around. So I doubt anything's gonna happen bad, but I don't know. So I had to go, to find the right value, actually I had to go back to the schematic of the board design. So the first thing I would notice if I tried to run something and I wasn't seeing the GPIO moving, am I actually using the right one? And so it's useful to kind of do some stuff back from our command line stuff. So I'm going to show you some of the JavaScript stuff hands on. But go back to config pin, right? So if we do, there's a handful of things to check when you're doing GPIO. Like one is that these, the right GPIO, but it's exported as a GPIO. And then you want to do things like, we found out earlier this is GPIO 45, so we need to recheck that. But there's a direction value. You're not gonna, if the direction was out, you wouldn't be able to read it. So that's a useful thing to check as direction. The pinmux is usually, if you're connected up to the right pin and you're not seeing the value change, usually the issue is the pinmux. So in this case, we've got the config pin helper. We know from the schematic that it's connected up to pin P233. And so we can look, sorry, that dash Q checks what the current mode is, dash I gives the information. So we can see that that's GPIO ID, kernel ID 45. So we can double check that. It does not save if you press run. I really quickly press control S after changing it. So if you change it and you click run, it won't save it. You lost connection. Did you unplug it first? Yeah, so it's gonna have to reboot. Not rebooting? It, you're not seated well. Yeah, you have to push, the bacon bits have to be pushed into the pocket beagle pretty hard. Well, you're gonna lose connection when you unplug it. Did you, so you're just actively using it? Oh, did you press the wrong button? So there's three buttons. Yeah, I forgot to recover that again because I mentioned it earlier in the lecture, but there's three buttons on here. The one closest to the seven segment LED is that user button, the GPIO button. The one below that is the power button and the one below that is the reset button. So if you press either of the two that aren't the user button, that user button, either of those two will cause it to lose connection and reboot. The middle one is the power button. If you just tap it once, it will shut down gracefully but it will shut down and immediately terminate the active session. Of course, the reset, there's nothing graceful about that. That's just going to immediately reset the board. Helpful buttons, but also a little bit of a risk factor for this type of lab. If you wanted to go in by SSH, so if you wanted to go in by SSH, so SSH, Debian, that's kind of distracting, it's the .8.6.2, the password T-E-M-P-P-W-D. So everything is in var lib, cloud nine. And then you go into examples and then the overall thing, the overall labs that I'd like you to kind of look at here is an extra as bacon cape. There's a PDF here and there's a number of scripts but all of these need to essentially be changed to go along with the new hardware. If you don't have the schematic, I have all the relevant information pushed in my slide. Has everybody been able to download the slides at this point? I did a PDF version now as well. So it's github.com slash E dash A-L-E and then slash slide. There's also a number of solutions under slash code, pocketbeagle.pdf. I see some blinking LEDs, that makes me happy because at this point I need to try to figure out if I want to slow down or speed up because I can show you some other cool stuff in here. Speed up? Oh, that's great. Yeah, no, there's, I would say everybody, there's a hashbeagle. If you're on IRC, is IRC okay or do you want Slack? IRC, so I'd say hashbeagle on FreeNode. There's also a beyond, is the E-A-L-E channel open for everybody or just developers? Okay, so actually that's probably a better one. So for this week, if you want to chat live, I'd say on FreeNode, there's E dash A-L-E so IRC.FreeNode.net? Okay, oh I love being able to paste. People are hearing. Okay, can you hear me better now without the buzz? Yeah. Yay, thank you very much. Appreciate that guys. Great, down a little bit up here. Yes, we can turn it down a little bit. If you're doing chats, this is a great place to try to collaborate, get some problems involved. This is a really great way to, if you haven't done IRC, this is a really great way to interact with the Beagle community following on. The hashbeagle, we think it's a little bit light today, I don't know, but there's usually around 300 people. Maybe they're all traveling, they're not leaving stuff virtually on, but hashbeagle is a great way to get some support. I tried to idle in it, you see even here while I was presenting I had it up there, so. But E-A-L is probably the specific to these labs. It's all a little bit, wow, but I'll speak softly. So okay, we want to try to speed up a little bit to show some other cool things. I'm just gonna go through. So thank you. If you're looking, if you can clone the code, that would be really, really helpful, but you can see the PWM solution there for fade. There's a similar thing under examples. I can't even speak quietly enough. Under the different tasks there about fading a PWM. There's also this, you saw that we updated the seven segment LEDs through using spy devs. You could also just bit-bang them purely with GPIOs. And so you could use the shift out function within JavaScript to essentially software emulate spy. I can't even speak loud enough to not get feedback. So what I want to, okay, I would like to try this, that's much, much better, thank you. So I want to try to go over some of what you've got to live boards and you can ask questions. I just full screened my console so that you can sit a little bit better. I don't even have the size a little bit of my font. It's obnoxiously large and full size it again. I don't know how to change, is that an option? Okay, background color, make it darker. All right, so there is under slash OPT. There's a number of different directories. Really useful stuff in scripts. So under scripts under tools, there's, once you get a network connection, so you should be able to do an internet connection sharing from your host and get the IP address from the Pocket Beagle. I've been struggling to do that with Ubuntu. No problem with my Mac, but anyway, I don't have that stuff to show you. But it's like, after you write the SD card images, if you have an SD card that's larger than what your, then the four gig is what the images are sized for. So you have an eight gig SD card. You might want to do something like pseudo-grow partition. That's what I do is when it's reboots, it's going to resize the partition. So there's a number of really helpful scripts like that in here. So it's a really growth partition. A really important one to know when you're reporting issues to the community is version. So it fetches a whole bunch of different typical configuration information for the system, like when the image was built, which version of Uboot you have installed, which version of the kernel that you're running. And then there's this interesting thing with overlays. So even though, I forget how deep to go into overlays, but so all the hardware is defined through Linux using this thing called DeviceTree. So it gives Linux an idea of what the hardware system looks like, what things are connected up to it. There's other ways to do that, but DeviceTree is the primary way that we do that. So there's a DeviceTree definition for Pocket Beagle. In fact, under UpStores, we're running the 4.9 kernel. What am I typing wrong? That's the beginning. That would break it. 335X Pocket Beagle. This is, that's the name of the DeviceTree store. So when everything boots up, so Uboot is the first thing to run and it goes and reads a DeviceTree file out of a slash boot. And the output of this source file is what it reads. And then it reads the kernel. So the boot loader, Uboot, reads both this DeviceTree and the kernel and it provides that DeviceTree to the kernel to tell the kernel what the hardware looks like. So if we wanted to dynamically change the, if we want to change the hardware from what it is by default, just the base board, then editing this DeviceTree is one approach that we could take. So you see here in the file, there's everything, well, there's an include file here in this one, but we see things like the spy, we have connected up to this. This is how spy dev is loaded. So it enables these spy dev channels to create the user space interface to spy. There's all these, those pinmuxes, those drivers for the pinmux controls, that's where all these drivers are loaded and they're configured. So everything gets set up through DeviceTree. So it's really, it's useful to kind of, over time you're gonna have to learn how to edit DeviceTrees. Just work in place, you're going to have to. If only there was a doc. So the, there's a number of other useful sources here, but this is a nice way to actually run and edit the live ones. I could actually edit this and make, and make in sudo make install, and it would overwrite my, I'm gonna just invoke this for, because I'm brave. So, and I didn't know it's all good source. So the, this will actually build all the DeviceTrees for all the different types of boards that this image can run with, plus the mothers that it can't. And it'll put it into the appropriate location in the boot folder so that the boot loader can get to it. Hey there, both the, probably be gone. A lot of the hardware, you know, we don't want to try to edit the main file every time. So Uboot actually has the ability to edit the DeviceTree live as it boots. So there's actually a way that you can get Uboot to make edits to it, so I've got additional files. You'll see this other repo called db.org overlays, and those are DeviceTree overlays for the Beagles, for all the BeagleBoard.org boards, PB, and there's a number of these different ones for Pocket Beagle. So if you see the PB at the beginning, not necessarily, all of them are gonna have PB at the beginning, but a lot of them do. You'll see that there are these overlays files for these different out-on-boards. So these are the clicks I keep talking about. So they look like this. So if I wanted to say add Ethernet to my Pocket Beagle, I could use the Ethernet click because I've got an overlay for it, and I connected to either, it can connect, it needs SPI. So I've got an overlay for SPI one, and I've got an overlay for SPI zero. So depending on which way I place it, I need to pick that correct overlay. And there's this file, a full of environment variables that U-boot reads on boot up. So in this case, I've added one overlay to enable the peer U, which is those microcontrollers. They're not enabled by default, so I've added that in the overlay. But you'll see a number of these places where you have U-boot overlay address. Those are defined more for the BeagleBoard Black, but you can, on Pocket Beagle, you can put them right into here, so you can just replace this file. Remove the hash at the beginning that's for comment, and put it in here in a file that you want to load. So we saw the name of the file was, let's see, well, copy that. I could remove that, I'll paste that here. And now on boot, it would actually, it would change the description of the hardware. U-boot would actually take that extra little chunk of device tree information and put it in there, so it now see, Linux would see that that was in the system after it booted, so that would just boot up, and I would have ethernet on my Pocket Beagle now, and there's a whole bunch of other ones that you can add. Yes, yeah, there's a great talk that was done at the last ELC, well, this is an ELC, but that embedded Linux conference on U-boot overlays. I don't know that I have anything that we can really dive you into quickly, but we can look, what you can do is look at a file, I think maybe that's a slash boot slash uenv.txt. So let's look at one of those files to get an idea of what it looks like. So you kind of have to know a little bit of, see a little bit of device tree to begin with, but there's, at the beginning, you'll see this extra slash plugin that's telling you that it's meant to overlay an existing device tree, and then you'll see these fragments and this overlay specification, right? So first of all, you have to understand what a device tree is. You understand what a device tree is. So let's focus on what a device tree is and what that looks like, and then go from there to overlays. And again, pull up one, I don't think it's common. So it's a textual description. So this actually gets run through a compiler and put into a binary form that is essentially just a bunch of, it's just to produce a structured data set. So that structured data defines the peripherals that are gonna be instantiated by the kernel. So we say we have things like we have memory, right? So we have memory and it lives between these addresses physically on the computer. So Linux discovers that it has memory through this mechanism. So it says I've got 512 megabytes of memory. And every peripheral, everything in the system is done out like this. So I have an I squared C controller, right? Not even the device is talking about, I have an I squared C controller. You'd see, well that's the pinmuxes before I get even to the, right? So I have an I squared C controller and I specify what's clock frequency. This is actually referencing elsewhere. But everything in the system is described to the kernel through this set of data. So you specify what it is and then you provide the different parameters underneath it. So like the others, here's an I squared C device. There's the E problem that's living within the SIP. So there's a 4K nonvolatile memory inside the SIP on an I squared C bus. So within I squared C I would say that this compatible line, this tells Linux which driver to load. So it's going to pull out and run that driver and then it's going to use all these different parameters. Here the register says that it's an I squared C offset 50. And then it's providing additional base information. So it's actually defining that the data that lives in this address range is called baseboard data. And what the details are, let me show you something on the web. What the details are for that. I only want to have one browser. www.kernel.org. In the kernel documentation there's a device tree and binding. So all the different types of things that you can instantiate like the eProm will give you a description of how you would specify that in the device tree file. So what on earth am I supposed to put into this? Well you look up the documentation for the device tree for that driver. If you don't have to read the driver itself, hopefully somebody provides you with decent documentation. That's really small print. But the important thing is it shows you what the different compatible lines are that you need to provide and what are the different parameters that you need to provide to that driver. So that's all in the kernel documentation folder. Under documentation, device tree, and then binding. So that's it. Sort of a base build to what a device tree is. Very much not pocket beagle specific. So I didn't really plan to cover it a lot. So I wanted to try to get you the different pocket beagle specifics. But we've done some things here to try to make editing device trees and using device trees on pocket beagle easier. We included the source for these overlays. So an overlay is something that patches a device tree. So let's use one I wrote because I might understand it a little bit better. So for instance, we installed all those pinmux helpers and stuff. So in the case of, I'm adding something on, the pinmux helper actually gets in the way of me taking over that pen. So what I can actually do with an overlay is I create a fragment, I target it at this OCP, the on-ship peripheral of the processor, where these devices have been instantiated in the existing device tree. And I said I created an overlay and for each of these items, I overwrite their status with disabled. So now when the kernel boots, it actually won't load these pinmux drivers by doing this. So I patched the device tree before the kernel even boots because this happens in the boot loader and you boot. There's also a way to modify while it's running live, but maybe I shouldn't move quite that fast. Anyway, so I disabled those, all those different peripherals. And then I also disabled the user space spy driver because I want to load a particular SPI driver, in this case the Solomon SSD 1306, which is an LCD controller driver. And I say what pins I want to load. So the important part here, though, is that I'm able to modify the tree before it gets loaded in the boot loader. So I have the big tree that describes all my hardware, but now I've got something I've done different because I've added this other board on. I want to change that overall description to better represent my hardware so I have to make an overlay for it. And the syntax is largely the same except we're targeting certain, we can either target the root to add stuff wholly new or if I'm targeting a certain subsystem, I'm putting it under SPI. I need to do that to point to that data structure that I'm going to modify. Absolutely. Well, it happens. It depends on where it reaches that point when it's kernel boot up or where it loads that driver. So it could potentially happen very quickly. I've seen cases where people can make the kernel load in tens of milliseconds. That's like 100 milliseconds. Let's say 100 milliseconds. But that's very, very, very, very specialized. Typically, you're going to be in order of half a second or so. A few seconds. It's not going to be milliseconds. Typically, it's going to be seconds, typically. The boot loader is really where you want to put it if you need it really quickly. Modify the Uboot source. You can set PinMux settings there and GPIO settings there. That's a good question. He's got an example folder on bb.org overlays where the previous, the bacon cape overlay, not the bacon bits, but the old bacon cape overlay was given as one of his examples. Actually, these things are more of examples of how you can make the board come to think of it. I would look at the bacon cape overlay. This is what the bacon one looks like. It's done for Beaglebone Black, so not for Pocket Beagle. There will be some changes relative to what it's actually patching, because it's not patching the Beaglebone Black-based device tree. It's patching the Pocket Beagle-based device tree. Not yet. I wrote one for the accelerometer, and I think I know what the bug is, because they change accelerometers between Rev-1 and Rev-0 and Rev-1. What was the other question? Be, do you really need a device tree class? My foundation literally views it on these kinds of conferences. They always show you 50 minutes of one section image over how something should be done still in the device tree. The second thing is documentation is supposed to have actually done the work. However, there's one thing I will tell you, and that is that the Beagle-Borg support what they do is they are often called some part of the system that is what covers their image. in the future, maybe next year or a day or two. The other thing is that tomorrow we are doing a part of this. Oh yeah, you're not on the mic. But I think it covers this time around. Certainly you will find that a number of the people that are speaking for you during this seminar are in fact trainers in it. What's my time check? Okay. Good deal. Good. All right. So I'm going to try to give you a little bit more example on device. This is a rich enough topic. It's worked a little bit more time. I do have an example that didn't work. I mentioned when I got the Rev-1 board that worked on the Rev-0. So I'm going to try to patch it because Michael told me that what happened was they swapped the device from an, let me show you what the device tree looks like. From the 8th, the free scale MMA, oh that red is really hard to read, 8452 to the 8453. This code is checked in to the code GitHub repo, but I'm just making some changes to what's inside there. So you will have this example as part of the EL code. And so what I've done here is I've targeted the I2C2. I wish I could tell you about this magic. This is magic foo that I copy repeatedly, and it screams if I don't. I have almost no understanding, a very vague idea of what that is actually doing. The parameters, you know what? I know the answer to that. Yes, yes, okay. So maybe I'll just scan next to you so my voice gets picked up. So address cells and slide cells, is that what we're talking about? Yes. I'm sorry, I was only barely paying attention. So address cells and slide cells have to do with how things are understood in subsequent child nodes. This is a child node here. And you'll see that there's a number of things in an array. Arrays have angle brackets like this. And inside you have a number of values. Those values are all 32-bit numbers by default. And they always come in essentially groupings of address and then the number of cells or entries in the array that are addressed, the number that are values that are then data, are specified by those two pieces of metadata. So the address cells in this case tells us that we have one cell or one entry in the array that is addressed and zero data. So what this means in this case for this particular device is the register value, that's what register stands for because we all like to shorten things down to the least amount of piping, is that this is the one C version of the address for this particular thing is one C. If it was a CPU, typically we go zero, one, two, three, four, the address just indicates the actual thing. If it is a memory maps device, you will find also that the address typically is the address of the thing that you're dealing with. The size tells you the size of the data because it's a register range, what that happens to be. The other thing I will point out briefly, and it is a rule but it is not always enforced, although newer versions of the tools are supposed to enforce it, is the first address is also used as a unit address in the actual node name. So you'll see that we have a name and then we have and then a number that looks specifically like the register address. They're both one C. The contrast is a bit hard to see with red on black. You'll also often see a label printed out ahead of this. So if you want to reference these things later on with overlays, you don't have to have a label but it makes it a whole lot easier because that's what's being specified here with this Ambersand target. If somewhere over there there was a label around the node, so you can add labels to the nodes. Often the node names and the node labels are the same but that's not at all required. They live in a different namespace, right? So the label namespace is global whereas the node name is local, right? So that's yes. Yes, the Ambersand is referencing a label. Where is the file at? What file? It's under... So on the GitHub, EL, and code, if you go into resources, Pocket Beagle, I'm going to check in a newer version after this but you'll see this. This is a broken one that I was in the process of trying to figure out. Anyway, that's the file I'm editing. I've already changed it from that. We're going to try this live here. I'm going to see if this works. So I've got another little shell script in here that's going to... We talked about how to do it in Uboot, right? You specify Uboot underscore overlay. You define one of those variables and the Uboot will... The scripts that run in Uboot will book that and load those overlays and patch the device tree live. Well, the kernel also has a live patching mechanism that's exposed through config.fs. So if you go to the directory syskernel, config, device tree overlays, you can actually create your own overlays and modify the device tree while the kernel is running live. So the process that you follow is to make a directory. When you make a directory, some files will show up underneath it magically because it's not a real file, right? It's just an interface to the kernel. And what I'm doing in this script is I'm actually compiling that device tree source and I just write to it directly. So this is the DTC as the device tree compiler and I write the output into this DTBO file or the overlay file that just directly writes it to the kernel. So I feed the source into the compiler into the kernel. Yeah, it's 4.... I don't remember where it went. I think we had to backport the patch into 4.... This is running 4.9. I think it was like 4.11 or so that they introduced the overlay capability that Pentelus introduced it. That is absolutely magic. So, yes. So you can create the overlays and load them in real time. I wasn't expecting this to work. I'm super excited. So usually the demo I just goes the other direction. So this is actually reading accelerometer values and I can see now they're limited in the number of bits relative to the other device. So there's the top axis is the X axis. So if I tilt it to the left, we can see it goes negative. If I tilt it to the right, you see it goes positive to 1G value. And then the Z, if it's laying flat, you see it's kind of maximum. That's the third value. It's maximum out at Z. It's sitting around 1G. If I move it up and down, you can see it changes. It's sitting around 1G. If I flip it over, it should be about negative that value. And the same with Y. So Y is this direction and then upside down is that way. So we're able to follow those patterns of the changing numbers. It's a little bit difficult to follow everything going on at once. But it's reading the accelerometer now. So it's loaded the Linux driver for the accelerometer that's on the board. And then it automatically creates these. So the driver exposes the values, the accelerometer values as virtual files. Let me cancel out of this. In the kernel. Yes, there's a C kernel driver that knows how to read and write that accelerometer already. You'll learn how to do that in the next couple of days. So yes, that driver is already written. And most of the time, most of the time when you want to add stuff, it's already somewhere there. You just have to figure out how to get it loaded. Because the kernel is just chock full of interfaces for all the sorts of stuff. This is a different accelerometer that was on the previous revision. I changed the version number and boom, it came up. It just depends on how you compile the kernel. In our case, they're mostly modules. So if you want to find out what modules are loaded, you can do ls-mod. And you can see that module was dynamically loaded. It's not pre-built into the kernel here. It was loaded. What Bein was saying was that there's a future tool forcing that app to be something particularly tied to it so that it's useful. Yeah, but that's news to me. As far as I know, it's arbitrary. The ad does have some meaning for indexing. Because you can essentially have multiple indexes of the same thing. So the ad is meaningful, but what the actual number is, I don't think it's meaningful. It's that reg value that's really meaningful. So in that script, I remember I looked earlier at the SysBus IEO devices, and there was only one of them. So when we loaded this I2C accelerometer driver, it created this other interface. And you can see all the different types of things that it has in terms of data that it's providing from the accelerometer, including things like Excel, raw, X values. And I just added that, again, that same trick with the watch in order to print all those values out in here. So I don't have to keep typing it in over and over and over again to read those values. I can just get them to display on the screen. So the terminal buffer, I'm absolutely posting the script. Hopefully you can... I'll make sure to post the script. Let me show this on here. So here's the shell script. That's too hard to read. So the overlay is in this MagicConfigFS directory, right? SysColonelConfigDeviceTreeOverlay. To make the accelerometer directory, that's just to say that I want to provide you with a new overlay. So I do that make directory. And then here I'm writing it into that DTBO file. So when I create the accelerometer directory, it creates a DTBO. Let me show you one more part of that because kernel debug config device tree, it's not on the pocket. These code examples are not on the pocket beagle. I'll put them in for future builds, but they're not there right now. So when I created that Excel directory, it created these other files. So DTBO pass status automatically. So if we cat status right now, we'll see that it actually says that the device tree overlay has been applied. So before I output that device tree overlay into this file, its status would have been, I don't remember how it says its status is before, but it wouldn't be applied. And the device tree source, so here I point to this i2cexcel.dts file. That's in this repo as well. But I've made a change to it. The big change being this model number here changed. I also just removed the interrupts. So we're just pulling the accelerometer at this point. There is hardware, you can configure hardware for doing the interrupts. I never actually finished figuring out all the stuff I need, all the magic food I need to put in here to specify the interrupts. I'm just using it by pulling. So I changed that from a 2 to a 3, and then removed those two, and I'll check that in shortly. Yeah, I wish I had a nice way to wrap this up, but this live kernel interface is very much the same way to kind of do what's done with files that are specified here. So we're taking these overlays, and here we're telling the bootloader about booting. The other way, we're just telling the kernel to hack them in while it's running. So if I specified that file here in the overlays, then every time I boot it up, that accelerometer interface will be loaded. I'm going to make sure I cover everything. I've got some details in the slides about the bootloader. This to me is useful information to try to understand a little bit more. There are some pointers here also to the patches for the bootloader that we applied outside of Mainline to try to handle. Currently, our application of overlays in Uboot isn't part of Mainline Uboot. That's a Beagle. The way that we're applying these overlay patches in Uboot, so the Mainline Uboot has the ability to apply patches, but the fact that we use these environment variables to specify the files and apply those overlay patches, we specifically patch that into Uboot. So if you run a Mainline Uboot, you would have to take some other steps to try to tell it to apply the overlay in Uboot rather than just specifying that environment variable. Make sense? All right. Other things I want to make sure the device tree configs in. There's another really handy tool called shellpin. So if you under script device, there's a purl script that I think is really handy. It's really designed for Beagle on black, but it's still really useful because it just gives you the summary of all the pins and what their current mode is, including what driver is currently controlling the pinmux. So under op-script device bone, shellpin.pl, shell-pin.pl. It's largely the same information that you can get from config pin. The nice thing is it just outputs in a table and kind of scans across all the pins that would normally be on the Beagle on black headers. You can get a more complete set by adding dash V, but this parses some debug files that are provided by the kernel to specify what the current pinmux mode is. I'm going to tell you the RX. So each of the pinmux controllers, if you see RX, that means the receiver is enabled. It's kind of weird. You can disable receiving on any of the IO pins, on any of the digital IO pins. That's a flag. The other things you can do are you can change the slew rate. So the fast, you'll see fast or slow. I think everything's set to fast slew rate, so it'll change the drive strength. If you have any noise issues on a board, you want to lower the drive strength because you just don't need the transitions to be so quick. You could actually change it to a slow slew rate. That may be something useful for GPIOs on the board. Up or down tells you whether or not a pull up or a pull down is enabled on the pin. So the internal pull up or pull down within the chip itself. The number there tells you the MUX mode. So each of the different pinmuxes can be either between 0, 1, 2, 3, 4, 5, 6, or 7. To say which mode is being selected on that pin, whether you're routing out the PRU signal or the GPIO signal or the SPI signal on that pin. And then you've got a description of what the active mode is. So if it's in PRU mode, if it's a SPI mode, that's all baked into that showpin script. It's been used quite a bit. The big thing for it right now is it's for Beagle and Black. So if you look at the descriptions of the pins on the far left, they're not going to reflect. It's not. There's an opportunity for mail error there, but it's extracting the data that it's reading live from the kernel. The parameter values, but it's just doing table lookups to the specifics. Which one? You have to do purl in front of it. Yeah, it doesn't have the... Somebody needs to chmod it. So the last thing I think I want to try to expose you guys to is the PRU. So those extra little microcontrollers really messed up my view here. Where can I grab it? I'm trying to place the grab to expand this. I don't think I'm cutting off anything too important. Because I know what you said, it's cutting off stuff on the left. Can't grow this for some reason. So there's... Under examples, examples, extras, PRU. I've put a couple of examples there for you. But I've got a modified version. We can run that version first. So examples, extras, PRU. Feel free to go ahead with PRU. So you'll see this HelloPRU.PRUC. And it may not come up syntax highlighted for you by default. In other words, in the lower right, you can select the syntax highlighting mode. So the syntax is at C. But I've given it a weird name because I talked earlier about the IDE having this ability to have these runners that can go off and execute scripts. What do you say you want to run a particular project? So I used a different file extension here to tell it how to go and run a PRU C program. So this puts a single C program, compiles it and runs it on one of those target CPUs. Just remembering one thing for you guys, though, that it won't run for you by default because of the overlay stuff. So I'm going to go ahead because of the overlay stuff. I've got a script. I'm sorry, I've got a command. If you're in this readme, if you look at this readme, there's something you can cut and paste which is this magic set line right here. If everybody can get to this website or not. But in the PRU examples, there's a long set line. All this is doing is editing that slash boot slash uenv.txt file to load a particular overlay because I want to load the overlay to enable the PRU. This is the EL code repo. The path is resources pocket beagle and then you just scroll down. The readme renders on the page. Once you run that set line, you need to reboot and that will enable the PRU for you. And if you understand said, you can just do what it says. You can make it easy to cut and paste. I kind of go through the different examples that I'm going to throw here on the readme anyway. From that, you can just click in this IDE once you get the file up. You can actually just click run. You have to expand this. T-E-M-P-P-W-D Good question. Brilliant. Good idea. T-E-M-P-P-W-D So it's now running and so what that is doing is actually this user 3 LED is now being toggled by the PRU. So it's a separate processor that's actually going through the on-chip peripheral bus and toggling the GPIO for that pen. It's a remote proc. It's the new one. So I'm trying to give everybody a sample C template that you can follow. I've got a bunch of crazy if-deft in here, but this code is actually pretty simple. The main routine, if you want to get to the on-chip peripheral you need to set this bit, this control bit. So just copy that line anytime you need to get to the on-chip peripheral any application if you want to go outside of the PRU subsystem with your accesses. That, otherwise, it sandboxes it, the PRU, the hardware sandboxes them and then I've got a silly for loop. This could just be a wild one. And I'm doing GPIO set so that is a memory mapped register defined up here. So the hardware for the GPIOs is controlled with set and clear registers. The advantage of that is you can do apply masks. You can update up to 32 GPIOs at a time using masks. Or you can select only certain ones to be updated. So instead of having to do a read, modify, write, you just write to either the set or clear and use a 1 for the bits that you want to change or a 0 for bits that you don't want to change. So if you want to clear it, you set the register bit to 1 and clear and that's how you clear it. Does that make sense? You write a 1 to set a 0? Maybe a little confusing. But the code here, that's what it's doing. It's writing those memory mapped registers. It's on the disk. It's examples, extras, PRU. Examples, extras, PRU, hello, PRU. And the other files that are kind of making this magic work are in the directory that are just kind of more also just boilerplate. This line is disabled right now, but if you wanted to, there's the GPIOs that are part of the PRU rather than the on-chip peripheral GPIOs. I'll try to repeat this a few times in different ways to make it make sense. So the PRU itself has GPIO pin or GPIO outputs that the pinmux can select to put them in PRU mode and then the PRU is in charge of those pins. Or you can have the pins go to the GPIO which is the on-chip peripheral GPIOs. So these registers are changing that whole chip GPIOs. So the same things that you'd be changing from the arm. If you want to change the GPIOs for the PRU itself, ones that are under its control, you just use the R31 registers. R31 is for reading, R30 is for writing. They're directly mapped to processor registers. So even though this is a line of C, this is an intrinsic that specifies the actual register within the processor. So you can actually create zero overhead loops that's going to create 100 megahertz waveform output if you wanted. Because you can just do an X or of a bit and do it in an infinite loop. And so people use this to create all sorts of cool things like like BeagleLogic where he's grabbing the values of 16 data lines and shoving them off into shared memory for analysis by SIGROC. It's a familiar SIGROC. So you can actually you can turn your pocket Beagle into a logic analyzer if you want. So with the GUI and everything. So I've got an additional modified version but this should hopefully get you the idea that you can write your own C code to run on those processors. There's a linker command file in here and a makefile. So this makefile is what does the compilation. It's just when you click the run button it runs that makefile. What was the question? It won't work. The way it's done right now is that you have to specify two environment variables. So I'll run it from the command line now because I've got another version in the EL example that actually comprehends the bacon cape bacon bits cape. It's toggling the blue LED closest to the USB. Not the one inside. The one inside is doing a heartbeat pattern but if you see it it should be toggling the one closest to the USB connector. If not, it's not running. This it says it loaded in RAM. So I've got another script that says run RGB pure U. So it does that one other step which is making sure that the the muxes are set properly. Of course for the LED it's not really using the muxes because it's just using the it's already muxed for GPIO. But for a couple of these a couple of the RGB LED pins are actually connected to pins that can be pure U output. And so I've got a modified version of the code that also sets those pure U outputs. And it's going to go through and just run it. But here's the thing about the make file is that you have to specify target which is the program you want to build. And then pure U in and specify the pure U number. If it's pure U 0 or 1 on. So instead of you can't just run make from the command line you need to have those variables set. So if it's muxed to the pure U you can toggle it at you know it's a 5 second latency from the command right. So you can you can literally sit there and make 100 MHz waveform. If you were to do a tightest possible loop on the pure U that toggled the GPIOs it would probably be an 8th or a 10th of that. Yeah. Yeah. There's going to be some jitter when you go outside because it's got to get it still has to get clock synchronized. So there will be a little bit of jitter and there's also other bus activity when you go to the on-chip peripheral. It's going into shared buses that could you know could take you know a gigahertz cycle or so of you know priority over the pure U accessing it. So yeah it's definitely you know 100 you know 100 nanoseconds is good enough which is pretty good. If you can live with 100 nanoseconds you can go off. So this should be okay. So I'm doing the decay thing where I'm like I go through each of the different LEDs the different colors and just flash them faster and faster. So I do red, you know red, green, blue and then white. So that example is part is there as a script running from the command line in the example provided on the Github. What was the rest of your question? The biggest thing is to make sure that the rest of the you need to make sure to disable when you're able to keep up with all the peripherals from the pure U. If you wanted to use the PWMs or the you know the SPI or the accuracy or any of those peripherals from the pure U they're very practical to use. Now just make sure you disable access from the Linux so that they're not stomping on each other trying to write your registers. The peripherals are pretty well isolated. I mean if you start changing clocks and the system clocks or other things like that that's going to have some real impact on the SPI-1 controller. I mean that's largely independent. You have to kind of look at the individual peripheral in some respects like if you end up using a channel of a PWM that's obviously going to conflict because even though there's multiple channels they're still controlled by the same overall clock management and stuff that's going on for that pure U that whole pure U I mean the PWM peripheral. So you mostly just need to apply some common sense. Is there a question back here? So at the OCP the L3 I don't believe is fully cross-barred. I think it's going to be just block. There's cross-bars for memory but not for the on-chip peripheral. They have their own their own target RAM. They have a shared memory area between them but they can't access the DDR so they can just like they can access all the on-chip peripherals they can access the DDR and so what's really usually to communicate with them you'll just memory map the memory space of the pure U from the ARM because the ARM can see the memory spaces of each of the pure U's including their shared memory and you would just kind of dedicate a region to write messages from the ARM and you would just map that with the DevMIM and I want to try to provide a simple example for that there's also in the kernel there's a provision for messaging called RPMessage that's very dependent on what you're trying to as far as you know cache coherency between the two CPUs if you're going off-chip usually I would just say message on-chip don't try to go through the caches I don't know what the exact cache coherency issues would be going off-chip but for like large bulk memory sharing it should work fine just synchronize off you know elsewhere I would synchronize in the internal memory the code so the EL code the code is going to be on the USB 6 tomorrow tomorrow where the slides and the code are all going to be on the USB 6? No sometime before the end of the week so if you keep coming to these classes you'll eventually get the sticks I'm on my rep-up slide so you'll get the USB sticks that'll have the code on it including I'm going to commit these changes today so the changes that we made here live will be on the sticks and they're all on the GitHub so github.com and I'm going to update you to read me as well with instructions that are completely up to date for running all the different examples just a couple quick plugs hopefully you guys are going to learn so much this week you're going to be amazing contributors and you want to contribute some things back to Beagleboard these are kind of those critical projects like alert overlays this is where all those click boards need support they need love, they need overlays image builder is how we put together the whole Debian image if you need to make any changes you want other packages included you want to trim some stuff up this is the place and lastly all those live examples that you see on the left hand side those all live in bone 101 that's the report the update and contribute changes and share your beautiful knowledge we've already used our time for questions so thank you we're going to talk about kernel modules and tables in kernel and if you're doing that on the board itself the usb teams are going to come eventually please don't leave we're here till Saturday evening please don't leave with ever coming to find one of us to get the usb team all I can promise is that we will have them ready before the end of Saturday part of the problem is because we're going to call not be trying to finish this there were a lot of very last minute issues that just worked around so I apologize for that but we do have UCP for everybody if not all of the information will be on the website it will be on the internet certainly if you want to know for sure what's going on we will also be emailing everybody on the mailing list it's on the email website let's do find out for the you'll really tell you what's going on on that mailing list so as long as you put your name in there somewhere we will get the information to you and like I said the file will be on the website as well if you don't get the usb team otherwise great for an hour see you back here talking kernel modules thanks again oh my god you went into the weeds so everybody loved it so it definitely shows where we got to go the device tree was really high on my list but it's a frustrating thing we didn't cover it the device tree is often covered in these things with i4c, fpi and usb stuff specifically it's never covered so that's why it's really good for that but honestly the peak of both is still the best as far as everybody's fighting because Kanto basically still has everything on that's awesome over in the corner over there it's definitely useful to understand what's going on well first you're doing a device tree so I think probably somebody else is a little better I would love to but I'm actually going to skip lunch so I'm almost done it's my last lunch okay I don't think we're going to guess this year but what's on the tree is there a chance some of the snippets of this could be the video is already online if you can't read the screen you're probably not going to be able to see it from the you will be able to actually read it from the video and the reason is we do picture and picture so we have to capture this we've captured that we're actually capturing that so it's beautiful we're just supposed to read whether or not this button is being pressed or not we're supposed to but not the other two the other two buttons will close it to reboot did you change it from p3 to p33 p2 33 it just says 1 it probably just keeps printing out the number 1 just make sure to get the right LED that's the trick the red button all the changes are live in the code right?