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 jump people onto the hardware, but I actually want you to try to pay attention to me. Crazy thought. Because the hardware is far more interesting than I am, and I'll completely lose you. The prerequisites included Linux, like the top of 100 gigabytes, like all this stuff in the brand. And other than that, you just talk 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 more interesting than I am, so I'll try to bore you to... I was supposed to push this latest version of Akin-Kreidner, a Skunkworks thing. At this point, yeah, I just spent 90 states to allow me to just focus on it completely. Benefit for TI is obviously people's focus, and all the kids and everything, so they're all public. The basic structure, other big, picked up these boards, brand new, closer to the development of myself, exercising the bacon that takes 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 Eagles for a week. Just get a lot of people to 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 good Linux before? Good, has a top Linux, makes money, foundation. So you make it, you want to call that. And where a lot of our community sits around is industrial automation type of task. Some 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 sledgehammer 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 miss work by using that computer. So, want to get inspiration. And for me, I got into, I couldn't use the computer without typing in programs.  So I wanted to play a casino game and I had that sort of osmosis here, typing these things in. Oh, I 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, what's reproduced for other people of any age, but in this, so much to learn now, right? You know, they don't use computers anymore, 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. But 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 like a line of, a 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. 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 on all the crazy fun things that make up an operating system and really make up modern computing. 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. 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 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 and useful as well. 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, they're doing things on just their desktop computers, right? They see very, very rich experiences that are very, very hard to reproduce. It's 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 in LED, or maybe turning a motor, starting to get some things, interactions of the physical role to kind of be that drug that hooks people on to computing, so they want to understand more. Sort of vision is to try to get things as simple to play with electronics as creating a web page. It's a company, 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 a Beagle, for us it's 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 all the things that it's also supposed to do for a phone, whereas if we make it an embedded appliance, we can really dedicate it to the task that we want it 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 of that with open source as the catalyst. 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 come 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? No, they're complaining about a buzz. 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 lowercase. 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 and 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 to Debian, right? So we've got a huge community of people helping to advance the state of the 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, 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 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 at collaborating is when it goes into the kernel. And 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 serves to get really the main specific pretty quick. So some people are really happy with Command Line SSH for doing development. I happen to like the Cloud 9 IDE. It gets me into the browser where I can actually run VI in my web browser. But there's Node Red, there's Pure Data, SuperCloud, 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, the domain-specific approaches, so we find a lot of people in our community are going and they have other distros or other things focused 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 CAPES, Mini CAPES. 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, you know, from kind of just like solving the problem as a whole, trying to give one a single point solution. But we don't wanna try to go and solve all of those problems ourselves either. What we wanna do is try to engage developers that's in 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 pass 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, you know, hundreds of different add-on things that you can censor and control 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 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 of table systems to put the bulk of it into a system and package, and we were launched a Beagle bone black wireless at $69, and fortunately 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, it's got 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 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, so it's all the sides of an outwits mint tin and maintaining that 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 we 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 that 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, what were our objectives 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, right? So you need some way to feed it data. It has a lot of, you need to kind of bootstrap the, the, there's pins that set what the boot mode is, to be able 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 a boot and that's all you need. It's got the RAM integrated, it's got the power management integrated 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. So 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 it's, you know, 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 could 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 pinout 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. Because 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, we wanna make sure these are available for everybody.  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. 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 Corechecks 8, 8 processor, so it's ARM V7, still 32 bit processor. But it runs at a gigahertz, it's dual issues, super scalar. It's reasonably quick. It's not gonna blaze new trails, but it is 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 micro-controllers in it. The two 32 bit peer use are really, really powerful and flexible, they give you single cycle access IOPEN, 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 Corechecks 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 512 megabytes of RAM, it's got USB and a whole boatload of stuff and 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-SEE, 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.  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. If it's meant to be a GPIO pin by default, there's the GPIO, the eternal 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 volts 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 building on the same pen 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 to 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 quadrature encoder two is available. There's the A, where's the B for, here's the B for quadrature encoder two. You can do hardware pulse counting. If you want feedback for motor position, there's the PRU pin that has the ultra latency. The PRU 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 like 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 avoid bringing those out.  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 standard to announce. There's over 300 different boards that match this configuration. And the way we did the headers is it mapped out to 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'll 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's set on the Beacon Black that Dave Andrews 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 Andrews 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 your zero, right at boot. It has a USB host port on it using the USB on there because we don't have that host port built in to the pocket vehicle itself because we reserve it for expansion. It satisfies it by bringing a USB host port. It remaps, so 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 interactions with 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. But I'm gonna kinda 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 happen 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 configPIN to give me some basic information about that PIN. 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 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, have you ever heard of SysFS used to SysFS?  So SysFS is a virtual file system. There's nothing sitting on my disk itself. It's not on the microSD card. It's just something in RAM. So I'm only talking to the kernel by talking anything to 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 locations. 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 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, dev. So devmcblock0 partition one is my root file system, right? That's the disk that I'm actually running as my root file system. And it's mounting other types of things on that. I've got a SysFS entry that's handled by the kernel mounted at 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, a Sys class 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 that 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 that 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, right? So it's shorting the connection between the IO pin and ground when I'm pressing this button, right? 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're at a GPIO.  But that's pretty significant, right? And Linux makes that really easy by turning everything into a file. The hard part, right, for us was just mapping the numbers, right, figuring out what the IO pin maps to actually into the software. So GPO 45 into 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 wanna do one other trick because this is gonna help me on this next time. I wanna 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 gonna 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 gonna keep running that read the cat. Cat is the program that's just reading the file. And so you have your 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 gonna be changing it constantly. Now this one I'm just gonna kind of jump, there's, where that happens to live is in the subsystem called IIO. That's the, it's literally 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 gonna come up for you in IO. It's a really interesting subsystem to learn more about. So I'm gonna look at what devices are in IO, and I'm looked at, I only have one. That's my only, 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 pin might tell me that actually. I don't know if config pin will tell me that. P1, was it P119? Oh it does, it tells me it's AIM-0. So config pin would have told me this anyway, but I actually put that one on the slide. So that's zero. So the one I wanna look at is in voltage zero raw. Now I think it's a bit of a misnomer, because it's actually just, right now what the driver's doing is actually giving it the 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, obviously I don't wanna sit here and turn that. So I wanna just do watch, run that watch command. I don't have to keep typing every time I wanna see the value change. So now I can turn the scroll wheel. So I'm gonna turn all the way to one way, 4095. Turn the wheel all the way the other way. We'll watch it changing as it's going. And it goes down to zero, 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 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 or just reading a file. There's an existing driver handling it. 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 if we wouldn't allow this, we'll 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 gonna 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 gonna 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 gonna 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 gonna 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 how to use that. So Node is the interpreter that I'm gonna run. And PWMJS is the program, so it's this program. That program is going to set each of the different pins to be analog outputs, which is just terminology for a PWM. And then this analog writes function. This analog writes 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 gonna be. Now the first time I run it, I think it should fail. Cause there's a, what has to happen is when we have to enable the PWM, initially it's 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 Udev?  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.  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 kind of makes sense? Okay, in the labs, we can kind of dive a little bit deeper into it. Actually, I'm over my time from beginning of 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, that 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 writing, actually writing code, yes. Why is there PWM red and PWM red alt? The, we had some debate in making the board whether or not we could just use those microcontrollers to control one of the, 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 we, anyway, we did it without being clicked board support because we, 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, pin one. That pin 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 pin. 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 MOTI 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 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 chips like 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 and you're starting a new command. So I've got some more examples in here. 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 commands 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 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 what config 10 is actually doing underneath the scenes a little bit. If you, well, you could 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, 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 is 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. 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 save that all for the lab. 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, it's great. No, that's not good. No, no, it's the opposite. Oh, you're right, okay. I just 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. Yeah. Basically, it's a drill pin, drill pin, right? What's the meaning of that? It's offering you some pre-downloaded files. 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, install it natively. Okay. And I'm not gonna have you install any stuff. I think for the other classes, they will. Okay, thank you. Everything I'm doing is on the board, as well. Do you have anything built in to debounce it? Anything built in to debounce it. Like, if it's a different momentary choice, what's it going to be done? 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. It's really, I do a lot of just GPO keys with zero debounce and with just regular buttons, 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? 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. Yes, I know. Did you register? Pre-registered? Yeah. Okay, you then, the guy you want to clean. He's on his knees, or he's bent down in the back. Everybody who paid for the kit, yes, though, anybody? Anybody not have their kit, who paid for it? Okay, we got one person back there. We have 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, on the beagle for this, we won't be using the second USB cable or the USB connection on the bacon bit, so 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 wanna 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 wanna 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, which you can get at 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.  We're gonna walk through some of ops scripts and then there's 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 that USB cable is gonna power to provide a 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 when you don't have to do it today because the SD card's a pre-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. And it takes the compressed images and it writes those to the SD card itself. And then once you've got that SD card programmed, this is where we're actually gonna actually start doing the steps together, right? 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 because 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 corrupt files. I always just pull the power. It's an EXT4 file system. It's pretty robust. I almost never have any, oh, 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 because 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 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 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 <IP_ADDRESS> for our computer and 6.2 for the pocket Beagle. And the pocket Beagle will give your computer that <IP_ADDRESS> address. And it'll keep for itself <IP_ADDRESS>. So when you connected to 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 probably could take a minute or so to boot up, if it's taking more than a minute if 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 <IP_ADDRESS>. 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 <IP_ADDRESS>? 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 <IP_ADDRESS> and <IP_ADDRESS>. 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. The magic number is in the readme. So if you haven't heard it, the <IP_ADDRESS> 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 hosts, this gives them a way to get in real easy. Who would not have network connections? I'm sorry. So it's running devian. Did the network device chill out? 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, there's a little secret for it's own size. Yeah, it's probably gonna be on the other side. You did? Yeah, I mean it's probably gonna be on the other side. Oh, but it 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 does it say not connected? Maybe you can disconnect it from the VM, you know. That or the VM might be getting in the way. But it didn't even say, it said there was no cable connected. So the, it saw it in and maybe it took it away to the VM. So where's the control for the VM that says what devices are in which? The other thing is, is for my stuff, you don't need Linux. You can just take it out of the VM and just use the Mac.  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.  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. So your network connection. So the magic at this point is just to, well I shouldn't, I shouldn't do it for you because I wanna, 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 ID at this point? You just got here. Okay, if you signed up for the class, make sure you get a board from, from in back. Okay. Yeah, I'm gonna, I'm gonna go ahead and move on but I think you should be able to, to catch up just following the readme. So there's, there's, there's a lot going on here with this USB thing. So I, I, I slow down and try to spend some time on this. I think it's kind of novel and fun and interesting. But, but there's certain integration challenges. So what's happened, what's happening here is that 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 gadgets is 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, emulate a whole bunch of different types of devices. So Linux has a huge selection of, 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, you know, so all these different gadgets, most of them fall into classes. So there's classes like mass storage for USB memory disk or a camera for your webcam or audio for your, for, for speakers or printers, hid for your keyboard or USB keyboards or mine.  Look, I can mouse and take it over. It's, it's very, very possible. So leave, leave it as an exercise, leave that as a longer exercise for the reader. There's some, some great Python scripts for doing exactly that. The session on USB is gonna talk more about the, the, the USB technology and some of those. It's, I believe it is gonna cover some of the gadgets and the host drivers as well. So some, some of the drivers that are available, but I haven't, 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, there's a file on the, in the, in the, the, 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 peer report we can actually, 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 don't want to, I've got a whole bunch of stuff in here on booting that's really, really useful, but I'm not gonna, I'm not gonna do that stuff now. I did want to show, I want to 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 in the, the bottom is the command line. So this is, this is running Tmux. I don't know how many of you run Tmux or like 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, cursors. It's Tmux is what we're running. I don't know what curses, I know what curses is. I don't know what curses is. Anyway, so there's a Tmux window in here and every time you, you could open up new shelves in this, you could do a 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 varlib cloud nine. So that's, that's where it, 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, let me 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, I'm just, 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, I got, 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. I found the device by doing a dmessage grep tty. Well, that was too much junk in my log. So Chromium is over, 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 file. There's this integration here with C9 for 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, it gives them a nice handy way of just running scripts on boot up. And then there's the examples. Under the examples, we're gonna, we're gonna look at the pocketbeagle 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, there's kind of to 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 pocketbeagle 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 pocketbeagle directory. So we'll go and do, the other item that we have is the code that we checked in through the Yale. 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, an example. I'm sorry, so this is examples of pocketbeagle. 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 slide and maybe this will work better. Oh, there it is. I got lucky. The button is P233, not P233. It's just a generic example. It's not to save that. 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 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 silk screen match and match up, but the easiest way visually is the micro-USB 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. The big host connector goes on top of the micro-USB on the pocket beagle and the micro-USB connection goes the opposite side. 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 we plug it in backwards, it's not gonna hurt anything, is it? It could. 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. I doubt anything's gonna happen bad, but I don't know. So I had to go, to find the right value, I actually 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 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, is it dead? 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 has to be pushed in to 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 varlib, cloud nine, and then you go into examples, and then the overall thing, the overall labs 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 slides. 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-A-L-E, and then slash slide. There's also a number of solutions under slash code, apocabeeble.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 hash beagle. If you're on IRC, is IRC okay? Or do you want Slack? IRC, so I'd say hash beagle on FreeNode. There's also, be on the E-A-L, IRC channel, be on, 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-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 down a little bit. If you're doing chat, 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 hash beagle, we think it's a little bit light today, I don't know, but there's usually like around 300 people. So maybe they're all traveling, leaving stuff virtually on, but hash beagle 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 has probably been specific to these labs, so a little bit loud, 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 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 on this. 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. Do you have a volume for someone in your background? No. So whatever, okay, whatever, I'd like to try this, that's much, much better, thank you. I want to try to go over some, well, why you've got the live boards and you can ask questions. I just full screens my console so that you can, it's a little bit better. I don't even, that's the size, a little bit of my font. Just obnoxiously large and full size it again. I don't know how to change, is this an option? Okay, background color, make it darker. All right, so there is under splash 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 set 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 is 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 U-boot 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 the, all the hardware is defined to Linux using this thing called device tree. 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 device tree is the primary way that we do that. There's a device tree definition for pocket beagle. In fact, under upstairs, we're running the 4.9 kernel, what am I typing wrong? Flash at the beginning, that would break it. 335X pocket beagle. This is, that's the name of the device tree source. So when everything boots up, so U-boot is the first thing to run, and it goes and reads a device tree 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 load, or U-boot, reads both this device tree and the kernel, and it provides that device tree to the kernel to tell the kernel what the hardware looks like. So if we wanted to dynamically change the, if we wanted to change the hardware from what it is by default, just the base board, then editing this device tree is one approach that we could take. So you can see here in the file, there's everything, oh, 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 that creates the user space interface to spy. There's all 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 device tree. So it's really, it's useful to kind of, over time you're gonna have to learn how to edit device trees, just work in a 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 and pseudo make install, and it would overwrite my, I'm gonna just invoke this because I'm brave. So, and I didn't know it's all good source. So the, this will actually build all the device trees for all the different types of boards that this image can run with, plus some others 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, we don't want to try to edit the main file every time. So UBoot actually has the ability to edit the device tree 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 device tree 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 these are these overlays files for these different out on board. 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 it to pick that correct overlay.  So in this case, I've added one overlay to enable the PRU, 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. 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, oh, we'll paste that here. And now on boot, 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 can really dive you in too 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 seeing 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?  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 a common one. 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 devices, 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 frequencies. 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 non-volatile 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 gonna pull out and run that driver and then it's gonna 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 doc. In the kernel documentation, there's a device tree and binding. So all the different types of things that you can instantiate like the EEPROM will give you a description of how you would specify that in the device tree file, right? 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 provided you with decent documentation. That's really small print. But the important thing is that 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 field to what a device tree is. Very much not pocket beagle specific so I didn't really plan to cover it a lot, right? So it's because I wanted to try to get you to 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, so 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 pin. So what I can actually do is something with an overlay but I create a fragment. I target it at this OCP is 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 yeah, so I patch 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 that, I disabled those, all those different purple and then I add, I also disabled the spy that the user space spy driver because I want to load a particular SPI driver. In this case, the Solomon SSE 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, it can, well it happens, it depends on where it reaches that point when it's kernel boot up, 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, or 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 U-boot source and you can set pinmux settings there and GPIO settings there. Yes, that's a good question. He's got 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, more of an example is using the board, come to think of it. I would look at the bacon cape overlay. So 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, right? Because it's not patching the BeagleBone Black based device tree, it's patching the Pocket Beagle based device tree. Not yet. No, I wrote one for the accelerometer and I think I know what the bug is because they change accelerometers between rev one and rev zero and rev one. What was the other question? So you really need a device tree class. One of the foundations, literally we do a bit on many kinds of conferences and they always show you sort of 50 minutes of like one second payment over how something should be done still in device tree. The second thing is the documentation is supposed to have actually done the work. However, there's one thing I will tell you and that is that the BeagleBone support and what they do is they are actually following some part of the decision that's in what cover during the meeting, I imagine future meeting next year at scale. The other thing is that tomorrow we are doing a partially IPeracy in fact first part of this. Oh yeah, you're not on the mic. But I'm gonna cover it this time. 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 gonna try to give you a little bit more example on device tree. This is a rich enough topic that it's worked a little bit more time. I do have an example that didn't work. I mentioned when I got the rev one board that worked on the rev zero. So I'm gonna 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 eight, the free scale MMA, oh that red is really hard to read. Eight, four, five, two to the eight, eight, four, five, three. This code is checked in to the code GitHub repo. 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 iSquad C2. I wish I could tell you about this magic. This is magic food 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, you know what. I know the answer to that. Yeah. 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 bear with 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. Okay, and you'll see that there's a number of things in an array, an array of angle brackets like this. And inside you have a number of values. Those values are all 32 bit numbers by default. Okay, and they always come in essentially groupings of address and then, sorry, yeah, addresses and then the number of data. And 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 address and zero data. Okay, so what this means in this case for this particular device is the registered value and that's what reg 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 versus if 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 app and then the number of the specificity like the register address, they're both one C, the contrast is a bit hard to see, with red on black, but essentially that's the deal. Address health and size health, it actually took me a really long time to learn that because again, the documentation is terrible. You'll also often see a label printed out ahead of this. So if you wanna 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 name space, right? So the label name space 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 under resources, Pocket Beagle, I'm gonna check in a newer version after this, but you'll see this, iTourCXL.dts. 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 gonna try this live here. I'm gonna see if this works. So I've got another little shell script in here that's going to, so 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 have this, 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, is 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 four dots. I don't remember where it went. I think we had to backport the patch into four dots. This is running four dot nine. I think it was like four dot 11 or so that they introduced the overlay capability. That Pentelus introduced it. That is absolutely magic. So, yes, you can create the overlays and load them in real time. I wasn't expecting this to work, so I'm super excited. So usually the demo, I just go 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 nearest maximum to one G value. And then the Z, if it's laying flat, you see it's kind of maximum. That's the third value. Maximum out at Z, sitting around one G. If I move it up and down, you can see it changes sitting around one G. If I flip it over, it should be about negative that value. And the same with Y, right? So Y is this direction and then upside down is that way. So we're able to follow those patterns of the changing numbers. 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. But so yes, that driver's already written. And most of the time, like 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. Like, you know, 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 for 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 IO devices, and there was only one of them. So when we loaded this I squared C 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, right? 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 go ahead and make sure it's in, I'll make sure to post the script. Let me show this on the here. So the, here's the shell script. That's too hard to read. So the, so it reads, so the overlay is in this magic config FS directory, right? This kernel config device tree overlay. So I make the accelerometer directory, that's 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 the DTBO file. Right, so when I create the accelerometer directory, creates a DTBO. Let me show you one more part of that because kernel debug config, kernel config device tree. It's not on the pocket. The code, 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 it creates, so when I created that Excel directory, it created these other files. So DTBO pass status automatically. So if we kept 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 what it says its status is before, but it wouldn't be applied. Now 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, all the magic food I needed to put in here to specify the interrupts. So I was just using it by pulling. So I changed that from a two to a three 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 the same, what's done with files that are specified here. So we're taking these overlays and here we're telling the bootloader to apply them while it's booting. The other way, we're just telling the kernel to hack them in while it's running. Cool, 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 gonna 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. I currently, our application of overlays in U-boot isn't part of mainline U-boot. That's a Beagle. The way that we're applying these overlay patches in U-boot, so the mainline U-boot has the ability to apply patches, but the fact that we use these environment variables to specify the files and apply those overlay patches, that we specifically patch that into U-boot. So if you run a mainline U-boot, you would have to take some other steps to try to tell it to apply the overlay in U-boot rather than just specifying that environment variable. Make sense? All right. Other things I wanna make sure the device tree configs in. There's another really handy tool called shellpins. So if you run a 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, shellpins.pl, shell-pins.pl, it's largely the same information that you can get from configpins. The nice thing is it just outputs in a table and kind of scans across all the pins that would normally be on the Beaglebone black headers. Then you can get a more complete set by adding dash V. This parses some debug files that are provided by the kernel to specify what the current pinmux mode is. But I'll tell you that the RX, so each of the pinmux controllers, if you see RX, that means the receivers are 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 wanna 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 a 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 the number says, so each of the different pinmuxes can be either between zero, one, two, three, four, five, six or seven, to say which mode is being selected on that pin, whether if 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 show pin 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 gonna reflect. It's not, it could be, yeah, there's opportunity for manual 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 specific. 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? Can't find a place to 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, a little run, we can run that version first though, examples, extras, PRU. You'll see this, hello pru.pruc. And it may not come up syntax highlighted for you by default. In the lower right, you can select C, 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 when you say you wanna run a particular project. So I used a different file extension here to tell it how to go and run a PRU C program. This puts a single C program, you know, 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. I've got a script, no I've got it, 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. And 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 wanna 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'll enable the PRUs for you. And if you understand said, you can just do what it says. You don't actually have to run said, but for folks that don't, I just try to make it easy to cut and paste. And I kinda go through the different examples that I'm gonna throw here and they read me 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 three 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. And 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 wanna get to the on-chip peripheral, you need to set this bit. This control bit. So just copy that line any time you need to get to the on-chip peripheral. Any application if you wanna try to go outside of the PRU subsystem with your accesses. That otherwise it standboxes it, the PRU, the hardware standboxes them. And then I've got a silly for loop. This could just be a while one. And I'm doing GPIO set so that 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 you use a one for the bits that you wanna change or a zero for bits that you don't want to change. So if you wanna clear it, you set the register bit to one in clear and that's how you clear it. That make sense? You write a one to set a zero? Maybe a little confusing. But the code here is that's what it's doing. It's writing those memory mapped registers. It's on the disk. It's examples, extras, peer you.  And the other files that are kind of making this magic work are in the directory that are just kind of more boiler, also just boilerplate. This line is disabled right now but if you wanted to, there's the GPIOs that are part of the peer you 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 peer you itself has GPIO outputs that the pinmux can select to put them in peer you mode and then the peer you's in charge of those pins or you can have the pins go to the GPIO which is the whole chip on-chip peripherals GPIOs. So these registers are changing that whole chip GPIOs, right? So the same things that you'd be changing from the arm. If you want to change the GPIOs for the peer you 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, you can create zero overhead loops that's gonna create 100 megahertz wave form output if you wanted because you can just do an XOR of a bit and do it in an infinite loop. So you're toggling a bit at 200 megahertz. 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 Sigrock. It's a familiar Sigrock. So you can actually make, you can turn your Pocket Beagle into a logic analyzer if you want, all right? 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 make file. So this make file is what does the compilation, right? It's just when you click the run button, it runs that make file. 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. I've got another version in the EL examples that actually comprehends the bacon cape, bacon bits cape. Yeah, the one closest, 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. It says it loaded in RAM. So I've got another script that says run RGB pure U. So it does the one other step which is making sure that the muxes are set properly. Of course for that one, for the LED, it's not really using the muxes because it's just using the, it's already muxed for GPIO. But for one, 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.  But here's the thing about the make file is that you have to specify target which is the program you wanna build and then pure U in and specify the pure U number. If it's pure U zero or one that you want it to run 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 five nanosecond latency from the command, right? So you can, you can literally sit there and make a hundred megahertz waveform. If you were to do a tightest possible loop on the pure U that toggled the GPIO, so it's probably an eighth or a tenth of that. Yeah, yeah. There's gonna be some jitter when you go outside to this, because it's gotta 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-ship peripheral. It's going into shared buses that could, you know, could take a gigahertz cycle or so of priority over the pure U accessing it. So yeah, it's definitely, you know, like a hundred nanoseconds is good enough, which is pretty good.  So this should be, yeah, okay. So I'm just, I'm doing the decay thing and 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 as part is there as a script running from the command line in the examples provided on the GitHub. What was the rest of your question? The biggest thing is to make sure that you need to make sure that disabled ones are able to keep up with all the peripherals from the pure U. If you wanted to do, 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, 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. But if you just use the SPI one controller, I mean, that's largely independent. You have to kind of look at the individual peripheral and 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, you know, clock management and stuff that's going on for, for that pure U, that whole, 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 there's, it's going to be just block. Yeah, so it's, it's, there's cross-bars for memory, but not for the on-chip peripheral. Yeah, they have their own, they have their own, their own target RAM. They have a shared memory area between them. But they can't actually access the DDR. So they, you know, just like they can access all the on-chip peripherals, they can access the DDR. And so it's really, like what you, usually to communicate with them, you'll just memory map the, the, the register, the memory space of the pure U's 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, like each way. And you would just, you just map that with the DevMIM. And I wanted to try to provide a simple example for that. There's also in the kernel, there's a provision for messaging called RP Message. That's very dependent on what you're, if 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, don't, don't try to go through the caches. I don't know what the exact cache concurrent coherency issues would be going off-chip. But for, for like, large bulk memory sharing, it should work fine.  I would synchronize in the internal memory. Then the, the code? Yeah. So the EL code will actually all, the code's going to be on the USB 6 tomorrow. Tomorrow or the slides in 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, the sticks. I was trying to, I'm on my rep-up slide.  So it'll be on, the, the changes that we made here live will be on the sticks. And they're all on the GitHub. So github.com slash e-a-l-e. If you go to Code Resources Pocket Beagle, and I'm going to update the README as well with instructions that are, that are completely up to date for, for running all the different examples. Just, just a couple of quick plugs. This is, this, hopefully you guys are going to learn so much this week.  These are kind of those critical projects that mentioned BB art overlays. This is where all those click boards need support. They need love. They need overlays. Image builder is, 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, the left-hand side. Those all live in Bone 101. That's the, the repo where those all get maintained and copied and there. You can see those as the update and contribute changes and share your beautiful knowledge. We've already used our time for questions, so thank you. Well, Bobby, I just wanted to go first. I'm just like to silly flip. Getting things like the USB keys and stuff done. I just think you're preparing with us. Hopefully you had a lot of fun and all the extra information that Jason brought today which was very much appreciated. We're now going to break into the next talk which I believe is that, is it two o'clock? Yeah, it's two o'clock, okay. And that's actually my talk. We're going to talk to you about kernel modules and tables in kernel. If you're doing that, mom, be out on the board itself. The USB keys are going to come eventually. Please don't leave. We're here till Saturday evening. Please don't leave. Dale, we're coming to find one of us to get the USB keys. All I can promise is that we will have some writing before the end of Saturday. Okay, and part of the problem is because literally we're all mad. You kind of finished this talk. There was a lot of very last minute issues as we just worked around, so I apologize for that. But we do have a few things for everybody. If not, all of the information will be on the website. It will be in GitHub. It will be on the e-linux linky. Certainly, if you want to know for sure what's going on, we will also email everybody on the mailing list that's on the e-mail website. Let's do find out for the e-mail list that everyone has found you. You'll really tell you what's going on on that mailing list, okay. So as long as you put your name in there somewhere, we will get the information to you. And like I said, your file will be on the website as well if you don't get the USB keys. Otherwise, great for an hour. I'll see you back here at the second colonel's manual. Thanks again. My God, you went into the weeds so fast. Everybody loved it, so that definitely shows where we have to go on the computer. The device tree was really high in my list, and it's a frustrating thing that we didn't have. We didn't cover it? Well, the thing is, the device tree is often covered with these things. The i4c, the SPI, and USB stuff specifically is never covered, so that's why it's really not covered for that, but it's so hard to do. But honestly, just to speak of both, both the stuff is still the best in the world. So as far as, you know, everybody's fighting in the world, it's still the best in the world. Because Panto basically still has everything on it. That's awesome. Panto, we're in the corner right over there. It's definitely used a little bit of a system that you need to understand what's going on.  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, but I have to get my last minute. I don't know if we're going to get our video, but I can't even read what's on the screen from my screen, is there a camera? 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 it. You've got to capture this. We've captured that. We're actually capturing that. So it looks beautiful, just because of that. Yeah, but I was just going to tell you, it's going to be right there. And by the way, a lot of people have to do that as well. It's really hard in this scenario to get it big enough. Hi. Yeah. I don't know if this one's going to be bad. We're still actually supposed to be bad. We're just going to read it. We're just supposed to read whether or not this one is being correct or not. I don't want to talk to the venue again. I'm not going to go to the venue again. I'm not going to go to the venue again. Yeah, but not the other two, because the other two buttons will pose it to reboot. Did you change it from P3 to P33? P2, 33? P2 underscores P3. Yes. Yeah, it shouldn't work. It's running. It just says one. It probably just keeps printing out the number one. Just make sure to get the right LED. That's the trick. Get the right button. That's the LED. Did that slide change it? All the changes are live in the code, right? I don't know if the device tree stuff is still a little vague. I wouldn't worry too much about it at this phase, if it's a little. Actually, what I'm more worried about is the documentation of what will be the Python and JavaScript to make the thing this stuff. I think it's about to go forward. Good. If they're all updated. Oh, yeah. For sure. Yeah, I need to have the code on the board. You can do internet connection sharing and share the network back. Well, I thought I knew what to do because up until Tuesday, I was using a Mac. And I switched to a Linux laptop on Tuesday. So, and I can't figure out how to get Ubuntu to do internet connection sharing. But I can figure out how to do it with a Mac. Probably, I've never done it with Windows, but, I mean, I. But the, there are sort of people who don't get connected. So you've got USP drivers that actually get out. Yeah. Is there a gateway? Well, you just need to do internet connection sharing. So you just, it looks like a network connection on this side. So, yes, they can get out to the internet if you bridge it. You just need to use your laptop to bridge it. Otherwise, you can connect up a USB Wi-Fi dongle. So, to the bacon base, you connect up a Wi-Fi dongle, and go that way. I need to make a bio break. I'm sorry to run out. OK. I'll be back. Pardon me. Oh, it's over there. How do we go? I don't know. It's good? Huh? I felt like the audience was pretty well engaged. And I was, and that. Oh. Go to the bathroom. Yeah. Just a little bit of a delay here. My laptop decided it wanted to reboot. So, we have the EL stickers here, and I was going to hand them out a bit later, but at the end of each thing here, if you guys can pass them down to the other people. Oh, there. That would be great. Hopefully, I've given everyone enough. There we go. There we go. Sorry. Oh, do you want to? OK. I should have some more, but slight technical difficulties, and I just wanted to make sure that's working. I was just working on some labs for us for later on, and unfortunately, it looks like my document just got lost. So, I have to do that during the break before we get onto the lab section. That's fine. As you can tell, a lot of these things have been done last minute. We've tried very hard to get all these things finished, but we've had a number of minutes, issues, and other things happening throughout our instructor, group of instructors. So, I apologize for any roughness, and I hope you still enjoy our program we're doing this week. My name is B.N. Webster. I'm an embedded consultant. I work for a company called Converse Encode. However, I do a lot of contracting, including contracting the Linux Foundation for both writing courseware surrounding Linux, specifically embedded Linux, as well as being instructor for the Linux Foundation.  So, what I do is what I call engineering-facing work. In other words, my users are engineers, and that's because I like talking to engineers. The rest of the world is insane. So, this is a whole lot more fun. I've been doing this sort of thing, well, I've been in the industry for close to 25 years. Started off in telecom, moved to data com, more or less optical. Oh, gracious. The gaming industry, I've done some defense work, medical, automotive, lots of different areas. However, always at the systems level, always engineering-facing, always doing things from board bring up through boot loaders, through kernels, drivers, compilers, various tools, libraries. I don't go much above that, even though I've done that work, I like stopping there. User-facing stuff is something other people are better at than me. But anything below that area is probably something that I've either worked on or worked with somebody on. So, that's why I really like a lot of this low-level stuff. And the developer, the app tool was one of the things that I worked early on and other things along those lines. Questions you can ask. Today we're going to be talking about something that's rather interesting. I've been using Linux since the early 90s. And I've been doing it professionally and not behind the scenes because a lot of us use Linux despite the fact that we were supposed to be using Solaris or HPX or Windows on the machine under our desks or dual-booted. I've been using it professionally since the late 90s and took a few more years than that. And part of it was because I didn't entirely understand this whole kernel module thing. I would make a lot of my changes to the kernel proper, reboot it, test things and go back and doing things. So, modules are actually your gateway to the rest of the kernel and that's what we're going to talk about. Who here has actually written a kernel module before? A couple people.  What does it do exactly? Why do we have it? So the big thing to get across to people about modules, a lot of people think that drivers are modules. Like a driver and a module, same thing. The fact is that all the module is, it's a way of getting information into the kernel. That's it. It's just bytes, a payload of bytes that goes into the kernel. That payload can carry whatever you want. Now, it could be a driver, but it could also be a library. It could just be a string. It could be a K probe. It doesn't matter. Whatever you want to put into the kernel is what goes in there. And the neat thing about modules is not only can you put them into the kernel, but you can pull them back out again. Now, that sounds funny that I said that, but in fact, adding code to a running kernel is easy. Removing it from a running kernel is actually a lot harder. And so we're not talking kernel patching here. We're actually talking about adding code dynamically into various systems. So there's actually quite a lot of infrastructure and checking that has to happen before we pull code out so we don't crash our computers. The other thing that modules are used for is for automatically loading only the drivers we need.  Many of you also have Macs like I have. But the thing about all these machines is they're essentially the same. They're all Intel boxes, some of them might be AMD, but they're all Intel boxes. They are roughly the same, right? There's a lot of ACPI glue and other things that make them look roughly the same. However, they are quite different. And there are things that, there's different controllers for graphics and for sounds and for lots of little bits and pieces. And we don't need to have all of those drivers in all the time. These days we'd have a kernel that had everything compiled in. These days if we did that, we'd run out of memory in a lot of machines, right? So we only load what we need. And so what we do is we build them as modules and then we use the initial RAM disk, a little memory-based RAM disk, and we load our modules from that. And so this means that we can dynamically figure what we need and only load what we need. That means we minimize the amount of memory that's actually used in the kernel. Part of the problem is because of the memory model, the way the kernel works. Kernel memory is what's called non-pageable. What that basically means is like a re