<d1b2>
<esden> Fun fact... red led are incredibly consistent between types and vendors
<ebb>
Reds are probably one of the oldest "chemistries", right?
<ebb>
As opposed to, say, blues
<kmc>
yeah
<kmc>
I made a red LED in undergrad lab once! using a bit of wax applied with a toothpick as a mask
<smkz>
:3
<smkz>
i still have twinges of regret about not taking that class
infinigon has quit [Ping timeout: 245 seconds]
infinigon has joined #glasgow
<d1b2>
<esden> I would love to carve out some time to do ASIC design. That would be a lot of fun. 🙂 But obviously it is not the same as doping one's own silicon. 😄
egg|anbo|egg has quit [Read error: Connection reset by peer]
jstein has quit [Quit: quit]
<d1b2>
<crobi> I remember a lab mate spent nearly a whole year working on a board to characterize our lab's experimental LEDs on a cube sat. sure was an entertaining time hearing his revision calls and design meetings for that project.
<sorear>
finding myself wondering about the spectral response of the detector... problem is underconstrained without it
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
infinigon_ has joined #glasgow
infinigon has quit [Ping timeout: 268 seconds]
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter_ is now known as PyroPeter
<d1b2>
<esden> @crobi ohh yeah, I will not reach that level of accuracy. 🙂
<d1b2>
<esden> @sorear those photos are mostly just for documentation purposes. Not quantitative measurements. Also I am being told that the devices meant for analysis are always relative measurements and require careful calibration and reference sources.
<d1b2>
<esden> So nothing I will do will end up satisfying anyone with metrological aspirations.
<sorear>
it's a shame because nearly any measuring device _can_ be used if the relevant documentation exists
egg|anbo|egg_ has quit [Remote host closed the connection]
GNUmoon2 has quit [Ping timeout: 240 seconds]
GNUmoon2 has joined #glasgow
m4ssi has joined #glasgow
egg|anbo|egg has joined #glasgow
richbridger has quit [Remote host closed the connection]
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
m4ssi has quit [Remote host closed the connection]
egg|anbo|egg_ has joined #glasgow
egg|anbo|egg has quit [Ping timeout: 268 seconds]
egg|anbo|egg_ has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
noopwafel has quit [Ping timeout: 240 seconds]
<d1b2>
<Nana> g'day everyone, can someone tell me whether there is already a possibility to delay my output for the scripting interface (e.g. UART / SPI / I2C) or to wait a few ms after sending before something is sent again?
egg|anbo|egg has quit [Remote host closed the connection]
egg|anbo|egg has joined #glasgow
<_whitenotifier-5>
[GlasgowEmbedded/glasgow] whitequark pushed 2 commits to main [+0/-0/±2] https://git.io/JYlfX
<d1b2>
<Attie> @Nana can you clarify? anything wrong with calling asyncio.sleep()?
bvernoux has joined #glasgow
Eli2 has joined #glasgow
Eli2_ has quit [Ping timeout: 246 seconds]
jstein has joined #glasgow
kbeckmann has quit [Quit: WeeChat 2.9]
kbeckmann has joined #glasgow
GNUmoon2 has quit [Ping timeout: 240 seconds]
englishm__ has quit []
englishm has joined #glasgow
bvernoux has quit [Quit: Leaving]
richbridger has joined #glasgow
<_whitenotifier-5>
[glasgow] electroniceel commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY8BX
karlyeurl has joined #glasgow
karlyeurl has quit [Read error: Connection reset by peer]
<agg>
ugh, this cursed ice40 differential input thing
<agg>
electronic_eel: that lattice tech note changelog indicates it swapped how it talked about _A and _B in 1.4, lol
<electronic_eel>
agg: oh, good catch
<electronic_eel>
seems like they confused it themselves
<agg>
certainly in icestorm/nextpnr you have to place the SB_IO only on the B site
<agg>
and the resulting input is then seen as though the B is the non-inverting/positive input
<agg>
the lattice technote also talks about only placing the SB_IO at "one" IO site, but doesn't say which
<agg>
I wouldn't be surprised if something stupid happens like icecube/radiant adds an inverter if you place it at the A site
<electronic_eel>
do you know of another lattice document than this lvds tech note that explains it in more detail? i would have expected the tech library document to explain it, but it didn't explain the _A and _B (or at least I didn't see it)
<agg>
I can't find anything, the tech library doesn't mention the SB_LVDS_INPUT attribute option at all
<electronic_eel>
do they expect the users to check with a scope or what?
<agg>
it gives a partial enumeration for IO_STANDARD not including any differential modes
<agg>
wonder if it was hacked in after siliconblue wrote the tech lib guide....
<agg>
i've used lvds input on ice40, though not recently, and haven't tried with icecube, though I did recently manage to install icecube
<agg>
but it's super annoying, have to create a fake nic named eth0 for licensing or whatever, so not hugely inspired to see what madness it does
<d1b2>
<gatecat> the inconsistency gets worse when you find the up5k has the A pins as positive
<agg>
yea!
<agg>
I mean, at least they fixed it, right
<d1b2>
<gatecat> and therefore the up5k needs constraints on the A side
<d1b2>
<gatecat> I guess so
<electronic_eel>
the comment in nmigen suggests that it is differently between the ice40 variants (LP/HX/UP/...)
<agg>
I'm pretty sure the nmigen comment is correct, modulo any tricks icecube plays if you try and use it for synthesis instead of nextpnr
<agg>
I mean it also basically doesn't matter, just use PinsN in the platform or invert=True or whatever
<agg>
v tiresome
<agg>
(I mean, obviously it matters hugely that it's the right way around, but you could just always pretend the A input is also the non-inverting input and make it ok in the platform)
<electronic_eel>
the glasgow schematics show the lvds pins as _N and _P. the schematics will be used as reference by addon and gateware developers. so it should somewhat match reality...
karlyeurl has joined #glasgow
<tnt>
The pinout documents have "True" and "Complement" noted for each pin.
<agg>
the 5k does
<agg>
my hx8k pinout doesn't, let me see if there's a new one
<electronic_eel>
tnt: where is this noted? the HX8K pinout one doesn't have it
<tnt>
ok, nm, I didn't check the hx one
<tnt>
I guess for those TN1253 points it out.
<_whitenotifier-5>
[glasgow] electroniceel commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY8zU
<tnt>
electronic_eel: btw in your comment ... figure 2 is "output pair", not input pair.
<tnt>
all the figures with input pair point to 'B' being non-inverting.
<electronic_eel>
oh! input and output pairs are different!
<agg>
oh, yea, good point, fig 3 clearly shows B as +
<agg>
and fig 5 too
<tnt>
output really doesn't matter, AFAIK the invert is done in a lut, it's all pseudo diff, not a true diff output driver.
<electronic_eel>
this is really designed to confuse the users
<electronic_eel>
the original bug report from wq was that the pin designators in the schematics are wrong. since they can be used for input and output, and they are swapped for in/out, the designators can't ever be correct the way they are done now
<tnt>
well ... not really ... as I said ... output doesn't matter you can swap freely.
<electronic_eel>
hmm, won't the input also usually go to a lut where you can swap?
<electronic_eel>
or better invert
GNUmoon2 has joined #glasgow
<electronic_eel>
so this seems more like a documentation problem to me. making this mess easy to grasp for addon and gateware devs
<tnt>
electronic_eel: sure you "could" swap, but for input the toolchain won't do it for you.
<tnt>
and you also need the constraint on the positive pin.
<tnt>
(or rather the toolchain won't do it for you if you're doing the sane thing and using io reg)
<electronic_eel>
hmm, "constraint on the positive pin" - could you explain that in more detail?
<electronic_eel>
remember that i'm a fpga noob...
<tnt>
tn1253 fig 9, the note on the input.
<tnt>
when using a lvds input in the ice40, you "only" create 1 single input port on the top level and connect ti to a single SB_IO instance on the "positive" pin.
<tnt>
The negative one is implicit
<tnt>
(and actually _must_not_ be wired or even declared on the top level or that shows up as a conflict)
<agg>
so the A/-ve pad number never shows up in your design, you only talk about the B/+ve pad number, and the toolchain knows since it's differential it needs to compare against the A/-ve pad
<agg>
and it then outputs 0/1 depending on if the B/+ve pad is </> the A/-ve pad respectively
<agg>
you could invert this yourself in the gateware, but it has a true sense in hardware
<agg>
but the output doesn't - you just drive any two pins you like, one to 0 and one to 1, the hardware doesn't care and is totally symmetric for output, so there's no hardware sense to which is positive
<electronic_eel>
tnt: and configuring the negative input is automatically done by the toolchains, both icestorm and lattice?
<tnt>
yes
<agg>
(icecube, lattice is for ecp5 not ice40)
<agg>
uh....
<agg>
ignore me, was thinking of diamond, lol
<electronic_eel>
but for the diff output you need to actually create two SB_IOs in your code
<agg>
yea
<agg>
so if you wanted, the glasgow schematic could have _P for the B pins and _N for the A pins, and it would match the hardware comparators, and you could make the outputs also match that
<electronic_eel>
so it would make more sense to name the pins in the schematics according to input
<tnt>
yes
<tnt>
(interesting side note is that you can't have bidirectional diff I/Os ...)
<electronic_eel>
so you need to fully reconfigure the fpga to swap from input to output?
<tnt>
yup
<electronic_eel>
and no partial reconfig on the ice40
<agg>
you also need somewhat different external resistors for lvds-compatible input vs output too, right?
<agg>
input is just one resistor across the P/N pins, output needs a three-resistor divider to do fake lvds
<agg>
the TN1253 verilog example for a differential output actually also uses _B for P and _A for N
<tnt>
agg: well .. given that the series resistor will see no current (or virtually none) for inputs, the output network can be used for inputs.
<agg>
but it also says very explicitly (I suppose this was the 1.4 update) "Connect the positive or true polarity side of the differential pair to the DPxxA input "
<agg>
lvds is current-mode so I guess it depends on the compliance of the source but yea it's probably ok
<agg>
oh, hm
<agg>
yea, flipped it in my head, you're right
<tnt>
well current through the term resistor ...
<agg>
doesn't matter
<tnt>
no current through the comparator.
<agg>
I think you end up with slightly different term resistors but not enough to cause issues
<agg>
I had 140R for the middle output resistor on a 3v3 vccio which was already kinda rounded
<tnt>
yeah, you'll need to tweak a bit.
<agg>
but I'm sure 490mV is going to be fine too in practice
<_whitenotifier-5>
[glasgow] whitequark commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY8ah
<_whitenotifier-5>
[glasgow] electroniceel commented on issue #281: P and N pins are swapped on revC2 - https://git.io/JY8Ve
<_whitenotifier-5>
[glasgow] esden commented on issue #259: revC LED type and resistor selection - https://git.io/JY8Vw
<_whitenotifier-5>
[glasgow] electroniceel commented on issue #259: revC LED type and resistor selection - https://git.io/JY8VF
<_whitenotifier-5>
[glasgow] electroniceel commented on issue #259: revC LED type and resistor selection - https://git.io/JY8w5
<_whitenotifier-5>
[glasgow] esden commented on issue #259: revC LED type and resistor selection - https://git.io/JY8ol