<d1b2>
<esden> @whitequark just the prototypes, not the full production.
<whitequark>
puck: pullups, likely
<d1b2>
<esden> The full production will still be done via a CM. The Glasgow ends up being on the verge of my assembly capabilities (too many bom lines -> too many feeders needed/my PnP is not fast enough) it will be faster overall when we assemble the full production run via a CM.
<d1b2>
<esden> The prototypes have so many parts that it is worth setting up the PnP to assemble the high frequency parts.
<whitequark>
puck: you could check with a meter, but since it's almost certain that this is the problem, i suggest getting a logic buffer straight away
<whitequark>
buffer TCK, TDI, TMS, that should fix it
<puck>
yeah, looking here i indeed think TCK is pulled to ground, and TMS/TDI are pulled up te VCCA of the chip
<d1b2>
<esden> So the back of the board will be fully machine assembled and the front will be partially assembled on the PnP and the rest hand placed.
<whitequark>
esden: ahh makes sense
<puck>
i don't think i have much in the way of random buffers laying around, so i might just wait until the revC2 appears and grab one of those
<whitequark>
puck: can't you buy some buffers on mouser or sth?
<whitequark>
if you're in EU it shouldn't cost too much
<puck>
i could; i should at some point start building a collection of electronic parts, but also i'm not sure this is the perfect time for me for that :p
<whitequark>
when i had this issue with revB i basically grabbed a buffer in qty 1
<whitequark>
but yeah
<puck>
this is mostly about fixing a pretty minor bug in a different device, and it's sorta low priority for me
<whitequark>
ahh
<puck>
but yeah, it being the pullup/pulldown makes sense, thanks for reminding me of that gotcha
<d1b2>
<tnt> Depending on what device you work on, removing the FXMA and bridging across it is also a solution. I did that on one port of mine and I use that with 3v3 without issues all the time.
<d1b2>
<esden> Ohh one more thing. The PROM reader addon for Glasgow we designed on stream just shipped from OSHPark! 🙂
<d1b2>
<esden> This is why @DX-MON contributed the latch functionality to the applet. 🙂
<whitequark>
esden: no pdf?
<d1b2>
<esden> yeah I forgot, give me a sec (really wish github had kicad file preview >_<)
<d1b2>
<esden> (when will someone write a kicad schematic and board renderer in java script?)
<whitequark>
cadlab.io has one i think?
<d1b2>
<esden> it is super slow though
<d1b2>
<esden> and really hard to navigate revisions
<d1b2>
<esden> I
<d1b2>
<esden> I did try using it, it was not really fun to use. 😦
<d1b2>
<esden> I am more thinking of an open source renderer that could be integrated into github/gitlab or any other website that wants to render kicad files.
<whitequark>
basically identical to my design, right?
<whitequark>
with the exception of latching
<whitequark>
once that's proven i suggest we migrate it to the main repo (i always intended to have addons there)
<whitequark>
fwiw, i have a specific plan for repositories once i merge out-of-tree applet support
<whitequark>
- GlasgowEmbedded/glasgow has {applets,boards,databases,...} that are known to work well and are particularly well supported. e.g. JTAG
<whitequark>
- GlasgowEmbedded/glasgow-contrib has {applets,boards,databases,...} that are known to work reasonably well/are reasonably complete but don't come with particular support guarantees and are perhaps obscure. e.g. the e-paper display applet i wrote
<whitequark>
- GlasgowEmbedded/glasgow-staging is just "anything goes"
<whitequark>
i don't want the main repo to be just "applets that i wrote", and some of the applets i write don't even really deserve to live there because they're barely functional. so the ones we currently have in the main repo would be split among all three
<whitequark>
the criteria for /glasgow would be "has an active maintainer" ie someone actually fixing bugs
<whitequark>
for /glasgow-contrib would be "works reasonably well" but if you find issues you're on your own
<whitequark>
for /glasgow-staging would be "maybe if it bitrots there someone will pick it up"
<whitequark>
/glasgow and /glasgow-contrib would need a proper review. /glasgow-staging would have no serious review beyond "is this actively breaking something important"
<d1b2>
<esden> Ahh ok, yeah I am happy to move it to either a parallel repo or into the main repo. The core goal of the twitch streams and the design was providing a template for addons in general.
<whitequark>
documentation as twitch streams :/ :/
<d1b2>
<esden> lol not the twitch streams themselves ... but at least the board. 🙂
<whitequark>
ahhhh
<whitequark>
we could def use a kicad template (if that's even a thing)
<d1b2>
<esden> kicad templates are a thing yeah
<whitequark>
think you could make a PR with a blank board and layout? or someone else
<whitequark>
even better if it's a template
<whitequark>
i *definitely* want that in the main repo
<d1b2>
<esden> I will send Pull Requests for the board (when it is proven to be working) and template (when I make it). 🙂
<d1b2>
<esden> I do think PROM reader for a common pinout like this is a good candidate to live in the main repo.
<d1b2>
<esden> But we can discuss it in the PR when the time comes. 🙂
<whitequark>
re PROM reader: yes, I think addons for applets in the main repo (and memory-prom definitely should be in the main repo) should also live in the main repo
<whitequark>
in general, /glasgow, /glasgow-contrib and /glasgow-staging would have the exact same structure
<whitequark>
well you don't need firmware in the last two, but you get the idea
<whitequark>
like filesystem overlays
<whitequark>
ugh the TI MSP430 programming docs are so miserable
<cr1901_modern>
I wonder how the GoodFET team felt when making their programmer...
<whitequark>
probably miserable
<whitequark>
like... i'm conflicted between following their doc enough that i can refer the functions directly
<whitequark>
or just ignoring their doc and doing what makes sense
<whitequark>
and it's not *quite* bad enough for the latter, but also not *nearly* good enough for the former
<cr1901_modern>
Would you like me to help break that indecision?
<whitequark>
probably, yeah, but i think i'd like that to happen tomorrow
<whitequark>
let me push my WIP code
<whitequark>
are you interested in the msp430 applet at all? like, beyond using it as a template for probe-rs
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to wip-applet.debug.msp430 [+0/-0/±1] https://git.io/JT6dH
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark 111f573 - [WIP] reorganize the applet
<cr1901_modern>
Funny you should ask that... adding support for glasgow to msp430 applet (as a Spy-Bi-Wire driver) would be interesting/something I'm mulling over
<cr1901_modern>
that should read "glasgow msp430 applet to probe-rs*"
<whitequark>
hm
<whitequark>
no, i'm specifically talking about the debugger
<cr1901_modern>
Oh, I don't know yet. I think after probe-rs support I will need a break. There's still a lot left to do to make msp430 on par w/ ARM unfortunately in Rust world
<whitequark>
what i'm asking is whether you'd use the applet if i finish it
<cr1901_modern>
No, not right now. Emphasis on not right now.
<whitequark>
ack
<whitequark>
tnt: what about you?
<cr1901_modern>
Just to be explicit- I'm very appreciative that the applet exists as a reference. I don't currently have any msp430 projects r/n beyond making sure AT2XT keeps compiling.
electronic_eel has quit [Ping timeout: 260 seconds]
electronic_eel has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 258 seconds]
PyroPeter_ is now known as PyroPeter
<tnt>
whitequark: if it's compatible with the newer FR2433 type devices, yes.
<tnt>
I only have a couple of msp430 project a year, so it's also not something I'd use as often as like the spi flash applet obviously.
<whitequark>
tnt: ack... i should see if i have any FR ones
<hl>
random question: could glasgow implement a USB2 device using the iCE40 pins? (idle curiosity, pondering double use as an iCE40 dev board)
<d1b2>
<daveshah> If by USB 2.0 you mean USB 2.0 HS; 480Mbit/s is pretty marginal for iCE40 fabric/routing, and with no IO delays or ability to oversample to 960Mbit/s doing 'CDR' would be hard too
<hl>
nah just FS
<d1b2>
<daveshah> oh that should be fine
<hl>
ah. So the buffer/level shifter chips don't create unacceptable turnaround for transitions between {oe=1/output, oe=0/input} for a half-duplex medium?
<d1b2>
<daveshah> That might work, but afaik the LVDS connector gets you access to raw iCE40 IO which might be more useful
<hl>
oh right, D+/D- are 3.3V not 5V. brainfart
Stormwind_mobile has quit [Ping timeout: 272 seconds]
oeuf has joined #glasgow
egg has quit [Ping timeout: 258 seconds]
Stormwind_mobile has joined #glasgow
oeuf has quit [Ping timeout: 258 seconds]
oeuf has joined #glasgow
<whitequark>
hl: the turnaround at FS is very relaxed
<whitequark[m]>
test
<d1b2>
<Benny> Test1234
<d1b2>
<Rogan> 👍🏻
<cr1901_modern>
parity check 2
Electro707 has joined #glasgow
whitequark[m] has left #glasgow ["User left"]
whitequark[m] has joined #glasgow
moho1 has quit [Quit: WeeChat 2.6]
Getorix_ has joined #glasgow
Getorix has quit [Ping timeout: 240 seconds]
Electro707 has quit [Ping timeout: 265 seconds]
whitequark[m] has quit [Quit: authenticating]
whitequark[m] has joined #glasgow
samlittlewood_ has quit [Ping timeout: 272 seconds]
samlittlewood has joined #glasgow
samlittlewood has quit [Ping timeout: 246 seconds]
samlittlewood has joined #glasgow
emilazy has quit [*.net *.split]
StM_ has quit [*.net *.split]
jpa- has quit [*.net *.split]
StM has joined #glasgow
jpa- has joined #glasgow
emilazy has joined #glasgow
samlittlewood has quit [Ping timeout: 264 seconds]
samlittlewood has joined #glasgow
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #glasgow
samlittlewood has quit [Ping timeout: 260 seconds]
samlittlewood has joined #glasgow
<_whitenotifier-f>
[glasgow] gregdavill opened pull request #222: hardware: Add 3d printed case - https://git.io/JTP7g
samlittlewood_ has joined #glasgow
samlittlewood has quit [Ping timeout: 265 seconds]
samlittlewood_ is now known as samlittlewood
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #222: hardware: Add 3d printed case - https://git.io/JTP5v
samlittlewood has quit [Ping timeout: 272 seconds]
<_whitenotifier-f>
[glasgow] whitequark commented on pull request #222: hardware: Add 3d printed case - https://git.io/JTP5G
<_whitenotifier-f>
[glasgow] gregdavill commented on pull request #222: hardware: Add 3d printed case - https://git.io/JTPd7
<_whitenotifier-f>
[glasgow] gregdavill synchronize pull request #222: hardware: Add 3d printed case - https://git.io/JTP7g