ExeciN has quit [Remote host closed the connection]
ExeciN has joined #glasgow
gregdavill has quit [Ping timeout: 260 seconds]
<whitequark>
awygle: pong
Stormwind_mobile has quit [Ping timeout: 265 seconds]
Stormwind_mobile has joined #glasgow
promach3 has quit [Quit: killed]
david-sawatzke[m has quit [Quit: killed]
john_k[m] has quit [Quit: killed]
fridtjof[m] has quit [Quit: killed]
jschievink has quit [Quit: killed]
emily has quit [Quit: killed]
ZerataX has quit [Quit: killed]
disasm[m] has quit [Quit: killed]
emily has joined #glasgow
fridtjof[m] has joined #glasgow
disasm[m] has joined #glasgow
ZerataX has joined #glasgow
david-sawatzke[m has joined #glasgow
jschievink has joined #glasgow
john_k[m] has joined #glasgow
promach3 has joined #glasgow
kerel has joined #glasgow
niklas has joined #glasgow
niklas is now known as Guest95153
ExeciN has quit [Ping timeout: 265 seconds]
hell__ has quit [Ping timeout: 260 seconds]
Th3Fanbus has joined #glasgow
Th3Fanbus_ has joined #glasgow
Th3Fanbus_ has quit [Remote host closed the connection]
Th3Fanbus is now known as hell__
tomtastic_ has joined #glasgow
tomtastic has quit [Ping timeout: 240 seconds]
hellsenberg has joined #glasgow
Stormwind_mobile has quit [Ping timeout: 258 seconds]
hell__ has quit [Quit: CPU has triple-faulted.]
hellsenberg is now known as hell__
bvernoux has joined #glasgow
hell__ has quit [Ping timeout: 240 seconds]
<awygle>
whitequark: ding
<whitequark>
awygle: dong
<awygle>
hehe, "dong"
<awygle>
uh so
<awygle>
i was trying to play with the ELA applet last night
<awygle>
and i wanted to ask a couple clarifying questions
<whitequark>
yep
<awygle>
it looks like it triggers on any change to any of the inputs, is that right?
<whitequark>
it doesn't have triggers per se
<whitequark>
it just records forever
<awygle>
oh. then how do i make it uh... write out a file? ctrl+c?
<whitequark>
yep
<whitequark>
it should be constantly writing to a vcd file
<whitequark>
but ctrl+c flushes a buffer
<whitequark>
actually now that i said that, i realize it's not buffering quite as efficiently as it could
<awygle>
aren't VCDs not very suited to incrementalism like that? does ctrl+c have to do some finalization cleanup?
<whitequark>
but that's the idea
<whitequark>
nope
<whitequark>
you can stream a VCD just fine
<whitequark>
gtkwave even supports streaming VCD through shared memory
<whitequark>
(i refuse to support that, it's horrifying)
<awygle>
right
<awygle>
ok
<whitequark>
have you looked at VCD files?
<whitequark>
just `less` it
<awygle>
yeah i have
Guest95153 has quit [Remote host closed the connection]
<awygle>
just something i've heard
<whitequark>
the main problem is adding new probes which the ELA applet doesn't need
<whitequark>
this is probably what you've heard
<awygle>
ah that makes sense yes
<awygle>
second question is it seems i need to pass the pins to --pins-i but i couldn't figure out the syntax
<whitequark>
0,1,2,...
<whitequark>
this is the same way it works for all applets but it's a bit weird
<whitequark>
so the idea is that you pass --port A or --port B or --port AB or --port BA
<whitequark>
if you do --port AB the physical pins A0, A1, ... B7 are "concatenated" into one long sequence
<awygle>
hm so i end up with an empty vcd
<awygle>
when i do this
<awygle>
does that mean no pins changed state? (possible)
<whitequark>
yes
<awygle>
mk
<awygle>
i'll try that all again while forcing pin state after my next meeting then <_< thanks
<awygle>
also i do get an exception when closing when there's no pin changes
<awygle>
UnboundLocalError: local variable 'timestamp' referenced before assignment
<awygle>
nbd but thought i'd mention
<whitequark>
oh that's a bug
hell__ has joined #glasgow
<electronic_eel>
esden: what are your thoughts about changing the tvs diodes for revC2?
<electronic_eel>
currently we have MG2040, they are about $ 0.60 @100 and just available at western distributors (mouser/digikey and the like), not at LCSC
<electronic_eel>
the alternative niklas suggested is using SP3012-06UTG, they are available at mouser, digikey and LCSC
<electronic_eel>
LCSC price is $ 0.13 @100, but they have just 6 lines, so we'd need two per channel
<electronic_eel>
performance wise they aren't that far apart, with the SP3012-06UTG being a bit more robust but 0.5pF, while the MG2040 is a bit less robust but has 0.35pF
<electronic_eel>
IIRC there were some reports about the footprint for the MG2040 in revC1 making problems, I haven't checked if you have improved it or not
<whitequark>
it's a pretty awful footprint
<whitequark>
improved or not
<whitequark>
inherently error prone
Stormwind_mobile has joined #glasgow
<electronic_eel>
yeah, the gnd-pads in the middle and the data pins being offset makes it difficult. the SP3012-06UTG is more symmetric, more like a resistor array or similar
hellsenberg has joined #glasgow
<whitequark>
i'm very much in favor
<electronic_eel>
ok
<electronic_eel>
the layout won't look as pretty, as you need two of them per channel and I don't think they'll fit next to each other
<whitequark>
hrm
<whitequark>
we can always ask marcan to lend us a hand laying this out later :p
<whitequark>
i really appreciated his work on revC0/1
<electronic_eel>
yeah, he is not only good at getting it working, but also making it beautiful
<whitequark>
yep
<electronic_eel>
but esden is quite good at this too, I really like the new silkscreen sectioning for revC2 he did
<esden>
electronic_eel: I am fine with that diode change. I was looking into it when you pointed out the part. You are welcome to put them in. I have a few things I will want to try to reorganize for aesthetic reasons later on, but not until wednesday probably. (icebreaker-bitsy assembly stream is tomorrow ;) )
<esden>
I will want to ask your opinion about those changes before I make them of course.
<esden>
For now just go ahead. :)
<electronic_eel>
ok, then I will change the tvs diode
<electronic_eel>
I'm currently checking another change, simplifying the reset circuit
<esden>
yeah I saw you mention it, looking forward to that! :D
<electronic_eel>
currently I haven't found anything that prevents us doing this change
<electronic_eel>
ok, so the ice40hx don't have power sequencing requirements
<electronic_eel>
the fx2 also doesn't directly have them
<electronic_eel>
but there is one catch: if there is a voltage sag while there is i2c communication, the new reset ic will just reset the fx2, not all the i2c bus members
<electronic_eel>
so the ics on the i2c bus can stay in some unknown and inconsisten i2c bus state
<whitequark>
that seems... unfortunate
<electronic_eel>
yeah
<electronic_eel>
currently the power sequencing ic completely shuts off the 3v3
<electronic_eel>
so all i2c bus members are properly reset
<whitequark>
the first thing the fx2 does is issues a read on a nonexistent eeprom address
<electronic_eel>
the fx2 might not start up in the correct boot mode and thus will fail to be recognized by the glasgow software
<whitequark>
not unless it reads C0 or C2 from there... hrm
<whitequark>
it would be best to fix that properly
<whitequark>
can we?
<electronic_eel>
we need some kind of power sequencing, so 3v3 is shut off on reset and the fx2 reset released only after 3v3 is stable again
<electronic_eel>
the LM3880 we currently have does that well and without too much board space
<electronic_eel>
but it is about $0.85 @100 while the MAX809J is $0.17 @100 at LCSC
<electronic_eel>
we could rig up something with the MAX809J and some rc-circuits and small 74xx little logic
<electronic_eel>
but this will add more components to the BOM and take up more board space
<electronic_eel>
I currently feel like it is not worth it
<whitequark>
:S
<electronic_eel>
we could use two reset ics: one on the 5v line, shutting off the 3v3 regulator, but not resetting the fx2
<electronic_eel>
then another one that is on the 3v3 line, that one resets the fx2 based on the 3v3 rail voltage
<electronic_eel>
so no 74xx logic necessary
<whitequark>
what if the brown out is only on the 3V3 line?
<electronic_eel>
then we may end up in an inconsistent state. but we already have this problem with the current design
<electronic_eel>
the current sequencing ic just monitors the 5v rail, not the 3v3 one
<electronic_eel>
but a design with 2 voltage monitor ics would amplify the problem a bit:
<electronic_eel>
if the 3v3 monitor triggers the reset, we really get a reset on the fx2
<electronic_eel>
currently the voltage will just sag, the fx2 may or may not do a reset due to this
<electronic_eel>
do we expect a brownout on the internal 3v3 bus in normal operating conditions?
<electronic_eel>
if someone pokes the Glasgow with a screwdriver and causes a short, I have no problems with it becoming unstable and needing a hard reset
<electronic_eel>
when we expose a 3v3 to addons in >= revD, we'll have to revisit this though
<electronic_eel>
as connecting / disconnecting them can cause a 3v3 brownout
<electronic_eel>
so probably separate regulator then for them
<whitequark>
yes i was thinking of revD
<whitequark>
separate regulator sounds good
<whitequark>
two regulators for the current design also sound good
<electronic_eel>
you mean two reset circuits? or two regulators?
<electronic_eel>
I'm currently leaning towards keeping the current solution with the LM3880 power sequencer
<whitequark>
ah, keeping LM3880 also works
<electronic_eel>
it might be $0.50 extra, but it is a tried and proper solution
<electronic_eel>
when I did my testing with the shorts on both vios, the reset always worked reliably
<electronic_eel>
I want to keep it that way
<whitequark>
gotcha, let's keep it
<electronic_eel>
ok, so I'm doing the tvs diode change in schematics and layout on the wip-revC2 branch next
hellsenberg is now known as Th3Fanbus
hell__ is now known as hellsenberg
Th3Fanbus is now known as hell__
bvernoux has quit [Quit: Leaving]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #glasgow
<d1b2>
<Hardkrash> There is a product called GreenPAK from dialog (formerly Silego) that has some nice programming functionality for making these kind of components. Some even include built in P-FETs for power switching rails. E.g. https://www.dialog-semiconductor.com/products/slg46127
<electronic_eel>
they have the big downside that they are OTP and need a special programming jig
<whitequark>
the programming protocol has been explained to us under NDA
<whitequark>
it's a fairly complicated parallel-ish protocol, so it can be our jig, but it will still be a special jig
<whitequark>
the GP5 devices are field programmable via I2C but i don't think you can program the OTP ROM that way
<whitequark>
though i might be wrong on the last part
<electronic_eel>
I think using them would make Glasgow unfriendly to build-your-own
<whitequark>
certainly
<whitequark>
the socket alone cost something like $50 IIRC
<whitequark>
and even if not you would introduce a circular dependency
<electronic_eel>
I like the concept of the GreenPAKs, but the OTP nature with custom footprint makes them hard to use in smaller scale projects
<electronic_eel>
also I don't know how friendly towards smaller companies Dialog is (they bought Silego)
<whitequark>
I think I never actually soldered a GP4 with all pins working on a HASL board
<whitequark>
that package is really not very friendly
<electronic_eel>
just been browsing their website and it seems like they added some new packages
<electronic_eel>
I think they previously just had a smallish qfn-20 with 0.4mm pitch, now they have a TSSOP-20 too, also some variants with more or less pins
<whitequark>
oh huh
<awygle>
whitequark: is "FIFO overrun, shutting down" indicating that more data happened than could go over USB without dropping some?
<whitequark>
yes
<whitequark>
do you hit that a lot?
<whitequark>
the buffering right now kinda sucks, i can fix that if it blocks you
<d1b2>
<Hardkrash> Great points on the greenpak, we would probably have to order a reel of 3k pre programmed for the community to share out... it would be interesting to see if they would work with makers on this...
<awygle>
whitequark: i always hit it instantly? which doesn't seem right
<whitequark>
hmm
<whitequark>
do you have floating inputs?
<awygle>
it's possible
<whitequark>
the vcd file should still be written
<awygle>
i should add pull-downs
<whitequark>
can you look at it?
<awygle>
it is, it's 16k
<awygle>
around 16ms of data
<awygle>
according to gtkwave
<whitequark>
look at the very end of the file
<whitequark>
any floating inputs?
<awygle>
there's a bunch of thrash around 15.3 ms but the end looks pretty flat
<awygle>
but since i don't expect any pins to be changing it's either something very wrong or a floating input(or more than one)
<whitequark>
yes that thrash is probably why it broke
<awygle>
mhm
<awygle>
gotta figure out how to put pull-downs on tristate pins...
<whitequark>
oh, easy
<whitequark>
moment
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJf0T