Embedded - 486: A Nice Rainbow Dream

Episode Date: October 3, 2024

Antoine van Gelder spoke to us about making digital musical instruments, USB, and FPGAs.  Antoine works for Great Scott Gadgets, specifically on the Cynthion USB protocol analysis tool that can be used in conjunction with Python and GSG’s FaceDancer to act as a new USB device.  While bonding over MurderBot Diaries was a given, Antoine also mentioned NAND2Tetris which Elecia countered with The Elements of Computing Systems: Building a Modern Computer from First Principles, the book that covers the NAND2Tetris material. Memfault is a leading embedded device observability platform that empowers teams to build better IoT products, faster. Its off-the-shelf solution is specifically designed for bandwidth-constrained devices, offering device performance and product analytics, debugging, and over-the-air capabilities. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury, Memfault improves the reliability of devices across consumer electronics and mission-critical industries such as access control, point of sale, energy, and healthcare. To learn more, visit memfault.com.

Welcome to Embedded. I am Alicia White, here with Christopher White. Our guest this week is Antoine Van Halter from Great Scott Gadgets. We're going to talk about USB and music. Hi, Antoine. Thanks for joining us. Thank you for having me. Could you tell us about yourself as if we met at an online Great Scott gadget get-together mixer? Cool. Hey, I'm Antoine. I work at GSG. I've been keeping busy developing firmware and gateway for Synthion, which is an all-in-one tool for building, testing, monitoring, and experimenting with USB devices.

I come from a kind of weird background. I think these days they call it non-traditional, which is a more professional way of saying that I dropped out of high school and played guitar for my supper until the internet happened and computers became fun again. We want to do

lightning round where we ask you short questions and we want short answers and if we're behaving ourselves we won't ask exactly which pickup. Are you ready? I am ready. What is your favorite musical instrument? Favorite

musical instrument? It has always been and remains the electric guitar. All right. What is your favorite pickup? Favorite pickup? Definitely the bridge pickup. Favorite murder bot story? Favorite murder bot story? All of them. The whole series. I mean, they form one story. How can you ask me to choose a favorite? Mine's always whichever one I read last. Heel or headstock truss rod adjustment? Oh, definitely heel.

What is your least favorite musical instrument? My least favorite musical instrument, it is probably the recorder. Oh, God. I had two years of hell with that in primary school. I think, is that a worldwide phenomenon? We had to do that, too. I don't know why somebody decided that everyone in the world has to learn to play the recorder when they're eight. You're breaking lightning round rules right now.

I know. Well, it's fine. Do you like to complete one project or start a dozen? I like to start one gigantic project that's going to take several lifetimes to complete because that means I'm never going to have to feel about dropping any sub-projects once they've served their purpose. If you could teach a college course, what would you want to teach? I'd want to teach a course based on, there's this book written by Noam Nisan and Shimon

Shachan called From Nand to Tetris. I don't know if you know about it. Actually, it's called The Elements of Computer Systems. I only know because I'm three quarters of the way through it. Cool. But instead of NAND gates, we'd start with passive components, diodes, transistors,

and instead of Tetris, we'd build a hybrid analog digital modular audio synthesizer. Nice. That's more of a college degree. Just the course. Oh, damn. Well, the Nand to Tetris feels like a college degree,

but I think it's mostly putting a college degree together. And actually, Shimon's going to be on the show soon. So if you have questions for him, just go ahead and send them to me. Finally, what is your favorite fictional robot? Got to be Motobot. I mean, I'm a show of sec units count. I mean, being a little bit human, a little bit bot, but surely they can count, please. Yes, definitely.

Thank you. Thank you to Memfault for sponsoring this show. We appreciate their sponsorship and the work that they do. Memfault is a leading embedded device observability platform that you're going to build 5, 10, 100, 50,000 units and you need to keep track of them, they'll let you create your own dashboard to observe how your system is doing in the field. Memfault gives developers a more scalable and sustainable process. This accelerates the time to market and de-risks product launches. You can cut product costs and deliver more high-quality software. Trusted by leading brands such as Bose, Lyft, Logitech, Panasonic, and Augury,

Memfault improves the reliability of devices across consumer electronics and across mission critical systems, such as access control, point of sale, energy, and healthcare. Thanks again to Memfault for sponsoring this show. Check out memfault.com and the Interrupt blog, which is filled with incredible amounts of information. So if I wanted to make a musical instrument, what are my options? I mean, I know that question is much too big, but... Well, you could start with taking your mug there and smashing it around

the room, and then that's a musical instrument. I mean, basically, if it vibrates, you can jam with it. Okay. So, moving outside the trivial, I want to connect it to my computer. And then immediately I'm faced with MIDI or USB or MIDI over USB or USB over MIDI. I don't know.

I don't think that one works. Just audio. Or just audio. What's better and why? I mean, that really goes to the foundations. Depends. That's where the foundations live. Because, you know, it all just used

to be an electrical signal and it would wobble and you know, we're done. So the only reason this is a question is because of history, I think, and, you know, maybe practicality. So a long time ago, when the first synthesizers were coming out, I mean, the first synthesizers were just connected with electrical signals. It was all control voltage.

But when the digital stuff started happening, people figured out, well, the audio, that's real time. We've got to get 48,000 samples per second from one end to the other and maybe even do stuff with that. None of the computers could do that. So they thought, well, the one thing we can do is the control data. And that's like, when did you press the key, which key did you press, and when did you let go of it?

And that's what became MIDI. I mean, nowadays computers are much faster, and for practical purposes maybe you still want to do that split. But if you look at a lot of the modular synthesizer culture the some of it that's now getting onto computers and it's being emulated um they are actually sending audio signals for control so you know it depends on what you're trying to do if you're just trying to send control data midi is what you want to do and if you don't worry about the timing or the latency on that, MIDI is pretty good. You can get it within 10 milliseconds.

But if timing or latency matters, no matter if it's control data or audio data or a mixture of the two, you're definitely going to want to use USB. So MIDI is just a stream of those things you said. You know, you put down the key here, you lifted it there. Maybe a few other parameters about how far you put down the key or things like that. And of course, which key. So it's not very dense. Like, you could run it over a serial port a fairly slow serial port maybe not 9600 but something no it's faster than 9600 I can't remember the actual speed

I think it's 33 or something 31.25 but still that's I don't want to say human interpretable because it's obviously not but it's not like a giga sample per second or a mega sample per second. Yeah, it's serial. It's like packets, right? Well, not packets, but it's control messages.

And it's one way, which I guess most musical instruments are. No, it's two way. Yes, but if I play my coffee mug into a MIDI controller, there's nothing to send back to the mug. What if you recorded, well, if you record your performance using MIDI, you can play it back to your device.

Oh, right. Because we're talking like a keyboard or something where it has a speaker as well. Like the synthesizer, yeah. Okay. Yeah. Or if you have one thing like a sequencer controlling a variety of synthesizers, they need to be able to read too.

So it's bidirectional. But MIDI does have a few limitations. Like you can only have so many instruments. And is it directional? Well, so by default you've got 16 channels, and it's directional in the sense that the in and out are two separate cables here. Is there usually a controller or master module? Mostly on the computer side it's a UART.

Yeah. Yeah, it's as simple as it gets. I mean, the beauty of MIDI when it came out is you could make it with $5 of parts. But then we go to USB, which is like, when I think about embedded systems,

serial is at the bottom, you know, that's the first thing you implement because it's the easiest. And USB, I mean, you implement because it's the easiest. And USB, I mean, you can do it without an operating system, but I usually recommend that if you're going to have USB, you also have an operating system. And maybe buy the stack or steal the stack or have a stack.

Have a working stack, don't develop your own. Whereas serial, it's like, yeah, we can just do bit bang on that if that's what you need. It seems like there's a jump in complexity here that I don't... It's a massive jump in complexity. And the only thing that enabled it was that the hardware manufacturers, the big hardware manufacturers, put a fair amount of money into ASIC development. So you'll find historically most synthesizers or other music kit is using an ASIC for the MIDI interface. There's no firmware or software driving if it's all done in hardware. Oh, so they buy like a USB to MIDI thing and just slap it down? Yeah.

Oh, so they buy a USB to MIDI thing and just slap it down? Yeah. Oh, okay. Huh. What does the communication to that chip look like from a microcontroller? It's basically a register-based interface on most of them. Okay. Yeah.

It's very simple. And so my coffee cup would have its audio acquisition module ADC to digital. And then the digital component would go into a MIDI parser. It would parse the signal, the analog signal that came in and now is digital? Yeah, so basically it'd set up the register saying this is the note on, this is the note, this is the velocity, and off it goes. Oh, so I don't really want an ADC coming in. Right. What I really want is switches or buttons to tell when things have happened. Or like on my drums, they have

pisos for when the head is struck and then it converts those to midis. So you don't want to do analog acquisition on MIDI. That's where USB starts to come in? That's when USB starts coming in. And I mean, those strips basically just have a straight

USB interface. You've got PDM data coming in and out of them, and they do the USB on the other side. XMOS makes, I think, the most popular one. From the computer side, one of these is USB over MIDI, and one of these is analog over MIDI. No, oh, sorry. One of these is MIDI over USB, and one of these is analog over USB. They look different, right? These are not the same. Oh, sorry. One of these is MIDI over USB and one of these is analog over USB. They look different, right? These are not the same.

We say USB like it's a thing, but it's not. No, the two specifications form... The master specification is the universal audio class, but there's a subspecification that basically describes how you embed MIDI over the Universal Audio Class device. And they're basically two separate endpoints. And an endpoint is also like a thumb drive or a keyboard. Yeah. I didn't realize they put MIDI inside the audio device.

Okay, I always thought it was a separate class. No. I mean, you can build a MIDI device that doesn't have audio support, and you can build audio with it, but... Yeah, I have lots of those. Cool. So we mentioned that the MIDI, the standard old MIDI from the late 70s,

I think it's the late 70s, is fairly slow bitrate, and has latency problems. Do those problems go away when you implement it over USB? Because USB is kind of unbounded. I mean, it's bounded, but it's comparatively unbounded. Yeah, it depends. It depends a lot on your operating system drivers. In theory, you can get a bit accurate

timing, a sample accurate timing on some setups, but it's worth noting that the few manufacturers that have worked on tightly integrated USB interfaces, I'm thinking

of the Access Virus Synthesizer, that generally they've done quite a lot of custom protocol development of their own, which kind of goes within the schema of UAC, but it does a few things a bit differently, just so that you can get timestamps matching up between the two endpoints. Oh, I see. Oh, interesting. I didn't get that. Explain. Well, if you've got the digital audio

coming over USB as well as the MIDI information, they're going to be skewed a little bit. Yeah, because nothing ever has the same time base and time is horrible and never work on time. So I think certain manufacturers do a lot of work in their own driver and stack stuff to either timestamp both of those so they can be synced up later or have them closer in time.

Why wouldn't you just send it all over analog? Analog? I mean, why bother with the MIDI if you've already got the highly sampled? Because you want the performance data. Maybe you want to take that audio out and replace it with a different synthesizer to keep the performance. Yeah, or the most common use case

is your computer sending MIDI to the synthesizer and then we're getting the audio back from the synthesizer going to the computer. Okay, okay. So my computer says, go play this note at this method, velocity or key and whatever. And then I'm also at the same time recording additional performance information. And the audio output. Okay. Cool. Okay. And so universal audio, what was the C for? Controller?

Class. Class. Class, right. Mass storage class. They all end with class. These endpoints are all well defined. by itself where you start out with a couple of numbers 9600, 891 and you learn how to decode that into the parameters you put into your PySerial or into your TerraTerm or whatever you're using. Yeah. USB has a lot more information.

Yeah, it's highly structured. How do I learn about those? And when do I decide it's important to learn about those? The first time you're going to learn about it is when you're in the studio and you're trying to make sounds on the external synthesizer and it all sounds wrong. Yes, that is when I usually learn about things, when it's all gone horribly wrong. Or if it, well, I mean, that's a first, that's a second step.

The wrong sound is you're making progress. No sound is where I expect to start. I thought about saying that. Oh, God, no, I don't want to go there. So that's the point in your life when you, for the first time, download a MIDI monitor and you're going to see the note on note of messages and you're going to compare it to what you want to happen and how things are configured and so on. I mean, if you want to know it deep, the answer is always read the spec.

The Universal Audio Class spec is a lot easier to read than almost any of the other ones out there. It gets a little bit complex when you talk about how the endpoints, because they're kind of a graph arrangement thing for the endpoints, we can connect endpoints to other endpoints and so on. But apart from that, it's reasonably straightforward. And I mean, the really easy way to do it is to just pull up FaceDancer and plug your Synthion into it and just look at the data traffic and you'll be able to see the numbers there.

So these are things you work on. Synthion is what? Synthion is our USB multi-tool. I hope you, I mean, I pull the multi-tool out of my pocket and it opens into many things.

But it's an FPGA based system that can then mock up any other USB system? Pretty much. At its core, Syntheon is a lattice ECP5 FPGA and three USB 5s connected to it. It's also got some GPIOs, but we'll talk about those later, I guess.

But it's literally FPGA with three USB ports. So, I don't, in this scenario, I don't know USB, which is only slightly true. And I don't know FPGA. I feel like jumping to Cynthian is like

I don't have either foot on a solid surface. You're describing the last two years of my life. So apart from the hardware, which is Synthion, and I mean, traditionally, Great Scott Gadgets has been a hardware company. We build hardware and then other people figure out how to use it. But somewhere in the very, very long time to get

Cynthion from prototype to shipping product, I think the company changed a bit. And I think these days we think of ourselves a little bit more as a software company. A lot of the work to get Cynthion shipping has been developing the software that turns it from an absolutely, it can do anything you can imagine, into, well, you can actually do some specific things with it reasonably easily. It's hard to have tools you can do anything with. Because then I just look at the tool like, okay, that means I have to learn too much. And it's a tool I want to be using to do something else.

I don't want to spend my time learning the tool. Yeah. I want the tool to fix my other problems, not create more. Do not shave the yak. Adopting a new puppy to take care of your overactive puppy. Are we getting another dog? We'll talk about it later. That's a no.

Anyway, is Cynthian a good way to learn USB or a good way to learn FPGA? Or a good way to learn neither. Okay, so number one priority at work is it's got to be a good tool to learn USB. As far as pretty much the entire team, including the boss, feels, it's a good way to learn, period.

So let's just go back to the MIDI use case. So you buy yourself something, you come home, get it out of the box, you plug it in. And in one port, you plug in your MIDI keyboard. In the other port, you plug in your synthesizer. You boot Synthion up and you make sure that when you press the notes on the MIDI keyboard, the synthesizer makes noises. So one of the first things you can do is you can start the Packetry software, which Martin wrote. And that will give you, it's basically a USB packet capture application. And you'll be able to capture every USB packet coming from the MIDI keyboard going to the synthesizer.

And if you look in that, you'll see what notes you're playing and so on and so on. So that's fun in and of itself. But now you want to start learning USB, so the first thing you want to do is maybe, well, let's take an established class like Universal Audio Class, and maybe something I could do is modify the data as it goes through synthion and that's the point you pick up face dancer and then maybe you write a little face dancer script in python that will if you play middle c on the keyboard it will run a little macro and send a chord a c major chord to the synthesizer It'll transform that data you put into it.

And if you play a D, it'll send a D minor chord to the synthesizer. Or maybe you press E and it plays an arpeggio of the E minor chord. So this is kind of a great way of figuring out, you know, mapping inputs to outputs, working out with what does a particular class do, how to work with it. So that's sort of on a high level. You mentioned FaceDancer. Yeah.

Which is one of the things you've been working on. Yeah. And it interacts with Python. But what is it? Cool. I'm terrible at building foundations. What would you use it for? Okay, so FaceDancer is basically a way to remote control a USB port from Python. So normally when you've got a USB device, the processing happens on the device.

What FaceDancer does is it takes what's coming in on the device side, USB port, and it takes the host side USB port and it inserts itself in the middle, which means that in Python I can receive any data that's being provided. I can generate data. I can make it impersonate other USB devices by when the host asks FaceDancer to enumerate, it will say, hey, I'm a USB FTDI interface and this is manufacturer, and these are my endpoints. And then the host goes, oh, yeah, you are. And then it pulls it for data, and then FaceDancer generates that data. It's a library for emulating USB devices, intercepting traffic between USB devices,

modifying the data between USB devices in Python. So I've had IMU initial measurement unit devices that can speak over USB, usually some sort of serial because it's a test device. I could connect that to one side of FaceDancer and then modify some Python code and hook it up to my computer and pretend it was a mouse? Yeah, you absolutely do that. That's a common use case for a keyboard plug their mass storage class device in and then copy all their data and plug it in.

They would never know. Yep. Okay. Well, I mean, you know, not everything has the best intentions. Yeah, FaceDance has started out as a security research tool. I mean, let's be straightforward about that. As a security research tool, you have to handle the edges of USB. Those things that might otherwise be accepted as minor errors and maybe corners that nobody really cares about because that's obviously a bug. Have you had to deal with that? So not personally, but when

FaceDancer first came out, that was kind of one of the fun things that everyone was doing is basically the host would request the descriptors from the USB device. The descriptors are what tells the host what the device is. And, of course, the host will ask for, you know, give me 56 bytes of data. And, you know, people being people, they'll, sure, a year is 255 bytes. And overflow the stack and do all kinds of fun things. And, okay, so people on FaceDancer would do that to the computer and therefore make the computer unhappy? Yeah.

Okay. As opposed to some USB thumb drive of unknown origin that I got from someplace kind of scary doing that to my computer or my face dancer. And so that's all Python, right? It's all in Python. And I mean, this is stuff you can do. To a certain degree, you can do a fair amount of this without any hardware assistance. But the combination of having dedicated hardware for it, and also at the same time being able to access it externally via scripting language,

just makes it so much more accessible. I have used Wireshark on my PC to debug USB. How is... Why would I use FaceDancer instead? Well, FaceDancer's native file format is PCAP.

So basically, you can save a Synthion capture and view it in Wireshark. Which is great, because Wiresshock can do high-level class decoding, which Packetry doesn't support yet. Packetry, you mentioned that, and

I've already forgotten what it is. Please. So Packetry is our Packet Capture app. It's a graphical user interface that basically you get a long stream of USB messages when you press record and that's real time traffic going through Synthion. Why would you use that instead of Wireshark?

So Wireshark can only get what the operating system kernel is going to give you and I think it's hard to get it to work on anything except a Linux machine. What we're doing with Symtheon and Packetry is it's a pass-through interface. So we're not taking the data, interpreting it, throwing it out the other side.

We're literally capturing the traffic on the data, interpreting it, throwing it out the other side, is we're literally capturing the traffic on the bus, which can also give us some insight into bus errors and kind of the lower level parts of the USB packet are visible. So you're basically on Wireshark. You're only going to see, hey, there was a packet. You're not going to be able to break it down into the header and the body and the acknowledgement and the CRC check and so on. Okay, so that answers one of our listener questions from Scott, which is, are you working on exporting to Wireshark's high-level USB packets to get class parsing? And the answer is, you can.

You're already done. Check mark. Yeah. Cool. Christopher, you had USB issues earlier this year with a poorly formed library on a microprocessor of some variety. We're definitely not

mentioning it. Well, I don't remember. I mean, there were some hardware issues because it was a new chip, but yeah. What tool did you use? I used the expensive analyzer that's existed for 20 years. The Beagle? The Beagle, yeah, which was fine.

Have you used the Beagle, Antoine? I actually haven't. It's too expensive. Fair. Yeah, if I recall, it was fairly expensive. It was like $2,500 or something. Yeah, and if the client hadn't bought it, I knew two people who had them who we could borrow them from. But yeah, I wasn't going to buy one for just us. But we could do similar things with Synthion. Yeah.

How much does it cost? Get into the real. I actually have no idea. I'm ashamed to say. I'd have to look it up. Much cheaper. I mean. Yeah. Adafruit has them and they are $200. Much cheaper, I mean.

Adafruit has them, and they are $200. Okay. There you go. So, yeah. Yeah, it does seem like it's a difficult thing to do, right? Because you are, like you say, you're not storing and forwarding, right? You're not actually a man in the middle attack on things, although you can be,

but it's letting things go through the bus while also snooping on the bus, which sounds like a little bit of a hardware challenge to not, you know, it's like a quantum thing, right? You can't look too hard at things or you change them, right? And then you can parse it in the Cynthion Packetry. And then did you say Packetry saves to PCAP or how do I get the PCAP out?

Yeah, you just file save after your capture. That sounds nice. Okay, let's work on some other listener questions. Mitch asks what is the worst bug hunting experience with USB you've had? And how does it involve zero length packets?

Okay, someone else has been there. Yes, yes, it did. All three times with possibly a fourth one that was reported on Friday last week. And that's all I'm going to say about it. Okay, for those of us not in the USB know. Okay, so a zero-length packet is an acknowledgement packet in the USB protocol. And I think Michael, my boss at GST, he says there's not a USB stack in existence that

doesn't have at least one ZLP bug. The protocol is weird. It's not always clear when should you send a ZLP and when you shouldn't. And if you get it wrong, the entire thing crashes.

And you're not sure exactly where in the transaction it crashed. What's it in this? The ZLP, the zero-length packet. No, no, what crashes? The device. And sometimes, if you're really lucky, the host as well. Have you considered just flooding everything with zero-length packets?

Well, that's the first thing you try. And then it goes even more wrong. Why? It does seem like, and this is a little bit of a tangent, but it does seem like USB is almost uniquely tough to get right. There, there's the diplomatic way of saying it. That is the diplomatic way of saying it. I think I've been doing USB and embedded since around, I think the first time I had to use it was around 2006.

Oh, I have code from 1999. Well, I was doing core routers back then. Didn't have USB. We didn't care for USB. Mine was so bad. USB was 10 times, 50 times too slow. But, you know, mass storage, you know, on embedded, we'd get an operating system that would come with a stack, and 30% of the mass storage devices you buy on Amazon

just wouldn't work, or wouldn't work in some weird way, or they had to be configured slightly differently. Or they had internal hubs with multiple additional units. Right, or you have to hack the stack some way. And from a consumer perspective, computers tend to seem to work okay. Like, people, I haven't had a lot of USB issues with computers and things I buy for computers. But embedded, it just seems like the stacks are just not, what's the deal?

They're not great. Yeah. I mean, it's just like, is everybody implementing their own stack? And they're just, it's just so complicated that you can't get it right? And if you're a Microsoft, you can after 20 years? I mean, 20 years having to worry about only one target does get you a little bit further. But I mean, a lot of what's happening is that,

well, there's kind of two things. There's a lot of prepackaged USB solutions. You know, this will give you a keyboard and you don't have to program anything. This will give you a serial port, you don't have to program anything. This will give you mass storage, you don't have to program anything. And that stuff is terrible quality assurance on them. It's normally made by a single manufacturer that had a small team working on it, and they just want to ship chips. And, you know, people buy what's cheapest. That's the one part of

it. But then the other part of it is implementing a USB stack right is really, really difficult. It's doing the USB stack for Synthion is probably the hardest bit of engineering I've had to do in my career. Which part? I mean, at the bottom, it's a serial protocol. Yeah. I'm really good with those.

Yeah. But then it goes horribly wrong. At the bottom, the internet is just Ethernet, which is just some wiggling of wires. Exactly. Where does it get really impossible? DNS. It all went wrong in the committee. Is that true? I mean, is it the problem that there were so many people advocating for their particular versions, their particular needs, that the entire spec is weird?

I think that's a big part of it. I think a lot of the focus was on trying to integrate the end-user cases, which didn't leave a lot of engineering resources for figuring out what the actual transport protocol should look like. I mean, there's, you know, specification separated from implementation is often a good idea. Oh, it is a great idea if your transport protocol has been really well thought out.

I mean, Ethernet is a joy to work with. It's simple. Yeah. USB complexity is, you know, it's, I kind of want to say HTTP, but USB complexity might be on the HTTPS level almost. Not quite as bad, but somewhere in between HTTP and HTTPS. And for a transport protocol, that is terrifying.

It's also very hard to find information about it. Yes, yes, yes, yes. And it's changed so much. I mean, we say USB, like it's one thing, but it is definitely not one thing between speed changes and protocol changes. It's, yeah, it's not one thing. No. Low speeds, not high speeds, not super speed.

What do you think causes, I mean, the promise of USB, who are these classes, right? That like, okay, we have... There's many devices we want to attach and each of them is going to have a class and you can just write a driver for that class and you're off to the races and every device that implements that class

is going to be the same and you can just plug them in and everything will work. But as we've seen with mass storage, particularly, like stuff just doesn't... It was such a promise. It was such a nice rainbow dream. seem with mass storage particularly. Stuff just doesn't... It was such a promise. It was such a nice rainbow

dream. Is that due to over complexity at some level? Why are mass storage devices so frequently incompatible? So separation of concerns when you're building layered protocols. I think they should have put more networking folk on the USB committees.

I mean, the other side of that whole mass storage class device debacle is USB to serial, which FTDI won. I mean, we don't even say USB to serial cables anymore. We say FTDI cables. Like, that's the only option. And mass storage classes didn't get a winner, so they didn't get a consistency. Well, it doesn't have a chip.

I mean, the FTDIs are... Right. They're the whole thing in there. You don't have to worry about it. To chip in your cable. Yeah. I mean, I assume there's USB to SCSI chips you could buy if you wanted or something like that.

Are there other classes you can think of, Antoine, that have winners and not winners? I mean, you mentioned a MIDI to USB. Yes, the USB audio class, it's kind of weird, and I don't know enough about the history of it. But out of all the classes I've worked with, it's probably one of the most straightforward, almost as straightforward as serial. It might have been that the actual data

being transferred is very simple in and of itself. It's basically just a PCM encoded packets. But then on the other side, I look at the MIDI 2.0 specification. Now, if you think mass storage is bad, this thing is something to read. Basically, it's kind of a mindset with protocol design. You can either approach

a protocol from, well, I've got 101,000 different use cases, and I'm the special case every one of them. Or you kind of think, well, look, this is what the data flow looks like. This is the actual data that's going from point A to point B, and then you layer your exceptions on top

of that. I'm guessing MIDI 2.0 went for the first. Either one. Yeah, I haven't seen that on devices that much. Is that, I guess, most things are just MIDI 2.0. What do you mean? The devices can't handle them?

No, I just haven't seen it advertised as, oh, the synthesizer comes with MIDI 2.0 or anything like that. How long has it been out? It's been out for a while, I think. Yeah. But yeah, I think most things are still just putting whatever the 1.1 or 1.0 on. Because they don't need the corner cases provided by MIDI 2. Well, and there's some extensions to MIDI, the original MIDI, right? I have one thing that has normally velocity, I think, is either 7 or 8 bits, but there's an extended

velocity that gives you 16 bits of velocity or something like that um so i have one device that does that but yeah what if i was making midi 2.0 i mean my first my first impression would be oh make it a lot faster reduce the latency and increase the resolution of things and call it a day. Exactly. Surprised they're over-complexifying it beyond that. Okay, a question from Benny. Would the current design of Cynthion scale to faster USB standards with a larger FPGA, or is the protocol entirely different with faster USB standards? That's a great question.

So let's ask. So if we wanted to take a Synthion and make it a super speed device, what do we need to do? So there's kind of two layers. One's the hardware, the other one's the gateway running on top of the FPGA.

So on the hardware level, the FPGA we're using is a LFE5E series, and those chips don't support a high-speed interface. So you want a FPGA that's got a SerDes capability like the LFE5U, I think, is the equivalent lattice part. Then you'd need to switch out the PHYs, the USB PHYs, the physical interfaces. We've currently got high-speed PHYs, so you'd have to switch it out for a super-speed one such as HD3SS460 that's got a 30s port on it. And then that's the hardware, and that's pretty much the only thing you'd need to change um then the gateway of course gets a bit more complex because more and more you know software defined means oh now we got to define it but um but our gateway library that we've been working on at GSG for many years now

already has some basic USB 3 support. And in fact, if anyone wanted to mess around with it, if you got something like the Lambda concept board, the ECPIX, that's got a Surdeys FPGA on it and Luna can do super speed on that. So it's very much within the same ballpark. Super speed is more complex. Power negotiation is a bit more difficult, and the signaling is a lot more complex.

But, you know, I think if you're interested in super speed, a good place to start would be figure it out in Cynthion, then upgrade to a better board, and then take what you learned. And it won't be such a big step. I think it took me about two weekends to get a super speed up on a dev board when I first tried it. One of the interesting things about Great Scott Gadgets is that, I mean, you just told someone how to take your product and then get rid of your product and do something else. And Great Scott Gadgets is very open about these things.

Yeah. Was that a draw for you when you were hired there 18 months ago? It was the draw. How do they, all right, how do they make money? I guess that's always my question, isn't it? Christopher was like shaking his head, like, I know what's coming here. She's going to say, it's open source. How do you make money? That's always her question. But I guess it is. Is it possible to make money if you're just giving away your information? There is. There's a secret source to it. It's not immediately straightforward. I mean, the recipe is not, hey, build some hardware and just sell it and give away the schematics.

A lot of people are down that, and it often ends in bitterness and unhappiness. I think the big thing that lets us do it at GSG is that our mission as a company is not to make open source hardware. Our mission is educational. We want to put information into the world. We want to let smart people give them the tools they need to figure out how the hell their world works. And what that does is it means that when you buy hardware from us sure you're getting the hardware but you're also getting the community and the mission that comes with that so our interests are aligned with the interests of our customers we never find ourselves in a

position where you know sure people are building clones or someone rips off a design or someone takes our code and builds a completely different product with it because it's not about the hardware it's not about the software it's about the education um and that's a very potent thing you sell because you're opening doors for people and you know you can make free hardware all you want but if it's not opening doors for people, you end up with, like you said, Alicia, you actually end up with a bigger problem than before you bought the tool.

Yeah, it's a fine line to walk because if your product is education and openness, then, you know, you're making products to help people learn things and dig into other, you know, reverse engineer things and stuff, but you can't look at ours. We make all these things for you to break other people's stuff, but please do not look

too closely at ours. Yeah, it's not tenable as a philosophy, I think. Yeah, that's great. You know, being able to chat with people. I mean, through the development of Cynthion. One of the biggest help we had through that whole process was folk who took the prototype schematics and printed our boards and made their own and got talking and became part of the community and ended up actually becoming part of the product development process. We'll get a question from Ben who does not remember what they had in mind when they backed the Synthion. But now that they have one, how would someone go about building their own USB device, not just hacking something into a USB stack? And where would the Synthion help out?

Like, what are the steps to get started? Cool. Cynthia, you've got two options. And often you'll start with one and then do the second one. But the easiest way, the simplest one, and I just want to put a caveat with the current state of the gateway, it'll only work with something that's relatively low bandwidth and not too timing sensitive. But if you

used FaceDancer, we've got an example template that's about, let me count, 70 lines of Python code and you fill that out and you've got a USB device and then you can

hook the endpoints up through Python to wherever your data is coming from or going to. And you can do that in half an hour. If you want to start getting a bit more serious and do high bandwidth, very rock-solid timing, also relatively easy, we've got another template in the Luna repository. Again, about 70-80

lines of code. Gateway. Filled out that template. Basically the details of the device descriptor and then how you want to hook it up to the GPIOs or any other peripherals or whatever else you want to do with the data as it comes in

and goes out. And bam, off you go. And then how do you move from that to, okay, I want to take that, which is kind of a simulation of my device, I guess, to I'm building this on a protoboard. A protoboard, well, if you're building small quantities and you've got a client with deep pockets, you just make a board based on the Synthion hardware with the FPGA on it and ship it as is. That's one option. Another option, if you're very wealthy, is you take the Verilog generated from your design and you get an ASIC manufactured. Or on the other end of that is you've learned enough through your simulation of the device that you're comfortable programming firmware on a microcontroller.

Do you have preferred USB stacks on whatever microcontroller you want to mention? Historically, the NXP stuff sucks the least, probably. It all sucks. The compliment. That said, Espressif have really made some strides. About two years ago, I worked with the current state of USB IDF. It's probably further along now, but I was really happy with that.

The other area with embedded Rust, there's a community USB stack. It hasn't got a huge amount of functionality, and it's advertised as experimental. But for a lot of simple use cases, it's really, really easy and painless to get going. Yeah, I think that's my feelings. Is that kind of an RTOS-diagnostic stack? Or bare metal?

Yeah, it's bare metal, yeah. Okay, cool. Although I think someone ported it to Embassy, which is the... I mean, the embedded Rust... I like the direction they've gone with Async and Embassy and so on. As I said, we don't need no stinking RTOS. Let's just build the whole thing out of coroutines,

which is kind of going back to the way it was done when I was very young. It's kind of going back to the way it was done when I was very young. It's kind of cool. I mean, if it's not timing sensitive, although these days, again, if it's timing sensitive, I'd probably be more inclined to reach for an FPGA. Well, you've

said rust, so it's time for me to close up the show. My apologies. That is not true. I'm having some sort of allergic reaction with my eyes that I can't see anymore. So I am going to close up the show. Antoine, do you have any thoughts you'd like to leave us with? Final thought.

This thing we call engineering, it's fundamentally a form of play, and we can't do it well if our job isn't fun. So for anyone out there, the day it stops being fun, that's the signal that you're ready to start the next stage of your career. What is that next stage? Tell me. Depends on who you are and what you want to do and what excites you. Our guest has been Antoine van Helter. It depends on who you are and what you want to do and what excites you. Our guest has been Antoine Van Helter.

Antoine is a software engineer, electronics hobbyist, and musician who likes to build beautiful things that make the world a better place. Thanks, Antoine. Thank you for having me on. Good night. Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listeners for their questions. Thank you to Memfault for sponsoring this episode. And of course, thank you for listening. You can always contact us at show at embedded.fm or at the contact link on Embedded FM. And now a quote to leave you with by Neil Peart. What is a master but a master student? And if that's true, then there's a responsibility to you to keep getting better and to explore avenues of your profession.