matthuszagh has left #glasgow ["ERC (IRC client for Emacs 27.0.50)"]
_whitelogger has joined #glasgow
<whitequark>
hm, i'm not actually sure why i was seeing errors in the loopback usb data on that board
<whitequark>
i don't recall fixing any bug that could have caused it
<whitequark>
still, i can't reproduce it, so let's just assume it was my fault anyway
mwk has joined #glasgow
<esden>
whitequark: that is ok, I am glad you were able to find some issue. Just FYI the loopback test was failing with my glasgow the other day too. I thought it was my hardware too, but I was considering asking about it. It was interesting to see your github issue. I will update the tools tomorrow and try again. Let's see if the error is gone.
<esden>
(but first I need some sleep it was a stupid long day for me today)
futarisIRCcloud has joined #glasgow
<electronic_eel>
whitequark: good idea using the free part of the fx2 eeprom for ice, no revC2 necessary
<whitequark>
electronic_eel: i'd rathr use a larger flash, really
<whitequark>
but it is not realistic
<electronic_eel>
eeprom is too expensive in these sizes, we'd have to go to spi nor flash
<electronic_eel>
but that needs pins on the fx2
<whitequark>
we can't
<whitequark>
yeah
<whitequark>
i mean
<whitequark>
it's not that expensive
<whitequark>
we'll lose maybe half a eur
<whitequark>
on a 150+ eur board... not that much
<whitequark>
but it's just not realistic addressing wise
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±4] https://git.io/JecBq
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark e1c8c85 - hardware/boards/glasgow: explain the function of R40.
<electronic_eel>
we could use a microcontroller instead, but that'd add to the toolchain
karlyeurl has joined #glasgow
<whitequark>
we use a microcontroller..
<whitequark>
we could add another 8051 :p
<electronic_eel>
no, I mean for example a stm32 with 1mbyte of flash
<electronic_eel>
in addition to the fx2
<whitequark>
:/
<electronic_eel>
that could also replace some other parts we currently use, like the dacs and adcs
<whitequark>
and could also lock up in spectacular ways
<whitequark>
i don't even trust the fx2 all that much
<electronic_eel>
it has a i2c bootloader, so we could re-init it from scratch through the fx2
<whitequark>
:/
<electronic_eel>
but a lockup during operation is possible, yes
<whitequark>
i have a reasonable amount of faith in the voltage alert function actually working, right now
<whitequark>
because most of it is running in asics
<whitequark>
the FX2 doesn't have a watchdog or else i'd use that
<electronic_eel>
I have a better idea for the voltage alert, we could use that for revD, let me just find it again
<whitequark>
connect it to DAC shutdown directly?
<electronic_eel>
damn, should have bookmarked it
<whitequark>
fwiw i'm not sure how much changes to the AFE/DFE i want on revD
<whitequark>
ideally it'd just be twice the revC plus the extensibility changes
<whitequark>
the DACs would need to be changed for MSOP-8 parts
<whitequark>
but this sort of thing is why this logic is on fx
<whitequark>
*fx2
<electronic_eel>
we could do the hardware shutdown on the one port and shut down the others with the fx2 in software
<whitequark>
that seems kinda like the worst of both worlds
<whitequark>
well
<whitequark>
i always thought of the Vsense shutoff as a sort of best effort feature
<whitequark>
not as something you can rely on for safety
<whitequark>
it's mostly so that the target isn't backfed for too long
* ktemkin
reads the scrollback
<electronic_eel>
it may be best effort, but the effort we are capable of isn't to be underestimated ;)
<ktemkin>
I’m honestly surprised the FPGA configuration flash isn’t DNP to begin with
<ktemkin>
considering needing to configure the FPGA without a host connection seems more like an exceptional case than something typical
<electronic_eel>
I can think of several usecases for Glasgow where you just want the FPGA with level shifters and the fx2 as support micro
<electronic_eel>
this isn't the typical rev engineering and debugging usecase of course
<electronic_eel>
and the 1 buck extra for the eeprom doesn't really matter when you consider the full bom
<whitequark>
it's not even 1 buck
<whitequark>
it's more like 20 cents iirc
<whitequark>
for the cheapest 1Mbit flash i can fnd
<electronic_eel>
you posted "CAT24M01 costs 0.78€ @ 100" in #164
<whitequark>
hm, let me recheck
<electronic_eel>
maybe LCSC has some cheaper ones
<ktemkin>
I mean, part cost usually is dwarfed by placement effort and space anyway
<whitequark>
nvm, i misread
<whitequark>
yeah
<whitequark>
ktemkin: i think using glasgow as something like an uh
<whitequark>
standalone PS2 device simulator or something is valuable
<_whitenotifier>
[Glasgow] whitequark commented on issue #165: Replace ADC with INA233 - https://git.io/JecRU
<electronic_eel>
yes, some standalone emulator, converter,... is valuable. the integrated level shifters are missing on most other fpga boards that could be used as alternative
<ktemkin>
I’d just expect anyone with an atypical use case to be able to solder on a flash pretty easily; and DNP’ing would free you from some space/routing concerns, since those could be meant for population on the solder side
<electronic_eel>
there are already some parts on the back, so no big difference there
<ktemkin>
(not really disagreeing; just surprised)
craigo has joined #glasgow
<emily>
glasgow laughs at your puny space constraints
<emily>
i wasn't expecting the revC to be quite as small as it is. very packed
<electronic_eel>
ktemkin: Glasgow comes with all the bells and whistles already integrated
<ktemkin>
I tend to DNP things like that on my designs when I suspect there’s value to letting the user select the part (e.g. for flashes for atypical use cases; I tend to think the user can select the size they want)
<electronic_eel>
as you've probably seen in the irc scrollback, selecting a different size sometimes isn't all that easy...
<ktemkin>
yep; though it’s a lot easier if you’re not using i2c flash =P
<electronic_eel>
yes, spi would make that much easier. but that would require redesigning parts of the fx2 to free up pins
ExeciN has joined #glasgow
<ktemkin>
or using one of those oddball parts that does e.g. i2c to spi bridging
<ktemkin>
that used to be a not-incredibly-uncommon feature of i/o expanders; but they seem to have gotten less and less common
<_whitenotifier>
[Glasgow] electroniceel commented on issue #165: Replace ADC with INA233 - https://git.io/JecRg
<electronic_eel>
you could maybe also bitbang it with a regular i2c expander, or use another microcontroller as I wrote above
<electronic_eel>
but both would need a bit more space
<electronic_eel>
and some development, and I think getting revC out soonish is important too
<ktemkin>
wait, doesn’t the fx2 have lines just tied to LEDs?
<electronic_eel>
yes
<ktemkin>
those really wouldn’t mind also driving a flash that’d only be used for early configuration; and you wouldn’t really even be able to see the flickering since the frequency would be high enough that the leds wouldn’t visibly turn on =P
<ktemkin>
and they’re on the fx2’s serial engine, so it wouldn’t even be that cursed in code >.>
<electronic_eel>
yes, that might work
<ktemkin>
the only downside is that you’d have to live with the weight of that sin~
<electronic_eel>
I'm more worried about the weight of the code, the fx2 we are using just allows 16k of code
ExeciN has quit [Quit: so long king Bowser]
<ktemkin>
hmm; I wonder how doable it’d be to have the ice40 configure itself via MSPI
ExeciN has joined #glasgow
<ktemkin>
totally impractical given you already have things laid out, but that’d be a heck of a cheat
ExeciN has quit [Client Quit]
<ktemkin>
(since you wouldn’t need any code on the fx2, since the fx2 would only participate in taking to the flash when connected to the host)
<ktemkin>
anyway, I’m done with the silly musing =P
ExeciN has joined #glasgow
<whitequark>
bitbanging an SPI flash with an I2C expander is super cursed.
<_whitenotifier>
[Glasgow] whitequark commented on issue #165: Replace ADC with INA233 - https://git.io/Jec0U
<ktemkin>
the olde-style expanders would occasionally come with a little SPI hard IP in them you could use as a bus bridge
<ktemkin>
which is what I was referring to; but I’m not sure those exist for cheap anymore
<whitequark>
ahh
<whitequark>
never seen those
<ktemkin>
but yes; bitbanging literally anything from an i2c flash is Cursed
<ktemkin>
er
<ktemkin>
i2c expander
<ktemkin>
words are hard
<ktemkin>
at least that idea makes the idea of sharing a bus with the LEDs sound less cursed~ =P
<whitequark>
i think it's fine as it is tbh?
<whitequark>
storing bitstream in i2c is cursed, storing bitstream in spi connected to leds also cursed
<whitequark>
it might be a bit faster with my optimized 8051 softspi implementation :p
<whitequark>
about an order of magnitude faster
<ktemkin>
again, wasn’t really making suggestions as much as musing
* whitequark
nods
<whitequark>
i've seen JTAG on LEDs
<whitequark>
in some cursed routers
<ktemkin>
that’s the real secret of hardware design, though: it’s all cursed
<whitequark>
never got it to work, too
<whitequark>
i mean yes, it's a question of degree really
<whitequark>
8051 is pretty cursed imo :p
<whitequark>
the rest of FX2 works remarkably well though, and is pretty well designed
<ktemkin>
it’s a decent little uC
<whitequark>
that's one reason i'm going with FX3 for revE, really
<whitequark>
FX2 never gave me any trouble. sdcc did but not too much
<ktemkin>
The fx2‘s competence is honestly a little upsetting, because I’d generally choose a more expensive uC to avoid 8051+sdcc
<whitequark>
hahaha
<whitequark>
yeah
<whitequark>
it's not that cheap either
<whitequark>
especially in all the interesting packages
<whitequark>
that don't leave me scrambling for GPIOs
<ktemkin>
I have a vague fondness for 8051s, since I learned assembly on them like two decades ago; but that evaporates every time I have to use them
<whitequark>
i recently wrote an optimized chacha20 for 8051
<ktemkin>
someone gave me half a reel of fx2s in one of the cursed tiny packages, since they had to switch mid-production to a larger one
<ktemkin>
and I have literally no idea what to do with all these
<whitequark>
which one?
<whitequark>
it's either qfn or bga
<whitequark>
if it's qfn you could donate them to make glasgows out of them :p
<ktemkin>
they’re bgas
<whitequark>
the bga is 0.5mm and a particularly obnoxious ball pattern, i looked and we couldn't use it
<whitequark>
aw
<whitequark>
have you seen their QFN design notes.
<whitequark>
it's slightly weird.
<ktemkin>
it's been a while
<whitequark>
i think we actually follow it exactly
<ktemkin>
(I just went and looked at the reel to confirm, and yeah, they're VFBGA-56)
ExeciN has quit [Quit: so long king Bowser]
<whitequark>
yeah i... don't know either lol
<ktemkin>
I can throw some of them to esden when I see him in like three weeks in case anyone ever wants to be a sadist and ask him to fab something with those~
<ktemkin>
apparently this is what they suggest even for bus-powered devices
<ktemkin>
because apparently interrupting your power planes in a way that cuts off direct return paths for... most of the board? helps to reduce EMI and RFI
<emily>
whitequark: aw i thought you were considering going fpga-only for revE with the partial reconfig stuff
<_whitenotifier>
[Glasgow] electroniceel commented on issue #165: Replace ADC with INA233 - https://git.io/Jec0A
<whitequark>
emily: probably not, it's much more complex than just that
<whitequark>
i generally go for reliability over elegance
* whitequark
points ot the 8051
<emily>
two FPGAs for maximum reliability!!
<emily>
fallover!!
<whitequark>
i mean you could do that but it's still less unbrickable than fx2/fx3
<_whitenotifier>
[Glasgow] whitequark commented on issue #165: Replace ADC with INA233 - https://git.io/JecE4
<ktemkin>
I'm handling pretty much all of my USB in gateware on LUNA (WIP low-cost, ECP5-based usb mutitool with more PHYs than sense)
<whitequark>
i'm not confident that i can bring up a reliable USB3 stack. conversely, i don't think i *want* to do it for revE
<whitequark>
"USB peninsula" lmao
<ktemkin>
I just have a $0.50 STM32F with full-speed that's parallel'd with one of the subordinate USB2 PHYs, and which only comes up if the FPGA fails to configure
<whitequark>
yeah
<whitequark>
the FX3 will do this if it receives a magic packet over Ethernet
<whitequark>
or you could poke it directly over USB of course
<ktemkin>
by the way, if you want a few CYUSB3012-BZXCs to play with, I have a few hundred dollars worth of 'em
<ktemkin>
"so like three chips"
<whitequark>
i have a devkit
<whitequark>
lol
<whitequark>
yeah
<whitequark>
fx3 is even more expensive
<whitequark>
granted, ecp5-5g isn't cheap either, and revE will have that
<whitequark>
the reconfiguration on revE is gonna be a bit weird
<ktemkin>
honestly, though, $20 for an FX3 isn't terrible, considering it's often like $15 for a gods-forsaken superspeed PHY
<whitequark>
the FX3 can't store an entire bitstream in its RAM and it can't be streamed directly to FPGA
<whitequark>
so it'll use a PSRAM buffer
<whitequark>
yeah
<whitequark>
it's not too bad for revE
ExeciN has joined #glasgow
<ktemkin>
gods, the documentation for the FX3 still reads vaguely like they've just discovered that the ARM9 exists and are proud of themselves for figuring that out
ExeciN has quit [Client Quit]
<emily>
are you sure they didn't just discover that ARM9 exists?
<emily>
"holy shit, this is way better than the 8051"
<electronic_eel>
esden: wow. some life sign from him. the design is looking good, in line with the concept of the previous ones
<electronic_eel>
but when taking the frequency of blog posts and the like he did as indicator, I fear he doesn't have the time to finish this
ExeciN has joined #glasgow
<emily>
"At our very first New York Maker Fair (RIP) we had the chance to meet one of our maker heroes at an after party. We introduced ourselves and Maker Hero replied “The Bus Pirate is too slow” and walked away. It was crushing, but it is accurate."
<emily>
what a nice person
<esden>
Damn people are horrible sometimes... :/
<esden>
electronic_eel: I just had a conversation about Ian yesterday with someone. The other person was curious what happened to him as he seemed to have disappeared for a very long time.
<esden>
My guess is as good as yours as to what he is up to these days. :)
ExeciN has quit [Ping timeout: 245 seconds]
ExeciN has joined #glasgow
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 3 commits to master [+0/-0/±3] https://git.io/Jecra
<electronic_eel>
but python doesn't really make it easy to manipulate bits, I had to try several ways to find an elegant one
<whitequark>
we might need to write glasgow.support.bitarray
<electronic_eel>
wouldn't it be better to make it a separate project and publish it on PyPy? So others could also use it
<electronic_eel>
PyPi I mean
<electronic_eel>
but obviously we'd have to write it first
<whitequark>
no, it wouldn't
<electronic_eel>
limit of projects to maintain reached for you?
<whitequark>
not exactly
<whitequark>
i simply don't want this specific one to be my problem
<whitequark>
if someone else wants it, great! now it's *their* problem.
<whitequark>
for the same reason i actually don't see myself accepting many applets upstream
<whitequark>
in fact right now you can't use out of tree applets at all and that's a very serious problem
<electronic_eel>
yes, if you don't want hundreds of applets upstream there should be an easy way to separate them
<emily>
a monorepo of integrated applets would have a lot more value than a balkanized ecosystem that can't be kept up to date as a whole :<
<electronic_eel>
and for others to collect them in separate repos
<emily>
at least, it'd be nice for some common community applets repo, even if it's not upstream
<electronic_eel>
so they can carry the maintenance burden if they want to
<whitequark>
emily: great. who's going to maintain that monorepo up to *my* standards?
<electronic_eel>
if it's not you, the person doing it could do it to their standards
<whitequark>
yes, but then i refuse to endorse it
<electronic_eel>
yes, I don't see a problem with that
<emily>
unfortunately github has no solution to OCPD :p
<electronic_eel>
you have first class applets and the second class ones from the monorepo
<electronic_eel>
but maybe we could reduce the need for full applets by more clever code and databases
<electronic_eel>
when writing the gpio applet, most work was just boilerplate access code to registers
<electronic_eel>
most ics are based around some register concept
<whitequark>
they also tend to all have unique quirks
<electronic_eel>
so if we create a comprehensive register access library which can take register definitions, meta registers, pretty print functions and so on, supporting a new ic is reduced to writing a map of register definitions
<whitequark>
i'm really not fond of magical shit like that
<whitequark>
it just keeps growing and growing new ad-hoc code to support this one quirk this one ic has
<electronic_eel>
you could always overload a method for a special ic
<whitequark>
yeah no
<whitequark>
i absolutely refuse
<whitequark>
programmers are pathologically unwilling to duplicate code. code duplication is good, actually
<whitequark>
(a lot of the time, not all)
<whitequark>
the only way i can see this meta-system working is if each device supported by it has a comprehensive hardware-in-loop testsuite and each change to the common code is tested in that testsuite
<whitequark>
which is unlikely to happen
<whitequark>
each time you overload a method you spread the contract for that method further over the codebase. this is actually already a problem, even though there's like 20 applets
<whitequark>
all of which i have hardware for on hand
<whitequark>
right now it's unavoidable because there's a bunch of legacy stuff like Pads() or the way FPGA registers are currently defined that'll have to be changed manually everywhere
<whitequark>
this all wouldn't be quite as bad if we used a language that isn't as awful at abstraction as python. unfortunately, we are in fact using python.
<electronic_eel>
the pca953x is a really boring ic with just 4 registers
<electronic_eel>
but still it took me considerable time to make it accessible in a convenient way
<electronic_eel>
ok, it was my first applet
<whitequark>
i think some improvement there is possible and necessary
<electronic_eel>
but still, I don't think I'd do it for a random ic I want to access
* emily
should get Clash-generated code running on her revC...
<whitequark>
but i don't think that a full-blown meta-system that just handles every ic with registers is the right solution either
<electronic_eel>
and remembering all the bits and doing it manually is really tedious
<electronic_eel>
that was what I hated most when using my bus pirate
<electronic_eel>
so I'd like to have a more convenient way
<whitequark>
nmigen will get a system for defining CSRs, a small DSL
<electronic_eel>
like writing down the registers in a map once and have most of it work
<whitequark>
i think i'm going to reuse that for FPGA-side registers at least
<whitequark>
it could potentially be reused for well-behaved IC registers too. if it doesn't fit that, well, you're on your own. define a system that handles the quirks of your IC *within your applet*
<whitequark>
in general, the rule of thumb is this:
<electronic_eel>
I'm thinking about I2C and SPI based interfaces mostly
<whitequark>
if generic code like this will conceivably be extended with a new case when adding support for a new device, it should not be generic code
<whitequark>
or conversely: if removing your applet would leave around code that is now dead, that code should have been inside the applet in the firstplace
<emily>
an 80% abstraction with holes to poke in for the 20% is still better than a bunch of undifferentiated code that can only be blindly executed
<electronic_eel>
that sounds reasonable to me
<emily>
it's a matter of taste to determine what's in the 80% or not but, well, software engineering is full of such judgement calls, right?
<whitequark>
i suspect a 80% solution could be as simple as "add this decorator at the top of your applet and the rest of the code becomes 5x more compact"
<whitequark>
would need to try it out
<electronic_eel>
yes, that could work
<whitequark>
probably the main hazard here is, well, there's no such thing as a bugfix in a codebase like glasgow when applets are concerned
<electronic_eel>
sorry, I don't understand
<whitequark>
if there's a bug in the generic register handling code and 50 applets are using it, 10 of them are probably implicitly relying on the bug
<electronic_eel>
and you don't have all the hardware to try. fair point
<whitequark>
yep
<whitequark>
it's possible to some extent to do tests without hardware in loop. i tried to write SPI flash tests like that
<whitequark>
it's extremely tedious
<electronic_eel>
if the bug is severe enough, we could version the interface
<whitequark>
i would rather just not have the interface in the first place.
<whitequark>
if the applet is maintained by someone, they will be alerted in the appropriate issue and fix it
<whitequark>
if it is not, git rm
<electronic_eel>
or move it into a staging area or something
<whitequark>
of course, if you duplicate 500 lines of code in 50 applets, this quickly becomes just as unmaintainable
<whitequark>
so as emily says, this is a judgement call. lesser evil kind of thing
<esden>
Hey everyone. Some progress on the glasgow batch production front. The CrowdSupply pre-launch page is live. Let me know if you find any typos or other mistakes on it. CS will start promoting this page early next week, so it would be good to fix any remaining stupid mistakes before that. :D https://www.crowdsupply.com/1bitsquared/glasgow
<whitequark>
honestly, the combination of "essentially infinite scope", "applets primarily written by and for hardware people", and "python" is extremely cursed
<whitequark>
but such is life
<sorear>
we have a rev with no known issues?
<whitequark>
it's why i'd much rather focus on making good applet interfaces that don't need to be constantly broken + have self-contained applets, rather than have an interdependent applet monorepo
<daveshah>
esden: real nitpick, iCE40HX8k should be iCE40HX8K
<whitequark>
fixed that
<daveshah>
Otherwise, looks really good
<esden>
daveshah: thanks! Good catch ... I always end up writing the lower case k... not sure why...
<jschievink>
esden: in the block diagram one ADC has the arrow pointing in the wrong direction
<jschievink>
other than that it looks great
<jschievink>
</ultranitpick>
<esden>
jschievink: good catch ... damn you folks are good nitpickers :D
<electronic_eel>
esden: I really like the block diagram
<jschievink>
The Legend and Block Diagram really look awesome
<whitequark>
yep, esden is very very good at making those
<esden>
hehe thank you all. I appreciate that. :D
<zkms>
i concur the diagrams are v pretty ~
<electronic_eel>
maybe replace "VCC" on the ports in the block diagram with "Vio"?
<electronic_eel>
that's what the leds are called and is used throughout the schematic
<esden>
I am figuring out a way to get those exported to some format that allows editing without Omnigraffle, and they will flow back into the upstream documentation.
<sorear>
I need to also say they diagrams are wonderful
<JJJollyjim>
But have you considered replacing the diagram with a big blob of L O G I C?
<electronic_eel>
lol
<esden>
JJJollyjim: yeah maybe I sohuld just upload a hexdump of a bitstream... that would be so much more data efficient. :D
<sorear>
is Glasgow/HX8K actually capable of 100MHz/200Mbaud? I thought it was half that
<esden>
electronic_eel: yeah you are probably right... although those pins also supply power to the target... so...
<esden>
electronic_eel: regarding the VCC vs Vio
<electronic_eel>
you have "VIOA" and "VIOB" in the legend
<whitequark>
100 MHz IO clock is doable, gearing it down is somewhat challenging but should be doable
<esden>
right... I do... as it has dual purpose there ... but the pin does not...
<daveshah>
I know people have done 250Mbps HDMI with HX8K IO
<whitequark>
i should actually make a design that proves 200 Mbps is doable on Glasgow specifically, though
<esden>
or HDMI 1080p clock on UP5K that is even slower
<daveshah>
But that's with a transceiver
<electronic_eel>
I think using "VIOA" and "VIOB" in the legend and block diagram both makes it easier to associate them
<daveshah>
And only 148.5Mbaud
<daveshah>
This was 250Mbaud HDMI with no transceiver
* whitequark
zz, read backlog tomorrow
<esden>
whitequark: sleep well :D
<esden>
electronic_eel: yeah I am not disagreeing ... I am about to fix it :D
<esden>
just "thinking" out loud
<electronic_eel>
in the tech specs "Each GPIO has a strong dedicated software controlled Pull-Up/-Down" - I'm a bit puzzled by the "strong"
<esden>
lover resistor value than the ones bulit into a typical chip
<esden>
*lower
<electronic_eel>
I'd either leave the strength out, or directly write 10K
<electronic_eel>
because otherwise it is higly subjective
<jschievink>
I like the trans flag
<esden>
it is funny how few people noticed the led color pattern so far... :D
<JJJollyjim>
I did a double take reading the schematic a while ago
<jschievink>
you don't see it on the renders in the repo
<esden>
but on photos that were being posted all around you do ... but I guess fewer people saw those...
ExeciN has quit [Ping timeout: 240 seconds]
<electronic_eel>
in the legend is "FPGA flash" and "FX2 flash", but it's EEPROMs that we are using
<electronic_eel>
in the block diagram too
<electronic_eel>
the flash/eeprom size is given in bits with small "b", that is correct, but you could still misread it as bytes. I suggest "1Mbit" and "256Kbit", there should be enough space for that
<electronic_eel>
the eeprom reset pad "REC" isn't labeled on the legend. I'd add that to show that it is easy to get a fully bricked Glasgow back to functioning without any soldering
<electronic_eel>
esden: you still listening? you got so quiet...
<esden>
I will not label the REC pad. That is not relevant to a typical visitor.
<electronic_eel>
ok
<esden>
the amount of info on that pre-launch page is already about 75% more information than a typical page. We don't want to overwhelm people. ;)
<electronic_eel>
to me it would appeal and show me a well thought through design, but maybe I'm not the typical visitor
<esden>
no you are not
<electronic_eel>
no problem with that
<esden>
:D that is the correct attitude :D
<electronic_eel>
another small thing in the block diagram: the level shifters and "Pullup/down, HiZ Control" are two separate blocks
<electronic_eel>
but HiZ is done in the level shifters
<sorear>
I wonder if there’s a way to convey “this is a thing you can make do arbitrary random bs in very little time”
<esden>
electronic_eel: you are being too literal
<esden>
HiZ as in-> no pull-up/-down...
<esden>
and yeah the level shifters have to be disabled...
<sorear>
any way to distill the “raccoon brought me X” *3 hours later* “I have X singing and dancing on command”
<esden>
electronic_eel: the legend is there to convey meta information, not be a replacement for a schematic or the block diagram on the first page of the scematic.
<electronic_eel>
sorear: a necessary ingredient for that is a whitequark, esden won't ship that
<JJJollyjim>
can they compromise and ship me a raccoon?
<esden>
sorear: the most complicated thing to describe glasgow is exactly that... it is so broad in capability that it is very hard to squeeze into one tag line.
<electronic_eel>
esden: I'm thinking of ways to improve that on the legend, but I hit limitations on the size and clarity, so what you did was good
<esden>
I err on "leaving information out" for clarity than "factual accuracy" :D
<electronic_eel>
yeah, getting that balance right isn't easy
<esden>
(reminds me of a conversation about customs today with an engineer that does formal specification and verification the whole day)
<electronic_eel>
another thing: the black arrows on the sync line cross the purple i2c, you can mistake them for being the same
<electronic_eel>
yeah, they miss the dot for being joined, but you'd have to look twice to see that
<electronic_eel>
so I suggest to change the colors a bit
<esden>
again... you are being too nitpicky
<esden>
I did try to reorganize the diagram to keep the crossings minimal. Also color choice was a serious consideration.
<esden>
but I also want to keep the diagram size to a certain size
<esden>
I will probably take another shot at this later
<esden>
but it needs more serious reorganization that I felt is not worth the last 1% of improved clarity
<electronic_eel>
maybe use the whitish overlay you used on the "I2C" label below the crossing lines?
<esden>
they should not be crossing at all...
<esden>
I should route it around the sync block I guess
<electronic_eel>
or the bridge style hops you see on old schematics for crossing lines?
<electronic_eel>
idea to reduce the sync text: use "Sync I/O" as label, then you can remove the "GIPO & Dir Sel" as it is then clear that you can use it as input and output
<electronic_eel>
when using usb it is often a thing if you need a special driver or not. So how about adding a small block "libusb" between the usb arrow and the "asyncio"?
<electronic_eel>
want to keep the "b" on the size and the "GPIO & Dir Sel"?
<electronic_eel>
but I like the libusb, that is good as it is now
<emily>
it's not libusb on Windows I think
<emily>
WinUSB I think
<electronic_eel>
hmm, wasn't it libusbK on Win? But I'm not sure, I never tried it
<esden>
yeah I was going based on the text and what information whitequark included in there. So I guess I should leave out the libusb part if it is not universally correct.
<electronic_eel>
maybe wait for whitequark to comment, she got it to work on win IIRC
<esden>
on the other hand, Windows is not "officially" supported anyways if you read the readme...
<electronic_eel>
or you could use something like "libusb/WinUSB" if it is WinUSB
<esden>
argh ... even more text ... >_<
<esden>
I am removing it... I don't care ;)
<electronic_eel>
get rid of the "GPIO & Dir Sel" that accounts for more chars than WinUSB :->
<electronic_eel>
esden: there are remnants of a red line on the lower settable power supply
<electronic_eel>
seems like the red arrow was moved in a wrong way
<electronic_eel>
so, enough nits picked, going to bed now :)