00:04 <whitequark> need to ask esden to send gruetzkopf a revC1

00:21 <whitequark> huh?

00:23 <sorear> oh, those are "alternate settings", not the same thing, ignore me ( https://github.com/GlasgowEmbedded/Glasgow/issues/64#issuecomment-427586774 )

09:31 <marcan> electronic_eel: I agree with whitequark about using the BP & co to describe glasgow

09:32 <marcan> I mean it doesn't even remotely do it justice either

09:32 <marcan> like if I came across Glasgow and the beginning of the text started off mentioning BP, I would groan until I figured out it can do much more

09:33 <marcan> thaat said, I suspect the first couple of paragraphs could be reworded a bit to send the message in a more TL;DR way in the first sentence and two, without mentioning other tools.

09:33 <marcan> *or two

09:34 <tnt> Oh, I didn't know the kernel would reset interface to alt setting 0 by default, good to know.

09:34 <tnt> (and ... my irc client was apparently scrolled up and I'm commenting on an old thread ... nm)

09:42 <_whitenotifier-3> [Glasgow] JJJollyjim opened issue #141: Better specify ATECC508A variant in schemtic - https://git.io/fjWtS

11:08 <_whitenotifier-3> [Glasgow] whitequark commented on issue #141: Better specify ATECC508A variant in schematic/bom - https://git.io/fjWqx

11:37 <whitequark> marcan: that's already kind of tl;dr heh

11:37 <whitequark> but i'm open to rephrasing it

12:07 <electronic_eel> how about adding this as tldr line at the top:

12:07 <electronic_eel> A FPGA with USB-interface provides IO-ports (1.8V-5V) with direction control and pullup/down. Comes with an OpenSource software stack in Python that reconfigures the FPGA on the fly for each task so it isn't limited by predefined pin functions. This allows to easily interact with a wide variety of digital interfaces.

12:08 <whitequark> that's shortening 2 paragraphs to 3 sentences...

12:08 <electronic_eel> is 3 sentences still too long for your liking?

12:10 <whitequark> i'm just comparing it with existing README and don't see much of an improvement

12:10 <electronic_eel> it is shorter?

12:11 <electronic_eel> isn't that an improvement?

12:11 <whitequark> it's saying half as many things in half as much space

12:12 <electronic_eel> I'd keep the longer text that we have now. But just add it at the top for people to get the idea without reading too much text

12:12 <whitequark> the "Glasgow = BP+BB+LS" was factually incorrect but it was qualitatively different

12:12 <whitequark> i really don't get this obsession with not making anyone read an entire two paragraphs of text.

12:13 <whitequark> i'm not selling this to VCs, and frankly even if i was, the existing introduction is probably enough

12:13 <electronic_eel> I read through tons of websites each day

12:14 <gruetzkopf> i'm not seeing the point int TL;DR'ing somthing that's not even half a page of text

12:14 <whitequark> so do i

12:14 <electronic_eel> each wants to sell me their thing. it's hard to find the interesting stuff

12:14 <whitequark> the README is written a bit like a paper abstract/summary

12:14 <whitequark> well i don't want to sell it to anyone

12:14 <electronic_eel> so a very short intro block getting t

12:14 <electronic_eel> he idea across is important

12:15 <gruetzkopf> "foo works like bar and baz, just different" is not helpful

12:15 <electronic_eel> in my opinion

12:15 <electronic_eel> gruetzkopf: we already established that the bp reference is not a good idea

12:17 <whitequark> to be clear, goals: make a really good tool that would be pleasant to use daily and that gets out of your way and is easily extensible

12:17 <whitequark> non-goals: selling it to as many people as possible

12:19 <tnt> my 2ct is that a block diagram would be worth 1000 words ...

12:19 <whitequark> tnt: hmm

12:19 <whitequark> can you do a 3 minute sketch of what you mean?

12:20 <tnt> sure

12:20 <electronic_eel> tnt: you'd have to do it for the hardware and the software side

12:20 <whitequark> i'm not so sure about a block diagram but for a completely different reason

12:21 <whitequark> i think a block diagram like that can help if you already work with fpgas and maybe want something like glasgow on your own

12:21 <whitequark> i mean, it's something that i *want* to see there

12:21 <whitequark> but i want it for misguided reasons. i only want it because i already designed the thing

12:22 <electronic_eel> I think that the vast majority of people we want to address already have a basic idea what a fpga is

12:22 <whitequark> i think that's unnecessarily restricting ourselves

12:23 <whitequark> i mean

12:23 <electronic_eel> now you are selling...

12:23 <whitequark> no

12:23 <whitequark> that's not it

12:23 <whitequark> glasgow is not an fpga tool, it's a debug tool that happens to use an fpga

12:24 <whitequark> if xmos actually worked maybe it'd use xmos

12:24 <whitequark> when i use glasgow, my goal is not "program an fpga", my goal is "cycle-accurate interaction with a bus"

12:24 <whitequark> (well not necessarily that one thing)

12:25 <electronic_eel> yes, I understand

12:25 <electronic_eel> but if you know what an fpga is, you get the idea what can be done with it

12:25 <electronic_eel> but before t

12:26 <electronic_eel> he open toolchain it was really complicated to set it up and reconfigure it

12:26 <whitequark> it says "FPGA" right in the second paragraph and talks about complexity in 3rd...

12:26 <whitequark> so yes, i agree?

12:29 <electronic_eel> let's see what tnt can come up with

12:31 <tnt> https://imgur.com/a/pEkNVxz

12:31 <tnt> err, this is just a quick hand drawn thing, but just an overview of the hw board.

12:31 <whitequark> yes, i understand it's quick and dirty, that's completely fine

12:32 <tnt> ideally you'd also want a overview of the sw stack. (with the interfaces / applets / ... layers)

12:32 <whitequark> i think it makes sense to have something like that in the revC section since it describes specific hardware

12:32 <electronic_eel> yes, that's what i meant. integrating both in one diagram somehow

12:33 <whitequark> i was going to make something like it since the beginning but as a part of documentation instead

12:33 <whitequark> not README

12:33 <tnt> electronic_eel: well, the sw stack spans multiple revisions while the hw diagram is specific to one hw.

12:33 <tnt> Ok, gotta go, bbl.

12:34 <electronic_eel> i think the revision stuff re the diagrams can be worked out later when we also have revD

12:35 <whitequark> that diagram would not be easy to make, hmm

12:35 <electronic_eel> you mean the software diagram? or ones for different revisions?

12:35 <whitequark> software on the diagram

12:36 <electronic_eel> yes, but it would make sense to have arrows from the different sw layers into the fx2, the fpga and so on

12:36 <whitequark> i don't think that's valuable to have in README at all

12:37 <whitequark> the whole point is that you don't have to deal with that nasty stuff, and that it's abstracted away so it can change...

12:37 <whitequark> a block diagram of hardware is useful because it's an overview of how the hardware is implemented exactly

12:38 <electronic_eel> yes, and that's why you see a nice upper layer to interact with and all the arrows start from the lower layers

12:39 <whitequark> so what's the purpose of that?

12:39 <whitequark> in the README that is

12:40 <electronic_eel> to get across what kind of abstraction level the sw stack provides

12:40 <electronic_eel> and that you don't have to interact with the nasty stuff like usb packetization and so on

12:41 <whitequark> so what's the problem with https://github.com/GlasgowEmbedded/Glasgow#what-software-does-glasgow-use

12:41 <whitequark> which already talks about that exact thing

12:42 <electronic_eel> as tnt said: a well done diagram can get this across faster than words

12:43 <whitequark> mmm.

12:43 <whitequark> well maybe

12:45 <whitequark> would have to be a pretty good diagram though

12:58 <_whitenotifier-3> [Glasgow] whitequark commented on pull request #140: database.microchip: generate AVRDevices from xml files - https://git.io/fjWYf

22:51 <_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjWCS

22:51 <_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark 758522f - gateware.fx2_crossbar: use commonly accepted naming. NFC.

22:54 <_whitenotifier-3> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/531547560?utm_source=github_status&utm_medium=notification