486: A Nice Rainbow Dream
Transcript from 486: A Nice Rainbow Dream with Antoine van Gelder, Christopher White, and Elecia White.
EW (00:06):
Welcome to Embedded. I am Elecia White, here with Christopher White. Our guest this week is Antoine van Gelder from Great Scott Gadgets. We are going to talk about USB and music.
CW (00:20):
Hi Antoine. Thanks for joining us.
AG (00:21):
Thank you for having me.
EW (00:24):
Could you tell us about yourself, as if we met at an online Great Scott Gadget get together mixer.
AG (00:35):
<laugh> Cool. Hey, I am Antoine. I work at GSG. I have been keeping busy developing firmware and gateway for Cynthion, which is an all-in-one tool for building, testing, monitoring, and experimenting with USB devices.
(00:46):
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.
CW (01:00):
<laugh>
AG (01:00):
<laugh>
EW (01:05):
We want to do lightning round, where we ask you short questions and we want short answers. If we are behaving ourselves, we will not ask, "Exactly which pickup?"
AG (01:12):
<laugh>
EW (01:12):
Are you ready?
AG (01:18):
I am ready.
EW (01:20):
What is your favorite musical instrument?
AG (01:23):
Favorite musical instrument? It has always been and remains the electric guitar.
CW (01:29):
All right. What is your favorite pickup?
AG (01:32):
Favorite pickup? Definitely the bridge pickup.
EW (01:36):
Favorite Murderbot story?
AG (01:39):
Favorite Murderbot story? All of them. The whole series. They form one story! How <laugh> can you ask me to choose a favorite?
EW (01:47):
Mine is always whichever one I read last.
AG (01:48):
<laugh>
CW (01:51):
Heel or headstock truss rod adjustment?
AG (01:55):
Oh, definitely heel.
EW (02:00):
What is your least favorite musical instrument?
AG (02:03):
My least favorite musical instrument? It is probably the recorder.
CW (02:06):
Oh God. <laugh>
AG (02:08):
Yeah. I had two years of hell with that in primary school.
CW (02:13):
Is that a worldwide phenomenon? We had to do that too. I do not know why somebody decided that everyone in the world has to learn to play the recorder when they are eight.
EW (02:24):
You are breaking lightning round rules right now.
CW (02:26):
I know. Well, that is fine. Do you like to complete one project or start a dozen?
AG (02:31):
I like to start one gigantic project that is going to take several lifetimes to complete, because that means I am never going to have to feel about dropping any sub-projects once they have served their purpose.
EW (02:43):
If you could teach a college course, what would you want to teach?
AG (02:47):
I would want to teach a course based on- There is this book written by Noam Nisan and Shimon Schocken called "From Nand to Tetris." I do not know if you know about it?
EW (02:57):
Actually, it is called "The Elements of Computer Systems." I only know because I am three quarters of the way through it. <laugh>
AG (03:05):
Cool. But instead of NAND gates, we would start with passive components, diodes, transistors. And instead of Tetris, we would build a hybrid analog digital modular audio synthesizer.
EW (03:18):
Nice.
CW (03:20):
That is more of a college degree.
AG (03:25):
<laugh> Oh, just the course? Oh, damn. <laugh>
CW (03:26):
<laugh>
EW (03:28):
Well, the NAND2Tetris feels like a college degree. But I think it is mostly putting a college degree together. Actually Shimon is going to be on the show soon.
AG (03:39):
Oh, awesome!
EW (03:39):
So if you have questions for him, just go ahead and send them to me.
CW (03:44):
Finally. What is your favorite fictional robot?
AG (03:47):
Got to be Murderbot. I am not sure if SecUnits count, being a little bit human, a little bit bot. Surely they can count? Please?
EW (03:56):
Yes, definitely.
AG (03:58):
Thank you.
EW (04:04):
<music> 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 empowers teams to build better IoT products, faster.
(04:18):
What that means is that if you have just realized that you are going to build five, ten, a hundred, 50,000 units, and you need to keep track of them, they will 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.
(04:46):
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.
(05:04):
Thanks again to Memfault for sponsoring this show. Check out memfault.com and the Interrupt blog, which is filled with incredible amounts of information. <music>
(05:20):
If I wanted to make a musical instrument, what are my options?
CW (05:26):
<laugh>
EW (05:29):
I know that question is much too big.
CW (05:31):
Well, you could start with taking your mug there and smashing it around the room. That is a musical instrument.
AG (05:37):
Basically, if it vibrates, you can jam with it.
EW (05:41):
Okay. So moving outside the trivial, I want to connect it to my computer. Then immediately I am faced with MIDI, or USB, or MIDI over USB, or USB over MIDI? I do not know. I do not think that one works.
CW (06:02):
Just audio.
EW (06:03):
Or just audio. What is better and why?
AG (06:08):
That really goes to the foundations.
EW (06:11):
Depends. That is where the foundations live. <laugh>
AG (06:16):
<laugh> It all just used to be an electrical signal and it would wobble and we are done. So the only reason this is a question is because of history, I think. And maybe practicality. Long time ago when the first synthesizers were coming out, many first synthesizers were just connected with electrical signals. It was all control voltage.
(06:44):
But when the digital stuff started happening, people figured out, "Well, the audio, that is real time. We have got to get 48,000 samples per second from one end to the other, and maybe even do stuff with that, and none of the computers could do that." So they thought, "Well, the one thing we can do is the control data." That is like, "When did you press the key? Which key did you press? And when did you let go of it?" That is what became MIDI.
(07:13):
Nowadays computers are much faster. For practical purposes maybe you still want to do that split. But if you look at a lot of the modular synthesizer culture, some of it that is now getting onto computers and it is being emulated, they are actually sending audio signals for control.
(07:35):
So it depends on what you are trying to do. If you are just trying to send control data, MIDI is what you want to do. And if you do not worry about the timing or the latency on that, MIDI is pretty good. You can get it within ten milliseconds. But if timing or latency matters, no matter if it is control data or audio data or a mixture of the two, you are definitely going to want to use USB.
EW (07:59):
So MIDI is just a stream of those things you said. 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 is not very dense.
AG (08:19):
No.
EW (08:19):
You could run it over a serial port, a fairly slow serial port. Maybe not 9,600, but something-
CW (08:30):
No, it is faster than 96- I cannot remember the actual speed. I think it is 33? Or something.
AG (08:35):
31.25.
CW (08:35):
Yeah.
EW (08:37):
But still that is- I do not want to say "human interpretable," because it is obviously not.
AG (08:43):
<laugh>
EW (08:43):
But it is not like a giga sample per second, or a mega sample per second.
CW (08:51):
Yeah, it is serial. It is like packets, right? Yeah. Well, not packets, but it is control messages.
EW (08:58):
And it is one way, which I guess most musical instruments are.
CW (09:01):
No. It is two way.
EW (09:04):
Yes, but if I play my coffee mug into a MIDI controller, there is nothing to send back to the mug.
CW (09:11):
What if you recorded? Well, if record your performance using MIDI, you can play it back to your device.
EW (09:17):
Oh, right, because we are talking like a keyboard or something, where it has a speaker as well.
CW (09:21):
The synthesizer. 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 is bidirectional.
EW (09:34):
But MIDI does have a few limitations. Like, you can only have so many instruments. And, is it directional?
AG (09:44):
Well, by default you have got 16 channels. It is directional in the sense that the in and out are two separate cables. Yeah.
EW (09:53):
Is there usually a controller, or a master module?
AG (09:59):
Mostly on the computer side. It is a UART.
EW (10:03):
Yeah.
AG (10:04):
Yeah. It is as simple as it gets. The beauty of MIDI when it came out is you could make it with $5 of parts.
EW (10:13):
But then we go to USB, which is- When I think about embedded systems, serial is at the bottom. That is the first thing you implement, because it is the easiest. And USB, you can do it without an operating system, but I usually recommend that if you are going to have USB, you also have an operating system.
CW (10:35):
And maybe buy a stack. Or steal the stack, or have a stack.
EW (10:39):
Have a working stack. Do not develop your own. Whereas serial, it is like, "Yeah, we can just do bit bang on that, if that is what you need." It seems like there is a jump in complexity here that I do not-
AG (10:51):
It is 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 will find historically most synthesizers or other music kit is using a ASIC for the media interface. There is no firmware or software driving, if it is all done in hardware.
CW (11:21):
Oh. So they buy like a USB to MIDI thing, and just slap it down.
AG (11:24):
Yeah.
CW (11:24):
And then-
AG (11:25):
Yep.
CW (11:25):
Oh, okay. Huh. What does the communication to that chip look like, from a microcontroller?
AG (11:34):
It is basically a register based interface on most of them.
CW (11:37):
Okay.
AG (11:37):
Yeah, it is very simple.
EW (11:42):
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?
AG (12:06):
Basically you would set up the register saying, "This is the note on. This is the note. This is the velocity," and off it goes.
EW (12:15):
Oh, so I do not really want an ADC coming in.
CW (12:17):
Right.
AG (12:17):
No, no no.
EW (12:17):
What I really want is-
CW (12:20):
Switches.
EW (12:20):
Switches, or buttons, to tell when things have happened.
CW (12:24):
Or like on my drums. They have piezos for when the head is struck, and then it converts those to MIDIs.
EW (12:30):
So you do not want to do analog acquisition on MIDI. That is where USB starts to come in?
AG (12:37):
That is when USB starts coming in. Those chips basically just have a straight DSP interface. You have 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.
EW (12:52):
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. We say "USB," like it is a thing, but it is not.
AG (13:11):
No. The two specifications form the master specifications, the universal audio class. But there is a sub specification that basically describes how you embed MIDI over the universal audio class device. And they are basically two separate endpoints.
EW (13:31):
And an endpoint is also like a thumb drive or a keyboard.
AG (13:36):
Yeah.
CW (13:37):
I did not realize they put MIDI inside the audio device. Okay. I always thought it was a separate class.
AG (13:42):
No. I mean you can build a MIDI device that does not have audio support, and you can build an audio-
CW (13:49):
Yeah, I have lots of those. <laugh>
AG (13:52):
<laugh> Cool.
CW (13:52):
So we mentioned that the MIDI- The standard old MIDI from the late seventies, I think it is the late seventies- Is fairly slow bit rate and has latency problems. Do those problems go away when you implement it over USB? Because USB is kind of unbounded. It is bounded, but it is comparatively unbounded.
AG (14:17):
Yeah, it depends. It depends a lot on your operating system drivers.
CW (14:20):
Okay.
AG (14:20):
In theory, you can get bit accurate timing, a sample accurate timing, on some setups. But it is worth noting that the few manufacturers that have worked on tightly integrated USB interfaces- I am thinking of the Access Virus synthesizer. That generally they have done quite a lot of custom protocol development of their own, which 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.
CW (15:04):
Oh, I see. Oh, interesting. Okay.
EW (15:06):
I did not get that. You explain.
CW (15:08):
Well, if you have got the digital audio coming over USB as well as the MIDI information, they are going to be skewed a little bit.
EW (15:16):
Yeah, because nothing ever has the same time base, and time is horrible, and never work on time.
CW (15:20):
Right. 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.
AG (15:30):
Yeah.
EW (15:31):
Why would not you just send it all over analog? Or-
CW (15:35):
Analog?
EW (15:35):
I mean, more- Why bother with the MIDI, if you have already got the-
CW (15:41):
Because you want the performance data.
EW (15:42):
The highly sample-
CW (15:44):
Maybe you want to take that audio out, and replace it with a different synthesizer, but keep the performance.
AG (15:51):
Yeah. Or the most common use case is your computer sending MIDI to the synthesizer, and then we are getting the audio back from the synthesizer going to the computer.
EW (16:01):
Okay. Okay. So my computer says, "Go play this note at this method, velocity or key and whatever." And then I am also at the same time recording additional performance information.
AG (16:18):
And the audio output.
EW (16:20):
Okay, cool. Okay. And so universal audio- What was the "C" for? Controller?
AG (16:29):
Class.
EW (16:29):
Class. Class. Right. Mass storage class. They all end with "class." These endpoints are all well-defined. It is not like serial by itself, where you start out with a couple of numbers, and 9600–8-N-1, and you learn how to decode that into the parameters you put into your Pi serial, or into your TeraTerm or whatever you are using.
AG (16:58):
Yeah.
EW (16:59):
USB has a lot more information.
AG (17:02):
Yeah. And it is highly structured.
EW (17:04):
How do I learn about those, and when do I decide it is important to learn about those?
AG (17:10):
The first time you are going to learn about it is when you are in the studio, and you are trying to make sounds on the external synthesizer, and it all sounds wrong. <laugh>
EW (17:24):
<laugh> Yes, that is when I usually learn about things, when it has all gone horribly wrong.
CW (17:30):
That is a second step. The wrong sound is you are making progress. No sound is where I expect to start with.
EW (17:36):
<laugh> Yeah.
AG (17:36):
<laugh> I thought about saying that, but then I thought, "God, no, I do not want to go there." <laugh> So that is the point in your life when you have for the first time downloaded a MIDI monitor. You are going to see the note on note of messages, and you are going to compare it to what you want to happen, and how things are configured, and so on.
(17:58):
If you want to know it deep, the answer as always is, "Read the spec." The universe audio class spec is a lot easier to read, than almost any of the other ones out there. It is a little bit complex when you talk about how the endpoints- Because they are kind of a graph arrangement thing for the endpoint. We can connect endpoints to other endpoints, and so on. But apart from that, it is reasonably straightforward.
(18:23):
The really easy way to do it is to just pull up Facedancer and plug your Cynthion into it, and just look at the data traffic. You will be able to see the numbers there.
EW (18:42):
So these are things you work on. "Cynthion" is what?
AG (18:48):
Cynthion is our USB multi-tool.
EW (18:52):
I pull the multi-tool out of my pocket, and it opens into many things. But it is an FPGA based system, that can then mock up any other USB system?
AG (19:08):
Pretty much. At its core, Cynthion is Lattice ECP5 FPGA, and three USB PHYs connected to it. It has also got some GPIOs, but we will talk about those later I guess. But it is literally a FPGA with three USB ports.
EW (19:29):
In this scenario, I do not know USB, which is only slightly true. And I do not know FPGA. I feel like jumping to Cynthion, is like I do not have either foot on a solid surface.
AG (19:44):
You are describing the last two years of my life.
EW (19:46):
<laugh>
AG (19:46):
<laugh> Apart from the hardware, which is Cynthion- Traditionally Great Scott Gadgets has been a hardware company. We build hardware, and then other people figure out how to use it.
(20:02):
But somewhere in the very, very long time it took to get Cynthion from prototype to shipping product, I think the company changed a bit. 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."
EW (20:37):
It is 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. It is a tool I want to be using, to do something else. I do not want to spend my time learning the tool."
AG (20:52):
<laugh> Yeah.
EW (20:54):
I want the tool to fix my other problems, not create more.
AG (20:59):
<laugh> Do not shave the yak.
CW (21:00):
And adopting a new puppy, to take care of your overactive puppy.
EW (21:04):
Are we getting another dog?
CW (21:06):
We will talk about it later.
EW (21:08):
That is a "No." Anyway.
CW (21:10):
<laugh>
EW (21:10):
Is Cynthion a good way to learn USB? Or a good way to learn FPGA?
CW (21:17):
Or a good way to learn neither? <laugh>
EW (21:17):
<laugh>
AG (21:23):
<laugh> Okay, so number one priority at work, is it has got to be a good tool to learn USB. As far as pretty much the entire team, including the boss, feels, it is a good way to learn, period.
(21:36):
Let us just go back to the MIDI use case. So you buy your Cynthion, you come home, get it out of the box, you plug it in. In one port you plug in your MIDI keyboard, in the other port you plug in your synthesizer. You boot Cynthion up, and you make sure that when you press the notes on the MIDI keyboard, the synthesizer make noises.
(22:03):
One of the first things you can do, is you can start the Packetry software, which Martin wrote. That will give you- It is basically a USB packet capture application. You will be able to capture every USB packet coming from the MIDI keyboard going to the synthesizer. If you look in that, you will see what notes you are playing, and so on and so on.
(22:27):
That is fun in and of itself, but now you want to start learning USB. The first thing you want to do is maybe, well, is take an established class like universal audio class, and maybe something I could do is modify the data as it goes through Cynthion.
(22:46):
And that is the point you pick up Facedancer. And then maybe you write a little Facedancer 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 will transform that data you put into it.
(23:05):
And if you play a D, it will send a D minor chord to the synthesizer. Or maybe you press E and it plays an arpeggio of a E minor chord. This is a great way of figuring out mapping inputs to outputs, working out with what does a particular class do, how to work with it. So that is sort of on a high level.
EW (23:35):
You mentioned Facedancer.
AG (23:37):
Yeah.
EW (23:38):
Which is one of the things you have been working on. It interacts with Python, but what is it?
CW (23:46):
<laugh>
AG (23:49):
<laugh> Cool. I am terrible at-
EW (23:54):
What would you use it for?
AG (23:54):
Foundations. Okay. Facedancer is basically a way to remote control a USB port from Python. So normally when you have got a USB device, the processing happens on the device. What Facedancer does is it takes what is 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 is being provided. I can generate data.
(24:30):
I can make it impersonate other USB devices. By when the host asks Facedancer to numerate, it will say, "Hey, I am a USB FTDI interface. This is my manufacturer and these are my endpoints." And then the host goes, "Ooh yeah, you are." And then it polls it for data, and then Facedancer generates that data.
(24:50):
It is a library for emulating USB devices, intercepting traffic between USB devices, modifying the data between USB devices, in Python.
EW (25:07):
So I have had IMU, inertial measurement unit, devices that can speak over USB, usually some sort of serial because it is 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?
AG (25:32):
Yeah, you could absolutely do that. That is a common use case. Or keyboard. Or a mass storage device.
EW (25:41):
Or I could have somebody plug their mass storage class device in, and then copy all their data, unplug it, and they would never know.
AG (25:51):
Yep.
EW (25:52):
Okay. Well, not everything has the best intentions.
AG (26:01):
<laugh> Yeah. Facedancer started out as a security research tool. Let us be straightforward about that.
EW (26:11):
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 is obviously a bug. Have you had to deal with that?
AG (26:33):
Not personally. But when Facedancer first came out, that was 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, "Give me 56 bytes of data." And people being people they say, "Sure. Here is 255 bytes," and overflow the stack, and do all kinds of fun things. <laugh>
EW (27:14):
People on Facedancer would do that to the computer, and therefore make the computer unhappy?
AG (27:20):
Yeah.
EW (27:21):
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 Facedancer. And so that is all Python, right?
AG (27:37):
It is all in Python, which- 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.
EW (28:02):
I have used Wireshark-
AG (28:03):
Yeah.
EW (28:04):
On my PC to debug USB. Why would I use Facedancer instead?
AG (28:12):
Well, Facedancer's native file format is pcap.
EW (28:16):
Pcap. Okay. Which is Wireshark.
AG (28:16):
So basically you can save a Cynthion capture and view it in Wireshark. Which is great because Wireshark can do high level class decoding, which Packetry does not support yet.
EW (28:33):
Packetry. You mentioned that, and I have already forgotten what it is, please.
AG (28:38):
Packetry is our packet capture app. It is a graphical user interface, that basically you get a long stream of USB messages when you press record, and that is real time traffic going through Cynthion.
EW (28:53):
Why would you use that instead of Wireshark?
AG (28:57):
Wireshark can only get what the operating system kernel is going to give you, and I think it is hard to get it to work on anything except a Linux machine. What we doing with Cynthion and Packetry is it is a pass through interface. We are not taking the data, interpreting it, throwing it out the other side. Is we literally capturing the traffic on the bus.
CW (29:26):
Hmm. Okay.
AG (29:28):
Which can also give us some insight into bus errors, and the low level parts of the USB packet are visible.
(29:38):
So you are basically on Wireshark, you are only going to see, "Hey, there was a packet." You are 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.
EW (29:51):
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?
CW (30:01):
You can.
EW (30:02):
You have already done that. Check mark.
AG (30:04):
Yeah. <laugh>
EW (30:04):
Cool. Christopher, you had USB issues earlier this year-
CW (30:12):
Mm-hmm.
EW (30:13):
With a poorly formed library on a microprocessor of some variety. We are not definitely not mentioning it.
AG (30:17):
<laugh>
CW (30:20):
Well, I do not remember. There were some hardware issues, because it was a new chip, but yeah. Mm-hmm.
EW (30:26):
What tool did you use?
CW (30:28):
I used the expensive analyzer that has existed for 20 years.
EW (30:34):
The Beagle?
CW (30:35):
The Beagle, yeah. Which was fine.
EW (30:42):
<laugh> Have you used the Beagle, Antoine?
AG (30:45):
I actually have not. It is too expensive <laugh>.
EW (30:48):
Fair.
CW (30:48):
Yeah. If I recall, it was fairly expensive. It was like 2,500 bucks or something.
EW (30:54):
Yeah. And if the client had not bought it, I knew two people who had them, who we could borrow them from. But yeah, I was not going to buy one for just us. But we could do similar things with Cynthion.
AG (31:08):
Ooh, yeah!
EW (31:10):
How much does it cost?
CW (31:10):
<laugh> Getting to the real.
AG (31:14):
I actually have no idea, I am ashamed to say. <laugh>
EW (31:16):
<laugh>
AG (31:16):
I would have to look it up. <laugh>
EW (31:20):
Much cheaper?
CW (31:27):
Adafruit has them, and they are $200.
EW (31:31):
Okay.
AG (31:31):
There you go.
CW (31:35):
Yeah, it does seem like- It is a difficult thing to do, right? Because you are, like you say, you are not storing and forwarding, right? You are not actually a man in the middle attack on things, although you can be.
(31:48):
But it is letting things go through the bus, while also snooping on the bus, which sounds like a little bit of a hardware challenge to not- It is like the quantum thing. You cannot look too hard at things or you change them, right?
EW (32:02):
And then you could parse it in the Cynthion Packetry. And then, did you say Packetry saves to pcap? Or how do I get the pcap out?
AG (32:11):
Yep.
EW (32:12):
Okay.
AG (32:12):
Yeah. You just "File -> Save" off to your capture.
EW (32:17):
That sounds nice. Okay. Let us work on some other listener questions. Mitch asks, "What is the worst bug hunting experience with USB you have had, and how does it involve zero length packets?"
AG (32:33):
Okay. Someone else has been there. <laugh> Yes. Yes, it did. All three times, with possibly a fourth one that was reported on Friday last week, and that is all I am going to say about it. <laugh>
EW (32:47):
Okay. For those of us not in the USB know...
AG (32:50):
Okay, so zero length packet is a acknowledgement packet in the USB protocol. I think Michael, my boss at GSG, he says, "There is not a USB stack in existence, that does not have at least one ZLP bug."
(33:10):
The protocol is weird. It is not always clear when should you send a ZLP, and when you should not. And if you get it wrong, the entire thing crashes. And you are not sure exactly where in the transaction it crashed.
EW (33:27):
What is "it" in this?
AG (33:29):
The ZLP, the zero length packet.
EW (33:32):
No, no. What crashes?
AG (33:35):
The device. And sometimes if you are really lucky, the host as well.
EW (33:42):
<laugh> Have you considered just flooding everything with zero length packets?
AG (33:48):
Well, that is the first thing you try. <laugh> And then it goes even more wrong.
CW (33:59):
It does seem like- This is a little bit of a tangent. But it does seem like USB is almost uniquely tough to get right. There is the diplomatic way of saying it.
AG (34:11):
That is the diplomatic way of saying it.
CW (34:13):
I think I have been doing USB in embedded since around- I think the first time I had to use it was around 2006.
EW (34:21):
Oh, I have code from 1999.
CW (34:24):
Well, I was doing core routers back then. Did not have USB. We did not care for USB.
EW (34:29):
Mine was so bad.
CW (34:29):
USB was ten times- They are 50 times too slow.
AG (34:32):
<laugh>
CW (34:32):
But mass storage- On embedded, we could get an operating system that would come with a stack. And 30% of the mass storage devices you would buy on Amazon just would not work. Or would not work in some weird way. Or they had to be configured slightly differently. And you had--
EW (34:54):
But they had internal hubs with multiple additional-
CW (34:56):
Right. Or you had to hack the stack some way. From a consumer perspective, computers tend to seem to work okay. I have not 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 is the deal?
EW (35:17):
<laugh>
AG (35:19):
They are not great.
CW (35:20):
Yeah. Is everybody implementing their own stack? And it is just so complicated that you cannot get it right. And if you are a Microsoft, you can after 20 years?
AG (35:30):
20 years having to worry about only one target, does get you a little bit further. But a lot of what is happening is that- Well, there are two things.
(35:41):
There are a lot of prepackaged USB solutions. "This will give you a keyboard, and you do not have to program anything." "This will give you a serial port. You do not have to program anything." "This will give you a mass storage. You do not have to program anything."
(35:55):
That stuff has terrible quality assurance on them. It is normally made by a single manufacturer, that has a small team working on it. They just want to shift chips. And people buy what is cheapest. That is the one part of it.
(36:13):
But then the other part of it, is implementing a USB stack right, is really, really difficult. It was doing the USB stack for Cynthion, is probably the hardest bit of engineering I have had to do in my career.
EW (36:31):
Which part? At the bottom it is a serial protocol.
AG (36:37):
Yep.
EW (36:38):
I am really good with those.
AG (36:39):
Yeah. <laugh>
EW (36:41):
But then it goes horribly wrong. Where exactly?
CW (36:44):
At the bottom the internet is just ethernet, which is just some wiggling of wires.
EW (36:48):
Exactly. Where does it get really impossible?
CW (36:53):
DNS.
EW (36:53):
<laugh>
AG (36:53):
<laugh> It all went wrong in the committee.
EW (37:01):
Is that true? Is it the problem that there were so many people advocating for their particular versions, their particular needs, that the entire spec is weird?
AG (37:14):
I think that is a big part of it. I think a lot of the focus was on trying to integrate the end user cases, which did not leave a lot of engineering resources for figuring out what the actual transport protocol should look like.
EW (37:31):
There is "specifications separated from implementation," is often a good idea.
AG (37:37):
Oh, it is a great idea, if your transport protocol has been really well thought out. Ethernet is a joy to work with.
CW (37:44):
Right. It is simple.
AG (37:47):
Yeah. USB complexity is- <sigh> I 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. For a transport protocol, that is terrifying. It is also very hard to find information about it.
EW (38:15):
Yes! Yes. Yes. Yes! And it has changed so much. We say "USB," like it is one thing. But it is definitely not one thing. Between speed changes and protocol changes. It is not one thing.
AG (38:35):
No. Low speeds. Not high speeds. Not SuperSpeed.
CW (38:39):
What do you think causes- The promise of USB were these classes, right? That like, "Okay, we have as many devices we want to attach. Each of them is going to have a class. You can just write a driver for that class, and you are off to the races. Every device that implements that class is going to be the same. You can just plug them in and everything will work."
(38:58):
But as we have seen with mass storage particularly, stuff just does not-
AG (39:03):
<laugh>
EW (39:05):
It was such a promise. It was such a nice rainbow dream.
CW (39:08):
Is that due to over complexity at some level? Why are mass storage devices so frequently incompatible?
AG (39:18):
Separation of concerns when you are building layered protocols. I think they should have put more networking folk on the USB committees. <laugh>
EW (39:31):
I mean the other side of that whole mass storage class device debacle is USB to serial.
AG (39:41):
Yeah.
EW (39:41):
Which FTDI won. I mean we do not even say, "USB to serial cables" anymore. We say, "FTDI cables." Like that is the only option. And master storage classes did not get a winner, so they did not get a consistency.
CW (39:58):
Well, it does not have a chip. The FTDIs are-
EW (40:01):
Right.
CW (40:02):
They are the whole thing in there. You do not have to, quote, "worry about it."
EW (40:06):
It is a chip in your cable.
CW (40:08):
Yeah. I assume there are USB to SCSI chips you could buy, if you want to do something like that.
EW (40:16):
Are there other classes you can think of, Antoine, that have winners and not winners?
AG (40:24):
Um.
EW (40:28):
You mentioned a MIDI to USB.
AG (40:30):
Yes. The USB audio class is kind of weird. I do not know enough about the history of it. But out of all the classes I have worked with, it is 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 is basically just a PCM encoded packets.
(40:55):
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!
(41:08):
It is kind of a mindset with protocol design. You can either approach a protocol from, "Well, I have got 101,000 different use cases, and I am going to special case every one of them." Or you think, "Well, look, this is what the data flow looks like. This is the actual data that is going from point A to point B," and then you layer your exceptions on top of that.
CW (41:39):
I am guessing MIDI 2.0 went for the first.
AG (41:41):
Yeah. That one. <laugh>
CW (41:44):
Yeah, I have not seen that on devices that much. Is that- I guess, most things are-
EW (41:51):
What do you mean?
CW (41:52):
MIDI 2.0.
EW (41:53):
The devices cannot handle them?
CW (41:54):
No, I just have not seen it advertised as, "Oh, this synthesizer comes with MIDI 2.0," or anything like that.
EW (42:00):
How long has it been out?
CW (42:01):
It has been out for a while, I think.
AG (42:02):
Yeah.
CW (42:02):
But yeah. I think most things are still just putting whatever, the 1.1 or 1.0, on.
EW (42:10):
Because they do not need the corner cases provided by MIDI 2-
CW (42:14):
And there are some extensions to the original MIDI, right? I have one thing that has- Normally velocity, I think, is either seven or eight bits, but there is an extended velocity that gets you 16 bits of velocity, or something like that. I have one device that does that.
(42:32):
If I was making MIDI 2.0, 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."
AG (42:42):
And leave everything else alone. Yeah. Exactly.
CW (42:46):
Surprised they are over complexifying it beyond that.
EW (42:49):
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?"
CW (43:01):
Oh. Hm.
AG (43:03):
That is a great question. So let us ask, "If we wanted to take a Cynthion and make it a SuperSpeed device, what do we need to do?" So there are two layers. One is the hardware, the other one is the gateware running on top of the FPGA.
(43:23):
On the hardware level, the FPGA we are using is the LFE5E series, and those chips do not support a high speed interface. So you want a FPGA that has got a SerDes capability like the LFE5U, I think is the equivalent Lattice part.
(43:44):
Then you would need to switch out the PHYs, the USB PHYs, the physical interfaces. We have currently got high speed PHYs, so you would have to switch it out for a SuperSpeed one such as a HD3SS460 that has got a SerDes port on it. And then that is the hardware. That is pretty much the only thing you would need to change.
(44:08):
Then the gateware of course gets a bit more complex, because more and more software-defined means, "Oh, now we have got to define it." <laugh> But our gateware library that we have been working on at GSG for many years now, already has some basic USB 3.0 support.
(44:29):
In fact, if anyone wanted to mess around with it, if you got something like the LambdaConcept board, the ECPIX, that has got a SerDes FPGA on it, and LUNA can do SuperSpeed on that. It is very much within the same ballpark. SuperSpeed is more complex, power negotiation is a bit more difficult, and the signaling is a lot more complex.
(44:57):
But I think if you are interested in SuperSpeed, 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 will not be such a big step. I think it took me about two weekends to get a SuperSpeed up on a dev board when I first tried it.
EW (45:26):
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. Great Scott Gadgets is very open about these things.
AG (45:45):
Yeah.
EW (45:47):
Was that a draw for you when you were hired there 18 months ago?
AG (45:52):
It was the draw.
EW (45:55):
All right. How do they make money? I guess that is always my question, is it not? Christopher is shaking his head like, "I know it is coming here. She is going to say, 'It is open source. How do you make money?' That is always her question." But I guess it is. Is it possible to make money if you are just giving away your information?
AG (46:15):
It is. There is a secret sauce to it. It is not immediately straightforward. The recipe is not a, "Build some hardware and just sell it, and give away the schematics." A lot of people have done that and it often ends in bitterness and unhappiness.
(46:32):
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. What that does, is it means that when you buy hardware from us, sure you are getting the hardware, but you are also getting the community and the mission that comes with that.
(47:11):
So our interests are aligned with the interests of our customers. We never find ourself in the position where, 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 is not about the hardware, it is not about the software, it is about the education.
(47:31):
That is a very potent thing you sell, because you are opening doors for people. You can make free hardware all you want, but if it is not opening doors for people, you end up with, like you said Elecia, you actually end up with a bigger problem than before you bought the tool.
CW (47:52):
Yeah, it is a fine line to walk, because if your product is education and openness, then you are making products to help people learn things and dig into other- Reverse engineer things and stuff. "But you cannot look at ours!"
EW (48:05):
<laugh>
CW (48:05):
"We make all these things for you to break other people's stuff, but please do not look too closely at ours." Yeah, it is not tenable as a philosophy, I think.
AG (48:16):
Yeah, that is great, being able to chat with people. 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.
EW (48:40):
We will get a question from Ben, who does not remember what they had in mind when they backed the Cynthion. But now that they have one, "How would someone go about building their own USB device, not just hacking something into a USB stack? Where would the Cynthion help out?" What are the steps to get started?
AG (49:05):
Cool. Cynthion, you have got two options. Often you will start with one and then do the second one. But the easiest way, the simplest one- I just want to put a caveat with the current state of the gateware, it will only work with something that is relatively low bandwidth and not too timing sensitive.
(49:25):
But if you used Facedancer, we have got an example template that is about, let me count, 70 lines of Python code. You fill that out and you have got a USB device. Then you can hook the endpoints up, through Python, to wherever your data is coming from or going to. You can do that in half hour.
(49:54):
If you want to start getting a bit more serious, and do a higher bandwidth, very rock solid timing. Also relatively easy. We got another template in the LUNA repository. Again, about 70, 80 lines of code, gateware.
(50:10):
Fill 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.
CW (50:27):
And then how do you move from that to, "Okay, I want to take that, which is kind of a simulation of my device, to, I am building this on the proto board"?
AG (50:42):
If you are building small quantities and you have got client with deep pockets, you just make a board based on the Cynthion hardware with the FPGA on it, and <laugh> ship it as is. That is one option.
(50:56):
Another option if you are 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 have learned enough through your simulation of the device, that you are comfortable programming firmware on a microcontroller.
EW (51:18):
Do you have preferred USB stacks, on whatever microcontroller you want to mention?
AG (51:26):
Historically, the NXP stuff sucks the least probably.
EW (51:29):
<laugh>
AG (51:29):
It all sucks.
EW (51:29):
Oh! The compliment.
AG (51:37):
<laugh> That said, Espressif have really made some strides. About two years ago I worked with the current state of ESP-IDF. It is probably further along now, but I was really happy with that.
(51:51):
The other area, with embedded Rust, there is a community USB stack. It has not got a huge amount of functionality and it is advertised as experimental. But for a lot of simple use cases, it is really, really easy and painless to get going. Yeah, I think that is my feelings.
CW (52:15):
Is that an RTOS agnostic stack, or bare metal?
AG (52:21):
It is bare metal, yeah.
CW (52:23):
Okay. Cool.
AG (52:24):
Although I think someone ported it to Embassy, which is the- The embedded Rust folk, I like what the direction they have gone with async and Embassy and so on. As they said, "We do not need no stinking RTOS. Let us just build the whole thing out of co-routines," which is going back to the way it was done when I was very young. <laugh> It is kind of cool. If it is not timing sensitive.
CW (52:50):
Right.
AG (52:50):
If it is timing sensitive- These days, again, if it is timing sensitive, I would probably be more inclined to reach for an FPGA.
EW (52:59):
Well, you have said "Rust," so it is time for me to close up the show.
CW (53:02):
<laugh>
AG (53:05):
<laugh> My apologies.
EW (53:07):
That is not true. I am having some sort of allergic reaction with my eyes and I cannot see anymore, so I am going to close up the show.
(53:14):
Antoine, do you have any thoughts you would like to leave us with?
AG (53:20):
Final thought? This thing we call "engineering," it is fundamentally a form of play, and we cannot do it well if our job is not fun. So for anyone out there, the day it stops being fun, that is the signal that you are ready to start the next stage of your career.
CW (53:38):
What is that next stage? Tell me.
AG (53:39):
<laugh>
EW (53:39):
<laugh>
AG (53:40):
Depends on who you are, and what you want to do. And what excites you!
EW (53:45):
Our guest has been Antoine Van Gelder. Antoine is a software engineer, electronics hobbyist and musician, who likes to build beautiful things that make the world a better place.
CW (53:59):
Thanks, Antoine.
AG (53:59):
Thank you for having me on. Goodnight.
EW (54:04):
Thank you to Christopher for producing and co-hosting. Thank you to our Patreon listeners Slack 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@embedded.fm or hit the contact link on embedded.fm.
(54:19):
Now a quote to leave you with, by Neil Peart. "What is a master but a master student? And if that is true, then there is a responsibility to you to keep getting better and to explore avenues of your profession."