Embedded - 180: Chickens in Helmets

Episode Date: December 20, 2016

Have you ever wondered how your programming tool works? Piotr Esden-Tempski and Gareth McMullin have built the Black Magic Probe and joined the show to explain how it works. Kickstarter for Black Magic and 1Bitsy ends December 29th. If you missed it (or need a Black Magic v2 instead of waiting for v2.1) go to the 1BitSquared Store. For more in-depth information about Black Magic, look at Gareth's github repo. For more information about the 1Bitsey dev board, look at 1bitsy.org.  Contest! Tweet to @1bitsquared. The YouTube channel about electronic teardowns was Mike's Electric Stuff: youtube.com/user/mikeselectricstuff. If you want to say other hellos to Piotr, try his personal account: @esden. Or you can contact Gareth via Black Magic's Gitter channel.  Embedded.fm Hats-n-Hacks party will be 2-5pm on Saturday, January 28, 2017 in Aptos, CA. More details soon, including how to RSVP.

Hello and welcome to Embedded. I'm Elysia White here with Christopher White. Our guests this week are Peter Esden-Temsky and Gareth McMullen. They're going to talk to us about programmers. Not human programmers, JTAGs, SWD, and black magic. Before we get to them, I would like to remind you that we are having a party! January 28th, the last Saturday in January in 2017, which is like a month away, you know. It's going to be in Aptos. It's in California, because that's where Aptos is. Something like 2 to 5 p.m.

Bring a hat or a hack or both. More details and RSVP instructions after the new year. Good afternoon, gentlemen. Thanks for joining the show. Hi, nice to be here. Hi, thank you for having us. So we do have two guests. So we're going to have to unravel your names a little bit.

Peter, why don't you start? Tell us a little of different projects. And I have founded the company called One Bit Squared, where we make UAV autopilots. And because of this, we also use development tools for embedded programming, because a lot of UAV stuff uses embedded hardware. And this is why I started working with Gareth. Okay, Gareth, that seems like a great handoff. Your turn. Hi, I'm Gareth McMullen. I'm an electronic firmware engineer.

I have been using open source software for a very long time now. And I'm the founder of the Blackmagic Debug Pro project and that's what we're here to talk about Yes, and I think it's really cool because we're going to talk about that device you buy that goes between you and your processor because there's a lot that goes in that What doesn't go between you and your processor? Between your computer and your processor

Me and my computer are one that. It doesn't go between you and your processor. Between your computer and your processor. Me and my computer are one. Before we do that, we want to do lightning round. And for those of you new to the show, this is

where we ask our guests short questions and we want short answers. And if everybody is behaving perfectly, which never happens, this all goes very

fast and we don't ask for why and how and all of that. Are we going to ask them both to answer all goes very fast, and we don't ask for why and how and all of that. Are we going to ask them both to answer all questions? No, just choose randomly. You got to keep them off the, you know, on their toes. Get them all ready. All right.

Go ahead. No. All right. Gareth, hacking, making, tinkering, or engineering? Engineering. Favorite embedded compiler? GCC. Peter?

GCC. Fair enough. What is the worst formal version control system you've both ever used? Oh, I can definitely answer that. CVS, or before that, R rcs i heard that is even worse yeah cvs is the worst i've actually used um i was instructed by an employer to use pvcs but i never actually did it uh do either of you or both of you have a tip or a trick that you think everyone should know so um i i actually think one of the very interesting tricks is that a lot of people don't know about it's like something that gdb can do is at least on on pcs is the rewind command so basically you can travel

back in time, which is a pretty cool feature. If you look into it, you will realize how powerful that tool is. I didn't know about that. It's something to try. Favorite fictional computer? Fictional computer?

Well, I think that is an easy answer. It's HAL, I guess. All right. That's a pretty wicked computer. Gareth Rebottle. R2-D2. All right. We'll take that. Let's see.

What language do you think should be taught in the first university course that teaches programming? I would say just to be a little bit cheeky is Common Lisp because everyone should learn a lisp in their lifetime. Took me forever to get rid of a lisp. Gareth? I've got mixed feelings on this, but since I have to pull one out of a hat,

I'll go with Python. Safe answer. Yeah. What science fiction technology or concept do you think will be real in our lifetime? So I think, and someone said that on this podcast before, I think the synthesizers is uh it's a reasonably safe bet because of all the 3d printing technology and it's actually going forward quite quickly yeah replicator units yeah okay gareth i don't have an answer fine cause favorite serial protocol gdb Serial protocol. GDB.

I'm not sure that's a serial protocol. Yeah, protocol maybe, but yeah. I think SPI is quite awesome because it's quick. Okay. We're getting, now lightning round's over. It's over. It's just over. How is GDB a serial protocol? Maybe I should have cleared that up.

It's the GDB Extended Remote Protocol, which is what the Blackmagic probe speaks to GDB. See, I suspected this was on topic. Okay, so tell me about Blackmagic as a whole, as though I had never heard of it and had only ever used J-Link in my life. So maybe, Garrett, yeah, you answer that one. So the Blackmagic Probe is a hardware device. It connects to your computer on the USB port and connects to an embedded microcontroller on a JTAG interface. And it does protocol translation between GDB's protocol and JTAG protocol to allow you to debug an embedded processor. It allows you to interrupt the program, inspect the internal

state of the microcontroller, resume it if you want, and if you want to modify the state, inspect the internal state of the microcontroller, resume it if you want, and if you want to modify the state, you can do. And so this is beyond the embed style, plug it into USB, pull over the executable, have it flash program itself, and then try to use printf to debug. This is an actual debugger as well as Flash programmer. Yes. It can be used as a Flash programmer,

but that's its secondary function. Its primary purpose is a debug interface. So to do interactive debugging, to start your process, interrupt it, inspect state, set a breakpoint, continue, see if the breakpoint's hit, get a backtrace. Those debugging functions are what it provides. So how is it different than my Jlink or Ulink or whatever link came with my board

or that I bought for $1,000. I would like to add something to what Gareth said here because besides being a main purpose, the debugging, to be fair, I actually, a lot of people use it as a programmer a lot because it's quite convenient and fast to do. And second of all, it's very reliable in that sense. And even though you can debug and write software with it.

Well, debuggers are advanced programmers. I mean, you often need a programmer in the manufacturing floor that just does the flash part, and so you end up with a whole bunch of them, and they're not as useful. But a debugger is more useful. So I can see why Gareth was emphasizing that. But it's good to know it does both.

Yeah, that's actually a very good point that you're making there, because I've seen quite a bunch of people actually using the Blackmagic probes on production lines because how they are priced and what they can do. And they actually do production testing while they are already flashing. So the debugging functionality is very useful because GDB can be scripted,

which makes it very nice for automated programming and testing in production. Wow. You can do much better unit tests that way. Okay, but we keep saying GDB, because that's all this works with. It doesn't work with my Kyle or my IR or my whatever the thing Microchip has or the Atmel Studio or any of the other things? I think, doesn't Atmel Studio have GDB support too? I'm not sure about that. I don't know. So let's put that one as a gray box. But yeah, I know what your point is.

Why is it only GDB? So maybe Gareth, you can answer that one. So when I started working on this, I first had used Microchip PIX, where I had a tool called the in-circuit debugger, but I never actually saw it able to do debugging. I was only able to put the program on and run it. I was a dumb programmer. At the time I started working on ARM, I was working on to put the program on and run it. I was a dumb programmer. At the time,

I started working on ARM. I was working on a bigger, more complicated program. The need to debug became important. At the time, I talked to my boss. I said, we need debugging tools for this. And we had a look around and you could buy IAR for $10,000 or something like that. And they said, no way, not going to happen. At the time, I started reading literature and seeing what was available. And I'd used GDB before on my computer. And there was a piece of the puzzle missing to connect the working GDB to the electronics. It made sense for me to use the free good debugger to do my embedded debugging. I already knew how to use it.

It was free and open source. There really wasn't an alternative that was free and open source at the time. There is now LLDB, which I haven't tried myself, but according to their documentation, LLDB also implements the GDB extended remote protocol, so it should work with Blackmagic Probe. So GDB makes a lot of sense because you can interface to it. And when you do IAR or Kyle or the expensive compilers, they have a different interface mechanism. Is that right?

I want to say yes. I don't know exactly what they have because... Because that's not what you work on. I didn't have $10,000 to throw at the problem and see what it was all about. What I do know is that how you interface with them involves actually talking to somebody there. There's no public open documentation on how to do this.

You also get a canned program, which you can run on Windows and can't look inside to see how it works. Those things are pretty big showstoppers for me. Yeah, there is. Yeah, I have to agree on that. But I actually looked into some of the protocols in the past because I had similar issues with the common programmers myself. And what happened is a lot of the protocols are reverse engineered. And you get programs like Open OCD did a reasonable job at

reverse engineering the protocols but it still is they don't have the documentation as Gareth says and the manufacturers I don't know from for what reasons they are trying actually to, I thought, sell silicon, not lock-in software, but they still don't document their stuff. And Blackmagic Probe opens that all up and just gets rid of the proprietary protocols as a middleman. Okay, OpenOCD. This is something I have come across before. I think anytime you name a protocol after a mental health condition, you are just signing yourself up for some pain and suffering. the hardware debugger programmer, and my compiler. And it's a software component. It's not the driver. The driver's lower level.

This is sort of middleware. So it's above the driver but sort of below my debugger, and it lets me step through things. OpenOCD has had some problems in the past for me because it isn't exactly stable on all of the platforms I tend to use. But that's okay. But you're not using OpenOCD. You have your Flash programmer and debugger, and you have a compiler, which is GCC, and you have the debugger, GDB. But you don't put OpenOCD in between them, right?

Yeah, that's correct. Yeah. Gareth, tell me more about whatOCD in between them, right? Yeah, that's correct. Gareth, tell me more about what you put in between them. So, well, you plug the Blackmagic probe in, your computer's USB stack provides all the drivers for you. It appears to your computer as a serial port. In vanilla GDB, unmodified, supports this extended remote serial protocol, and you just point it at the serial port. Vanilla GDB, unmodified, supports this extended remote serial protocol, and you just point it at the serial port, and it talks directly to the hardware. What OpenOCD does,

it's a computer application that does the protocol conversion between JTAG and your GDB serial protocol. What that does is include it in the Blackmagic Probe firmware. All that protocol translation happens on the device. You don't need extra middleman software to do the protocol conversion. So I don't need OpenOCD, which for me, I just yay because

while they've done a brilliant job, they've tried to support everything in the world. And since this is on a particular device, it doesn't have those problems. Yeah, they don't have also the capacity. It's like it's an exponential problem to test everything. So we can't really blame them for not being able to do that. But it only would work if the manufacturers of the probes

would actually say like, okay, we support actively this open source conglomerate to make everyone's life somewhat more easy. And we will test that actively and contribute to the project. But sadly, yeah, open source is a curse word in that world, I think. Sadly. Yeah. So you support GDB and how it works,

but you don't support all the other compilers. You also don't try to support every single processor in the world. You're focused on the Cortex-M. The whole M series or some subset? Yeah, it's Cortex-M, and there's alpha support for Cortex-A. And also what it does is we can try to test more stuff.

But Cortex-M is very well defined with the ARM debugger interface version 5. It's quite well defined. I think Gareth can tell more technical details to that yes so what we have is the cortex m core is completely supported um that allows you to load programs into ram and gives you all the debug functions there are each or each vendor has their own implementation of flash memory. For that, we need a specific driver for each vendor's device. We have quite a lot of them. We definitely don't have all of them.

Can you name some of the big ones you have? I mean, I remember seeing ST on there. We have STM32, a lot of STM32s. We have a lot of Atmel SAM 3 and 4 and atmel sam d we have we can make them look it on the website it's fine we don't have to list all of them i can find a list for you they're not in my head yeah i have i have a nice uh graphic on the project here it's like we have st atmel nordic nxp ti free scale silicon labs at the moment so nordic nordic is not just the cortex m it it has uh all of these other peripherals yeah but that's the registers that you have it's uh usually they what they do it Nordic is radios, right? Yeah. Usually what they do, they put the core inside next to a radio chip,

and they have some interface that they interact with, or they have memory-mapped registers that is handled as normal memory for the Blackmagic probe. So as long as we support the flash and and the actual debug interface and that all looks very very much the same but your registers i have to look up the register maps and make my own register variable so that i can say you art receive register and be able to type that in instead of the number. Is that right?

Yeah, that's right. But what happens is this is actually a very good point. So there is a big division here where you have GDB is actually concerned with the part of where stuff is. So if you compile with GCC a program, it generates an ELF file, and GDB or GCC has a parameter called minus G. And with that, you add symbols to the ELF file. So the binary itself carries also all the symbols that you added to the program, like variable where they are. And so you can just load that ELF file in GDB. And you can then say, print me the content of variable X. And it finds that symbol inside the ELF file and it knows where it is in memory.

So it can access it over JTAG. So Blackmagic Probe itself, it's not concerned with that part. It's GDB's part to know where things are. And so if you have, so I was, I am also involved in this project, LipOpenCM3, which cm3 which creates this tables of where the registers are and functions to act with on the on the peripherals and the hardware parts so this is the responsibility of a library to actually define where where stuff is so again a black magic probe is just transferring the the commands that GDB generates to the target and reads the memory or writes it. Now that health file with the symbol table, that's not something you have to download to the target. That can be separate to be loaded within GDB. That's correct, yeah.

So that's why you have hex files or binary files that have no indication. But in case of Blackmagic Probe, because you use GDB, the modus operandi is opening GDB with the ELF file as a parameter to it. And the ELF file has the symbols already. So when you issue the load command in GDB, it flashes the memory or loads it into ram but it also knows where the symbols are when you then immediately go into debug mode if mode if you want to okay so i i did forget to actually say you have a kickstarter and we should go back to that now

before we get deeper into how jtag and swd works because i have some questions about that but tell me about your kickstarter so uh i have at some point like about a year ago so so far gareth was the one who was developing black magic probe and making the hardware for it and writing all the software for it. And about a year ago, I offered Gareth help to take over the hardware development and manufacturing so that we can bring it to more people. And one big question was,

we needed a development board to show off what the Blackmagic Probe can do. So I created the 1-bit C2. So it's a small ARM Cortex with an STM32 on it board, really small, so it fits on a breadboard. I didn't see much that could do that, that would just fit directly with the Blackmagic Probe. It has a JTAG program interface on it and so on.

So not going too far into the weeds here, I decided that it would be good to have a Kickstarter for the new version of the Blackmagic Probe that I was working on. And about, what was it? I think the 29th of November, we launched the Kickstarter. And this encompasses the 1-bit C and the Blackmagic Probe so that you have good access to an evaluation board

that you can test the features that the Blackmagic Probe offers. And yeah, that's our Kickstarter. And so for, let's see, what is the price here? For $60, you can get a Blackmagic Probe, just the Blackmagic Probe, not the one Bitsy with its Cort um cortex m4f dev board the black magic probe we've been talking about that can work with gdb and actually do the debugging as well as the programming of cortex m devices yes and then for a little more wasn't that much more it's like 25

bucks additional for the one bits it depends on which tier you get. You get quite a lot of discounts if you get more 1-Bit-Cs or more Blackmagic probes. Yeah, so a 1-Bit-C was $25, and if you combine a 1-Bit-C and a Blackmagic, that's $80. But most of my debuggers, of which I do seem to collect quite a few, have cost a lot more than $60. That's funny that you say that because we are also getting people say like, why is the open source Blackmagic Probe $60? It sounds so expensive. And what people don't realize is how actually expensive devices like that are, that have so much functionality. And in my mind, having an open source firmware should be value added, not value subtracted. So yeah, we are basically financing a lot of the software development and future hardware development

with the revenue from that project so it's not like we are moving to bahamas with that money it's not really enough for that we would have to charge like a thousand dollars a probe if anyways you know what i mean uh and your but your goal was only $10,000 to start with, and you're way over it. So you've met your goal. What are you hoping to get to? So Kickstarter is complicated. We set the goal for $10,000 because that's basically what would like to be able to assemble and build this stuff here in the US

instead of going to China with it. So it requires bigger quantities to meet similar prices as there. So that was one of the driving factors here. And I don't have a value that I would want to get to. I think it is great that as many people as did already supported the project. And I just wish more people would join and can try out what Blackmagic Probe can bring to the conversation. And the more people back the project, the more time and energy and money we can put into the project again. So the more backers, the better, and we will be able to do greater things with that money.

Have you done other Kickstarters? I've done one in the past. It's quite a long time ago. It was, I think, 2011. But that I learned quite a lot of things about Kickstarter through that. What was your most valuable lesson? There's several. One of them is a lot of communication during the Kickstarter. But the other thing is, have your product really, really figured out before you go to Kickstarter. Don't assume you will be able to figure it out during or

after it's funny for a product called black magic to have a goal i mean your goal is to not have any magic before you ship are you worried at all about fulfillment uh of course i am it's like things things go crazy more often than I wish they would. It's always a question. It's like, will you be able to get the parts on time? Will suddenly a part got recalled or something? Yeah, especially because it's Kickstarter. So we are getting the money and then ordering stuff.

It's easier when you don't do's Kickstarter. So we are getting the money and then ordering stuff. It's like, it's easier when you don't do a Kickstarter. You can then order parts and basically postpone the release of the product until you have everything figured out. It looks very easy afterwards because, oh, there is a product on the store. It's done. With Kickstarter, it's much more complicated.

And a lot of people, I think, that back on Kickstarter forget that. But this isn't your first time selling boards like this. No. Well, at OneBitSquared, we do that quite a lot. Yeah, you have a store and everything. I mean, on Kickstarter, there's the Blackmagic version 1.2. But if I wanted version 2 right now i could

ask for it off of your store or that's what it looks like yeah the 2.0 is currently available the 2.1 is an improved hardware revision of that board and the there's like the reason for the kickstarter is to be able to get a bigger audience. It's for people to hear about it. I think you guys also heard of it semi through the Kickstarter campaign. I'm not sure. You tell me. Actually, we did hear about it from the Kickstarter campaign.

But it turned out that once I mentioned it to a couple of people they'd already used various things so that was sort of exciting and validating made me a little more confident that you'll be able to ship this hardware thank you that's that's good to hear uh yeah i i think we should be able to do that um and yeah we we actually i'm not sure gareth when when did actually black magic probe start uh the real beginnings of it were about a decade ago oh wow the the first devices that actually went out for people to use were about 2011 i think about then yeah this is the 20 pin uh version of the board right yeah that big that big one with the with the 20 pin 100 mil connector on it that those were hand soldered by me yeah wow um so yeah it's like the the probe has quite a long history

so the software is quite stable and there's a lot of input. But we just want to reach a bigger audience. That's one reason for the Kickstarter. And the second one is be able to buy the parts in quantity, like really in quantity. Because everything we did so far were like hundreds. And I would wish to be able to buy them in thousands. So the parts. And this will allow us to actually eventually decrease the prices

so that there is more people that can get it. Yeah, those quantity buys really do make it much cheaper. So in some sense, this is less a normal Kickstarter where you're trying to get a new product out there it's a group buy to get well yeah if you look at kickstarter there's a lot of projects like that it's like not everyone is actually like honest about it but a lot of projects out there are like this really awesome product the teensy by post by Paul Stoffel. That is really amazing. And he does a great job for the Arduino community.

He also had it like basically completely ready, went on Kickstarter and said like, here's a new version of the board. And people love that. We don't always have great advertising mechanisms. So whatever works, I don't, I'm not going to say you can only use Kickstarter to fund art projects. Or things that will never see the show notes yeah i wanted

to make sure okay but back to what does the black magic do i think the bitsy is pretty cool but it's a dev board and i have a lot of dev boards and i have a lot of other boards that... It actually does have certain special features to it compared to other development boards because you could compare it to... Because it has an STM32 on it, you can compare it to some boards that are mostly targeting the Arduino market. So they either have only an SWD interface or none,

because as you might know, Arduino doesn't have any debugging capabilities. And then the discovery boards that also come with a ST-Link on board that is only SWD. And also the form factor, if you compare the 1-bit C compared to the size of a discovery board, it's quite difficult to put it in a cramped prototype or something. So it's a little bit, it's like a small board that is inspired by the Arduino tiny boards, but it has proper JTAG and SWD debugging.

Looking at it, it looks like the old, oh my God, they're like 10 years old now, the Expresso boards from NXP that were just a really nice form factor, went onto a breadboard, just the right size and everything. And the Expresso boards had their own built-in debugger that you could cut off if you wanted to and then wire in differently. And I liked those a lot.

It was really handy. Yeah. But you just said something about SWD and JTAG, and I realized I don't usually care which one I'm using. Which one? What's the real difference? I mean, other than one wire that the hardware engineer always whines about. I think for me, the biggest difference is JTAG, you can chain. So you can have more than one microcontroller in the system,

and they can be accessed over one JTAG interface. That's quite a useful tool if you have, for example, an FPGA on board too, and together with a microcontroller. And not every microcontroller also supports SWD. Doesn't the ARM Cortex-M say you have to support SWD? I'm not sure about that. Gareth, do you know an answer to this? No, I think it's optional

um i haven't seen one that doesn't support it um the obvious the obvious point here worth mentioning is that swd is an arm proprietary protocol and j tag is a standard um that said j tag as a standard is about as good as xml as a standard in that it's it's general enough to do everything and not specific enough to do anything yeah i i have a very good now i remember uh ti doesn't use swd okay and there are cortex m's there are plenty of them so yeah yeah ti has uh decided to go with the standard quote-unquote, namely cJTAG. That is a one-wire version of JTAG by the JTAG Consortium. Do you support that on the Blackmagic?

Not yet. Okay. Gareth, it's like, do you have... Not yet. Good. But, I mean, JTAG wasn't even originally designed for this. It was to test protocols and probe pins on FPGAs. And then it morphed into software debugging.

Christopher, you keep shaking your head like I'm insane. Why? I know. I wrote that question. Oh. Because you stole it. head like I'm insane. Why? No, I wrote that question. Oh. Because you stole it. I stole Christopher's question. Well, it's a shared property state.

Go ahead. No, I don't even, okay. What was I asking then? The point was JTAG was originally more for electrical engineers to scan a chain of chips on a board to test signal integrity and everything's connected up and query registers and stuff. I was curious, since these guys have worked with this, how it morphed into being a software debugger.

Now I only hear it in that context. 20 years ago, I only heard it in the digital IC context. I don't have a good answer for that. History of computing is always boring. Yeah. So, well, it was the five pins that you would already have on

your IC. You would want a debug interface and you don't want to waste any more pins on it, JTAG is like XML. If we want to shove debugging information into it, why not? We can. So they did.

And every vendor has got their own way of doing it. Yeah, and I think you answered a few minutes back when you made that same analogy that it's like XML. It's there. It's extremely general. We can make it do whatever we want, so why not? All right.

Do you have any other questions? No. Would you like to type them so that I can just read them as though they were my questions? No, you can steal the next one. How is a free programmer like embed? He already answered how the embed ones are different. I mean, the USB embed ones aren't even debuggers.

Those are just programmers. I'm pretty sure that was your question. Is this how we're going to run our show? Really? Is Peter still on the call? He's disappeared from my screen. Uh-oh. It's okay.

Chris and I apparently are just going to hassle each other at this point. Is Peter still on the call? He's disappeared from my screen. Oh, it's okay. You're just going to hassle each other at this point. So Gareth, what, what is cool about the black magic? I mean, it's cheap. It does all this stuff. But what is the thing that you were most proud of? I don't know how to answer that. I mean, is it that it's open source?

That's a pretty cool feature that nobody else really has. Or is it that it should be implemented in an FPGA because this is usually FPGA sort of stuff, but you did it in a processor? No, very little of it should be done in FPGA. To me, that doesn't make much of a difference. I'm just talking, to be honest, what I wanted didn't exist, so I wrote it. Yeah, well, necessity is the mother of invention after all, right? I mean, seeing something that's missing in the market is a huge inspiration a lot of times.

Yeah. Yeah, I think it's probably a better question to ask Peter because he will tell people why they should buy it. To me, it's obvious. I spent countless hours working on it because it was that important to me. Okay. Then what should people know about their programmers? Forget black magic. For years, I have plugged in a USB programmer and plugged it into my board and tried not to swear when all of my compilers crash and when things don't go well. What things should I be looking for?

What boxes should I tick? I mean, I know there's internal RAM and there's tracing on some debuggers, which is a lot of internal RAM, and there's breakpoints, which used to only be two, but now you can have more. What sorts of things do firmware engineers need to know about their programmers? I would like to say as little as possible.

Oh, well, then I've been doing it right. That's one of the basic goals of the Blackmagic Probe is that you actually don't need to know very much. You plug it in on each end and it just works. You don't have to write a complicated configuration file saying what memory you've got where and it just figures the stuff out. You just plug it in and everything is automatic. You don't need to know how many breakpoints there are or at what addresses the registers are. It just does it for you. Okay, excellent.

Then I will continue in my blissful ignorance but if i wanted to work on this project black magic is open source so if somebody out there is like oh well i want to extend it how would they go about talking to you or what would you what things do you think people will want to extend it to do? How can they contribute to your open source? So the project is on GitHub. That's the place to go is to get it, compile it, put your own version on your board. The most obvious feature that people want

is support for a new microcontroller that we haven't seen before. This is generally not very difficult to do. You need the hardware you want to support you need the data sheet and all you really need to know to implement a new driver is what where the flash memory is located and how to program it and that's usually there is usually a manual somewhere deep in the in in most, this is in the manufacturer's data sheet or reference manual. Yeah. There are cases where this is under non-disclosure agreement

and you can't get it. But those are very rare these days. Should you want to be not worried about that, IAR and Kyle have a whole bunch of these files that describe how to program flashes. And so some people have been tempted to look in those files to see what the parameters are and how they differ from other things they know how they work. It's a little bit of hacking, if you want to have fun with it.

But I could totally see using this for external debugging and we talked about gdb and using the programmer with gdb and sort of scripting some unit tests and manufacturing but you can do even more than that if you can change the software on the programmer itself you you can if you have a custom application. Nothing stops you from using the Blackmagic Probe firmware to interface with the microcontroller in some way that you want. I have had one person contacted me. They wanted to just use the part of the Blackmagic Probe firmware

that does the programming to put in their automated test equipment. Nothing stops you from doing that. The official Blackmagic probe firmware offers you all the debug functions, but maybe you don't need them. That's up to you. All right. Have you used, or actually, what processor does the Blackmagic run? It's an STM32F103. Actually, what processor does the Blackmagic run?

It's an STM32-F103. Oh, that's their low-end models. Yes. I could use it as a dev board if I wanted to. I could get a Blackmagic to program a Blackmagic. Yes, we do that all the time. Sorry, I'm just cluing in on this. It's an endless chain of black magics.

It looks like we've lost Peter, and maybe forever. I'm not sure. So let me go on and ask you another question. You work for a company in San Francisco, Swift Navigation, and they make GPSs, but you live in New Zealand. Is that right? How does that work? That is correct. I rent a desk in a shared office space and work remote control. We have meetings using Skype or Google Hangouts, we communicate on Slack. I take regular trips every few months. I go to San Francisco for a few weeks to catch up with what's going on in person. Wow, that's more often than I manage to get to San Francisco.

Shh! We have clients there too. Okay, so that makes a lot of sense given how we work. How do you stay current in tech? Do you have magazines or blogs or podcasts? How do you learn stuff? The main way is probably by talking to people. By working in the office, I am exposed to various technologies

and keep up to date that way. Also, through discussion and working on open source projects. I can see how working on open source projects would be an education, both interpersonal and technology-wise. Oh, Peter's back. Excellent. Hi, Peter. Hey. Same question for you. How do you stay current in technology? And where do you go to learn new things? So I think I employ a similar technique I always did,

is reading other people's code and other people's solutions. And then I think that's most of the stuff that I know I learned. Of course, I went to college i i learned something there too it's not like school is for nothing but um uh yeah i i try to um i'm very curious about other people's solutions and how people do things and i love reading about this and being in the community and then if that fails then reading data sheets and white papers and maybe even patents at some some point it's useful tear down some other hardware is really useful yes so where do you go for that i mean do you are there forums you hang out on do you look at hackaday or is there an open source yeah hackaday is is pretty good um but um the

good teardowns are actually can be found on youtube it's uh um electric mike or what his channel is he's really good at teardowns but also when i'm interested in a specific device i just start googling and going on the picture image search and try to find high resolution pictures of stuff that makes sense i mean you learn a lot by looking at the board yeah yeah you do it's similar with software. It's like with hardware, it's actually a little bit more like open source should be where you can actually see other people's stuff. The bummer about all this stuff is actually that a lot of people are opportunistic about this. And instead of actually learning and creating new stuff based on other people's ideas they just rip them off that's a bummer do you worry about that for for one bitsy and black magic

oh that comes with the territory that's how i would see that it's you can change people's minds and it's like all you can do is innovate and do cool stuff and hope that there is enough people that appreciate it and so far it's like especially in that kickstarter i can say there is a lot of people that get it and it's awesome cool so what is the best use of black magic and when would i not want to use it when would i want to pay more for it? That's a very good question. I mean, it's two big benefits and disadvantages. So I personally think the biggest advantage is that it is open and that it is very easy to use.

It's like if you're using open source tools anyways in development, and actually a lot of people use it for production and like commercials stuff. So for those, I think Blackmagic Probe is a... And as long, of course, the chip that they are planning to use is supported by Blackmagic. That's a great solution because it, from my experience, pretty much just works. In cases where your boss is telling you you

have to use an expensive tool that's a different story well if they're paying for it it's almost okay yeah yeah so one one thing that i can imagine is like i went to a class from st just recently and they were using kyle for class. And then someone said like, oh, yeah, if you want a license that $35,000 for one seat license, I'm not sure how true that is. But that's what I heard. It's not that much. But maybe that's with the with the RTOS and some options. That's what they were mentioning. But it makes sense, I guess, when you actually need to shortcut the development as much as possible. And then the money makes sense. Even if it was that expensive, I think.

Yes. Well, and there are good reasons to use Kyle over GCC. For example, the Nordic examples tend to be written first in Kyle. So if you're going to use cutting-edge Nordic stuff, you probably want to use Kyle. Or you're going to have to wait for a while for the GCC version and other open-source versions to catch up. Yes. So there is some advantage there. It's not cheap.

I totally agree. And I guess Gb works fine on my windows computer it isn't as pretty as some of the other ones but once i get used to using it again it works really well probably better than most of the others yeah i'm not sure gareth was telling you about that but it's like for example um i personally am not a huge fan of eclipse which ends up being the go-to solution for a lot of users good for you and and but that's why um so i was using for quite a while a sublime text but i can't ask anyone to pay for a text editor. So we ended up using Atom, the text editor done by the GitHub people.

It's pretty cool. It's very flexible. And Gareth wrote a plugin for it to make GDB very useful in that environment so that you get all the data representation that you would expect from an integrated IDE and make it very nicely easy to use without actually having to go back to Eclipse. Well then Platform.io is based on Atom right? Yes Platform.io is based on. And they have a lot of Platform.io is sort of like embed, but offline. They have a lot of getting started.

They have a lot of, not hand-holding, but more libraries and more getting up to speed quickly. If I was going to use Nordic and not use Kyle, I probably would go there to see if I could handle all of that. And that's based on Atom, which is GDB. It was kind of cool. I haven't finished playing with it. Yeah, so we have support for Platform.io from 1Bit.c. And yeah, Platform.io is... The people even reached out to us because they had in their to-do list to add GDB and local debugging support.

And they reached out recently to Gareth about that, about his plugin. One other option that I know a few colleagues are using is Microsoft's cross-platform Visual Studio Code that has a plugin for GDB. So you can do all that stuff there too. Yeah, I looked at that it's it's actually open source i can't believe you're the one who's hawking microsoft visual studio it's not visual studio it's visual studio code it's it's yeah yeah runs on everything runs on everything still

says microsoft somewhere how is black magic different from the very high-end programmers? I know some of the high-end ones have lots of internal RAM to allow for long traces. How are those different? I'm not saying better, just if you're going to pay $10,000 for a debugger, I want it to be something more than what I can get for $60. I personally haven't used any of those really high-end tools, so I can only tell you what I've heard. But they supposedly have the parallel trace capability, which allows you to actually get instruction trace out of your running program.

So that, as Peter was describing, what you can do with gdb is you can do reversible debugging you can run your program when stuff goes wrong you can run your program backwards to before it went wrong and then slowly go through and until the problem happened this you can't do on the black magic probe you can only run your program forward and inspect the state whenever you like but there's no way to go back after things have gone pear-shaped. This is an idea and we are thinking about how we can do this in a future product,

but it's not, we haven't done it yet. So that's the rewind command. Yes. All right, not supported yet, maybe sometime. Do you have other programming features you're thinking about adding in the future that you can share with us? Nothing that's a big secret.

Ideas, we want to work on more supports on Cortex-A devices. So we want to support like the Raspberry Pi 3 and the BeagleBone Black. We want to add CJTAC support for the Texas Instruments devices. Those are really the upcoming things on the to-do list. But the Cortex-As, most of them need operating systems, which doesn't that make debugging more complex? In the case where you're running a Linux system on a Cortex-A device

and you want to debug a particular application there, you can just run GDB server as a process under Linux to debug it. That isn't a problem. Where we need this is, if you run a bare metal application, you would want this. To debug the boot process

before the operating system has started up, you would want this. There are still applications where you want a low-level debugger. What about debugging the kernel? Is that a separate kind of thing, or is this something that you could do? Yes, you can debug the kernel with this.

There is also a kernel module that implements the GDB protocol. You can use that as well. Peter can talk more about this, but people are also interested in this from a security point of view because it allows you an out-of-band access to the target's memory. So Peter did a talk where you would run Linux on a Raspberry Pi and over the JTAG port you can manipulate the memory to give yourself access that you didn't have otherwise.

So you might use this if you bought a router from the shop and you want root on it, but they didn't give you the information, you could connect up the JTAG port and break in yourself. Which, of course, we do not recommend because that will void your warranty. Unless you're having fun, in which case, have fun. You don't need to add disclaimers for hacking on this show. I know. Do you have any more questions, Christopher? I have a couple questions.

You mentioned features in the software that you'd like to implement in the future. I was wondering if SWD and JTAG, is there anything that you'd like to see the chip support that they don't? Any changes to the protocol? I know you said they were very general, so maybe the answer is no. But is there something that can be done in hardware to make debugging easier, better for the rest of us?

I don't have any great ideas. The current generation of ARM chips is very good. There's nothing obviously missing that they need to improve. What would be nice is for there to be an industry standard way to do this. At the moment, in the Blackmagic Probe, we only support ARM devices. There's not that much that says we can only support ARM devices, but ARM have got their way of doing it, and if you went and bought an Intel processor,

they would have a different way to do it. It would be nice if there was some industry standard way that you could talk to access debugging features like breakpoints and stopping and starting. That would be good. We'll call it JTAG. Wait, no, that's taken. What else you got?

What else have I got? Oh, you mentioned since this is open source that you can change things on the device to support other devices. Well, change the software so you can support other devices. Would it make sense, and this is just me trying to understand

what I might contribute or things I might add. Would it make sense if I had an existing device with maybe a peripheral to expose that peripheral through GDB? Maybe the register map for a particular I2C thing that I want to be able to look at in line with my code debugging. Does that make sense or is that not the kind of thing? Oh no, you could totally do that with the ELF file

by essentially instantiating a variable on that spot with a nice structure to it. Yes, but beyond that, maybe... That's just memory mapping the registers. Maybe there's a peripheral where I want to interact with it in some way. Or you have to query it to get information. It would still be something you would do in your program rather than in the debugger.

And I think in GDB, you can call functions on the target. You can say print and give it a function call, and it'll run that function and give you back the result. You can do that, but the function would still be written in your program, not in the debugger. Okay, that makes sense. Yeah, you can also do things on the PC. So you can do system calls through the GDB, through the debugger.

Oh, okay. So for example, if you want to load test data from a file, you can do open and it opens a file on your computer. GDB is incredibly powerful. Working with some of the lackluster IDEs I work with, I always forget how incredibly flexible GDB is, especially once you've learned it. It was the first debugger I really ever used.

So I was always surprised when it got to the fancy GUI ones, how less capable they were sometimes. They were prettier, but not smarter. I can see more at once, but I can't see certain things that I want to see. But this would be the nice thing about actually creating a very decent UI that uses the UI for what it's intended to show data. Now I'm wandering lost into, could I modify Blackmagic to do some of the profiling stuff

and monitor battery? That's kind of what I was thinking, yeah. Because measuring low power is so hard sometimes, especially if you're going into sleep for a little while and then coming out. But if you had the JTAG access, you would be able to see that and trigger an ADC read somewhere so that you could measure the power at the right.

I suspect there are lots of things we can do to hack this. Which is good that I ordered one. Thank you. Maybe you should have ordered two. Maybe you should have ordered two. Maybe we should have ordered two. Okay, I think we've kept you for about long enough. I do have more questions, but maybe we'll try this again after we get the black magics. Peter, do you have any last thoughts you'd like to leave us with?

Yeah, it would be lovely if as many people as possible support our Kickstarter and also join our Gitter chat. It's gitter.com slash Black Sphere, Black Magic. You can add it into the notes. There's a lot of people there that do a lot of hacking with the Black Magic probe, and you can ask your questions there if you have specific ones excellent and gareth do you have any last thoughts you'd like to leave us with yes uh don't be scared of the gdb command line interface it is not difficult to use you just have to learn it first very reasonable first. Very reasonable. And Peter, do you have a discount code for us and maybe a giveaway? Yeah, we do. So if you go on the OneBitSquared store, there is a discount code EFM2016 for 10%

discount till the end of the year. And we also have a Blackmagic probe with 1-bit C to give away. And you just have to tweet at Esten or at 1-bit squared and tell us why you need it. And we will randomly choose someone before the end of the Kickstarter. It's like on the 28th of December

because 29th is the end. So that if you don't get one, you still have a chance to back. Excellent. Thank you for both the discount code and the giveaway. Our guests have been Peter Eszintemski, founder of OneBitSquared, a site that develops open source hardware and software for emerging personal nano UAV market.

Yeah, that's right. I didn't ask him any UAV questions. Gareth McMullen is our other guest, an electronics and firmware engineer at Black Sphere and Swift Navigation. The Kickstarter for One Bitsy and Black Magic

Probe ends on December 29 29th so get them soon if you missed it check out the store one bit squared.com that's the numeral one b-i-t-s-q whatever squared um links to that and the kickstarter are in the show notes there is the discount code as mentioned 10 off until the end of december efm 2016 and the giveaway tweet to one bit squared maybe tweet to embedded fm too i like to know you know and say why you want the black magic probe and one bitsy winner will be randomly selected and if you don't have a Twitter and you really want to enter, then email,

hit the contact link on show on embedded.fm or email show at embedded.fm and I'll tweet for you. You know, nobody needs to be discluded. Do it by December 28th so you can still buy one if you don't win.

Okay, okay, that's all. Thank you so much, Peter and and Gareth for being with us. Thank you for having us. Thank you very much. And thank you to Christopher for producing and co-hosting and for all of my lovely upcoming holiday gifts.

Also, thank you. Just put the pressure on. Thank you for listening. Go to Embedded FM if you'd like to read the blog, contact us, or subscribe to our YouTube channel, which is just this show, so really you don't have to. And now a final thought for you from Leonardo da Vinci. Once you've tasted flight, you will forever walk the earth with your eyes turned skyward. For there you have been and there you will always long to return. This makes me wonder, was he a time traveler? How did he fly?

Embedded is an independently produced radio show that focuses on the many aspects of engineering. It is a production of Logical Elegance, an embedded software consulting company in California. If there are advertisements in the show, we did not put them there and do not receive money from them. At this time, our sponsors are Logical Elegance and listeners like you.