 all my career, so I mostly live and see in C++, I connect devices, and I really, so start working on the NERVS project, and when, so recently NERVS has become a little bit more popular and it's gotten a few more people involved with working with hardware in the Elixir community, and I really wanted to make a talk, or give a talk on how to get start with hardware in Elixir, because I think Elixir has some really interesting pieces to it. I came to the, so from my point of view, I came to the Erlang community because I was very interested in some aspects of OTP, but Elixir has many great things and certainly builds on what's there, and I wanted to share some ways that you can avoid some pain, and to that effect, this is what we're gonna talk about. There are really three parts of, there are three ways of interacting, or three main ways of interacting with hardware when you're using Elixir, and one, of course, is NERVS, so of course a favorite one, I'll give a little blurb about that if you haven't seen that yet. The other one is using these desktop Linux, so I guess the term in my field is single board computer, so this is Raspberry Pi, Beaglebone. Talk a little bit more about that, about how you can actually get pretty far on these boards, and then the other thing that I think is completely underrated is interacting with hardware on your laptop, but you need to know where to look. I think you need to know the trick to for how to get started on that route. So I'll talk about those and give a couple examples of projects that have gone these routes. So NERVS, so NERVS, this is, this is a project that I started three, or a little bit over three years ago, and the idea was just to combine OTP releases with a small Linux-based system, so that I could do what our technical line says is craft and deploy bulletproof embedded software, and as things have picked up, especially, I'd like to thank this community because you guys have been unbelievably good and welcoming to me in this project, and certainly Justin and Garth really helped me get back into it with the, and bring Elixir to the forefront with the project, and they've certainly contributed an insane amount, so I don't want to take anything away from that. But so NERVS, so what are some of the key things in NERVS? If you haven't used it before, you might have this nebulous feel for what's NERVS, what's not, well NERVS is actually basically the tooling, and there's some basic common infrastructure for embedded systems projects that's included within the main part of NERVS. Now there's certainly a lot of other things that people do with NERVS, but you can kind of think about it as like Phoenix and all the ecosystem that Phoenix has. NERVS has the core part, and there are many ways of extending in projects that build upon it. So it's a tooling. When you start to use it, you'll get a different feel. It's not really batteries included, it's kind of the opposite, it starts small, and then you add on the pieces you need. This is something that has appealed to me quite a bit in my career because it's the projects that I tend to work on. It's good for me to know what the ingredients are, and I think the downside of starting big with batteries included is that it's kind of hard to figure out where all the moving parts are and where they're going. Now on the opposite side, starting small and building up, you need to know what to add. So I'll briefly mention a couple ways of dealing with that and making that part a little bit easier. It's cross-compiled, we've always been cross-compiled, and the main reason has been that we've been targeting hardware that is really not fun at all to do development on. So you work on your laptop or some nice build machine and it produces a little piece of firmware that runs on that piece of hardware. Now, another part that may have been more controversial will surprise people if there are any embedded Linux people here is that the embedded Linux ecosystem overlaps with the Erlang OTP ecosystem of componentry in various ways. We tend to choose the Erlang Elixir ways, which probably don't find surprising, but sometimes it has ramifications because you'll go look things up on the web for like, how do I do this thing with DNS and find out that, well, we don't use some of the embedded Linux tools for doing basic operations, either with DNS, we use Erlang's route, or with a couple other pieces. So this is the, let me just move on to the big diagram. So if there's one thing to remember about nerves, this is it. All you have to do is remember this picture and you'll never be lost. And there are two sides of this picture. So there's the bottom side and the top side. The bottom side describes what happens. The parts that we put together, mostly on our side, and then if you get to be an advanced user, you may dig into this yourself. But it basically includes Linux, C, the C libraries, all that stuff gets compiled and then built into something called a system image. And we distribute system images, so you get one for your platform. And then they can build download if you have in your mixed file. You can reference these and they'll be downloaded to your system automatically. So it's all really nice. And then on the other part of it, the top side, this is where most of your development hopefully lives if it doesn't live there and you're probably not using Elixir that much. But the idea is you set up Elixir, your Elixir projects the normal ways. We have a helper called mixnerves.new which will template things out to get you started. But you set it up, use the standard Elixir tools to build things. And now we go to an OTP release. So once you get to the release, there's some additional steps with Nerf. So the release, for those of you who aren't familiar, contains all the beam files that are compiled and some initialization scripts, mostly to handle the Elixir and Erlang side. Those need to be married with the system component tree, the Linux kernel. And that gets created in a firmware image which for those of you with Raspberry Pis, that gets converted into, you'd write that onto an SD card which you could then plug in. For those of you who might be doing something professionally with this, where you're not using SD card, you have built-in memory, that would be programmed either in production or manufacturing step, and then there'd be upgrades that you could ship out to your device using whatever method you have for communicating with your device that could apply new firmware images. So that's about the extent which I'm gonna get to go into Nerf. If you want to know more about it, you can follow our website or there have been several other talks that you can watch on it. The main part I wanna get to are the underserved parts of interacting with hardware. And this is just, why not get a Raspberry Pi and install Erlang and Elixir on it and just run from it. So you can get these, you're not stuck with the Raspberry Pi, there are hundreds of them. And the neat thing about this is that if your project needs some IOs that the Raspberry Pi doesn't have, maybe you need an FPGA or, which FPGA is a really low-level hardware way of performing some hard real-time action. So you can get these fancy ones, you can, a lot of them come with Debian. So with the Raspberry Pi, you get Raspbian, which is really Debian repackaged. And they work like real computers. So if you're new to this, it's really easy to interoperate because it's just like a really slow PC. I do have to say one thing on this, and I learned this the hard way. Actually a couple of times, which is kind of embarrassing, which is just like you wouldn't pick your laptop, based solely on hardware specs, don't just pick these boards based solely on hardware specs. And sometimes these boards look so cool that you just want to pick them up and just play with it and then you find out that the software's really, really bad. Or really old and ancient and un-being tamed. So that's just a note there, just when you're looking for boards. The ones I mentioned here are very good. They're outstanding. They're Raspberry Pi and Beaglebone. There's several others there, they're good. All right, so Debian, what's great about it? Well, everyone uses it. So if you actually want to get help, which we're a small community, we're kind of new on the hardware side, so it's not like Stack Overflow has tons and tons of how you do this in Elixir, how you talk to this device. Most often you're gonna find out how you work with a device with Python or some other language. So the good news is that when you're on this board, you can always try it out in one of those other languages or post your questions and you'll get some response. The bad part is that you're building Erlang from scratch, almost always, because for whatever reason, a lot of these boards have Erlang 17 or earlier, which doesn't have maps, so it's less useful. And I guess if anyone happens to be here who knows how to work with Debian in ways to update their packages for Erlang, please let me know, I'd really love it if I didn't have to rebuild these as often. I guess one note here, if you're working on the Raspberry Pi, Erlang Solutions has that totally fixed. You can just get their package off their website. All right, so now, those are two of the routes. So the Nerds and Desktop Linux, they have similar capabilities in what you can do with them. So I wanted to go over a particular application which has gotten more, has come up a few times on the Nerd Support List, which is monitoring your garden. So I don't know why this year it's monitoring your garden. Other years it was making beer, but this year seems to be the garden one. So here's what comes up. So what you do, apparently people can't remember to water their plants. I have this problem too, but you have a Raspberry Pi and you wanna actually do something with it. So you want to connect some sort of moisture sensor to the Pi and use it to monitor the soil, so you know into water. So nothing super complicated, but when we get into the details, you'll see it can be a little tricky and it actually turns out to be more interesting than I thought when people first started asking about this and I changed my presentation to include it and you'll see why. So here's the setup. So you get a moisture sensor, although probably some of you have seen this where it has two prongs and the idea of these sensors is that you apply a voltage, goes down one prong and then you basically see how much it comes out the other side to see how conductive the soil is. So that's analog and for those of you with Raspberry Pi's, you'll know they don't have any analog inputs. They can't, the analog input and you can't give it like three volts and it will tell you that's three volts that it got. So you need to have some chip in between to do the translation. So they're analog to digital converters. They're like millions of these, but a very inexpensive one and easy to solder one is this MCP3008 and if you go to a lot of websites, they'll point you to this one. So anyway, it takes analog in on one pin and then converts it to something called spy. So spy is a particular digital interface. It's one of a couple that are very popular in embedded systems and hardware. So the pins, those pins on the upper left corner of that pie, there's some that are spy inputs. So we take that and then the other piece of information that you need to know is how do you access it in software and there's, if you search Hex.pm for spy, you should get Elixir Ale and that's a library that's been around quite a while but it has interfaces to what you talk to spy peripherals. So what does that look like? So the first thing, you know, most of us do is like, all right, we have these inputs and outputs. So let's match all of the APIs together and see how, see what we need to, our programs do to glue them all together. So you look at the Hex docs for Elixir Ale and for spy, there's one function. So, all right, so this ought to be good because how hard can it be with one function? So the neat thing about the spy bus is that since you transmit and receive simultaneously, so it's not like I send a byte and then I get a byte back, it's like I send and receive a byte at the same time and this is kind of strange but in a couple slides, you'll see why this makes sense and it's actually quite a simple way to implement hardware. One thing, I guess the other thing when you deal with hardware and the APIs for hardware, you'll find out that things are a lot simpler than you may expect them to and sometimes simpler or nothing, you just can't believe that it actually just works that way. So sometimes you have to just take a step back and just look at it fresh while like, what would be the simplest thing for turning wires on and off? So we got this function. So now what we need to do and we need to find API to this chip. So in hardware speak, API is data sheet and there should, so those of you who have looked up data sheets before, it has a lot of scary stuff in it but the good stuff isn't here. This is the real API, this is the document that you need to go to to find these and Google will get you there. So in this case, here's the webpage for the MCP 3008 and at the bottom there's a link to download the data sheet. Then you have to take the step of searching for the most important diagram which is, which looks like this and I'll explain this and so if you're totally new, you might wanna just, and you're working this, you might wanna read up on spy but I can tell you real quick how spy works. So spy, there are three wires. Actually this shows four wires, this diagram but the top wire, we can ignore that for now that fourth wire is used to tell the chip that you're actually talking to it and the way these things are hooked up quite often is you're always talking to the chip. So the three next wires, the one cell called CLK that stands for clock and then DN that's data in and data out. So data in, this is chip centric since this is the doc from the chip. So data in would be coming from the Raspberry Pi to that analog to digital converter. So the way this works is when you send and receive over the spy bus, the Raspberry Pi twiddles since one sets it to zero volts and then sets it to three volts. So zero one, zero one, so that's the clock twiddles. So every twiddle is a bit that goes through. So here's how it works. It's the first bit, that one, it's called the start bit and if you read the doc, the sections I didn't copy, it says set that to one, okay. Then there's a mode bit and well, there's a little paragraph that sets it, but that tells you how to set that right above that. So that's good. There's address bits. We went back to the picture of that chip, you notice the head a whole lot of pins. You can take input from a whole bunch of Moisture sensors if you were interested in it. So they have an address. So that's probably not too hard. Then there are 10 bits in the result. So 10 bits, zero to 1,023 is what you get back and 1,023 means you're getting a lot of volts. You're getting close to three volts or five volts depending on how you run the chip and then zero, get back zero, it's zero volts. So you know if you have a lot of Moisture in your soil, you're gonna get a high number, you don't have much, you're gonna get a low number and then you play around with this a little bit and calibrate it and you figure out what the good number is. So let's just complete this. You get a couple more bits in there because you count the twiddles and then this is what happened. So it came to 17 bits and then this actually prompted the post to the list in which it was, I don't know what to do with 17 bits. So those of you who've done bit strings with Elixir, you're like, oh, I can do 17 bits but that's not really good enough. The spy interface takes bytes. So you're like, oh, 17 bits. Did I count it right? And I actually counted this an embarrassing number of times to make sure it was actually 17 bits because who makes an interface that gives you numbers in fractions of bytes? And actually, if any of you work with hardware people, you start finding out that this is not uncommon. I don't know why they do that to us, but they do. So then what do you do when you don't know how to use an API? Well, you look for examples. So the word for example in hardware speak is application note. So all right, so you start Googling app note. They often shorten it. And then you get a diagram like this and you're like, oh, okay, I really hope this is helpful. And it actually turns out to be helpful. It wasn't immediately obvious, but if you look at the bottom two rows, they're groups of eight bits, so you have bytes. So they said, okay, here's what you do. If you can only send and receive bytes, well, just make the first byte, just put one bit, the start bit in it. So you send a one, and then 17 minus one is 16 bits. So if we were to go back to the previous diagram, then you'd see that the first, the start bit, and then the rest are the 16 other bits. So what we need to do on the top is send a one and then send the mode and the address. And then the X's mean don't care. So we can just send zeros, because that's easy enough. And then on the receive side, they're basically saying, question mark, we don't know what we're gonna give you, so don't look at it. So we just have to ignore, I think that's like, what, 14 things or 13 things that we have to ignore and then we get a zero. We definitely get a zero. And then we get the good stuff, the value. So three bytes, yes. So what does that look like in Elixir? And this is actually one of the coolest things to me. So if you look at the, so spy transfer, if you look at that second parameter, the pass of one, and then the mode, size, and so size of one, so one bit, the sensor, which is the address, so it has a size of three, so three bits. And then we're gonna send 12 bits of zeros. So we do that spy transfer and then on the receive inside, that with the pattern match, we just ignore the first 14 bits and use the 10. And this is, I actually almost can't imagine a more concise way of expressing this. And so I want to impress upon everyone here that with so many, with our interactions with hardware, so many times you have to go through a library, right? So there's a lot of stuff encapsulated in libraries. And going through a library is great. We need this abstraction, but the problem is, is if anything goes wrong, what are we doing? We have to look at the, see how things are implemented in the library and we eventually have to look at the data sheet. Well, this matches almost directly with what the data sheet says, except in possibly more friendly terms. So if anything goes wrong, well, we have the data sheet here. You can just compare and look. And more often than not, you want to do something that your library doesn't support and you just want to tweak it a little bit. And because you know you've read the data sheet that the device can definitely view this, but then you have to cut through all these layers of abstractions. And Lixar makes this so nice and simple that you just have just what you need right there. And this is not some isolated example of a device. There are so many devices that are just as simple as this. It ended up with code like this. You're almost questioning, do I even bundle this in a module? Because it's so easy. All right, so that's the first part. And this next part of the talk is going to be about what you do when you want to work with hardware on your laptop. And so obviously the laptop is really nice, right? Most of you, all of you probably are very comfortable working with your laptop already. And maybe you haven't done anything with hardware, so changing as little as possible to do stuff is highly desirable. There's actually quite a bit that you can do, but of course the drawback is it's on your laptop and if you're building something and want to have it monitor something 24 seven or do something, I mean you're not buying laptops all the time, right, that'd be silly. But the other problem is despite how fast your laptop is, the interface is to connect the hardware from your laptop are a little slower than what you can get on a Raspberry Pi and Deaglebone. So here's the thing. Often someone who'd present this would say, okay, use a serial port, so I'm gonna call it a UART and because that's what it's called in pretty much everything that I use. So there are differences, so those of you who know this know that there are details here that I'm skipping, but you will see this term frequently in some of the, in the data sheets and other documents for these devices. So UART, briefly universal asynchronous receiver transmitter, three wires is what these things normally have. So receive, transmit, ground. They do kind of the obvious things, ground. Of course that has to be connected to everything that you work with and then receive and transmit. They toggle the line to send bits or you look at the line to see how it's toggled if you want to receive something. If you haven't used a serial port before, just think TCP except you manually hook up the connection, things don't work and sometimes, oh, bits, bytes drop, bits, you know, all sorts of bad things that probably won't happen to you all that much until you actually start letting other people use your stuff, so that's that. So why do we stick around with this kind of technology? Well, it's dirt simple and it's everywhere, everywhere and embedded. I mean, you can think of any number of ways to communicate between chips, but this UART has hung around there and I think what it comes down to is it's really easy to debug, right? If you want to just test to see if the wires work, right? You can stick a paper clip and tie together receive and transmit and then on your computer have a terminal and say, you know, type AAA and it doesn't come back. No, there's probably a break in the wire. But if it comes back, then at least that part works. So there's a lot of aspects that are pretty easy to debug. It's of course wired, a wired technology. There's lots of options to make this go wireless. Of course, once you start talking about wireless, there are other options that you may want to consider. All right, the key thing that you need is USB to serial cable. So all of you that came to the workshop, we gave these out at the workshop, but this is like the best piece of equipment that you can get and they're not that expensive. There are some details to this. So I wanted to post this up here so that anyone, when you go to buy one, just to keep some of these attributes in mind. So logic, it will have a spec that says logic voltage level. So that's the receive and transmit wires. So the idea is that if you're talking to something that only likes three volts, don't give it five volts, right? So, I mean, nice thing. So logic voltage level is that almost always you're gonna be working the three volt for probably most of what you do with elixir. I think most of the five volt things are at least much less common now. The other part is they sell them with, see how the wires are apart. The other way they sell them is with the wires stuck together in one line. So that's called a six pin header. That is actually convenient. If you really like the Beaglebone Black and there are a couple other things, they have the six pin headers so you can just plug it on. When you have the wires apart, what happens is you plug in one wire into the wire that you think is received or the place that's received, another one in the transmit and then you find out that you got them backwards and things don't work. So it's kind of like USB, you know how you plug it in one way then turn it over and plug it in the other way and then keep on doing that. Though it's the same idea when you have them apart. But it doesn't matter. You actually don't hurt anything if you make that mistake. Then the convenience is some of these come with five volt power supplies. The red wire on there, that will supply five volts. So you can actually power the thing that you're talking to as well, which is very convenient. Some names look for FTDI, prolific. I only put this, so if you go to a reputable place, you don't have to worry about this, but there are clone chips out there and I got duped a couple times, I think by being cheap when I needed a few more and if you're on Linux, no problem, you're fine. It seems like the clone chips always work on Linux, but Mac and Windows, they give you unknown pain that it's kind of the last thing that you need when you're getting into hardware. Okay, so let's do something with this and a fun thing to do is just to find out where you are with GPS and the GPS modules, there are actually tons of these. Most of them work the same, a similar way and they have a UART interface, so this is one that's actually pretty easy to plug into, so I took a picture of it, but if you look at the holes on the left side, the bottom four, so the VIN that's voltage in, so you give it five volts or the next one's ground and then receive transmit. So if you actually had that USB to serial connector that I showed before on the previous page, you just connect those wires to those four ports and you're good and you can use GPS on your project and so we're gonna connect it up to your computer, your laptop so you can do some development with the GPS chip and I guess from the software side, these GPS chips come with little documentation that says how they report things and there's a spec called NMEA 0183 and it tells you the format and I'm not even gonna show this spec because I actually think that most people will kind of glean the basics just from seeing it. So you get this chip, you connect it to the computer, then you need some software in Elixir to talk to it and one of these is this library called NervzUART. So NervzUART has the C code that knows how to talk to the serial ports. So there's actually another one called Serial, so both of them work. So I'm gonna demo, well not exactly demo, I'm just gonna show you some slides of how this looks when you connect it up. So the way I normally, when I get a new device, I just wanna play around with it so I bring it up in IAX session with NervzUART. First thing is where is the device connected to your computer? So this is on Linux, so you call NervzUART a numerator and you get that one UART connected on TTY USB zero and it gives a couple descriptions on it. If you're on Windows then you'll get like com five or com six and Mac, this is really helpful because you get some TTYCU dot blah, blah, blah, blah and it's really long and easy to make a mistake to type in, but you can enumerate them, figure out which one is the right one. If you actually go into producing devices you can set a lot of those fields so that your program can look through and pick the right one. So that's kind of neat. So the next thing is we're gonna open it up. So the first thing to do is to start the NervzUART gen server and then open. So there are a couple parameters open. Well, what are you gonna open? TTY USB zero is just like we showed in the last slide. Serial ports all have speeds. So those of you from the modem days, we're back at 9600 bot and we're okay with that because GPS only updates so quickly, so it's not a problem. Last parameter is called is whether you want active mode or not. So active mode is a NervzUART feature. There are two ways of working with devices. So one's passive mode. So passive mode you write out and then you call read to get more data. And the reason why passive mode is interesting is sometimes you just want to set a configuration on the serial port and be done with it so it's kind of nice to have that inline code to where you write read directly. The other interesting part is when you get into flow control, if you don't call read, the serial port eventually turns on flow control and stops the sender from sending you new stuff. The alternative mode is active mode, which you still send the same way, but when you receive stuff, you receive it in messages. So let's just see what happens. So connect it up to GPS, call read, and we'll get back a big string of all the stuff that the GPS chip sent. And I fully didn't take it apart, but if you stare at it long enough, you can kind of glean some slash r slash ns. So it sends you stuff that's line-based and then there are a bunch of commas. So I think if you're thinking that this is CSV, that's pretty close to it. So anyway, start there, start seeing stuff, and you're like, okay, well, let me try to integrate this into my app. So I know in my app, I'm gonna make some gen server and I wanna receive events whenever the GPS reports a new position. So this passive mode stuff, this was one mile, but let's switch to active mode. So let's just see what happens there. So you switch to active mode, and then all of a sudden, you look at what messages you get, and then you're like, oh shoot, I got a message for each character. And first time you see this, it might not be obvious what happened, but at 9,600 bars, your computer's doing a lot of waiting. So it gets a bite in, then a few billion cycles go by, then it gets the next bite. So you end up getting messages one at a time, which is kind of annoying, since you kind of have to accumulate things, but it's actually worse than that because you're not guaranteed to get one by the time, you could get two, you could get any number. So there's a process with Nerf UART, so it can accumulate things and give you the messages from the device in nice little chunks that are easy to parse so you don't have to aggregate the data on your end. I think that this is one of the things if you've actually implemented this, it's a little trickier than it seems on First Blush, so anyway, with Nerf UART, there's a behavior, you can implement behavior for how this framing is set up, but for so many devices, things are line-based, so there's a built-in one, and you just specify that, and you say that the separator slash r slash n, like we saw, and then you get what you'd expect, all the nice little lines with the messages, and then for those of you who may not know what they have never seen, the 0183 stuff, you basically get a short little code, like GPGGA, to tell you where you're at, and if I let the GPS go a little bit longer, it'd give a little bit more interesting data there and you'd pull out your latitude and longitude. So that's actually where I stopped with this because I thought that for most of you unbundling CSV data was sort of bread and butter, but getting the actual data was perhaps the harder part. So if you're interested in hooking GPS's up, maybe if you're working with them on a project, this will get you started. There is a library out there that someone wrote that decodes these messages that you get into nice little latitude, longitude, velocity, and all the other nice things that you can get from the GPS satellites and chips. It's called XGPS and it's on hex. So what else, what else can you do? I think this is an age test. So by the last, I hope some of you saw this, so otherwise I'm feeling kind of old. Good, good. So ATTT, so those of us who lived before internet days, the way we would connect to other computers is through modem and we type in ATTT, so that was dial and we had seven digit phone numbers back in the old days, so we type that in. And actually if you, so this is digital, I had to do pulse, so even more embarrassing. So the reason, why do I say this? It's because the whole AT command set is in tons and tons of chips. And you will see this if you want to use any of these. So Bluetooth cellular cell light. So if you have a project where you want to communicate with my locally or even if you're on a boat or something, you have to go to a cell light because you don't, or you're someplace where you're really remote or if you just have some data collection app where you wanted to report in via cellular. Well, you can use Nerf UR to connect to that device over your base connection and you type, well, your program type, AT, and then you can look at the specs for that or what commands you might want to send. It's very useful, so, and it's very easy to use. And the reason why I point this out is even if you're not going to deploy this on your laptop, you can do all the development on your laptop. And I think that's very important, especially if you're new to the field, is to stay on your laptop as long as you can, get some of the kinks worked out or maybe feel a little bit more comfortable and then move on to nerves or move on to a Raspberry Pi so that you're incrementally getting more familiar with this kind of business. So the next thing I want to point out was just the gym that's out there that you can do, which sometimes I feel it's a little silly but I wanted to explain why it's not. So that's connecting to an Arduino. So you can just get any Arduino, plug in USB to your computer, and it can talk over the serial port. It actually makes a virtual serial port, so it's accessible and there's your art. If you install, if you go through the Arduino IDE, there's this thing called Formata. And Formata is just a simple protocol to let you remote control your Arduino. What's neat about that is that when you can remote control your Arduino from Elixir, you can access all these IOs and shields and everything in the Arduino ecosystem on your laptop. So if you're interested in doing this, we actually have a Formata library in Elixir. It's there, it's kind of sad right now because it's looking for a maintainer, but it's actually quite convenient to use this and I would encourage anyone to step in and help out with this. I know I certainly will be helping out a little bit in the near term to get to a place so it's more convenient to others, but it would be nice to get this going more. And I need to mention this because I have another talk that I give on how do you architect nerve space systems or actually any embedded Linux system. And this is one of the takeaway slides that's for a lot of embedded. So these are special purpose devices. You have a bigger, fancier processor, an ARM chip or MIPS or x86 that handles all your web, you know, the web page, the GUI, command and control. There's all this other infrastructure that handles. So you have it right here and you're running on Elixir so it's all software real-time. And then you have a micro controller off to the side that handles the hard real-time pieces. And the reason you do that is because developing hard real-time pieces, even though they're very simple, maybe they have these short deadlines and they need to work predictably, it's a lot easier to think about their correctness and test their performance out in the context of a nice little chip where it's unencumbered by all these other pieces of software running right next to it. And I mean, you're not worrying about Linux interrupts somehow making this thing go, you know, get delayed by a fraction of a microsecond would end up causing a hiccup on your device. So you have this setup where you have the two processors and you communicate between them via like a UR connection. Actually, there are a lot of other buses that you can use but since we're talking about URs, I put that one there and it's not uncommon to see that. So that hooking up that Arduino to your laptop is totally a real thing. It's that has analogs in professional embed devices. All right, so we've gone through the main routes. So how do they compare? What's the summary here for when you should use one or the other? Now the, so if you're using, so the first step is where are you doing your development? So laptop, Nerfs, you are, you know, you're on your PC or your laptop and then I call a host. If you're on Nerfs or the desktop Linux, the target's involved. So Nerfs has a hybrid approach where there's both you're doing some work on your laptop and the tipping over firmware to the target and then the desktop Linux one is basically, you work directly on the target like it's your own little computer. Other things to consider, so really the performance and the amount of this space really matters when you're developing on the device. So the desktop, the Raspberry Pi's, you kinda wanna make sure that they're fast enough for those of you who have worked on them. If you get like the original Raspberry Pi and you start doing too much stuff on it, you, it gets a little frustrating. And if you're compiling Erlang or Elixir on some of these devices that I've used, the compile times are like half a day or a day. So it's kind of painful. So get one that's fast and don't put yourself in this pain. And if you want to work on a Raspberry or if you eventually want to use a Raspberry Pi zero, maybe do some early work on Raspberry Pi three, right? So this, it's a little faster. Support devices, this is where it gets into what you can hook up. So obviously on, if you're using your laptop, it's whatever goes over your, but the other two nerves in desktop Linux are pretty much just limited by what's on the board, whereas if you start out with the desktop Linux or Raspbian, all the drivers are included. So often I start out there. And I, you know, if I don't know what I'm doing, I start out there, then I kind of see like, what are the pieces that I didn't know existed that I'm using? And when I get that list, then I add them to my nerves configuration. That makes things a lot easier because you can do everything on nerves, you just need to know what you need to add. Let's see. A couple other things, the tools, well, you can read as well as I can. Deployment, I think deployment's interesting when you get into production, or you want to start sharing this with a lot of people and the things get easier as you get to, as you get to nerves. I think this is one area where we focus a lot on. Fortunately, not everything's open sourced yet, but being able to send around small packages that have the code that runs on the device is quite nice and things update a lot more quickly and that you can do things like sign the packages and that's so that if you're concerned about someone mucking with your firmware, midstream, you can do stuff like that, whereas the others, it's not quite as obvious how you do it and things are a little bit slower. So I guess the key thing is when do I use this? And I use all three, like I said in the beginning and I highly encourage all of you not to think that I want to do Elixir and I want to connect the hardware. No matter how much I want you to go to NERS because this is really a fun project for me, that's not always the right answer. So check with yourself. If you can do something on your laptop through a UART, if I wanted to use USB to serial cables, it's actually quite nice experience. I actually find myself when I can, when I have some setup that's similar to that, doing a lot of development there. The desktop Linux one, if you have a lot of confusion with NERVS, go there, see how Dubbian or Raspbian or whatever the operating system or the board vendor did, how they solved the problem. Usually it's a lot simpler than you think, but when you don't know what you're doing, it's nice to check in. And so then the last one, NERVS when you want to do this for real, or there are actually quite a few cases where NERVS actually makes some things easier, so you might go to the laptop, you might skip over the middle one and go straight to NERVS. But that's a gist, that's how I look at it. And if you want to find out more about the two projects that I talked mostly about, the NERVS UART and NLXRL, those are, they're on GitHub, of course, and they're also on Hex, so you can find them there. On Twitter, you can find me there at FunLift and at, I'm at NERVS Project too, so NERVS Project, of course, is central to NERVS, but we certainly cover a lot of other things that are of interest in general. The Lixerlang Slack has, I think, become the de facto channel to go to on Slack if you want to do anything embedded. There are other channels, but there are actually quite a few people that answer questions, embedded questions, so it's really cool that if you need a little bit of help there, you can go there. And of course, if you're doing something professionally and you get stuck or just want to have a little bit of help, feel free to contact me. This is what I do to keep this hobby and this project going, so it always makes me happy to help someone else put this into production, so you can email me there. So that's what I got, and I think we're out of time, but I'll take questions afterwards, I'll be around.