<rqou>
so that cross compiling doesn't require executing code on the target at compile time
<awygle>
cyrozap: pretty cool! doesn't have GTHs tho :(
<rqou>
azonenberg: another possible solution is to do what you suggested last time i brought this up
<rqou>
and just make a #ifdef ALANMI #include <stdint-vc6.h> #endif
<awygle>
i guess it has "PS-GTR" though, whatever that is
<rqou>
O_o wtf look at the date on copyright.txt (in abc)
<rqou>
"10 years ago"
<awygle>
looks like they go to the displayport though
<awygle>
"does compile correctly on solaris"
<rqou>
great
<rqou>
how useful /s
<rqou>
even berkeley has already killed their solaris boxes
pie_ has joined ##openfpga
<rqou>
awygle: no more nova/star/torus/etc. and the thin clients that perpetually confused freshmen :P
<rqou>
it used to be a _right of passage_ to fail to print using lp(1) :P :P :P
<cyrozap>
awygle: Yeah, I was on the fence about getting it, but without much high-speed I/O, I can't really think of a good use for it.
<azonenberg>
awygle: PS-GTR are serdes that are attached to the ARM
<azonenberg>
rather than FPGA fabric
<azonenberg>
You have the ability to configure them as pcie, sata, displayport, etc
<awygle>
azonenberg: you are slower than Google :-P
<azonenberg>
awygle: google doesn't have to shower after a long bike ride
<azonenberg>
If google showers, in fact, the SREs are gonna be running around in circles trying to figure out which of the sprinklers in the datacenter is leaking
<awygle>
azonenberg: do you agree with my assessment of "1.2V into a 3.3V I/O pin"? "probably some leakage, probably not dangerous"?
<azonenberg>
awygle: What's the spec on the part?
<azonenberg>
it may actually be fully within spec
<azonenberg>
depends on Vih
<awygle>
It's outside of Vih/Vil
<awygle>
IIRC
<rqou>
azonenberg: oh, you mean one of my former housemates :P
<rqou>
(he's a google sre)
<rqou>
not close to datacenter ops though
<azonenberg>
awygle: so yeah i'd expect leakage but not harmful
<azonenberg>
but it wont work
<azonenberg>
What's the application?
<awygle>
Breaking out a 0.4mm BGA on osh park rules lol
<azonenberg>
lol
<awygle>
Sacrificing io to get VCC in to the balls
<azonenberg>
lol
<azonenberg>
i mean, if it works
<azonenberg>
but personally i'd just use a different chip
* azonenberg
would love if oshpark had a microvia service
<azonenberg>
even if it was like $25/in^2
<azonenberg>
i'd pay that for some designs\
<rqou>
y no 6 layer service
sgstair has quit [Ping timeout: 240 seconds]
<azonenberg>
rqou: they were working on it a while ago, i think there was a pilot run
sgstair has joined ##openfpga
<azonenberg>
they were trialing flex too
<rqou>
iirc @pdp7 told me demand wasn't that high so it's tricky to do (although i might be misremembering)
<azonenberg>
yeah thats what i figured
<rqou>
hah, flex
<rqou>
@pdp7 told me something "fun" about that
<azonenberg>
oh?
<azonenberg>
i know a while ago they were soliciting test flex designs
<azonenberg>
basically, send us your gerbers and we may or may not make them, and they may or may not survive
<azonenberg>
if we do get working boards they're yours for free
<awygle>
well the chip is the point sometimes lol. And you don't need much io.
<awygle>
I stole this trick shamelessly from tinyfpga
<azonenberg>
awygle: when wolfspraul was doing spartan6 bitstream RE work years ago (or was it artix7?)
<azonenberg>
he did a 1-layer ftg256 breakout
<awygle>
lol
<azonenberg>
home etched too, no soldermask
<awygle>
I assume - yeah, home etch
<azonenberg>
basically minimal power/ground, jtag, and just enough gpios to verify a working bitstream
<awygle>
There's no other reason to do 1 layer
<awygle>
I'd like to do home etch sometime but I need a real home I think
<azonenberg>
Not recommended, IMO
<azonenberg>
like, it's cool to do and all
<rqou>
just live with me, chemistry all the time :P :P :P
<rqou>
(not really, and not as bad as whitequark)
<awygle>
yes, the coolness would be the point
<azonenberg>
but getting tolerances good enough to work with nontrivial designs requires significant work and expenditure
<azonenberg>
multilayer is even harder
<awygle>
rqou: substantially worse than whitequark I suspect :-P
<azonenberg>
And when i do the math... my time is worth say $150/hr
<azonenberg>
doing the pcb myself vs oshpark might save $10
<awygle>
rqou: decap them ice40s brah
<rqou>
soon(tm)
<azonenberg>
and if it takes an hour to do the board
<azonenberg>
It's a net loss of $140
<azonenberg>
The only time the equation works out differently is if i need something RIGHT NOW
<awygle>
It's not that straightforward because you have to wait for osh. But yes.
<azonenberg>
and i consider that a planning failure, because i normally have several projects in the pipeline
<azonenberg>
and i just context switch to hide the latency
<azonenberg>
(can you tell i spent a lot of time doing CUDA dev? :P)
<awygle>
I could see it for "I wonder how long these traces can be before SGMII starts to fail"
<rqou>
azonenberg is a barrel processor
<azonenberg>
awygle: well, no
<rqou>
go do a barrel roll :P
<azonenberg>
because impedance and such matters
<awygle>
Yes yes. RGMII then.
<azonenberg>
i'd need it to be on fr408 with the same soldermask etc
<azonenberg>
Otherwise the data is inconclusive
<azonenberg>
oh and, ground plane
<azonenberg>
etc
<awygle>
You could lower bound it. But I get your point.
<azonenberg>
i just dont even see the experiment as being worth running
<azonenberg>
because the data would be of no value
<rqou>
hmm, is soldermask thickness consistent enough to give you reliable impedances?
* awygle
starts thinking about CPW transmission lines etched at home
<awygle>
Good luck with gap control lol
<azonenberg>
CPW?
<awygle>
Coplanar waveguide
<awygle>
Sans ground plane
<azonenberg>
oh, ok
<azonenberg>
yeah i've just never seen the abbreviation
<rqou>
aren't ground planes require?
<rqou>
*required
<awygle>
Na, that's GCPW
<awygle>
The ground is on the same layer for CPW
<azonenberg>
yeah i've used them in designs
<azonenberg>
i just was used to it being spelled out
<awygle>
(it's also on the same layer for GCPW, just... Also on the bottom lol)
* awygle
really wants to do an RFIC someday
<rqou>
unfortunately i know nothing about rf
<rqou>
even though i managed to get an Extra ham radio license
<awygle>
I continue to wonder if there's a shitty approximation to differential GCPW...
<azonenberg>
awygle: btw, re SGMII range
<awygle>
I should try some sonnet tests someday. SOMEDAY
<awygle>
rqou: meanwhile I only have tech
* azonenberg
recalls april 1st "SONET to sonnet" RFC
<azonenberg>
rqou: probably b/c 1.8V wasnt common at the time
<awygle>
That said, this post is insane.
<rqou>
but 1.5V was?
<azonenberg>
oh
<azonenberg>
idk i only read the timing info in the spec :p
<azonenberg>
awygle: sec
<awygle>
That may be the common mode I guess...? Weird either way...
<rqou>
supposedly older rgmii is supposed to be 2.5V (weird) and newer rgmii is supposed to be 1.5V (also weird)
<azonenberg>
awygle: lol yeah thats common mode
<azonenberg>
anyway, assuming 100 mV for the sake of discussion
<azonenberg>
the minimum channel gain we can tolerate is 0.285 or just over -10 dB
<azonenberg>
From FPGA to PHY, ignoring jitter and eye closure in the horizontal axis
Zorix has joined ##openfpga
<azonenberg>
The buffer appears to have similar specs, worst case 100 mV differential amplitude and typical 350 mV output
<azonenberg>
So pretty much by using the buffer we can tolerate a total of 20 dB channel loss
<azonenberg>
(if appropriately distributed)
<awygle>
Okay. I'll actually run numbers on that tomorrow but that says "buffer in the middle" to me
<awygle>
Tbh it sounds like 12" run wouldn't even be a deal breaker but margin is good.
<azonenberg>
awygle: my goal was to cut as close to the edge as i could on the backplane/phy side
<azonenberg>
since the fpga has much less timing margin
<azonenberg>
the oversampling rx needs a fairly wide (0.625 UI minimum) eye opening
xdeller has quit [Ping timeout: 265 seconds]
<awygle>
feels like jitter will be your bigger problem, but good levels can't hurt
<awygle>
Anyway I have a 730 meeting, more math tomorrow.
<azonenberg>
awygle: well if i do clock recovery then jitter is less of an issue vs if i had a refclk
<azonenberg>
and buffering should help somewhat with jitter since faster edge rates
<azonenberg>
awygle: anyway, the good thing is
<azonenberg>
By putting the buffers on the backplane, as long as i can guarantee the fpga-to-backplane link is reasonably safe
<azonenberg>
I can redo the backplane as needed to get good results :)
<azonenberg>
extreme example: put an artix on the backplane and just use it to retime the lvds :p
<rqou>
btw anybody here want to feasibility-check rgmii on ice40?
<whitequark>
rgmii? you're nuts
<rqou>
why?
<awygle>
250 Mbps is too fast
<whitequark>
125 MHz DDR
<awygle>
do gmii
<whitequark>
even if you worked out the timing issues with the serdes the fabric can't feed it that fast
<rqou>
not even with a 32 or 64 bit wide datapath?
<rqou>
tbh i don't have a good overall "feel" of how fast an ice40 is because "herp derp HDL" combined with not bothering to optimize timing at all doesn't lead to particularly fast designs
<awygle>
that's the absolute max output speed at 2.5v
<awygle>
Of the buffers
<rqou>
what is? 125 MHz?
<azonenberg>
Hmmmm
<rqou>
supposedly just a toggling pattern can get 155 MHz at 1.8v
<rqou>
yeah, seems to be cutting it too close to work
<azonenberg>
that would actually be a fun challenge, once we get support for larger xc2c
<azonenberg>
see if we can do a super basic ethernet mac
<azonenberg>
:p
<rqou>
wtf azonenberg
<rqou>
xc2c is pretty slow
<azonenberg>
um, what?
<azonenberg>
slow?
<azonenberg>
it's very fast compared to other low end PLDs like greenpak
<azonenberg>
i mean sure compared to the xcvu9p on my desk here it's slow...
<azonenberg>
But i've always seen their main deficiency as being gate capacity
<azonenberg>
Not speed
<rqou>
fine, pin-to-pin delays are fast, but internal delays are slow
<rqou>
which is expected given a sum-of-products architecture
<azonenberg>
You'd have to heavily pipeline it
<azonenberg>
xc2c32a -4 is ~4 ns through the OR array or 3.8 through the AND array fast path
<azonenberg>
GMII is only 125 MHz (RGMII might be pushing it but i can't rule out)
<rqou>
ok, i guess the 32a is pretty fast
<rqou>
the larger parts like the 512 are slow as shit
<azonenberg>
well duh
<azonenberg>
but the 256 even is fairly fast
<rqou>
wait, don't forget
<rqou>
xc2 has internal DDR flops
<azonenberg>
6 ns through the or array
<azonenberg>
Yes, i know
<azonenberg>
So RGMII might be plausible
<azonenberg>
the fun part would be a packet generator plus CRC engine
<azonenberg>
2c128 is... not beyond the realm of possibiliy
<rqou>
does the xc2 even have enough state bits for that?
<rqou>
don't you already need 32 state bits just for the crc?
<azonenberg>
2c128 has 128 ffs
<azonenberg>
To send a fixed size ethernet frame from a hard coded MAC -> broadcast MAC
<azonenberg>
with PRBS-7 as content (say)
<azonenberg>
you need a couple of smallish counters, then a PRBS-7 generator and a CRC-32 generator
<azonenberg>
i'd have to throw it together
<azonenberg>
but i'd ballpack a 2c128 - 256
<rqou>
that might actually fit
<azonenberg>
Keep in mind you're talking to the guy who brought up a 10baseT link in a greenpak
<rqou>
yeah wtf
<azonenberg>
and if i had two, i think i could actually do the 4b5b and make a working PHY
<azonenberg>
(this was just autonegotiation)
<rqou>
also, greenpak really really needs more state bits
<azonenberg>
it miiiight fit in one but that would be dicey
<azonenberg>
rqou: thats a planned future toolchain optimization actually
<azonenberg>
REALLY aggressive area optimization
<azonenberg>
Doing derpy things like using counters with a value of one as a DFF
<azonenberg>
i will find every ff in the hard ip and figure out a way to use it as a general purpose logic if at all possible :p
<azonenberg>
seriously, i think a 10baset phy in greenpak is not beyond the realm of possibility, but the crc32 needed for a mac would be all but impossible
<azonenberg>
... unless
<whitequark>
actually
<azonenberg>
i think i could do it, but not at the required speed
<whitequark>
i think you can use the shift registers
<azonenberg>
Yes exactly
<azonenberg>
but you'd be bitslicing
<whitequark>
overclock it
<azonenberg>
you'd need to do 8 cycles of the shreg at 10 MHz
<azonenberg>
borderline
<azonenberg>
But plausible
<whitequark>
yep
<whitequark>
maybe with the right voltage and binning
<azonenberg>
you'd need 2-3 greenpaks for all the logic i think
<sorear>
if you're generating fixed packets, can't you generate a fixed crc?
<azonenberg>
sorear: the goal was to be doing a PRBS
<azonenberg>
rather than hard coded
<whitequark>
sorear: that might be more complex actually
<whitequark>
Parallelogram is a demo running on the Commodore One extender board, which contains an Altera Cyclone III FPGA and an SDRAM chip. The logic design was made from scratch, including a homebrew CPU, FM synth and blitter with pixel shader support. The demo won the wild compo at Revision 2012.
<rqou>
hmm, that looks like a "pretty normal" "pack stuff in an fpga" design and not an insane gate-constrained design
<whitequark>
yeah it does now
<whitequark>
the previous time I was reading it I had much less FPGA experience
<whitequark>
it looked more impressive
<azonenberg>
lol
thallia has quit [Ping timeout: 260 seconds]
<rqou>
hmm, ice40 does _not_ have local clock inverts on each FF
<rqou>
i think that probably makes rgmii unachievable
_whitelogger has joined ##openfpga
<rqou>
hmm, i thought i did, but apparently the IO cells have two FFs just to handle DDR inputs
<rqou>
although it might/probably will still be impossible to meet timing
<whitequark>
you don't even have tools to meet timing
<whitequark>
with the open-source toolchain
<rqou>
you can't LOC individual logic blocks?
<whitequark>
well if you're that masochistic
<azonenberg>
lol
<rqou>
shouldn't you only have to do that until you've managed to widen the data into something manageable?
flaviusb has quit [Ping timeout: 255 seconds]
thallia has joined ##openfpga
<rqou>
azonenberg: is there anything in ethernet/rgmii that would require you to respond in a set amount of time?
<rqou>
i think no as long as you ignore half-duplex?
<azonenberg>
No, they're source synchronous buses
<azonenberg>
fire and forget
<azonenberg>
this is how i plan to cheat sending packets on agreenpak with something that totally doesnt have the horsepower to process incoming traffic
<rqou>
what about collisions? :P
<rqou>
half duplex forever! :P :P :P
<azonenberg>
eeew
<rqou>
but yeah, do you have to do anything special in that case?
flaviusb has joined ##openfpga
<azonenberg>
i think just look for incoming traffic
<azonenberg>
you dont have to DO anything for it
<azonenberg>
just abort when you see it
<rqou>
but how quickly do you have to abort?
<azonenberg>
Don't remember
<azonenberg>
i've never implemented half duplex :p
<rqou>
half duplex is going to haunt engineers for years to come, isn't it :P
<rqou>
i know many people at BRCM also hated it because you have to do completely different stuff
<azonenberg>
see, thats the advantage of not making commercial stuff
<azonenberg>
I can deprecate whatever the hell i want
<azonenberg>
as long as i personally dont need it
<azonenberg>
I still have some 100baseT stuff for example
<azonenberg>
But i have no need for 10M
<azonenberg>
i will likely support it in my new switch just because it's pretty much free
<azonenberg>
But i do not plan to support half duplex
<rqou>
no test equipment with 10m?
<azonenberg>
pretty sure everything is 100
<azonenberg>
i have one devkit with 100 too
<azonenberg>
everything else is gig
<azonenberg>
well ok, unless you count the 10/40/100G stuff
<azonenberg>
but you know what i meant :p
<rqou>
nothing like BRCM's customers: "i've got a factory floor of a bajillion 10half devices and i want to turn them into a single 1g/10g trunk"
<azonenberg>
yeah
<rqou>
which is apparently one of the big reasons why 10half is still supported
<azonenberg>
i'm more like, i've got a lab of a few 100/full devices a couple dozen gig/full devices
<azonenberg>
and i want a single 10G uplink
<rqou>
also, apparently customers like the "enterprise" switches rather than the dumb switches for this use case because *) tons of ports *) good management features
<azonenberg>
Yes, this is why i am building my own switch to be more along those lines
<azonenberg>
The edge layer switch will be 24 tri-speed copper + 4x 10G optic
<rqou>
hmm, looking at it on paper i _think_ rgmii on ice40 is theoretically possible
<rqou>
you have to have an exact pinout and hand-place a bunch of FFs
<azonenberg>
So far i'm at $600 in BOM for silicon and LAN connectors; i still have to add passives, SMPSes, boot flash, and connectors between the pcbs
X-Scale has quit [Read error: Connection reset by peer]
<rqou>
i think you can do it if you feed the rxclock into one pair of IOs and put the 4 data lines into the IO pairs directly above/below
<rqou>
using the DDR mode you're now at 125 mhz x 8 bits
<rqou>
and then immediately to the right you can place another set of FFs to reduce it to 62.5 mhz x 16
<rqou>
but i have to check whether there are enough local tracks to do that
<rqou>
hmm yeah, there are
<rqou>
you'll probably have to manually PAR this part
X-Scale has joined ##openfpga
<rqou>
hmm, maybe not
<rqou>
clock and clock enable are shared through the entire logic block
bitd has joined ##openfpga
thallia has quit [Ping timeout: 264 seconds]
thallia has joined ##openfpga
thallia has quit [Ping timeout: 264 seconds]
thallia has joined ##openfpga
<rqou>
azonenberg: why do you use BSD licenses for your kicad libs?
<rqou>
shouldn't a CC-type license be more suitable?
<rqou>
oh wtf
<rqou>
CC-BY has a "no additional restrictions" clause?
<rqou>
i don't want that
<rqou>
i guess BSD it is
<rqou>
even though that's also not particularly effective on schematics
<rqou>
huh, not even all of my own kicad libs are all a consistent style
pie_ has joined ##openfpga
<rqou>
azonenberg: i know you don't have any free time, but if you ever get a moment i would really really appreciate a quick review of https://github.com/rqou/rqou-kicad-libs
<gruetzkopf>
i thought that i already mentioned my cursed 10G adapter in here
<gruetzkopf>
suddently it's up on twitter again
eduardo_ has joined ##openfpga
eduardo__ has quit [Ping timeout: 256 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
Bicyclidine has joined ##openfpga
Bike has joined ##openfpga
ondrej2 has quit [Read error: Connection reset by peer]
ondrej2 has joined ##openfpga
rohitksingh has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
renze has quit [Client Quit]
renze has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 264 seconds]
<mithro>
Morning everyone!
renze has quit [Read error: Connection reset by peer]
renze has joined ##openfpga
<awygle>
Morning mithro
user10032 has joined ##openfpga
azonenberg_work has joined ##openfpga
wpwrak has quit [Read error: Connection reset by peer]
azonenberg_work has quit [Ping timeout: 268 seconds]
<cyrozap>
rqou: No CC0?
<cyrozap>
That's what I use for my KiCad libs.
wpwrak has joined ##openfpga
<rqou>
cyrozap: i still want people to give me credit
<rqou>
also, at the risk of starting a flamewar, imho all the current "open hardware" licenses suck
pie_ has joined ##openfpga
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
<awygle>
rqou: not necessarily disagreeing, but why?
<rqou>
most of them are in the "copyleft" space, and somehow it feels like there's a lack of permissive licences
azonenberg_work has joined ##openfpga
<awygle>
Isn't solderpad supposed to be that?
<Ultrasauce>
I feel like footprints are skirting the edge of what's copyrightable in any case
renze has quit [Quit: Spaceserver reboot?!]
renze has joined ##openfpga
renze has quit [Read error: Connection reset by peer]
renze has joined ##openfpga
<awygle>
If footprints were done in the way they should be, as a standard data file + a script to produce the footprint according to your design rules, then the script would be copyrightable but not the data file. As it is, I think footprints are copyrighted. They're "interpretations" of facts.
<rqou>
awygle: TIL about solderpad
<rqou>
that's actually pretty close to what I want
<awygle>
Lol
<awygle>
Happy to help you continue to make licensing decisions I don't agree with or understand :-P
<rqou>
i want people to use my stuff, why is that hard to understand?
<cyrozap>
rqou: I use CC0 because at least for me it'd be a huge hassle to include not just the BSD license text, but a copyright/attribution line for every single footprint I use. Like, where is that going to fit on the board artwork? Or in the schematic? A symbol/footprint combo takes a few hours of work *at most*--who cares if I'm going to get credited or not? And am I really going to threaten to sue someone
<cyrozap>
for using an 80-ball BGA footprint without attribution, which was mostly auto-generated from information extracted from a datasheet anyways?
renze has joined ##openfpga
renze has quit [Read error: Connection reset by peer]
<cyrozap>
Like, these aren't "Artisinal, Hand-crafted Footprints and Symbols" made by some ECAD hipsters--they're functional elements that no one in the industry cares about properly attributing.
<sorear>
given that *street maps* are of limited copyrightability in the USA
<rqou>
cyrozap: afaik you don't actually have to put attribution on the board artwork itself
<rqou>
copyright doesn't apply to physical things
<rqou>
it only applies to the design files
<cyrozap>
If anything, you should be using a font license, since fonts are the closest things to symbol libraries in terms of how they're actually used. e.g., Microsoft can't claim copyright over your Word documents just because you decided to use the "Trebuchet MS" font.
<rqou>
um, afaik no
<rqou>
fonts have special status in countries other than the US
<rqou>
I don't know if it's really analogous to PCBs
renze has quit [Ping timeout: 240 seconds]
renze has joined ##openfpga
renze has quit [Client Quit]
renze has joined ##openfpga
ZipCPU|Alt has joined ##openfpga
ZipCPU has joined ##openfpga
ZipCPU|Alt has quit [Client Quit]
ZipCPU|Alt has joined ##openfpga
ZipCPU|Alt has quit [Remote host closed the connection]
bitd has quit [Quit: Leaving]
digshadow has quit [Ping timeout: 256 seconds]
GenTooMan has joined ##openfpga
<pie_>
qu1j0t3, im an idiot lol i keep shorting batteries on the breadboard
<qu1j0t3>
pie_: hm
<pie_>
i keep plugging both terminals inthe same row
<qu1j0t3>
yeah, it's a risk. i use a supply and fuse
<qu1j0t3>
cuz i kind of fully expect i'll F up
<pie_>
static type system pls
<qu1j0t3>
hahahahahahhahah
<Ultrasauce>
you can have that, just solder a battery connector to the power rails
<Ultrasauce>
(or two specific rows or whatever)
<Ultrasauce>
instead of using jumper duck typing for everything
digshadow has joined ##openfpga
<qu1j0t3>
Ultrasauce: very good idea, but you don't need to solder
<qu1j0t3>
Ultrasauce: i use header pins a lot to adapt things to breadboard
<qu1j0t3>
but even if pie_ uses the power rails, they might well cause a short elsewhere
Bike has quit [Ping timeout: 260 seconds]
<Ultrasauce>
just use a nice high current source so the short will go away quickly
<qu1j0t3>
hahahahahaha
<qu1j0t3>
and a volatile atmosphere so you find out about it
user10032 has quit [Quit: Leaving]
<pie_>
xF
<pie_>
* xD
<pie_>
gonna need to implement some safeties before i start using a computer psu instead of some 5v usb thingy :P
<qu1j0t3>
pie_: some people sniff at fuses but i've blown it more than once, once by doing exactly what you did
<qu1j0t3>
pie_: when tired
<qu1j0t3>
pie_: and yeah i'm using a benched PC supply
Bicyclidine is now known as Bike
<pie_>
i want to try witing up my chinesium sourced pwm led controller but im in no mood to set up an mcu dev environment :|
<pie_>
*wiring
<pie_>
tlc5940
<pie_>
wow this thing is actually pretty complicated
mumptai has quit [Remote host closed the connection]
m_w has joined ##openfpga
<awygle>
i was known as "sparky" at my last job for shorting 2 batteries in 2 days
<awygle>
not little crappy ones either
<awygle>
(of course, i said the setup was unsafe and needed to be reworked, but that didn't make it into the mythos, nor did the way my boss overrode me)
<awygle>
on the gripping hand like eleven other people successfully executed the operation _without_ shorting the battery, some many times
pie__ has joined ##openfpga
pie_ has quit [Ping timeout: 260 seconds]
<rqou>
awygle: i hope you weren't changing cps2 batteries or anything like that or shorting the batteries would lead to much sadness :P
<awygle>
rqou: they were 3s lipos, I don't remember the capacity but big RC batteries