-
Hack Chat Transcript, Part 2
02/26/2020 at 21:06 • 0 comments@alexwhittemore That means you need to start scheduling the transfers in advance; which means using the async API; which brings the Usual Asynchronous Fun.
In KiCad (newer versions at least) diff-pairs are pretty easy to route. Pcbnew automatically detects lines ending with "+"/"-" or "_P"/"_M" and starts a diff-pair. So I didn't even waste a lot of time on it.
Every device should support "local processors" that can speak full speed to the sensors. Collect raw data, then analyze that data for optimal LOSSLESS compression. Many devices are running at high speed sending redundant data. Then wondering "why don't I have enough bandwidth to get my data from the sensor to the disk over there?"
@Kate, would you have recommendation for any open source USB stack that don't use Linux?
@ThanhTran as in, an open source host-driver stack?
tinyUSB is nice
@Kate Temkin: Both host and device mode
Thanks @de∫hipu
how well does TinyUSB really do host mode?
(Also: in regards to what I've been saying to @alexwhittemore: don't get me wrong -- you can use libusb quite effectively on Windows; you'll just need to do more "install time" configuration than on e.g. Linux or Mac.)
I see Adafruit & others using it, but mostly for device mode. Who's actually deploying TinyUSB for host use?
@ThanhTran I've used tinyUSB in device mode, and it is quite nice, if your CPU is supported by it [or you're willing to write a driver]. It has host mode; but I haven't played with that side of it. :)
Thanks @Kate Temkin
@Paul Stoffregen never used host mode on it, so I can't say, I think it does hid host on samd21 at least...
Host drivers are significantly more complex than device drivers; and embedded hosts applications on tiny microcontrollers are, relatively speaking, a lot more rare; so stacks like tinyUSB are usually built to target either a few easy cases or some very specific ones.
(Host *stacks, anyways)
I have to leave now. You are all arguing how to optimize with parts within USB and the real issue, and probably the solution, is to deal with all devices. When you look at the core hardware interface in all OSs it has been treated as a stepchild of the OS that only wants to sell software or hardware. If the SENSOR community will set up their own core services in each OS, but independent, then you might gain some measure of control and stability. Then you can optimize USB to Ethernet, USB to disk, and the other data flows.
Data flow optimizations is NOT something that OS and browser are good at. So build it from the hardware up, but do it with a global open community. Raise the money. A few hundred million would be cheap.
I just saw nMigen mentioned above - it looks like a super cool project, but I haven't seen much information about it. Any thoughts on it?
@WRR Honestly, I think nMigen [or something that looks a lot like it] is probably the direction a lot of people will end up going in.
Original Migen has a pretty expansive community; even if it's not anywhere near as expansive as the "classic" languages (VHDL/Verilog).
I haven't touched FPGAs but at first sight having a real programming language to generate stuff with seems like a good idea
Yeah, it does seem like a friendlier sort of HDL, and the "misoc" moduar RISC-V core looked like a cool idea. Thanks, and sorry to distract from USB!
In what I've done with them, languages like nMigen and original Migen are incredibly empowering. It's extremely difficult to create an "open stack" that's more than trivially customizable in VHDL or Verilog, since the languages really limit how parametrically you can design things.
@Kate Temkin What EMI protection would you recommend? What other companion ICs would you add on the board for a perfect USB design? Say you have USB connector and an FPGA; what's between them? I guess the answer is a bit different for USB host, USB device, USB OTG, USB Type-C with PD, USB Type-C with SS lines.
@Matti Virkkunen FWIW, designing FPGA hardware is almost nothing like programming in the classical sense, which is why HDLs look very little like "real" programming languages. But then the biggest issue with traditional HDLs like Verilog and VHDL is speed and ease of use, which is why projects like this have sprung up.
@alexwhittemore I'd actually argue that traditional HDLs are a bit too much like programming, but in all the wrong ways -- which is why we wind up kind of creating the right shape for our designs in VHDL or Verilog, and hoping a synthesis tool can infer what we mean from it.
@alexwhittemore Yes, I know the logic you're writing isn't like normal programming. But having a "real" programming language to aid in automation, generation and parametrization seems like a good idea.
@Kate Temkin - Has any testing been on how well ViewSB can process a continuous 480 Mbit/sec stream (or even some fraction, like sustained 20-30 Mbyte/sec transfer of SSDs), especially on Windows & Macintosh?
@Kate Temkin maybe. They definitely let you under-specify, in a way that looks like it should work but doesn't actually synthesize rationally.
@Twisted Pair in my Hair EMI isn't my area of specialty; but generally following the guidelines for {your individual USB frontend, the USB specification} regarding layout and impedance control goes a long way. If you're using something that's not meant as a PHY, a lot of avoiding EMI is the same complex impedance-matching problem that you have in other RF-frequency design.
@Kate Temkin : how does a hacker / very small volume producer of gadgets deal with need for unique VID? The price is a little steep if you are not committed to idea of becoming a registered vendor.
VHDL and Verilog are languages designed to describe hardware -- you use them to describe behavior, and try to make it so your description maps well to the technology you're going to synthesize things into. nMigen is a python toolkit for _constructing_ hardware, rather than describing its behavior -- which is a subtle but important difference.
@salec Typically, the tactic is to use someone else's Vendor ID, with their permission. OpenMoko and e.g. http://pid.codes/ give out PIDs to open source projects under their vendor IDs; which they've inherited from organizations that have e.g. stopped producing new devices.
Adafruit also gives out PIDs for CircuitPython-based projects.
We're up to the one hour mark, so we have to let Kate get back to work if she needs to. Everyone is of course welcome to stay on and chat, though. I want to thank Kate for the lively and wide-ranging discussion, and thank everyone for participating.
It's been awesome chatting with you all. ^^
@Kate Temkin thank you!
thanks :)
A reminder that I'll post a transcript right after the chat, and for next week's Hack Chat concerning On-Demand Manufacturing:
https://hackaday.io/event/169814-on-demand-manufacturing-hack-chat
On-Demand Manufacturing Hack Chat
Dan Emery will host the Hack Chat on Wednesday, March 4, 2020 at noon Pacific Time. Time zones got you down? Here's a handy time converter! One of the downsides of this model is the need for initial capital to buy the machines and build the factory.
Thanks!
thank you!
Thanks @Kate Temkin! And thanks to everyone for dropping by. Hope to see you again soon!
-
Hack Chat Transcript, Part 1
02/26/2020 at 21:06 • 0 commentsOK, let's get started. We're happy to have Kate Temkin here today to talk about USB hacking. Kate gave half of a great talk at Supercon on Everything SDR, so we wanted to ask her to drop by to keep the conversation going, and get more specific about USB
Hi, everyone!
Welcome, Kate - can you tell us a little about yourself?
@Nicolas Tremblay do you have a lathe of turn undead?
Sure! I lead the software team -- and create all kinds of digital things -- over at Great Scott Gadgets. I like to work on all kinds of tools and educational materials; the kind of things that let people interact with and understand little pieces of technology.
In that case I've written a USB stack once from scratch (for microcontrollers with USB peripherals) so I guess that's low level
I do a fair amount of USB stuff -- I'm actively working on hardware and software for USB analysis/emulation/hacking. I also do a bunch of other things -- of late, I've been doing a lot of work with Lattice FPGAs, since they now have open-source tooling.
@de∫hipu nope, we have a mill to churn out more at a decent pace
@Kate Temkin How can a beginner start with USB?
@Kate Temkin What should be the steps to learn and code USB?
@Kate Temkin Do you run into any enumeration issues with USB3.0 and Windows 10?
A lot of the "getting started" depends on what kind of things you want to do with USB -- there's a pretty wide range of stuff, from "writing USB code for microcontrollers" to "writing host drivers" to "creating the raw hardware/gateware that talks USB".
@Kate Temkin Aren't these already available? I didn't have to do anything with my ucontroller and my pc (windows and Linux). So where does USB development comes handy. Sorry if these are very basic questions
@Kate Temkin - Is Rhododendron shipping? Or if not, any idea of when it will become available for sale?
@Kate Temkin , wich basic tools do you use to code USB for microcontrollers? Wich language, IDE, etc ?
And cheers from Argentina!
For my money - WHAT ABOUT HOST DRIVERS!? Like, ok, I've got a gadget, it needs to blast data over usb at 1GB/s. I know USB is a good choice, I know it has to be USB3, I know it can't be usb serial/virtual COM. Where do I start?
@alexwhittemore What about 1G or 10G ethernet? Why USB?
@Paul Stoffregen I'm actually not sure if Rhododendron is going to be released, or if we're going to go straight to LUNA -- which is kind of my follow-on project to Rhododendron.
Ok, hypothetically speaking, call it 1.5GBps. And no 10Gig ethernet because who has that?
@Kate Temkin did you ever work with ST microcontrollers and usb? If yes what is your opinion about their HAL functions vs low level calls directly? Spent weeks on my current projects getting a composite device to enumerate correctly and it was quite a battle until everything worked... There were many half baked things that caused some confusion.
I feel that it might have been better to learn it from the beginning on with lower level implementations.
For reference, Rhododendron is a super-low-cost USB analyzer I've worked with that rides atop the GreatFET platform. LUNA is a standalone USB multitool that I'm designing with similar low-cost goals; and which supports analysis.
@alexwhittemore I thought pretty much all modern ethernet cards are 10G?
@Mark J Hughes I spent the last couple of years looking at global sensor networks and many devices start out as USB.
What is missing for the mostly Internet browser community is a localhost server that can talk to the device and be access through websocket or http requests from browsers (javascript) and remote sites.
Windows can't do it, ChromeOS refuees to, Mac no, Android no, Linux no. Too many dialect and philosophies. So after hammering it to death, I think a compiled application running as service in any of these environments that gives read write to devices is the simplest and fastest way to serve the largest number of people.
Are there specialized requirements yes. But "read a file or directory". "Save sensor data to disk". Send data to that device. Compare these two cameras.
@de∫hipu well, for one, it's the USB hack chat - so the hypothetical is contrived for the purpose here :). But also, absolutely not. No way.
Oh, hadn't heard of LUNA. Clearly I've not kept up. Is any info published about it at this point?
I'm working on a system on module PCB for integrating a TI Sitara AM4377 onto some EtherCat devices we're developing for work so we can hand-solder the various iterations of prototypes..... The AM4377 is ARM9 based. Does anyone in the group have experience writing the drivers for the ARM9?
@RichardCollins I thought that browsers have USB support already?
@de∫hipu 10gig-e is now attainably-priced, but absolutely not ubiquitous. Think like $150 for a dongle or card.
@Kate Temkin Thank you for all your contributions and inspiration to the community. What USB bus challenges does one have to be cognizant of in design of USB SDR like devices
@alexwhittemore If your device is something other than e.g. a flash drive or image capture device, and you're not producing Lots (TM), your choices tend to be pretty limited in terms of "ways to implement SuperSpeed USB without a headache". The common hobbyist ways are to use something like an FX3 (an expensive Cypress USB3 microcontroller) or to use a FIFO chip like a FT601.
@de∫hipu Individualized and crude and incomplete.
@de∫hipu If by browsers you mean "just Chrome" (and its children like Edge nowadays) then yes
@alexwhittemore that sounds like a reasonable price for an industrial use case
@Paul Stoffregen LUNA is open-source; and there's _some_ information about it in the repository: https://github.com/greatscottgadgets/luna ; but mostly I've been keeping quiet about it until it's more ready. :)
@Matti Virkkunen of course I didn't mean lynx
@de∫hipu Firefox doesn't support WebUSB for one.
@Matti Virkkunen I'm sure you can write a plugin
Of course but that beats the point. Might as well write a standalone service at that point.
webusb is coming to firefox eventually, its just not a finalised standard yet
How important are the "low-power sleep mode" requirements in practice? It sounds like bus-powered devices are only supposed to draw up to 2.5mA when they aren't being addressed, which seems hard to manage
@Paul Stoffregen The short version is: it's an ECP5, FPGA-based toolkit for creating open USB devices in gateware -- which lets you use it as a specialized FaceDancer or analysis board that actually builds the gateware you're interested in on the fly. :)
WebUSB support in Chrome is spotty at best as well, for instance on Linux it often doesn't have the necessary permissions so it's not exactly "Plug and play"
@Kate Temkin Interesting point. I haven't ever tried to implement a custom USB SS controller. Ok, so re-contrive my example to drive better at USB device drivers. I want to implement something faster than virtual COM, perhaps still only HS. Where do I start writing a driver? Or how do I shoehorn a generic get-data-from-A-to-B into an off-the-shelf HID device or something? What even is the menu of options?
I think they are too busy adding support for oculus rift to care about web standards
@alexwhittemore Depends -- do you need to support Windows, specifically?
For what it's worth you can have USB serial (CDC ACM) over HS USB as well as far as I know. And Windows supports that automatically now.
sounds very interesting ;)
@baldrick (NE2Z) For something like an SDR, usually figuring out how to squeeze throughput from the bus is the hard part.
@Kate Temkin Let's say yes, but then, why ask the question? What's the difference?
However if it's real time data then USB serial isn't the best option. You'll want isochronous transfers.
I made it! @Kate Temkin I really enjoyed your talk at Teardown last year, excited to hear what you've been up to since
@WRR Lots and lots of devices completely violate the low-power mode current-draw specifications. :)
@Kate Temkin meta question, which it seems you're touching on. Where are things at with the work that GSG has been doing around USB FBGA cores? (i.e.is it still best to get a separate IC for the PHY layer and implement protocol on the FPGA or would you recommend users still, for the time being, going with a fully integrated USB answer and solely focus on interfacing that way)
@alexwhittemore You can pretty easily get very high throughput using libusb's asynchronous transfers; but they're more of a pain on Windows than on other platforms. So, the degree of Windows support determines a lot of what's "easiest".
Like, if I'm implementing a generic widget, the one thing I KNOW works is a USB serial adapter, and then I can simply shuffle data over UART. But that's limited in 1) speed (like, ~1mbps, or i guess maybe more if you're using a device with a native USB phy? I'm not sure what the practical limit of a virtual COM port is on an embedded device with native HS PHY), but also "device shows up as a virtual COM port" is not the cleanest from the software side. On both windows and mac, how do you figure out "which serial port"? So like, what are the other options?
I guess it sounds like "libusb" is your goto - what does that entail?
same question, writing device drivers for anything but hid is a mystery to me, would love to know a bit of detail what writing a driver with libusb entails, even if its linux only
@brianredbeard For low speed or full speed, you can operate completely PHY-less pretty darned well with nearly all FPGAs. For high speed, you're probably best off adding a ULPI PHY, since 480Mbps clock recovery is non-trivial, and they're cheap.
@Prof. Fartsparkle writing drivers even for HID is a mystery to me :)
@brianredbeard SuperSpeed, on the other hand, has a PCIe-like-fronend enough that it shares a PHY communications standard (PIPE, the PHY interface for PCIe); which means you can actually use FPGAs with built in SerDes modules to talk USB 3.0.
Florent / enjoy_digital actually has wrappers that provide a PIPE interface to FPGA SerDes's, so they look like USB3 PHYs. :)
@alexwhittemore I guess driver is the wrong word in this case I guess, lets rather say get data through HID :D
there are some nice examples for TinyUSB Arduino lib if you want to give it a try, I wrote the PC side example for it
Yes libusb isn't "drivers" in the "kernel driver" sense at least. Entirely in user space. In the end it's not much more complicated than using, say, sockets. Find a device, claim it, transfer some data back and forth.
oh nice so can we expect USB3.0 IP cores for something like the ECP5 at some point?
@Kate Temkin i'll need to dig into some of those specifics. Thanks for the breadcrumbs on a new trail to explore.
@Prof. Fartsparkle There's actually an already existing one; though it's in Verilog -- https://github.com/mossmann/daisho
@Kate Temkin Have you ever worked with stm32 usb stack or cypress microcontroller?
oha
@Kate Temkin "*though* it's in verilog"?
If you use that with https://github.com/enjoy-digital/usb3_pipe, you can already talk USB 3 using an ECP5's SerDes. :)
@alexwhittemore Contrasted to a new technology like nMigen.
Ah
@Kate Temkin I once designed a 7-port USB 2.0 hub. For every D+/D- I routed differential pairs. Then I was told that I did unnecessary work as the transfer speed is so low. Was it really unnecessary or not?
I am recommending to write a Service that is just a compiled App in any of these OSs
It simply can speak to any device, or call modules to do so. It replaces the device drivers in all the OSs
Built for speed and interoperability and universal ease of use.
The behavior is controlled by an open community, not any one of the browsers or IDEs or libraries or OSs that have their own agendas, biases and limitations.
yeah, like Microsoft is ever going to do for anything like that!
@RichardCollins I didn't get your idea. Please elaborate
How much time are you (all USB users) wasted just trying to get things to work in one OS, let alone be able to run in any?
@Twisted Pair in my Hair Don't confuse "transfer" speed with rise/fall times. It's not the speed that causes EMI -- it's short rise/fall times. But in a broad sense, USB-2.0 forgives a lot, and I mean a lot of sins.
For USB 2, routing things differentially was definitely the way to go. Even if the mutual inductance wasn't necessary for noise immunity; you'll probably have a lot better a time with EMI with those traces routed properly. :)
@Twisted Pair in my Hair I've done mean things routing USB2.0 that still worked, but "completely ignore differential impedance entirely" sounds like garbage advice.
@alexwhittemore Re: a bit ago: once you have a USB device capable of doing e.g. bulk transactions, it's actually not that bad to grab chunks of raw data using libusb. If you use their synchronous API, you can e.g. read data a chunk at a time just by calling API functions.
Plus, the fact that shooting yourself in the foot is SURVIVABLE isn't good reason to shoot yourself in the foot.
yea especially for high speed usb2.0 saying it doesn't matter at all how you route is definitely wrong
How about writing usb2.0 stack for spartan6? I think I should start with a book of Jan Axelson. Can you advice some additional materials?
that is a fair amount of data you push there, it will still work but it might be degraded
Plus routing just one differential pair shouldn't be that hard so "why not"
...one to each destination anyways
@alexwhittemore What gets complicated is when you want to really push your throughput -- because you don't want your software to effectively be reading, doing something with the data, and then reading again; since all that data processing time is time that your device isn't grabbing data.
Has anyone here played around with USB-C Power Delivery? I'm working on a product that is a Power Delivery source, but a USB 2.0 Upwards Facing Port / device. My understanding of the spec is that there's no way for USB 2.0 Downwards Facing Ports / hosts or non-USB / no-data devices to pull 5V. You have to negotiate Power Delivery via the CC pins or nothing at all. It would be ideal if there were a way to fall back as a dumb 5V charger.
@Twisted Pair in my Hair The reason that diff-pair are routed so closely is to keep the fields confined, as much as possible, between the traces. If you have different signal line lengths, or changing impedances, theres a good chance that one signal can propagate in front of another -- and where the lines are no longer truly differential (e.g. opposite polarity), you'll get a ton of EMI noise.
Hire professional or volunteers to write rock-solid, work anywhere, never break, easy to talk to, service.
I am old enough that I am way older than Microsoft. The earliest operating systems were clean and stable compared to today. The USB community should fund its own service in each of these OSs. PAY someone to do it. Raise money from donors. Ask for support from Open communities.Quit trying to maintain every toolkit in every environment where the OSs and browsers are all change according to their own whims and marketing ideas.