azonenberg_work has quit [Ping timeout: 252 seconds]
wbraun has quit [Quit: wbraun]
cr1901_modern1 has joined ##openfpga
cr1901_modern has quit [Ping timeout: 245 seconds]
cr1901_modern1 has quit [Client Quit]
cr1901_modern has joined ##openfpga
azonenberg_work has joined ##openfpga
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 252 seconds]
[X-Scale] is now known as X-Scale
azonenberg_work has quit [Ping timeout: 246 seconds]
azonenberg_work has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
unixb0y has quit [Ping timeout: 240 seconds]
azonenberg_work has quit [Ping timeout: 272 seconds]
Miyu has quit [Ping timeout: 268 seconds]
unixb0y has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
jevinskie has joined ##openfpga
jevinski_ has quit [Ping timeout: 246 seconds]
<SolraBizna>
in which I spend two days running into every possible wrong combination of UART polarities
rohitksingh_work has joined ##openfpga
eightdot has quit [Ping timeout: 240 seconds]
eightdot has joined ##openfpga
Bike has quit [Quit: Lost terminal]
grantsmith has quit [Ping timeout: 250 seconds]
grantsmith has joined ##openfpga
<marshallh>
i know that feel
<marshallh>
tx > tx? not on this device, it's tx > rx
<Lord_Nightmare>
better than the votrax type n talk where the db25 connector on the back has a wiring error that swaps RTS and CTS; they shipped a special cable with it to swap them back, but these are almost universally missing from units on ebay
<Lord_Nightmare>
since they look like a plain db25 to db25 cable
<Lord_Nightmare>
fortunately its 2 traces to cut and a tiny X of patch wires to fix
wbraun has joined ##openfpga
azonenberg_work has joined ##openfpga
wbraun has quit [Quit: wbraun]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 244 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinskie has joined ##openfpga
<gruetzkopf>
have i mentioned the 1200bd partyline modems that use RTS for PTT?
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
jevinski_ has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
Ultrasauce has quit [Remote host closed the connection]
WilhelmVonWeiner has quit [Ping timeout: 260 seconds]
Ultrasauce has joined ##openfpga
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner is now known as Guest3080
jcreedon has joined ##openfpga
jevinskie has quit [Read error: Connection reset by peer]
jevinskie has joined ##openfpga
<SolraBizna>
nextpnr is now taking several minutes per *iteration* routing my project
<SolraBizna>
if ever there was a sign that I'm close to device capacity, this is it
<azonenberg_work>
SolraBizna: what chip?
<azonenberg_work>
(you need a bigger one lol)
<SolraBizna>
iCE40 UP5k
<SolraBizna>
in the end I'm going to be on an HX8k, but I'm taking this detour to attempt the contest
<SolraBizna>
I've been iterating slowly on the pieces, and I haven't really had time to optimize any for size (since I don't even have them all working on a basic level yet)
maciejjo has quit [Ping timeout: 252 seconds]
Patater_ has quit [Quit: Explodes into a thousand pieces]
Patater_ has joined ##openfpga
<SolraBizna>
but it's backfiring now, since it takes me over an hour to iterate on even the smallest change
oeuf has joined ##openfpga
maciejjo has joined ##openfpga
oeuf has quit [Read error: Connection reset by peer]
oeuf has joined ##openfpga
Miyu has joined ##openfpga
Miyu has quit [Ping timeout: 252 seconds]
<SolraBizna>
ugh, is there a good libre Verilog UART out there?
<rqou>
azonenberg_work has one
<rqou>
it's optimized for the fabric to use though, not a cpu
<rqou>
e.g. it will assert done signals for only a single cycle (not latched)
<SolraBizna>
sounds like I can wrap a couple FIFOs around it and interface it to my CPU pretty easily
<azonenberg_work>
SolraBizna: yeah you could
<rqou>
i've used a hacked up version of the opencores one before
<rqou>
it's not great though
<azonenberg_work>
it's in azonenberg/antikernel-ipcores on github
<azonenberg_work>
SolraBizna: good catch, i guess the extra bit of padding never got used for anything so i never fixed it?
<azonenberg_work>
feel free to send a PR :p
<SolraBizna>
I just might do that, it'll make a nice break from a whole three days of debugging my own attempt at a UART without an oscilloscope
<azonenberg_work>
this code is pretty well tested
<SolraBizna>
It looks pretty solid
<azonenberg_work>
i do want to do a few tweaks to clean it up a bit at some point, in particular if you have oversampling turned off there's no metastability hardening on the input ff
<SolraBizna>
hm... it looks like it will have issues if the clock divider is very close to zero
<SolraBizna>
not that that will actually matter in practice
GuzTech has joined ##openfpga
<azonenberg_work>
SolraBizna: yeah it assumes a decently fast clock
<azonenberg_work>
i didnt optimize it for bizarre situations like 10 Mbps uart on a 20 MHz clock
<SolraBizna>
makes perfect sense
<SolraBizna>
getting a reliable UART link >1Mbps is gonna be insane no matter what... and even my braindead giant-spaghetti-tangle-of-logic RV32I core still managed to reach 8MHz
<whitequark>
SolraBizna: huh?
<whitequark>
UART works just fine on 3 Mbps
<SolraBizna>
I'll take your word for it
<whitequark>
SolraBizna: do you need a proven UART?
<whitequark>
mine is not oversampled so it's smaller and simpler
<SolraBizna>
neither is azonenberg_work's by default
<whitequark>
ah ok
<whitequark>
nvm then
<azonenberg_work>
whitequark: the issue is that my uart right now divides the clock down (even with oversampling off) so you can sample in the middle of the data eye
<whitequark>
since mine is in migen azonenberg's probably easier to integrate
<azonenberg_work>
so you cant use a divider of like 1-2 very well
<whitequark>
azonenberg_work: i sample in the middle of data eye too
<azonenberg_work>
But realistically, nobody wants to run a uart that fast
<azonenberg_work>
so its a non-issue
<SolraBizna>
the one I was building required a 16x line rate clock, so this is definitely an improvement on that :P
<whitequark>
that too
<azonenberg_work>
if yo need a 3 Mbps uart you'll have a 10+ MHz clock
<whitequark>
yeah
<azonenberg_work>
I think right now mine realistically wants a 4x rate clock at minimum
<azonenberg_work>
But i havent touched the code in a little bit
<azonenberg_work>
obviously if your clock isn't an exact multiple of the line rate, you get problems with small dividers causing big errors
<azonenberg_work>
vs if you have say a 50 MHz clock doing 9600 baud, you dont need an exact multiple becuase the error is tiny
<azonenberg_work>
whitequark: oh, $BOSS wants me to learn python this coming week
<azonenberg_work>
lol
<azonenberg_work>
I have a project in mind that i think might actually be useful (as well as educational)
<whitequark>
azonenberg_work: my UART has a function that calculates clock error :p
<whitequark>
it used to be in verilog, actually
<whitequark>
oh
<whitequark>
I still have that one
<azonenberg_work>
anyway... I want to make a low level, roughly timing accurate model of FREESAMPLE
<azonenberg_work>
the trigger and acquisition subsystem
<azonenberg_work>
whitequark: start with a raw data capture somebody in ##fpga sent me (5M samples of USB3 @ 12.5 Gsps, as a float[])
<azonenberg_work>
Sinc upsample to 125 Gsps
<whitequark>
azonenberg_work: use numpy
<whitequark>
definitely use numpy
<azonenberg_work>
then iterate through that dataset
<azonenberg_work>
find rising edges, model the propagation delay of the comparator as i do so
<azonenberg_work>
Do a timing-accurate model of my trigger circuit (just an AND gate and four flipflops)
<azonenberg_work>
and delay line
<azonenberg_work>
Then feed into a second comparator to actually latch the signal compared against my DAC'd reference voltage
<SolraBizna>
"It’s somewhat too complicated and inflexible due to my desire to have 50% duty cycle on something that’s marked as “clock” going out of a reusable module." ← lol
<azonenberg_work>
whitequark: then repeat a few million iterations and see what the data looks like
<whitequark>
SolraBizna: mostly linking it to you because of the clock freq deviation functions
<azonenberg_work>
before i build hardware i want to sim it
<whitequark>
SolraBizna: also, are you running simulation?
<SolraBizna>
I am
<SolraBizna>
but my tools are... lacking
<SolraBizna>
in particular, they are very very poorly suited for testing ... signals
<whitequark>
huh?
<azonenberg_work>
whitequark: anyway, in theory if i evaluate this circuit on my signal with a few thousand points at each (time offset within UI, voltage) tuple
<whitequark>
so does your UART work in sim?
<azonenberg_work>
then normalize the resulting array so that each element is a real number in [0,1] indicating the percentage of the time the signal at time T was > V volts
<azonenberg_work>
I should have a 2D array which is the partial integral of an eye pattern with respect to dV
<azonenberg_work>
then if i take the partial derivative in the Y axis, i should get the actual eye
<whitequark>
yep
<SolraBizna>
It's hard to tell; the closest thing to an oscilloscope I have is `$monitor("%t tx=%d", $time, tx)`
<whitequark>
why can't you use gtkwave?
<whitequark>
plus iverilog
<SolraBizna>
I probably could, if I knew what I was doing :P
<SolraBizna>
It's one of those cases where it surely would have saved me a lot of grief, but I never sat down and thought "time to actually learn how to use gtkwave"
<whitequark>
you should do that now
<whitequark>
or you'll have even more pain later
<SolraBizna>
that's almost certainly true
<whitequark>
no, it is definitely true :p
<tnt>
+1. Trying to write verilog (or vhdl) without sim tools is a bad idea. Especially if you're trying to write a whole risc-v core ...
<GuzTech>
tnt: Which is why I'm writing my risc-v core in Clash so I can easily evaluate parts of my implementation without even starting QuestaSim, ModelSim, etc.
<GuzTech>
And that already helps significantly.
<tnt>
SolraBizna: If you're already using monitor, just stick a $dumpfile("blah_tb.vcd"); $dumpvars(0,blah_tb); in a initial block and then, done, you can just load the vcd in gtkwave.
<GuzTech>
SolraBizna: Simulation is essential. If it doesn't work in simulation, it will definitely not work in hardware. If it does work in simulation, it *could* work on hardware.
<tnt>
I sure hope that contest will yield a <= 500 LCs risc-v core ...
<whitequark>
GuzTech: same but migen...
<GuzTech>
tnt: picorv32 is already very small, but yeah, it will be interesting to see what people come up with.
<tnt>
GuzTech: really ? I thought picorv32 had trouble fitting on a up5k at all.
<daveshah>
no, in its smallest config picosoc is less than half a up5k
<GuzTech>
whitequark: I used SpinalHDL before, and it quite liked it, but after getting used to runtime evaluation... it's pretty difficult to use anything else.
<tnt>
daveshah: ok, good to know. Any idea of fmax ?
<GuzTech>
tnt: On the 7-series Xilinx FPGAs, the smallest configuration uses like ~800 LUTs.
<tnt>
GuzTech: yeah, I'm talking ice40 here.
<daveshah>
tnt: probably around 15-20MHz with nextpnr
<SolraBizna>
one version of my core actually worked on real hardware but hanged iverilog
<GuzTech>
It easily fits on the HX8K with a bunch of peripherals. But I don't know *which* configuration of picorv32 is used by default by picosoc.
<SolraBizna>
(it was getting stuck evaluating a combinatorial loop that was semantically straightforward but in a way it couldn't detect)
<GuzTech>
Why do you have a combinatorial loop in your code?
<whitequark>
do not use combinatorial loops
<whitequark>
FPGA LUTs are not glitchless
<whitequark>
they do not have a guaranteed behavior
<SolraBizna>
the loop was a logic error on my part
<SolraBizna>
or rather, it arose from unintended inferred latches
<SolraBizna>
it was supposed to be a straightforward "A depends on B depends on C", but something about the latches made it seem (to iverilog) that C also depended on A, and it sat there grinding on logic that wasn't actually changing
<SolraBizna>
that core was a silly idea anyway; it was just me trying to explore the consequences of trying to cram too much logic into not enough clock
<SolraBizna>
(the consequences were, unsurprisingly: the logic became hard to understand and had a crummy Fmax)
<tnt>
Is all that's needed to set the .extra_bit ?
<daveshah>
yes
<daveshah>
and make sure you don't also place a global buffer that conflicts with it
<tnt>
How does nextpnr know which global buffer that pll output is connected to ?
<daveshah>
I am not sure if this is in the database yet, actually
<daveshah>
it is the same global buffer as the `padin` at that location
<tnt>
I'm looking at http://www.clifford.at/icestorm/io_tile.html ATM. So if I understand correctly, setting that extra bit, if the PLL is active/configured, this will route the pll output to the global buffer. And if the PLL is not there/active, then this will be like a SB_GB_IO ?
<daveshah>
yes, exactly
<daveshah>
the PLL is effectively between the IO pad and the IO input to the FPGA
<daveshah>
this is also why you can't use those IOs as inputs at all when the PLL is used
<tnt>
Right. I wish there was a map of those fpga with all tiles marked with location and what's in there :p (I know that's what chipdb is, but not vere visual).
<tnt>
Speaking of which, maybe I'm too dumb to see it ... but is there a way to pan left/right/up/down in next pnr gui ???
<daveshah>
right or middle click
<tnt>
Oh, ok. Right that's why I missed it. Doing that with a touch-to-clock trackpad is tricky.
rohitksingh has joined ##openfpga
cr1901_modern1 has joined ##openfpga
rohitksingh has quit [Remote host closed the connection]
cr1901_modern has quit [Ping timeout: 272 seconds]
rohitksingh has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 250 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined ##openfpga
Guest3080 is now known as wilhelmvonweiner
wilhelmvonweiner is now known as WilhelmVonWeiner
<tnt>
daveshah: what do you think the best approach is to avoid global net conflict ? Would creating SB_GB locked to the right site with some attribue marking them as 'used by pll' be a good approach ?
rohitksingh has quit [Ping timeout: 272 seconds]
genii has joined ##openfpga
Miyu has joined ##openfpga
<daveshah>
tnt: yes, that seems reasonable
<daveshah>
You could also use that attribute to set the extra bit
<daveshah>
That should then scale nicely to SB_GB_IOs too
<tnt>
daveshah: small details, promote_globals() is done before pack_special() [which is where I'd have created the SB_GB].
<daveshah>
tnt: I can't see any problems in changing that, if it would make things easier
<daveshah>
promote_globals does need to know how many globals are available
rohitksingh has joined ##openfpga
rohitksingh has quit [Ping timeout: 252 seconds]
rohitksingh has joined ##openfpga
jevinskie has joined ##openfpga
jevinsk__ has joined ##openfpga
jevinski_ has quit [Ping timeout: 250 seconds]
jevinskie has quit [Ping timeout: 264 seconds]
jevinskie has joined ##openfpga
jevinsk__ has quit [Ping timeout: 260 seconds]
<tnt>
Apparently by changing the output routing, I manage to make the PLL not lock. Awesome ... :p How did I even manage that.
<whitequark>
tnt: what board?
<tnt>
icebreaker
<tnt>
yeah, it's not an upduino if that's what you were thinking :)
<tnt>
I'm sure it's something in my bistream that must screw it up somehow. I guess I don't quite understand how it all fits together.
<GuzTech>
I've just had a bunch of students that found it a bit weird that I brought 10 different FPGA boards that I own to uni to show to prospective master students...
<GuzTech>
I'm not weird, you're weird!
<GuzTech>
:P
<tnt>
huh why would that be weird ?
<tnt>
ok, maybe because you _only_ brought 10 ?
<GuzTech>
Yeah ok, but I couldn't fit every board I own into my bag...
<GuzTech>
Most of them don't even *know* what an FPGA is :P
<tnt>
Ah yeah :). Speaking of which, I got my ECP5 5G board (the 100$ one) Damn, the packaging for that boardis huge :p box inside box inside box with little card inside.
<GuzTech>
Instead of collecting stamps, I collect FPGA devboards.
<GuzTech>
Cool!
<GuzTech>
I want to try the ECP5 series too one day.
<tnt>
And I also got all the parts for the glasgow :D Now just waiting for the PCB.
<GuzTech>
whitequark said that work is being done on rev. C (?)
<GuzTech>
If it's ready and I can buy it somewhere, then I'll get it for sure.
<GuzTech>
I'm not the best at assembling stuff (mainly because I don't do it too often).
<tnt>
Yeah, I'm assembling a rev B. rev C is not complete, has a lot of changes and also will use BGA, so not so trivial to make it myself.
<tnt>
I'll definitely buy a rev C once they're available, but I've been fed up trying to use bus pirate / bus XXXx and being disappointed every time and so I could use a homemade rev B in the mean time.
<GuzTech>
Have fun assembling it :)
television has quit [Ping timeout: 250 seconds]
rohitksingh has quit [Ping timeout: 240 seconds]
television has joined ##openfpga
television has quit [Changing host]
television has joined ##openfpga
<G33KatWork>
-win 15
<G33KatWork>
grrrr
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 264 seconds]
<rvense>
have any of you used that ice40 board that plugs into a beagleboard?
<tnt>
Mmm, I think my issue is that nextpnr thinks the IO tile is not used because none of the pllout_{a,b} is wired anymore and so it disables stuff ...
<tnt>
rvense: do you have a link ? (I haven't but interested in having a quick look)
<shapr>
I'm teaching a Monday lunchtime class at work using the BeagleWire
m4ssi has quit [Remote host closed the connection]
Patater_ has quit [Quit: Explodes into a thousand pieces]
<whitequark>
tnt: sweet :D
<tnt>
daveshah: is by anychance the numbering of global network different in nextpnr than in the official lattice doc ?
<daveshah>
tnt: eh, the usual trap
<daveshah>
The SB_GB and SB_GB_IO in a tile drive a different global
<daveshah>
Despite being in the same tile
<tnt>
whitequark: hehe, well thank you for making it :)
<daveshah>
I think the Lattice docs only show the SB_GB_IO global numbers
Patater_ has joined ##openfpga
<tnt>
daveshah: oh ... so in fact the "fake" SB_GB I need to make is not the one right next to the PLL but the one that actually drives the global net that correspond to that PLL.
<daveshah>
tnt: yup
<tnt>
daveshah: so you can actually have the SB_GB that's next to the PLL used by a completely different signal then ? even when the pll is output to global ?
cr1901_modern has quit [Read error: Connection reset by peer]
<daveshah>
tnt: yes
cr1901_modern has joined ##openfpga
<tnt>
daveshah: \o/ My LED blinks :)
<qu1j0t3>
tnt: o/
<qu1j0t3>
o _ o _ o _ o
<tnt>
7h to make a led blink. Productive day :p
<daveshah>
tnt: awesome
<tnt>
Still need to figure out how to extract all that information from the DB though. ATM I just hardcoded it all ... hum ...
<rvense>
shapr: it's nearly perfect for a silly project i have.. have you used the ram on it?
GuzTech has quit [Quit: Leaving]
<shapr>
rvense: nope, not yet. I'm teaching myself fpga/verilog in the process of teaching this class
<tnt>
Mmm, chipdb.py doesn't seem to process .gbufin or .gbufpin at all. How does nextpnr even know which SB_GB correspond to which global net ?!?
<daveshah>
I think it is done in chipdb.py when the SB_GB Bels are added
<daveshah>
Effectively hardcoded in chipdb.py
<tnt>
Oh yeah, you're right. I see that now.
wbraun has joined ##openfpga
<tnt>
Mm, yeah, I think that nextpnr's db just doesn't have the required info in it.
WilhelmVonWeiner has quit [Quit: Lost terminal]
WilhelmVonWeiner has joined ##openfpga
WilhelmVonWeiner has quit [Client Quit]
<shapr>
rvense: I know I can write C code to tell the beaglebone's gpmc to move data between main memory and the BeagleWire ram, but I don't know how!
<daveshah>
tnt: I am fine with you hardcoding it
<daveshah>
The set of support devices hardly changes quickly
<rvense>
shapr: i looked for an example but couldn't find it
<tnt>
daveshah: Yeah, I was hoping I could find the 'padin' wires somewhere (which in the chipdb.txt link back to the global network and tile x/y), but they don't seem to be there either.
<tnt>
I'm still a bit curious how this whole bba / db thing even works.
<daveshah>
Basically it's about building up a C structure describing the architecture at build time in a generic yet efficient way
<daveshah>
This avoids the startup time cost of parsing a database file
<daveshah>
Because of some performance issues doing this entirely in Python, we generate a text bba file in Python and "assemble" it to a C string
<SolraBizna>
yeah, I really should have been using gtkwave this whole time
pie_ has joined ##openfpga
<pie_>
hey folky. so i ended up needing to do some simple electronics stuff for work to automate testing some software, i need to hook up this relay and im not sure how to read it off the datasheet https://omronfs.omron.com/en_US/ecb/products/pdf/en-g5v_1.pdf
<pie_>
*folks.
<pie_>
i found the part that shows some sort of internal diagram "bottom view"
<pie_>
at the bottom of page 4
<pie_>
im guessing 2 and 9 are the solenoid (no polarity)
<pie_>
and it switches between (5,6)->1 and (5,6)->10?
<kc8apf>
pie_: that part seems to come in many coil voltages. What voltage is yours rated for?
<pie_>
with (5,6)->1 being the default state?
<pie_>
kc8apf: oh. uhhhhh
<pie_>
i dont know. im pretty sure the only model number on my part (dont have it with me) was g5v-1
<pie_>
it did have some strangely high voltages written on it, like 30, 60, and 125 iirc (at various amperages also listed)? i think that was just for the maximum voltage the circuit it switches should use?
<pie_>
kc8apf: youre looking at the table on the left?
<kc8apf>
pg 1, left table
wbraun has quit [Quit: wbraun]
<kc8apf>
contacts are rated 0.5A@125Vac or 1A@24Vdc
<kc8apf>
coil seems to come in 3, 5, 6, 9, 12, or 24Vdc
<pie_>
i think thats multiple voltages listed for the same model?
<kc8apf>
but that's not part of the model # (!)
<qu1j0t3>
pie_: no
<pie_>
i mean...idk why they would do that but i think that means multiple voltages are ok?
<qu1j0t3>
pie_: it will have a specific coil voltage
<qu1j0t3>
pie_: i just spec'd an omron relay
<pie_>
oh. huh. ok i have no clue then
<kc8apf>
yeah, the coil resistance sets the voltage
<pie_>
wat do
<kc8apf>
look at the case
<kc8apf>
should be written on it
<pie_>
ok. i will check tomorro
<pie_>
assuming thats ok, then what?
<kc8apf>
as for pin-out, yes 2 and 9 are the coil
<kc8apf>
5 and 6 are tied together and are the common
<kc8apf>
1 and 10 are the two throws with 1 being connected when the coil is denergized
<pie_>
im actually wanting to use this as a simulated switch, so i think i would just leave 1 hanging
<pie_>
*floating
<kc8apf>
yup, when the coil is energized, 5/6 will be connected to 10
<pie_>
yay \o/
<pie_>
whats the shaded rectangle on that diagram supposed to be?
<kc8apf>
as for the coil itself, you need to figure out the voltage, make sure whatever you are using to drive it can source enough current, _and_ put in some sort of flyback snubber
<pie_>
oh its right under it "indicate the products directional marks"
<pie_>
kc8apf: oh, good thing i asked then. flyback snubber?
<qu1j0t3>
diode should be ok?
<kc8apf>
when you turn off power to the coil, the magnetic field in the coil causes a voltage spike
<kc8apf>
diode usually fixes it
<pie_>
kc8apf: well /apparently/ im going to be prototyping it from an arduino micro, but i need to scale up to 10 relays later
<kc8apf>
if I'm building a board, I prefer to use purpose-built relay drivers
<qu1j0t3>
kc8apf: made a very important point about the diode
<pie_>
kc8apf: that explains why the last circuit had a diode
<qu1j0t3>
ya
<pie_>
kc8apf: by last i mean there was some stuff on the breadboard but i just started over because i couldnt RE it
<pie_>
thanks, ill keep that around for the scaling up
<kc8apf>
those take care of all the wonky bits. Just feed it a logic-level on/off signal
<pie_>
i also plan to add safety features for stuck-closed and stuck-open, well the latter doesnt really need safety? but i want to signal error condition with a LED or somethng
<pie_>
well none of this is safety critical in any sense in actuality
<pie_>
ok thanks, ill have sometihng to work off of now \o/
<kc8apf>
buy an off-the-shelf SSR for industrial control?
<pie_>
whats an ssr
<qu1j0t3>
pie_: looks like with coil voltage 5V, draws 30mA, which i think is ok for Arduino (40mA? but check Arduino doc)
<kc8apf>
optoisolators are an LED and a photodiode in a single package
<kc8apf>
when you turn on the LED, the photodiode turns on
<pie_>
kc8apf: thats what it seems like, but idk if a photodiode is basically like an optically triggered transistor, and even if it is, i dont really know how transistors work /in practice/
<kc8apf>
that device will pass up to 50mA and up to 80V
<pie_>
(i know how they work on a physical level)
<pie_>
also, thanks
<pie_>
qu1j0t3: what was your breadboarding safety setup again? just a fuse on the power lines?
<qu1j0t3>
i use a fuse, but it's not that useful
<kc8apf>
when the LED is off, a max of 100nA will flow from collector to emitter. When the LED is on, up to 50mA will flow.
<qu1j0t3>
i mean it won't save any semiconductors
<qu1j0t3>
but at least it will not allow a short circuit to do too much harm
<pie_>
kc8apf: im not sure what counts as "shorted"
<pie_>
i mean, "not shorted", for the circuit im automating
<qu1j0t3>
pie_: i have only 12v and 5v and my small bipolar supply (< 20v) on to the breadboard
<pie_>
the button in question is a reset button
<pie_>
but i can just ask one of the guys tomorrow
<kc8apf>
the two wires are probably +5V and an IC's input pin or an input pin pulled high and GND
<kc8apf>
really doubt 100nA would trigger the input
<pie_>
kc8apf: sounds reasonable
<pie_>
also bbiab, just got home, really need a shower
<whitequark>
pie_: transistors are charge controlled devices
<whitequark>
to a first approximation
<whitequark>
all transistors, bjts and fets and all others
azonenberg_work has quit [Ping timeout: 268 seconds]
<pie_>
whitequark: what do you mean by charge controlled
<pie_>
the voltage applied?
<whitequark>
no
<whitequark>
the charge accumulated on the control electrode is what provides the power gain
<whitequark>
like, in FETs, the charge is isolated on the gate
<whitequark>
so it appears voltage-controlled
<whitequark>
in BJTs the charge is drained away via the pn transition, so it appears current-controlled
<whitequark>
but in both cases it's actually charge-controlled and those are separate effects
<pie_>
im kind of embarrassed because either i dont know how they work well enough, or im totally missing what you mean.
* pie_
goes to look at transistor internal diagram and think for a bit
<adamgreig>
i found it helpful to think of the gate as a capacitor
<adamgreig>
when you apply a voltage you charge it up
<whitequark>
yep
<adamgreig>
and the charge on the capacitor sets the e-field strength which is what sets the channel size
<whitequark>
that's how most FET models actually work, too
<pie_>
adamgreig: well yeah, pretty sure i got that for FETs :I
<pie_>
iirc fets seem really simple tbh
<whitequark>
bjts are basically the same as fets
<whitequark>
fundamentally
<pie_>
i think i never thoroughly understood bjts
<qu1j0t3>
i've been studying them for months, not sure i do either yet :)
<qu1j0t3>
pie_: i can recommend some books
<pie_>
though it /was/ kind of a crash course in physics class
<pie_>
whitequark: i havent had time to think yet but im guessing its something like: applying voltage increases the amount of charge carriers in the intermediate area
<pie_>
oh wait i just described all (most?) semiconductor junctions ever
<gruetzkopf>
i like relays so much, i have about 12000 of them.
amclain has joined ##openfpga
<Bob_Dole>
I wanted to buy a bunch of the clear ones once, the ones you can see the state the contacts are in, and try to use that for a bit of hands on learning logic.
cr1901_modern has quit [Ping timeout: 245 seconds]
<pie_>
gruetzkopf: wowo
<pie_>
gruetzkopf: today, on hoarders :P
<pie_>
jk tho, that just makes you a neerd ;p
<gruetzkopf>
yeah
<gruetzkopf>
so?
f003brv has joined ##openfpga
<f003brv>
Hi
<f003brv>
Is #openfpga compatible with Mac?
<f003brv>
OS X?
<f003brv>
also what OS do you folks use for FPGA dev, Linux or Windows?
amclain has quit [Quit: Leaving]
amclain has joined ##openfpga
amclain has quit [Client Quit]
<etrig>
plan9
<whitequark>
f003brv: it should be compatible with macOS, yes
<whitequark>
I use Linux personally
<SolraBizna>
same
<Bob_Dole>
same
cr1901_modern has joined ##openfpga
<f003brv>
cool thanks
<f003brv>
very helpful
<f003brv>
I'll have my Linux set up in a week or two
<f003brv>
I was worried I was going to need Windows as well.
<f003brv>
but I'm glad I can do FPGA work on Linux and Mac too
<f003brv>
goodbye for now
<f003brv>
:wq
<f003brv>
q
<f003brv>
quit
f003brv has quit []
feuerrot has quit [Ping timeout: 264 seconds]
feuerrot has joined ##openfpga
<cr1901_modern>
protip- do not try running ninja -j3 when building nextpnr on Windoze w/ 8GB of RAM. You will crash your system when it inevitably goes to swap building those damn binary blobs