04:14 <d1b2> <TomKeddie> @rwhitby Nice work. I had a question about the level conversion for usb data, I guess this is some special Apple thing? I wasn't aware usb data was ever anything other than 3.3V - am wondering if a couple of no-load 0R resistors to bypass the level converter might be useful?

04:15 <d1b2> <rwhitby> this is for devices which can route 1.2V debug UART over the D+/D- lines after you've sent it some special VDMs.

04:15 <d1b2> <rwhitby> https://github.com/AsahiLinux/docs/wiki/HW:USB-PD

04:15 <d1b2> <TomKeddie> I figured at much, that's the apple arm scenario.

04:16 <d1b2> <rwhitby> 3.3V is an option for the level converters, so that should work fine for normal USB

04:16 <d1b2> <TomKeddie> It'

04:16 <d1b2> <rwhitby> Hmm, I wonder about the direction pins though

04:17 <d1b2> <TomKeddie> I'm playing with getting Luna going on Glasgow, have it working on the lvds connector. It's more the latency on the direction control I am concerned about.

04:18 <d1b2> <TomKeddie> Glagow already has one layer of direction control, my initial attempts to get luna working on the test interface have not been successful but I've only put about 30 mins into it.

04:18 <d1b2> <rwhitby> i see, so the I2C writes to change the direction control on PortB will introduce too long a latency for full speed USB ?

04:19 <d1b2> <rwhitby> (and then extra writes to set the direction lines for the USB-PD add-on.

04:19 <d1b2> <TomKeddie> It's not i2c it's a pin (on the glasgow board). It might work.

04:20 <d1b2> <rwhitby> I need to take a deeper look at how glasgow works internally 🙂

04:20 <d1b2> <TomKeddie> Perhaps I'm looking at the wrong schematic.

04:20 <d1b2> <TomKeddie> https://cdn.discordapp.com/attachments/613461005392936961/810727113119236146/unknown.png

04:20 <d1b2> <rwhitby> that's exactly what I just looked up 🙂

04:21 <d1b2> <rwhitby> ah, it's the pullup/down which is on I2C control

04:22 <d1b2> <rwhitby> so once you work out how to control the glasgow DIR pins from the FPGA, then I'll just tie that to the USB-PD DIR "data" (from the point of view of glasgow FPGA) pins

04:22 <d1b2> <rwhitby> so they should be able to be switched at exactly the same time and not introduce any additional latency.

04:23 <d1b2> <TomKeddie> I hope so, still need to get it working with just Glasgow.

04:30 <d1b2> <rwhitby> ok, so either you'll be able to get it to work on glasgow (and therefore it will work on the usb-pd board as well) or you won't be able to get it to work and therefore the usb-pd board won't work either.

04:31 <d1b2> <rwhitby> are you testing device-only? or host as well?

04:31 <_whitenotifier-5> [glasgow] TomKeddie opened pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtPFA

04:42 <d1b2> <TomKeddie> Device only at this stage. I'm not sure luna does host yet, am a bit out of touch on that. I'm might be easier to roll an add-on with an external transceiver chip list the USB3343.

04:49 <d1b2> <rwhitby> I was talking to @DX-MON yesterday and they looked to see if luna supported host and said that it did.

04:56 <d1b2> <Greg> Just based on the docs it's not. (But I know docs can become out of date sometimes) https://luna.readthedocs.io/en/latest/features.html#support-for-host-mode

05:00 <d1b2> <rwhitby> @DX-MON looked in the code, but perhaps saw the mentioned low-level comms interfaces designed to allow host rather than full host support.

05:06 <DX-MON> to tie the USB direction stuff in the FPGA to the dir pins on the outside, do: `m.d.comb += d_p_dir.o.eq(d_p.oe)` (same for d_n)

05:06 <DX-MON> that'll tie the direction pin and the internal output enable together

05:06 <DX-MON> d_p_dir.oe should be perminantly driven high anyway

05:07 <DX-MON> you can make that ~d_p.oe if you need the logic for the dir pin to be reversed to the way the OE for the FPGA pin works

11:39 <_whitenotifier-5> [glasgow] attie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXqz

14:58 <_whitenotifier-5> [glasgow] TomKeddie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXWB

15:05 <_whitenotifier-5> [glasgow] attie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXWd

15:11 <_whitenotifier-5> [glasgow] whitequark commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXln

15:20 <_whitenotifier-5> [glasgow] TomKeddie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXlA

15:43 <_whitenotifier-5> [glasgow] TomKeddie synchronize pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtPFA

15:43 <_whitenotifier-5> [glasgow] TomKeddie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtX4s

15:47 <_whitenotifier-5> [glasgow] attie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtX4u

15:51 <_whitenotifier-5> [glasgow] mndza synchronize pull request #265: Add bitarray implementation to eliminate external dependency - https://git.io/JtZfr

15:51 <_whitenotifier-5> [glasgow] attie reviewed pull request #275 commit - https://git.io/JtX41

15:51 <_whitenotifier-5> [glasgow] attie reviewed pull request #275 commit - https://git.io/JtX4M

15:51 <_whitenotifier-5> [glasgow] attie reviewed pull request #275 commit - https://git.io/JtX4D

15:51 <_whitenotifier-5> [glasgow] attie reviewed pull request #275 commit - https://git.io/JtX4y

15:52 <_whitenotifier-5> [glasgow] mndza reviewed pull request #265 commit - https://git.io/JtX45

15:54 <_whitenotifier-5> [glasgow] mndza reviewed pull request #265 commit - https://git.io/JtX4x

16:10 <whitequark[m]> hey, can y'all tell me how using Glasgow makes you feel? there's an important reason I'm asking this which I unfortunately cannot share right now

16:14 <tnt> Huh ... "nothing" ... which is good. I want my tools to be pretty transparent and just not think about them. I pick it up, do whatever I'm trying to do, then forget about it. That's not always the case with other tools where I sometimes end up feeling frustrated or angry.

16:15 <_whitenotifier-5> [glasgow] mndza synchronize pull request #265: Add bitarray implementation to eliminate external dependency - https://git.io/JtZfr

16:15 <tnt> To me it's one of those things where you don't notice it when things go right. But you most definitely notice when they go bad.

16:22 <_whitenotifier-5> [glasgow] mndza synchronize pull request #265: Add bitarray implementation to eliminate external dependency - https://git.io/JtZfr

16:29 <_whitenotifier-5> [glasgow] TomKeddie reviewed pull request #275 commit - https://git.io/JtX0s

16:40 <_whitenotifier-5> [glasgow] TomKeddie synchronize pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtPFA

17:00 <_whitenotifier-5> [glasgow] attie commented on pull request #275: cli: add --force-reload option to override bitstream id check in all cases - https://git.io/JtXuf

17:04 <d1b2> <Attie> glasgow doesn't have that high level of frustration that so may other tools have - what's it doing / will it work / how do i ___

17:04 <d1b2> <Attie> it doesn't get in the way, and it's really nice to work with - both from the "using what exists", and from "making new stuff" points of view

17:06 <d1b2> <Attie> i said in my fosdem talk that you should never find yourself wondering "do I trust ${tool} right now?", and I think glasgow has been really very good on that front

17:07 <d1b2> <Attie> it's not been perfect (e.g: UART auto baud), but that's an unattainable ideal - we can dig in and fix it!

17:29 <gruetzkopf> Glasgow feel: extremely relieved i'm carrying around one glasgow and not 25 terrible vendor tools

17:47 <electronic_eel> a feeling when selecting Glasgow as a tool: the concepts behind it are sound. Even if not all protocols are implemented yet and some potential usecases are not covered yet, the groundwork is layed out in a way that in can be developed on without requiring bad compromises.

19:38 <_whitenotifier-5> [glasgow] whitequark closed pull request #273: platform/rev_c12: add connector definition for the lvds connector - https://git.io/JtKxb

19:38 <_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JtXoc

19:38 <_whitenotifier-5> [GlasgowEmbedded/glasgow] TomKeddie 87b03df - platform.rev_c12: add connector definition for the lvds connector.

19:38 <_whitenotifier-5> [glasgow] whitequark commented on pull request #273: platform/rev_c12: add connector definition for the lvds connector - https://git.io/JtXoC

23:51 <d1b2> <esden> When I use Glasgow It is a calming (don't worry you won't break anything) and empowering (it can be done) feeling. Like using a very long lever to move a heavy boulder. It is a force multiplicator. 🙂

23:52 <whitequark> thank you everyone, this gives me strength to go on at a point when i had a lot of self-doubt from the recent events i don't want to enumerate

23:53 <d1b2> <konsgn[no-Mic]> I don't use it yet, but cut me some slack, I just found out about it a little bit ago. Seems like an immensely powerful device.

23:53 <d1b2> <konsgn[no-Mic]> Definitely looking forward to working with it.