 Let's get started. You're all here because some of you might have or might want to start developing on some new hardware. Most of you would be probably familiar with this kind of stuff, debugging with a debugger. I guess all of you who have debugged an embedded system have also done something with JTAG on debugging the hardware with that or the software with that. I'm not really going to talk about that because I assume that you're really familiar with that. You're doing that every day. But what I'm talking about is what if you're getting new hardware, something that has never run before, something that no one has ever booted up before. How are you going to verify that the hardware is working and get the software running while you don't even know that the software is correct? Or how do you know that the software is working when you don't even know that the hardware is running? A lot of people do this style when they're doing the software bring up. You have it on your table, connected to computers, serial output and everything and try to figure out whether it does what you're thinking it should do. But sometimes the serial output isn't really working and you go back one level and connect your oscilloscope and try to figure out whether it does what it's really doing or should be doing. If you're here to learn about electronics, I must disappoint you. I'm not going to teach you that it's not possible within just half an hour. If you want to hear about that, you can invite me to a conference. I do a half day full day talk on that and you will learn about electronics all the way down to the electrons. What I might be teaching here you is a couple of tricks and techniques or actually more the tools how to use these techniques on how to debug hardware the first time you're getting it and you don't know what it's doing. If you want to learn about electronics, get this book. It's the Bible. It's better than any other book on electronics I know. No. But believe me, this book is worth learning German for. Only just for the book. It's a thousand day challenge pages in the current edition and it contains everything you ever want to know about electronics. Every German electronics engineer has this book. One at work and one at home at least. And people like me own about five copies of it. Just a little remark. I will be naming a couple of products and companies during this talk. I'm not endorsing their use. I'm not working for them and I don't get any money from them for managing. If anyone from these companies is here, I would like to get some samples or borrow some of these devices for a longer time if possible. So the most basic instrument you will need and I tell you will really need that is a multimeter. For electronics, if you're not doing real hardware but just a software side, it doesn't need to be a fancy one. It doesn't need to be a fluke. Definitely not. You don't spend your whole month's salary on it. 50 Euro multimeter is enough for what you do. What you have to look for is that it covers in voltage and current the range you will need. Most probably the upper range what you need is 20, 30 volts for normal electronics. If you're dealing with mains, 400 volts at least. In current, usually you are below one ampere most of the time. 10 amps is more than enough for everything you will need. On the lower end, make sure you can measure down to one milliamp better than micro amps or so. And also something that is very important is this little symbol at the bottom, this diode. Most people don't use it but it's the most, single most important measurement you will need as a software engineer on the multimeter. Because that measures the diode voltage on... I'll talk about it later. You will see why. The other most important instrument you will ever see is the oscilloscope. Mostly because electronics guys will have it. And mostly because with that you can debug timing. Timing of signals when they happen, why they happen. The oscilloscopes you will be needing will not be expensive ones if you need one actually. But I still encourage you to use one of the big three. Tectronics, Agilent, LeCouar. Because if you choose one of the, let's say Chinese ones, you might be measuring things or seeing things on the display that are not happening actually. Or you are never actually sure what you're seeing is actually happening or you're measuring something out of thin air. And at least the low end techs in Netherlands are quite cheap these days. You can buy them for from $1000 up. It does not need to be a high end one. Usually a couple of megahertz is enough. As a rule of thumb, the analog bandwidth should be about five to ten times higher than the highest digital frequency you are measuring. And the sampling rate should be at least five times higher than the analog bandwidth. That's actually something that the Chinese ones always trade off a bit. They have a higher analog bandwidth but the very low sampling rate. Within the Nyquist limit, but Nyquist limit says basically you have to have twice the sampling rate than the signal you have. But that applies only for purely sinusoidal signals, which we don't have. Digital signals have very, very high harmonics. That means the spectrum goes five, ten, hundred times higher than the actual signal frequency. But you need those to see the square waveform. If you don't have these harmonics, you're seeing anything but the signal. And if you want to see what the signal you have on the wire is correct, you will need this high bandwidth. So for a 10 megahertz signal, which is what you will probably see on an SD card, 10 to 20 megahertz, you will need about 10 to 200 megahertz of analog bandwidth and about one gigahertz, one giga-samples per second. The 2024 tectonics we have here is one that is available in that range. I think it costs about $2,000 or so, or $1,500, not quite sure. If you need an oscilloscope, get your company to buy one of these. It's really worth it. Don't go for regal if you can't avoid it. If you're a hobbyist, well, you can go for regal, but I would advise you to save up a little money, buy it a little bit later, and go for tech or natural and instead. It really, really helps if you can trust your measurement system that it really does what you think it does. In recent years, we have seen this kind of oscilloscope, pure USB-based ones. I have not yet had much exposure to these. They look cool. The specs are usually nice. Chinese ones aren't available, so I guess the engineering is good on them. But here also, please pay a little bit more money to get a better one than save money, because it's really worth it to know what your measurement system is doing. The other oscilloscope kind of thing is the logic analyzer. If you've been in Matt's talk yesterday on Sigrock, you might have seen a couple of presentations on that. This one is probably the thing you will be using most, because with that you can analyze what your signal is doing, when it's doing and how it's doing, and it conforms to your software. And unlike those oscilloscopes, you can measure over a very, very long period. Getting samples over a second or two seconds with high resolution is easily possible with logic analyzers, but it's not possible with an oscilloscope if you don't spend 10,000, 20,000 for your oscilloscope. If you are going expensive, you can buy one of these. This nice baby costs about 15,000. It is an oscilloscope with a 16-signal logic analyzer attached to it. The big advantage of it is that you can measure or you can trigger the analog system by the logic analyzer and vice versa, so you can correlate what your system is doing, the digital system with your analog system. And that's really helpful if you have a sensor generating interrupts, and you want to see that the readout of the sensor really works as it is supposed to work. If you are going the cheap way, the OpenBench logic sniffer is available for about 50 bucks. Nice little thing, I must say, works 99% of the time if the software works. The software that comes with it does not anymore. Z-Grog is much better choice for it. So if you get one of these, get Z-Grog instead of the open logic sniffer, and save you a lot of time. I have one of those and I use it often for work because it just works. For most of the stuff I'm doing, it's a fine thing. A little bit more fancy is this one here, this costs, if I'm not mistaken, 200 euros. It has more pins. The sampling factor is also with 20 megahertz, quite fine, but the software support is much better than Z-Grog can do, but only available for Windows. Otherwise, great thing, just works out of the box, no fiddling with anything. It works. How many people of you have worked on USB devices? How many of you have hated not being able to see what's going on in the bus? Good. This is the thing you need. Yes. Total phase is, from the Linux support, great. They develop the system, the whole software in a way that is portable between Windows and Linux, and they do regular updates. If you buy the hardware, you get more or less indefinitely the software support. This one here costs $1,500. It's the bigger one of three, the middle one. It does high speed USB. There's one that does only full speed and low speed, but I recommend you, if you have the money, get this one, because it has one big advantage over the other, the small one. It has signal beside the USB input output. It has four input and four digital output pins, with which you can measure timing. I had to bring up a complete USB stack on a CPU that was not fully supported yet, and figuring out why something is not working all the time is very, very tedious when you have the suspicion that it might be a race condition. It turned out it was a race condition in hardware, and the only way you figure that out is when you can get the timing information from your CPU to your GPIO pin, somehow out, and into the USB system to correlate it with the packets. As I said, the software is available for Linux, works, I never had problem with it. Same thing on Windows. Well, Windows, you wouldn't do it because Windows generally cannot keep up with the high data rate this one generates, so we don't want to use it there. One very, very important instrument most of the people forget is a bench power supply. I've seen a lot of people struggling with getting their hardware working and seeing weird, weird stuff going on until they figured out that what is happening is that the power supply was not good enough. And there's also a reason why I put here an HP or these days Agilent power supply, get one that is good. They cost money, a damn lot of money, but it's worth it. This one here is so stable you can do with that high frequency electronics and it will keep your power supply stable enough for it to work. Cheaper ones like one that Konrad sold a couple of years ago can actually fry your electronics. We had one that creates a 40 volt spike on the output each time you switch it on and off. Your electronics might survive a couple of times, but it will degrade over time and at some point in time it will stop working, you don't know why. Please, get a good one, it's worth it. So we have learned what kind of tools we have. Now the big problem is how to apply them. Unfortunately, when I wrote for the first suggested talk, yeah, that's easy, there are just a couple of things you should keep in mind and it's all easy, five minutes to explain that. And then I figured out, well, no, for someone who knows electronics, it's easy, yes. But for someone who does not, it's not so easy. So I'm going to pick here just two cases that are most common in the case of developing or bringing up new hardware and not mentioning the whole rest. If you have something that doesn't work correctly with your board and you can't figure out what to measure, please contact your hardware guy. There are enough people around, even for the hobbyists, that know electronics. You can find them at least in most embedded Linux channels that can help you getting that done. Otherwise, get the teacher's shank, the book I mentioned before. It's worth it. It explains you how to do things. The first thing to get hardware running is actually get one of these. It doesn't have to be a Beaglebone. It should be more the one evolution kit that the CPU you're using with, working with. Because if you're starting your software, running in a hardware that you know is going to work is a big plus. If you don't know that the hardware is working and you try to get your booting system running, I've done it. It's a pain. It's a big pain. Also, make your hardware guy, whether you have a say in the development, stay close to the evaluation board. It really, really helps if you have the evaluation board to go back to to try your software and figure out whether the things you are seeing is the software not working correctly or the hardware having a small flaw somewhere that is hard to debug. Get also a couple of the evaluation boards to modify. Your system will always have modifications be different than the one you're using on the evaluation board. But an evaluation board is to be messed with. Solve the thing out. Solve the new things in. Get it working the way your product should be working. It will really help you to get later the software done. The next thing you should be getting is this. The datasheet of the processor of the important components of your system. I know most of you should know that, but in the embedded linux channels I'm in, it's mostly really a problem that most people just don't read them. Everything you need to know about your processor, how to access the IO pins, what resolution the video output can support, it's written in there. Please read it. I know the datasheets these days are intimidating. Modern SOC has probably some reference manual range of 1000 to 3000 pages. At least game over it that you know what's written in that. These are also mostly split into the reference manual and the datasheet with the reference manual being a general overview how to work with it in the software side and the datasheet usually containing the pins of the package and the electrical specifications. But the border where the line where they cut it, what is reference and what is datasheet is not always clear. So please look to the datasheet as well. There might be some information in there that you as a software engineer might be needing. The other thing you will need is this guy here. The schematics. How many of you can read schematics? Good. How many of you can't? Okay, I'll teach you later. No, really. The schematics is usually easy to read. There are very few things you need to know as software engineer. Your hardware guy can teach you that what you need to know in five minutes. And this thing contains all the connections you need to know to be able to configure your hardware correctly through the software. It doesn't take much time to read it, so please refer to it. For people who are working with the Beaglebone, Minnow board or whatever is out there, please have a look at it. If you don't know what pin you're working with, the schematics tells you. You don't have to look at the layout. Please don't look at the layout. Following traces there is... No, just don't do it. The next step of getting the board working is visual inspection. This here is a section of a board from a well-known US company that is quite known in the BSD world. These are the three of the SD RAM chips. I have marked here on one the power supply and the ground pins. Who can tell me what's wrong with this picture? Yes, exactly. We have here around each chip four decoupling capacitors. Yes, it's actually two because they are shared between the chips. We have eight power supply pins. Rule of thumb in electronics is that for each power input pin you have, you have to have one decoupling capacitor. And for SD RAM chips like these that can draw up to two or three amps in a short time period, this is not going to work. If you ever see something like this, please take something heavy, maybe in the range of a piano and drop it on your hardware guy. This is really the most annoying thing you can ever have because in 80-90% of the case it will work. And then you do something that is slightly different, just add a line of code of something and it will create data corruption. The things you have to look out is, as you see here, there are not enough decoupling capacitors and things like this where two of the power pins are going to the same via and to the power plane. Yes, it's really horrible. The guy who did this design, I told him that this is the reason why he crashes off the design of the board, told me it's a bug in the Linux kernel. The driver for the network interface isn't working correctly. Yeah, right. I fixed it with a soldering iron. What actually happens there is this is a simplified one of a switching system where we switch on a load and here see this is the voltage on the load and this is the current through it. What you see here is at the time you switch on, there's a huge oscillation due to the capacitance and inductance to every electrical system. You will see that each and every time everywhere, whatever you do, if it's slow, if it's fast, you'll see that. What matters is actually if you can keep that low enough that it does not interfere with your electronics. The SD ramps I have here are inherently analog components. They are not digital. We measure the voltage of a capacitor to determine whether it's a 1 or 0 and the difference we are measuring between 1 and 0 are one-tenth, two-tenth of a volt. So if your power supply is dropping half a volt because of the switching of the output pins, your measurement is going anywhere but to be correct. So please keep an eye on that. If you have a guide or something like that, you know what you need to do. Next step in getting your system running, get a power supply band and two multimeters. What you're doing is you program the power supply that it will deliver the correct voltage and a maximum current you expect the board to use. Give it another 10% so that the inrush current at startup is handled but limit it so that if you have a short circuit that the board will not get fried. The multimeters are for the measuring of the current and the voltage on the board because you don't trust what the power supply is giving you. The multimeter is always more accurate even if it's not calibrated. When you have power applied and nothing smokes, yes, it happens more often than you think. Measure all voltages on the board. You will always have these days two, three, four, five different voltage rails. Measure them and ensure that they are correct. If you have an oscilloscope, please also measure them on the scope to see whether they are stable. If you see something like this, go back to your hardware guy and tell him that his power supply system is not stable. This happens very often and it's usually... I can't say it's due to bad design but it's starting from an assumption that is not really true and it happens more often than you think. That's why a good hardware guy on the first bring up will measure power supplies to ensure that you have a stable enough power supply to power your system. I couldn't find a better picture. I was talking about diodes before. This picture shows you the standard in 99.9% of all chips, how pins are connected, both input and output. Here is the pin of the chip and here we have the internal electronics of the chip. At the pin you have two diodes, one connected to the power supply and one connected to ground. The reason for this is to protect the electronics from too high and too low voltage to ensure that the device always properly works. If the diodes wouldn't be there, a small spike going below or above the power rails could fry up your electronics forever. And these diodes are the ones that help us to actually ensure or determine whether the part is correctly soldered. With modern BGA cases where you have a lot of pins that you cannot see anymore, this is what you should use if you want to verify that your board is correctly soldered. What you do is you take your multimeter, set it onto the diode mode and measure the diode going to the positive power rail and the negative power rail and ensure that you have around 0.3 to 0.7V of diode voltage. If it's considerably more or less than that, then something is wrong. Most probably a bad solder joint. Give it back to your hardware guy. Let him figure out what is wrong and give it back to you then. If you cannot ensure that your software will do anything about what you want, you measure it to the power rail. You measure it always between the pin and power rail or ground. In this case, this one would be the pin itself and this here would be the positive power rail. Other questions? Yes, clamp diodes. They clamp the input voltage or output voltage to the power rails. This is a picture that Russ gave me a day or two ago. I put it in because it's really nice. It shows how bring up usually works. We have here the device itself with cables going to a peak-based miniature oscilloscope to measure, I think it was SPI. SPI was. And to see the signals. This is probably the thing you will be doing most with electronics debugging in the software world because you're usually interacting with the outside world through some pins, through some signal, accessing a bus, SPI, I2C, SD card or whatever and want to know where it's functioning correctly. The way to do this is, for example, to use a logic analyzer. That's the one I would recommend as long as you're sure that the signal looks correct from the electrical point of view. Go to a logic analyzer, put it in, check whether what you're expecting on the pins is actually there. I've seen a lot of software being written and not correctly working, like accessing SPI APROM that works most of the time but sometimes it just didn't do. What happened was that two of the bytes were swapped in the protocol and from software you can't see that. It's just writing to registers but here you actually have the signals and with the protocol decoder you see that what's going on and you can check with the datasheet of your device but that is the correct way to interact with that. Another very neat thing is that's one of my devices I had half a year ago we were measuring, we got an interrupt from an outside system and had to power up then a sensor and measure continuously from that sensor and something didn't quite add up in the measurements we got and it was very weird, it half worked and half didn't. What it was is we got the measurements here and somehow in this little place we got a gap of 100 microseconds where it didn't measure. Finding this out with pure software means no way. What it was actually is that we had a priority inversion on some interrupts and a lower priority interrupt interrupts us in the measurement there and mess up with it. I've given you a small overview of how to debug software how to interact with the hardware and what to drop on your hardware guy if he's not doing what he's supposed to do. Do you have any questions on this? Yes please. Not stable enough. These power supplies are meant to power a motherboard or hard drive that have additional power conversion units on it and they stabilize the instable power supply a lot more. Additionally, PC power supplies have a minimum power rating which means you have to draw a certain current out of them for them to be able to work correctly and with today's 400, 500 watts supplies you have to draw at least 10, 20, 40 watts or out of them and waste it somewhere so you have halfway stable output. If you can't get to do that your output is anything between 0 and 12 volt and fries your electronics and doesn't work on the power supply, please. It's worth it. If you are in the States, actually you can get this for 100 dollars. In Europe they're a little bit more expensive. Used ones go for 500 euros or so. Yes. Depends on what I'm measuring. Most of the time I use the internal frequency reference of the oscilloscope or the logic analyzer because for my things that's stable enough if it's off by 1% which is really, really a lot for these things I don't care. If I have to do high precision measurement of the clock or something I usually have frequency references give me a 10 MHz signal calibrate my oscilloscope with that and then go to measure my signal. If you need this kind of precision go on eBay, buy one of the rubidium standards that are available for about 100 dollars and you're done. Yes, you can also buy GPS but please buy something like a thunderbolt or one from Jackson Labs one of the furries because the usual GPS frequency thing is that you can buy that are not timing the references will output directly what your GPS system is generating and that fluctuates a lot it fluctuates with every fix it gets so if you really want to have a stable frequency get one of these GPS DOs GPS Discipline Oscillators that keep the frequencies stable they don't fluctuate with every fix they average over multiple fixes to keep the frequencies stable. Yes. I found an interesting one that I found a couple of years ago with plugable devices that you don't realize that if you're plugging something in that has its own power supply it may not be at the same ground level and what happened was when you plugged it together it crashed because the ground caused a current flow into the board that caused the power supply to bounce. Yes, grounding is the bane of all electronics actually. Usually for the things we do it does not matter because our systems are compact. If you're doing something on a bench that is distributed over a meter so you have to be careful about that you don't have any ground loops. I recommend there a book called The Circuit Designers Handbook I think or the Secret Designers Guide I'm not sure. It has a whole chapter on grounding and how to do it properly. The thing is you should really get your hardware guide to have a look at grounding before you do software because it's easy to mess up there even with small things. Yeah, I know. I've built devices. I've done that myself. I mean built something then realized that the ground is not working correctly and fixing that is pretty hard. I have what? I don't know. Yes. Because I grounded it. So that is like... That's actually something you have to keep in mind if you're doing measurement with oscilloscope as well. The ground of your probes is connected. So if you're having two probes on different devices connect them over the oscilloscope so we have to ensure that the ground level of both is the same. Not only DC, but also with high frequency because if you have anything that runs with 100 MHz you will have high frequency components on your power supply and they will travel on this ground loop. Any other questions? Good. Thank you for coming. Enjoy your last hour here in Edinburgh and have a nice day.