<d1b2>
<B1tW0lf> Hey @esden . First of all thanks for uploading your work, it's a great help on designing with KiCad. I've just seen your glasgow episode 5 on yt (unfortunately i always miss the stream). I've recently worked on a few boards that had to incorporate the option to use USB C or USB micro (take a look at the Jetson Nano for an example of a PCB https://hackaday.com/wp-content/uploads/2019/03/jetsonusb.jpg). On the image you can see the footprints of the
<d1b2>
TYPE-C-31-M-14 and the 105017 connectors. I can't show you the real board layout due to IP but this should give a nice example. What is your take on solutions like this? It was a hell to route and had to use 0.2 0.45 vias to get the USB C DP and DM connected.
<d1b2>
<tnt> You'd need a USB-C connector that's raised of the board. The classic ones would short the microusb pads.
<d1b2>
<B1tW0lf> We've used a bit of isolating material when placing the usb C
<d1b2>
<tnt> Right, but that's hard to automate.
<whitequark>
let's not add load bearing plastic to the USB connector please
<whitequark>
I wonder if you could do type-C one side, type-µB another?
<d1b2>
<B1tW0lf> Indeed, not my preferred solution but right now someone places a bit of isolating tape on the PCB's just before it goes into the P&P. I've only seen this once in the industry with the Jetson Nano dev kit. I find it kind of interesting that such a big corp uses this concept
<whitequark>
dev kits can be ridiculously inefficient ime
<whitequark>
lattice's ice40hx8k devkit uses a $10 Linear's LDO
<whitequark>
with like 1 mV of ripple or something. completely pointless
<d1b2>
<B1tW0lf> > I wonder if you could do type-C one side, type-µB another? @whitequark#0000 Yeah this is possible. Ive seen one board that has a USB C on one side and a USB Micro on the other. Due to the thickness of the cable you cannot plug in both, which is a nice solution in the USB C transition phase if possible. Unfortunately i was very limited with PCB space and could only place connectors on the top side
<d1b2>
<B1tW0lf> Ofcourse you wouldn't want to use the USB C connector with SMD and TH pads
<whitequark>
I'm thinking only one would be populated
<whitequark>
so the main benefit is having only one design file for both variants
<d1b2>
<tnt> You'd need to put the usb-c one on the bottom if you want the micro-b to be right side up.
<whitequark>
hrm
<RaYmAn>
I'm curious - what's the reason for even keeping micro-usb at all?
<whitequark>
not everyone lives on the bleeding edge and whether we will opt for µB or C it will result in people wanting a fork that uses the other connector
<whitequark>
case in point: i don't even have any C-C cables
<whitequark>
and in fact if i *did* have C-C cables they would be useless to me because the only type-C port on my laptop is useful for Thunderbolt and/or charging
<d1b2>
<B1tW0lf> The main problem with USB C is that most people dont have these cables yet and or dont have the equipment to connect it to
<RaYmAn>
interesting. I guess it depends country. I barely have any microusb cables left and only really have USB A <-> USB C left
<d1b2>
<B1tW0lf> I've got some USB A 3.1 to USB C cables because there are only a handfull of laptops/PC's that incorporate USB C <-> USB C
<whitequark>
RaYmAn: it depends on how wired into latest tech you are, really
<RaYmAn>
I wouldn't really call usb c bleeding edge anymore, but I get your point
<whitequark>
i definitely would, laptops with useful amounts of type-C ports became available in what, last 2 years?
<tnt>
Yeah, I have tons of micro-usb ones, but only 1 USB A->C and that's pretty much dedicated to my phone charger. Just like I don't keep "power only" micro-usb cable I only want to keep fully capable usb-c cable and so they are not that cheap (at least here)
<tnt>
(and I also have no usb-c ports except one on my graphics card ?!?)
<RaYmAn>
I don't think I've ever really used USB C <-> C for anything tbh, but fair enough.
<d1b2>
<B1tW0lf> yeah i agree with tnt. USB C is still pretty new and has power only, usb 2 only, usb 3 ony, 60W and 100W variants already. I think this might be the main issue with USB C cables
<whitequark>
just like WASM i plan to use for shipping yosys/nextpnr is "bleeding edge" even though it's been theoretically available for 5 years (of which only in last 0.5 years did it get possible to use for our purposes), the same applies to type-C
<whitequark>
i'm not *against* supporting people who want to go C-only
<whitequark>
sure, the specs are broken in so many ways, but we're already going with USB, so screw it, type-C going forward it is
<whitequark>
but i also don't want to exclude people who don't
<d1b2>
<B1tW0lf> yeah kind of curious if we get a mini C someday as the connector is still pretty big
<whitequark>
please for the love of gods no
<RaYmAn>
What's the minimum python version for glasgow these days? :P
<whitequark>
3.6
<d1b2>
<B1tW0lf> i sure hope it wont but i have the feeling that USB C is too 'big' for the phone companies
<whitequark>
if left to my own devices i would have went with 3.8
<whitequark>
but that's because glasgow heavily uses async and until 3.8 there is no way to get an async REPL
<whitequark>
which is an outstandingly important feature in my view and not mere convenience / conformance
<whitequark>
that said, because of the gentoo users we're still stuck at 3.6
<whitequark>
so... you can see i apply the same principle
<RaYmAn>
One could argue that you should support python 2.7 to really have the same principle, but now we're getting dangerously close to trolling territory so I'll stop ;)
<whitequark>
python 2.7 is deprecated and unsupported, plus it's missing critical features
<whitequark>
i absolutely refuse to support *mini*B, in spite of some requests to do that, because it's objectively inferior to microB
<whitequark>
similarly, you can't use glasgow on usb 1.1 and you aren't going to be able to
Stephie has quit [Quit: Fuck this shit, I'm out!]
<whitequark>
(i think we're technically not spec-compliant on that aspect right now, might have to ensure it at least enumerates)
<whitequark>
(but i think glasgow actually does pass all other USB conformance tests except for the sleep current ones)
Stephie has joined #glasgow
<whitequark>
(i made it do that mostly for entertainment value)
<tnt>
whitequark: Doesn't 9a83d8574fd4031fe067eaf5c5ae748ecff7b4d6 remove 3.6 support ?
<whitequark>
tnt: hrm
<whitequark>
i forgot to update setup.py, it looks
<whitequark>
also
<whitequark>
now that i review that commit i realize it's possible to keep 3.6 support and also fix those TODOs
<whitequark>
`required` can be set as an attribute on the subparser, and importlib_resources provides a 3.6 shim
<whitequark>
so i guess i wouldn't be strongly opposed to reverting it and adding 3.6 support back. i remember that i wrote 9a83d8574fd4031fe067eaf5c5ae748ecff7b4d6 after i wasted something like a hour on my life on a missing subparser invocation, so i think you can see why i went aggressive with it back then
<whitequark>
we should either fix setup.py or revert that
Stormwind_mobile has quit [Ping timeout: 246 seconds]
<marcan>
(I haven't updated yet but I will soon, you are entitled to use a stick)
<whitequark>
oh, cool!
<marcan>
they have 3.9 in the repos too, so one would hope the 3.8 transition will be less delayed
<whitequark>
debian is going to slow that one down i think
<marcan>
whitequark: basically the only reason I haven't done a full update yet is because a boot update broke like 5 package builds
<marcan>
and I'm currently in the lazy process of deciding whether I find patches for them or report bugs or just drop the packages because my tolerance for BS like this has some limits
Getorix_ has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
Stormwind_mobile has quit [Ping timeout: 260 seconds]
Stormwind_mobile has joined #glasgow
tomtastic_ has joined #glasgow
tomtastic has quit [Ping timeout: 256 seconds]
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
electronic_eel_ has joined #glasgow
electronic_eel has quit [Ping timeout: 264 seconds]