Lutetium
@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!
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.