futarisIRCcloud has quit [Quit: Connection closed for inactivity]
futarisIRCcloud has joined #glasgow
FFY00 has quit [Ping timeout: 260 seconds]
FFY00 has joined #glasgow
_whitelogger has joined #glasgow
Yatekii has quit [Ping timeout: 258 seconds]
<esden>
Hey all. I am curious what you all think about removing the part ID legends from the Glasgow silkscreen. The reasoning is, that it is not super useful as a user and for manual assembly something like htmlbom does a great job of geographically showing where parts go. (same thing for debugging) I think removing the ID legends will declutter the silkscreen and make the important information easier to read. This will also
<esden>
provide more space on the board for legend information. Obviously information about what section of the circuit does what will stay and/or be expanded. Which connector is which will stay in place, and information which pin has which signal will stay or be even expanded.
<whitequark>
cc marcan awygle
<whitequark>
janhenrik_ and electronic_eel too
<esden>
Also if any of you are interested in changes that I am making for revC2 you can find that branch here: https://github.com/esden/Glasgow/tree/revC2 I will create a pull request when I am done.
<esden>
I bet you all have better things to do than watch my streams. :D
<esden>
So far I have mainly changed some parts for easier sourcing and better pricing. No functional changes were made.
<marcan>
dang, and I spent so much time fitting them all in :p
<whitequark>
marcan: we kinda screwed up with DFM it seems, at least, cost wise
<marcan>
someone already made a cost-reduced version, right?
<whitequark>
janhenrik_ yeah
<whitequark>
cost reduced to like $40 fully assembled
<whitequark>
with very few if any functional changes
<marcan>
where did we screw up? parts choice?
<whitequark>
oh, take a look at the irc log
<whitequark>
but in short, sorta, we can save a lot by going for the parts jlcpcb stocks, less nasty packages in some places, and even more by going to one sided assembly
<whitequark>
the last part is what bothers me the most but we decided we can check that it still works fine with decoupling on top
<marcan>
ah yeah, that's like step 1 of cost reduction right
<marcan>
going with the jlcpcb catalog
<whitequark>
yep
<whitequark>
i was super impressed that janhenrik_ managed to actually beat my *original* cost target
<whitequark>
for revA
<esden>
not all parts are cheapest from jlcpcb...
<whitequark>
by 1/5
<whitequark>
esden: yeah, i know there are tradeoffs. i'm not married to jlcpcb
<esden>
some parts I can get at better price in other places, but in general you are correct
<whitequark>
it's more that i was really impressed with this because i thought it's not possible in reality to get this sort of cost reduction
<whitequark>
speaking of
<marcan>
re decoupling, definitely going to work for the shifters since we're going through vias anyway, it should be *better*
<whitequark>
esden: have you looked into replacing those sot563 parts with something nicer?
<marcan>
dunno about the FPGA but it's probably fine?
<marcan>
and I don't think anything else matters
<whitequark>
yes
<whitequark>
i wasn't 100% sure about the FPGA so i thought we can give it a full IO toggle test at like 200 MHz
<marcan>
yeah
<esden>
whitequark: I did replace them already with sot363
<esden>
that is what I spent yesterday and today on
<whitequark>
oh! sweet
<whitequark>
that is the major obstacle to DIYing, other than the BGA
<marcan>
as long as you keep the axial symmetry 8)
<whitequark>
actually I'm fine with the BGA but that damn package defeats me
<esden>
but I also learned a thing... KingCredie board quality is so good that the nasty parts are not even a problem... o_O
<esden>
still, it is good to improve if it is possible
<whitequark>
certainly
<esden>
also the slightly bigger parts fit on the board without problems and we can even save space as the via fit under them
<esden>
some of the via I mean
<esden>
marcan:
<whitequark>
yeah... i'm not sure why we originally went for 563
<marcan>
yeah
<esden>
I would appreciate your input and review of my changes at some point.
<marcan>
anyway re part IDs, I'm not super married to them, but I think *some* are useful. maybe leave ICs in?
<esden>
marcan: ok sounds good
<esden>
I think it is even more useful to know what which section does.
<marcan>
it is
<esden>
this is good for someone who just picks up the board at a hardware hack meet up thing
<marcan>
I was actually thinking that for the shifters, more than IC IDs, it would be useful to know which port-bit each is
<whitequark>
absolutely
<whitequark>
i misidentified them a few times
<marcan>
so maybe a little legend on the side with like a diagram of the bit assignments would be good
<marcan>
or something like that
<marcan>
brb, switching internet upstreams
<esden>
very good ideas! I will be playing with the silkscreen legend on the next stream if you are interested. I will then let you know how it goes. :)
* whitequark
. o O ( as more people contribute, removing the part IDs would leave more space for acknowledgements )
<esden>
whitequark: haha ... no no ... only real OG deserve space on the silkscreen :P
<esden>
ok anyways, that sounds all pretty good. I will check on the backlog tomorrow. I need to go to bed unfortunately. :)
<pepijndevos>
esden, you were doing streams working on revC2, right?
<esden>
pepijndevos: yep
<pepijndevos>
oh lol, good timing. sleep well
<whitequark>
good night
* pepijndevos
installing stuff to test glasgow that just came in the mail
<esden>
the archives of me working on it are on twitch... I tend to highlight the "main sections" of the stream: https://www.twitch.tv/esden/videos
<esden>
All right... n8 everyone :)
gregdavill has joined #glasgow
<pepijndevos>
hrm, I copied the udev rules, but still getting usb1.USBErrorAccess: LIBUSB_ERROR_ACCESS [-3]
<vup>
pepijndevos: are you in the plugdev group?
<pepijndevos>
vup, uh... no, it seems. but I've used a similar udev rules for the st-link and that worked fine... will compare...
<pepijndevos>
the stlink just literally has ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", TAG+="uaccess"
<pepijndevos>
no groups or mode or any of that
<whitequark>
pepijndevos: the rules for glasgow specifically require you to be in the plugdev group
<pepijndevos>
It seems the plugdev group is an ubuntu-ism
<plaes>
static groups (plugdev, for example) is deprecated
<plaes>
TAG+=uaccess provides access based on systemd-session to current logged-in user
<plaes>
unfortunately it's somewhat undocumented still :(
<pepijndevos>
Also unfortunately if I only use uaccess I get an error, with an explicit group it works for me.
<pepijndevos>
Self test passed :)
<pepijndevos>
But uuuuuh, is there no SPI slave applet?
<whitequark>
nope, think about it
<whitequark>
USB has unbounded and quite high latency
<whitequark>
and unlike I2C, SPI has no clock stretching
<whitequark>
so you can't really write a *generic* SPI target applet
<whitequark>
(which would let Python code running on the host to respond to SPI data)
<pepijndevos>
I mean, not one that actually sends stuff, but just dumping incoming data should be possible right?
<whitequark>
true but the usefulness seems very limited
<whitequark>
that's not so much SPI as it is RX-only USART
<whitequark>
well
<whitequark>
SART?
<whitequark>
SAR?
<whitequark>
yo uget the idea
<hell__>
I'd say it's probably better to make a logic analyzer applet and then parse the captured data as SPI
<whitequark>
valid
<pepijndevos>
Honestly that's pretty much what I'm looking for I guess
<hell__>
it'd be more generic, so more reusable
<hell__>
s/more//G
<whitequark>
yeah there's still no LA applet unfortunately
<pepijndevos>
For any specific technical challenge, or just because it's not high on the priority list?
bvernoux has joined #glasgow
<pepijndevos>
Honestly seems like from a hardware perspective, the Saleae that I misplaced is also basically an FPGA with awesome input buffering, except they *only* have a LA applet.
<hell__>
i'd guess the latter reason
<whitequark>
latter
<whitequark>
there's --trace
<whitequark>
and every time i needed an LA, i would already have a sketch of an applet
<whitequark>
so I could just use --trace
<pepijndevos>
trace?
<whitequark>
`glasgow run --trace`
<whitequark>
glasgow has an integrated LA
<whitequark>
i.e. an LA that gives you visibility into applet I/O, from the pin side and USB side
<whitequark>
it just doesn't have a dedicated LA applet that samples pins
<whitequark>
in a way, it has a more powerful solution earlier than a less powerful one
<pepijndevos>
so not quite usable as a generic LA, but useful for debugging WIP applets?