 Hey, I'm just going to talk about MRA library. So MRA is a low-level skeleton library for Linux-based systems. So this is what we at 96 boards are heavily using in our boards for giving the user space access to our community members. So which means that all of our 96 boards got support in MRA library. So you can just go in, build that library or you can just download the pre-built packages of MRA library, and then you can just start using it. So the usage of MRA library just spans across the peripherals of Linux-based systems, which means that you can use it for accessing the GPIO, I2C, Spy, or even ADC if it's on there. So what are those, what are they used for? What is it? Let's say for example, if you want to control an LED connected to your 96 board, you can just do it via GPIO. And if you want to access a sensor like the temperature sensor, if you want to get measure the room temperature, you can just access it using the I2C bus using the MRA library. We have some predefined examples also on how to do that. And one of the best thing about MRA library is that it offers a lot of interfaces, like it got C, it got C++, Python, Java, JavaScript, and you can choose whatever you want, whatever you are comfortable with, and then you can just start building your application. So where does it, where has it hosted that MRA? What did you put at this library? Actually, this library is a part of Intel IoT DevKit program. The Intel guys actually started this library for their own purpose, but later on, it got actually extended to other architectures like ARM, MIPS, and all. So it's in the Intel IoT DevKit repo. But so where do you put it? Is it part of a distribution or where does it hosted? Oh, okay, sure. When you put it on the board. Okay, so that's what I said before. There are two ways to install this library on your board. So first way is you can just sudo apt install MRA, libmarray.dev. So that's the prebuilt package for the MRA library. So the second option is to build the library from source. Just clone it, build it, that's it. You're ready to go. Does it make things simpler, easier? For people to do more intricate things? Yeah, so it makes things simpler because just download the library, install it, and then you can start creating the applications based on your needs, that's it. Very simple. So actually I had a question about using the MRA in the user space. So a lot of people might say, why is this good? Because that's kind of a complaint, having a library in the user space. Okay, so I was actually talking to a guy from AeroElectronics. So he was asking me, what's the best library for accessing peripherals on 96 boards? I said to him, MRA, and he asked me the same question as Robert asked, why should we use MRA? And so one of the requirement for him to use MRA was that he wants to have multiple interfaces. Like I said before, it actually supports multiple languages. So he wanted to use Python, and then I said, MRA already has a Python interface. He said, okay, I'm going to use that. Nice, yeah, it's pretty simple. Yeah, actually I really like it as well because I mean, a lot of times when you're working on different boards, the GPIO location is different, right? And so you want to just toggle a GPIO or you want to work with one of these sensors, like you're saying. Of course, so just unified. I would say that's an important aspect of 96 boards and MRA, of course. So the reason why I'm saying is that we have a lot of boards. We have boards across different SOC manufacturers. So let's say we have Dragonboard, which is from Qualcomm, and Highkey, which is from Highsilicon. Both boards are having different SOCs, but they comply to 96 board specification, which means that they are not pin compatible, but according to the 96 board specification, they expose the same GPIO pins on the low-speed expansion header and high-speed expansion header, which means that you don't need to try any board-specific pins for accessing GPIO. You can just use the low-speed expansion header number there, like 23. The GPIO starts from 23. You can just use 23 on any of our 96 CE board and you can just access the GPIO. There's no board-dependent way of accessing. It's all unified. What about more low-level enablement? Is there anything needed there? So we do need to have the board support for all of our 96 boards, and that's what 96 boards team is doing, and also some of our community members is also doing that, which is very good. And you just need to add some piece of information in the board support file in the MRA, and that's it, you are done. So since when is this available? Is this a new thing? No, it's been there from the day where Intel started to involve with IoT, but it's not very popularized because Intel didn't popularize their IoT kits yet, but we started using it because we saw the potential of MRA because it's already standardized, and then we had one 96 boards GPIO library before, before I joined, and that was good, but it's only for GPIO. And then we started about other peripherals. It doesn't make any sense to create single library for a single peripheral. We want it in a single place, unified. That's why we choose MRA, and it's very good now. What is 96 boards rule in kind of like standardizing things and making things like easier? Yeah, so for MRA library, I'm the co-maintainer of it. So my duty is to take care of the 96 board support in MRA, which means that I'll add board support, I'll maintain it, and also I'll also work on standardizing some of the infrastructure of MRA. But that doesn't mean other people can't go in there and contribute as well, yeah. It's open for everyone. You can send pull requests, you can submit issues, whatever you do, whatever you can. Yeah, we actually recommend that too, by the way. So like, you know, if you do have a 96 boards that you're working on and you're gonna release, it'd be great if you came and worked with Mani beforehand so that you could get all of your support into MRA before the release. I would like to share an experience now. We have one board called Dragon Boat 820C, and that got released by Aero, sorry, Qualcomm, and one of the community member, he took that board and then added MRA library support for that. It's just a board support for that board, and then he submitted a pull request to MRA. I reviewed it, and then I merged it. It's very easy, yeah. Very easy, yeah. And is it fun? It's very fun. Yeah, it's fun. It's very, yeah. Because if you can have the whole concept of the 96 boards, right, if you wanna have all these boards and enabling cool IoT projects, cool, all kinds of stuff, but if it's too confusing, too complicated, that would be an issue, but do you think things easier? Yeah. At a simple level, right? Like, I mean, I O is your interaction, receiving and transmitting to the world, to the environment, so I mean, like, that's gotta be one of the more fun parts of working with devices like this. I know you can always get down and dirty and code into, you know, kernel space and have all of this fun developing, but, you know, when you go to a hackathon or when you're working with people that are dealing with robotics and all sorts of stuff like this, like I O is actually very important, and so, you know, providing a library like this, you know, gives people these tools to work with, yeah. Also, you know, just getting started right off the bat, I remember my first experience with an Arduino, just seeing the little blinky light, right? Like, that's I O, it's just fun, yeah. It is fun. Yeah, and of course. And I would guess students want to have it easier, like, oh, anyone who starts working the board? Yeah, so the instructions are there in our documentation repo. You can just go in, we have a dedicated MRA readme instructions that will tell you how to install the library, how to get it. We do have some examples also, and you can just go and reuse the example on your board to get started and then you can do the customization you want. So one of the challenging factor for 96 boards is that we are actually, it's not like Raspberry Pi or BeagleBone Community. We are a diverse community, which means that we have boards from different SOC vendors, different board manufacturers. So that's where the problem lies. It's not very common. So it's been very challenging, but we are trying very hard to unify it for the whole 96 boards ecosystem to make the life easier for user space community. It's the coolest space to be right now in development boards, right? Yeah. Is it? Yeah, because there's all this stuff happening in the ARM ecosystem is the coolest one, right? And who else is doing that? That kind of, you know, making standards. Yeah, of course. We are creating standards. Oh, you know what? I might as well pull some of this stuff out here. Yeah. All right, let's see. So that you can kind of see what we mean by the standardization. We've shown these boards off quite a while, but here you can check out the Dragon board. So that's the famous Dragon board? Yeah, this is the famous Dragon board. The most popular 96 boards? Yes, of course. How good is the Dragon board? How good is it? You are relative too. This is the infamous Dragon board 820. And then we have Alt-96 here. This is an FPGA board. And then this is what we mean when we say that it's very important to have a unified library, but not only a unified library, but a unified I.O., which is what is with the 96 board standardization. So when you have your low-speed expansion connector here and your high-speed expansion connector here, when the I.O.'s match across different SOCs, which these are, the Snapdragon 410e, Snapdragon 820e, Snapdragon 410e, and then the Zinc Ultra-Scale FPGA board, you're matching up this I.O. to the Mezzanine, you can plug this in, oops, you can plug this into this board, you can plug it into this board, or you can plug it into this board. And as long as there's a strong software story behind it, it should basically work. And that's kind of the beauty of it. So was it a challenge to get to this point? Like in the first couple of years of the 96 board, there wasn't this? Absolutely, yeah, it's been tough. Yeah, it's been a tough uphill battle, I should say, but it is definitely nice to have such an engaging community of developers that made this happen. And that's basically how it all started, right? It was, 96 boards was for the ARM developer. It's very tough because nobody has tried it before and we are the only one who tries to standardize the ARM ecosystem. So we are still learning and I hope it's going well. How is it to, how does it feel to be one of the guys standardizing around the ARM ecosystem? It's feel great. I mean, I would say I'm very proud of being part of 96 boards team. Can you stick around? Sorry? You're going to stick around? Yeah, yeah. I'm giving a promise, so. It's on video now. Yeah. Cool, awesome, all right. So let's do some more videos, right? Great, yeah, sounds good. Check the next video.