electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #glasgow
levi has quit [Quit: Connection closed for inactivity]
levi has joined #glasgow
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<electronic_eel>
whitequark: I like the button idea
<electronic_eel>
the question is where to put it on the board so that you can easily access it. maybe where the FX2 EEPROM is now?
<electronic_eel>
or do we want a button with a long ... (stick? plunger? actuator? don't know the correct term) that would stick out of a case higher than the shrouds of the ports?
<noopwafel>
clearly you want an external connector leading to a big red button under a plastic cover
<electronic_eel>
won't fit on the board unfortunately
<gruetzkopf>
well, the board will fit inside..
ExeciN has joined #glasgow
ExeciN has quit [Read error: Connection reset by peer]
Stormwind_mobile has quit [Ping timeout: 246 seconds]
ali_as has quit [Ping timeout: 256 seconds]
ali_as has joined #glasgow
Stormwind_mobile has joined #glasgow
bvernoux has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 264 seconds]
bvernoux has quit [Read error: Connection reset by peer]
<electronic_eel>
on a more serious note, I think ALPS SKRPABE010 might work well. Available for about $ 0.05 at LCSC, also available at Mouser, Arrow and a few others
<electronic_eel>
it is 4.2x3.2mm and I'd put it where the FX2 EEPROM is now, near the edge of the board
<whitequark>
electronic_eel: except i just realized we can't do it
<whitequark>
no pins
<electronic_eel>
so that you can make a cutout in a lasercut case
<electronic_eel>
why no pins?
<electronic_eel>
you mean on the fx2?
<whitequark>
yeah
<electronic_eel>
we can multiplex it with the leds on revD
<whitequark>
i'd rather just not have it then.
<electronic_eel>
double-diode with int, and the other one multiplexed with err or something
<whitequark>
no.
<whitequark>
just no.
<whitequark>
screw those hacks
<electronic_eel>
I think we thought of a solution to free up one pin on revD for a common/single overcurrent protection with the INA233
<electronic_eel>
we might use that solution for the button instead
<whitequark>
what was it?
<electronic_eel>
I think it was using the CDONE directly for the ICE led
<whitequark>
ah, yeah
<electronic_eel>
that doesn't sound much like a hack to me
<whitequark>
yes, that one is reasonable
<whitequark>
in fact it's better than what we have now
<whitequark>
since iirc i actually hit some issues where CDONE!=FX2_LED
<electronic_eel>
oh
<whitequark>
well, those bugs are fixed now, but conceptually your suggestion is better
<electronic_eel>
I'm more worried about the physical aspects of adding the button
<whitequark>
yes
<whitequark>
i am also quite uncertain about that
<electronic_eel>
with a lasercut case it works when we put it on the edge of the board, but what if you want a full encasing 3d printed one
<whitequark>
this is already a problem because of LEDs
<electronic_eel>
you can use a window of clear plastics for them
<electronic_eel>
but you need a sizable hole for you to get in there with a finger
<whitequark>
there are buttons with a looooooong plunger
<electronic_eel>
or you need some mechanism to extend the button to the outside
<electronic_eel>
the ones with the long plunger add a big lever you can use to rip it off the board when using it without case
<whitequark>
true
<whitequark>
i've been thinking about this button for several months by this point
<whitequark>
and the mechanical aspects always led me to the conclusion that it might not be such a great idea
<electronic_eel>
so I'd say we should use a small smt button and if you want a full case, you need to mount some plunger and button mechanism on the case
<whitequark>
that's basically fine by me, except i don't know where we could find any space for the button
<electronic_eel>
now if you can't use the button because of your case, you are in the same position as now - you have to use commandline to switch to safe mode
<tnt>
how about a 90 deg button next to the usb connector (for mechanical aspect of exposing it that might be easier, no idea about routing/space on the pcb tehre) ?
<electronic_eel>
but the users which are able to touch it get a faster solution
<whitequark>
tnt: no space
<tnt>
Although ... for 3d printed case, you can just 3d print an flexible part of the case that will act as a plunger right ?
<electronic_eel>
I think we can make enough space for the button where the fx2 eeprom is: shift the polymer cap left (already necessary for the 6.3mm one) and then move the eeproms up
<whitequark>
possible
<electronic_eel>
yeah, if you do some multi material 3d printing, you can embed buttons that work
tomtastic has quit [Ping timeout: 256 seconds]
tomtastic has joined #glasgow
<electronic_eel>
the button would pull down the pin on the fx and also, through a diode, pull down INT0, right?
<electronic_eel>
or do you think polling it in the main loop is ok?
<electronic_eel>
or maybe even better bc soft debouncing and preventing too many interrupts?
<whitequark>
electronic_eel: hmmmm
<electronic_eel>
if the button is just used for safe mode, I think it won't matter. but the button may also be reused as some kind of user input button and is pressed as part of normal operation
<whitequark>
no, should just be for safe mode
<electronic_eel>
that is the primary use, as written on the silkscreen and in regular firmware
<electronic_eel>
but if someone wants to hack on the firmware to change it to a user button, I don't want to make it harder for them
<whitequark>
i don't want to specifically enable that
<whitequark>
because that degrades its utility as a safety mechanism
<whitequark>
so if it happens to work worse for that purpose, i'm 100% fine with it
<sorear>
naive question, what does this button accomplish that pulling out the USB cable doesn't
<whitequark>
nothing
<whitequark>
the problem is that i do `glasgow safe` an order of magnitude more often than i pull out the cable
<whitequark>
tbf, i think what would also work is just making it a reset source
<electronic_eel>
the micro usb cable/socket is quite tight, at least on my glasgow. but that should get better with the new usb c one on revC2
<whitequark>
this way we (a) don't have to touch any pins, (b) don't have any risk of firmware not polling it or something
<whitequark>
(c) have it automatically "compatible" with any applets that might be running concurrently (they'll crash with LIBUSB_ERROR_IO, which is fine)
<electronic_eel>
yes, a reset would also work. but then using it as user button is impossible
<whitequark>
i'm fine with that for the reasons i explained above
<whitequark>
(the only downside of a reset is that, with the current software, you'll need to rebuild the bitstream. but we already are quite close to the point where caching bitstreams reliably is possible, so that shouldn't be a huge problem)
<electronic_eel>
I think rebuilding the bitstream is a non-issue if the alternative is a burnt ic
<whitequark>
that's not the right way to look at it
<whitequark>
the right way to look at it is: if the safety mechanism is annoying, people won't use it (or use it enough)
<sorear>
I thought bitstreams were already cached on the device
<whitequark>
sorear: yes, but reset (or pulling out the USB plug) clears that
<whitequark>
since it's just in the SRAM
<electronic_eel>
whitequark: ok, but rebuilding the bitstream is a thing of 10 or 15 seconds. I think this is still far from annoying
<sorear>
would reset cause enumeration order changes if somebody is using multiple glasgows? is that likely to be a problem for any workflows?
<whitequark>
electronic_eel: well, it annoys me enough that i avoid any actions that require it (in fact this is how `glasgow safe` came into existence)
<electronic_eel>
and when we go to ecp5 for revE or something, true caching should be ready
<d1b2>
<gimbas> What does Glasgow safe do
<whitequark>
turns off output drivers and LDO
<whitequark>
basically, removes all power from whatever is attached, and stops driving its IO
<whitequark>
sorear: you already are supposed to use serials for that
<d1b2>
<gimbas> Got it, sounds useful
<electronic_eel>
ok, so directly triggering a reset from the button is fine by me
<electronic_eel>
I think the best way is to pull down the power of the new reset ic a bit with the button, this will trigger the regular reset cycle
<electronic_eel>
with all the proper timings and so on
<whitequark>
yep
samlittlewood_ has joined #glasgow
samlittlewood has quit [Ping timeout: 256 seconds]