<cr1901_modern>
egg|zzz|egg: Do you really have alerts set for when the word "egg" pops up? ._.
genii has quit [Remote host closed the connection]
<egg|zzz|egg>
cr1901_modern: yes
<egg|zzz|egg>
cr1901_modern: I ping on egg,float*,double,754,binary32,binary64,Kahan,round*,integrat*,numeric*,RK*,Runge*,oblate,oblateness,n-body,lagrange,principia,prolate,*zygote,๐ญ,๐,่,๐ จก
<cr1901_modern>
sounds fun...
<egg|zzz|egg>
integrat* is the one that misfires the most, double is surprisingly silent
<egg|zzz|egg>
cr1901_modern: as for egg, that's my usual nick on esper so I'd ping on that without a custom rule anyway
<egg|zzz|egg>
and it's actually useful, since people call me egg
azonenberg_work has quit [Ping timeout: 252 seconds]
azonenberg_work has joined ##openfpga
Miyu has quit [Ping timeout: 244 seconds]
unixb0y has quit [Ping timeout: 260 seconds]
unixb0y has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
<whitequark>
mithro: it's not bad but i'm concerned about the footprint
<mithro>
whitequark: I'd be mainly interested in using the UF2 with the FX2 to "flash" FPGAs by dropping files onto the mass storage device....
<whitequark>
yeah sure
<whitequark>
I've n ever implemented a mass storage device though and I'm not sure how much that and the builtin FAT image or image generation code would take
<mithro>
> @Mithro the 8kb size is as small as it gets, there's an 16u2 version but its for UNO - like not for the 16u2
cr1901_modern has joined ##openfpga
<whitequark>
8 kb size?
<whitequark>
where's that from?
<mithro>
whitequark: From a random response to my question "Any idea how "small" people have make UF2 bootloaders? It seems like there is an Atmel ATmega16u2 bootloader?"
<whitequark>
8 kb is a *ton*
<whitequark>
but that probably includes atusb?
<whitequark>
wait, what's the u?
<mithro>
Dunno... It seems to include LUFA?
<whitequark>
aha, usb device
<whitequark>
nooot sure, i *think* i could get it under 8kb but i'm not sure at all
<whitequark>
for fx2
<sorear>
how badly does it break OSes to have mass storage devices that don't actually store blocks
<mithro>
I seem to recall a demo for the fx2 doing a mass storage device, but I assume that didn't have to do any of the FAT side of things - just forwarding the blocks to the storage attached to the FIFO/GPIF interface?
cr1901_modern has quit [Quit: Leaving.]
<whitequark>
sorear: it doesn't
<whitequark>
this is a common trick
<whitequark>
mithro: yes
<whitequark>
FAT isn't super hard if you don't store the actual image but generate it on the fly
<sorear>
do you just assume the host will keep everything in page cache until the device is unplugged?
<whitequark>
as in, isn't necessary to put it into the firmware and it makes building the bootloader somewhat easier
<whitequark>
sorear: no
<whitequark>
windows uses write-through cache on usb drives
<whitequark>
well, by default, there's an option
<whitequark>
which no one enables because it loses data
<whitequark>
you don't actually need to "safely eject" anything assuming the writes are all done
<whitequark>
i think linux distros finally gave up on cache on usb drives and do the same thing nowadays but i'm not super sure
<whitequark>
if you just mount it you need to umount it
<sorear>
write-through, yes, but I mean you don't need to implement read back of just written FAT/directory pages because the host's cache will serve all reads of written data?
<whitequark>
no
<whitequark>
but it wouldn't read the firmware you're copying to a drive
cr1901_modern has joined ##openfpga
<whitequark>
and if it did, well, it reads zeroes, whatever?
<TD-Linux>
it would break badly if you write enough that the FAT grows and then part of it gets dropped out of ram
<TD-Linux>
but I don't think that's a concern with this metho
<sorear>
> You may ask why is it even safe to ignore the special file writes - wonโt the OS get confused if it cannot find what it wrote? Here, we rely on the fact that the amounts of data written are minuscule by modern standards, and the OS will generally cache this data. If it needs to read the data back, it will use the cache and not the drive.
<sorear>
> I wonder if anyone ever read the entire 1000-page brick that is the USB spec.
<sorear>
reading the blog post by the UF2 designers
<TD-Linux>
this all seems too simple. make a usb bootloader that appears as a printer and distribute firmware as pdf files
<sorear>
that, but speakers
<Ultrasauce>
usb bootloader that is a keyboard; it opens a browser, downloads & executes a program that uploads the new firmware encoded in caps lock toggles
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
<rqou>
whitequark: linux still caches
<rqou>
and if you do implement this, please do it correctly
<rqou>
don't be NXP
<rqou>
don't rely on the fact that windows is *) write-through *) in sequence
<rqou>
or i will be really unhappy that i need mtools to flash on linux
<rqou>
in terms of space budget, NXP has 16 kB, and this also includes some other USB gadget drivers for some other device classes
<whitequark>
rqou: you'll be amused
<whitequark>
because uf2 is made by windows people but it specifically avoids those two issues
<rqou>
ah, it's "that" hack
<rqou>
i guess it works
<rqou>
i'd rather we implemented this without hacks though
<rqou>
but uf2 won't be any more cursed than my yet-to-be-tested flashing-over-fido-u2f idea
<whitequark>
they have that too
<whitequark>
protocol over hid
<whitequark>
which is sort of what u2f already is?
<whitequark>
wait
<whitequark>
"uf2"
<whitequark>
"u2f"
<whitequark>
illuminati confirmed
<rqou>
just HID isn't good enough
<rqou>
even though fido u2f is layered over HID
<rqou>
but yeah, imho uf2 is "meh"
<rqou>
fairly typical hack
<whitequark>
meh?
<whitequark>
oh
<whitequark>
it's not super exciting
<whitequark>
but i think that boring infra improvements are really important too
<rqou>
i'd rather they made it such that you just have a raw file without any funny headers
<rqou>
e.g. the NXP way but without the bugs
<whitequark>
oh?
<whitequark>
unless i commit to 2x the flash size i can only do it if the OS writes metadata before data
<whitequark>
which is not guaranteed obviously
<rqou>
wait why?
<rqou>
oh, i'm hoping/assuming that the OS won't reallocate clusters if you overwrite an existing file
<rqou>
maybe this is a bad assumption
<rqou>
alternately i'm assuming that the device has enough RAM to store at least the relevant parts of the FAT when the OS tries to write it
<rqou>
oh wait
<rqou>
i see the actual problem now
<rqou>
so it's back to "i'm hoping/assuming that the OS won't reallocate clusters if you overwrite an existing file"
<rqou>
it'll be no more buggy than NXP's
<rqou>
although i guess uf2 is much more guaranteed to work
<rqou>
i still want to try/someone to try my proposed "data smuggling over fido u2f" idea though
emeb has quit [Quit: Leaving.]
<whitequark>
how do you even do it securely
<rqou>
don't care :P
rohitksingh_work has joined ##openfpga
<whitequark>
uh
<whitequark>
so another rqou solution
<rqou>
i mean, you can add security back in
<rqou>
have a "are you sure you want to update firmware?" button on the device? :P
<rqou>
or have a special mode?
<rqou>
i just wanted a proof of concept?
<rqou>
why do you always make fun of my solutions?
<whitequark>
because i spent literally most of my life fighting with shitty 80% implementations that scratch someone's itch and then grow all over tech like a sort of a cancer and then you can't possibly avoid them and then someone uses the absolutely rotten foundation to build something multiplicatively even worse on top to scratch their own itch
<whitequark>
and what you're doing is,
<TD-Linux>
also you will make the mozilla security folks very angry and sad :)
<whitequark>
is you're making those implementations but you're doing it ON PURPOSE
<whitequark>
like Unix was probably fucking unavoidable, it's a tragedy like oil spills in 1800s were a tragedy
<rqou>
TD-Linux: i don't care; i've already given up on the browser security people
<whitequark>
but your solutions are like Deepwater Horizon oil spill.
<whitequark>
the last thing you said in this channel is "I don't care that I directly make the problem worse"
<TD-Linux>
rqou, having a flashable device exposed to the web is literally giving every web page root
<rqou>
well, don't plug one of these things into your computer then?
<TD-Linux>
I won't :)
<rqou>
it's not anything that wasn't possible before
<rqou>
i'm just carefully putting together just the right pieces
<rqou>
i like to describe it as "the browser security people infoseced themselves too hard"
<rqou>
by simultaneously making the actually good apis (e.g. webusb) really annoying to use
<rqou>
but by also pushing 2fa and by extension fido u2f
<whitequark>
i... i find this conversation so incredibly aggravating for reasons that i have stated above that i'm just going to /part
whitequark has left ##openfpga [##openfpga]
TAL has quit [Ping timeout: 252 seconds]
gruetzkopf has quit [Quit: quit]
azonenberg_work has joined ##openfpga
TAL has joined ##openfpga
Bike has quit [Quit: Lost terminal]
jcreus has joined ##openfpga
<rqou>
o/ jcreus
<rqou>
nice hostname
<jcreus>
huh it's been a while since I was on IRC and had to re-register my nick
<jcreus>
lemme whois myself
<rqou>
something something still no stanfurdium :P
<jcreus>
hehehehhe
<jcreus>
I'd make a quip about football, but I lack the passion or knowledge to do so
<jcreus>
hm, quick question - is there a current hacker favorite ice40[up5k?] board? I recall seeing a cheap one a while back that had issues with the oscillator and board layout, but also several kickstarters in the pipeline - anyone have played with any of them?
<rqou>
i forgot what the official one is
<rqou>
tinyfpga here made one
<jcreus>
oh, nice
<jcreus>
bit expensive but I guess that's the price for not having to reflow bga
<azonenberg_work>
jcreus: because bga is soooo scary
<rqou>
i normally dev on the official hx8k board
<rqou>
oh yeah, many people here will sell you on how bga is not that difficult to do
<rqou>
(although the up5k bga is much harder)
<jcreus>
oh I know it's just me being terrible at it
<jcreus>
also had a bad experience with a teensy 3.5 bga (though that was subjected to -60 to +60 degC swings)
<TD-Linux>
the tinyfpga is best and has an awesome bootloader
<TD-Linux>
other than that, the icestick is an alternative and cheap
<rqou>
icestick is a hx1k right?
<TD-Linux>
yes
<rqou>
not the lattice official piece of shit up5k board
<awygle>
tinyfpga doesn't have a up5k does he?
<TD-Linux>
nope
<TD-Linux>
but there's an ecp5 in the works :D
<awygle>
the one you're talking about is the upduino
<TD-Linux>
yeah though I would recommend the tinyfpga bx over the hx8k dev board (I have both)
<rqou>
hmm, i would recommend the hx8k dev board because lots of IO
<TD-Linux>
if you need it sure. though the bx has lots of io on the bottom if needed
<awygle>
I am increasingly less interested in dev boards, which is interesting
<TD-Linux>
oh I totally missed the feather form factor one
<TD-Linux>
awygle, it's because you found out that making pcbs isn't that hard
<awygle>
TD-Linux: yeah basically
<rqou>
wait a sec
<awygle>
I can get a dev board or just make one that does exactly what I need
<rqou>
the tinyfpga bx isn't an HX series at all
<TD-Linux>
feather is pretty neat because of the onboard lipo circuitry
<awygle>
It's an LP right?
<rqou>
yeah, it's an LP
<TD-Linux>
er sorry lp8k
<rqou>
jcreus: takeaway: check very carefully exactly which series you are getting
<rqou>
they have different timing among other things
<jcreus>
yep, many thanks rqou
<awygle>
LPs are fine too :-P
<jcreus>
forgot how good IRC is for this
<awygle>
yeah fpga irc is great
<tinyfpga>
LP and HX are the same except for timing
<TD-Linux>
yeah hx is faster (though you probably won't notice the difference)
<tinyfpga>
LP is a bit slower than HX
<rqou>
be glad you joined after we took all the offtopic out :P
<tinyfpga>
and UP is even slower than LP, but makes up for it with the large SRAMs, multipliers, and peripherals
<jcreus>
tinyfpga: how about power? tryna make super low power, and since I'll end up having an RF frontend it'll be the least of my worries, but is there much variation between families?
<jcreus>
or are they all O(1 mW)?
<tinyfpga>
jcreus: UP is the lowest power
<awygle>
they're all pretty low tho
<awygle>
what kind of RF frontend?
<tinyfpga>
jcreus: the Feather board Iโm working on uses high efficiency switching power supplies and a smart battery charger IC
<jcreus>
awygle: custom based on the si4463 - up to 20 dBm, but configurable to lower for shorter range
<rqou>
tinyfpga: O_o
<awygle>
tinyfpga: are you willing to name drop the insanely small switcher on the EX?
<rqou>
can i just get the battery subsystem standalone?
<awygle>
jcreus: cool :) i used to do that kind of thing professionally
<awygle>
i kind of miss the RF bits
<TD-Linux>
rqou, there are a lot of discrete battery management boards on adafruit / feather already (but probably not with the 1.2v core regulator of course)
<jcreus>
awygle: yeah, RF is fun, though I'm far from a wizard. Getting few hundred km range on the 4463 for a balloon project, though, so can't really complain (trying to add video, only telemetry for now)
<rqou>
last i researched it all of them sucked in some way
* awygle
has also done a balloon project
<awygle>
i should test that mixer board more thoroughly someday. lots of other more important things tho
<awygle>
want to run 433 MHz radio in S-bnand
<jcreus>
yep, we ran it on 433 (also, if going too far offtopic, feel free to continue via DM, or some rf channel if they exist)
<awygle>
i ran 433 and then made an LNB to receive S-band with the same radio (2100 MHz), but never quite validated it fully. if you find a good RF channel, let me know :) i'm gonna go to sleep now though.
<TD-Linux>
tinyfpga, ohh boy is the 3.3v switcher the bare die package one?
<tinyfpga>
rqou: do you have a cheap one in mind? would have to be very inexpensive to justify
<rqou>
i don't
<rqou>
i still need to research this
<tinyfpga>
TD-Linux: all switchers are WLCSP
<tinyfpga>
on my EX and feather boards
<TD-Linux>
I saw it on the ex you had at the fpga meetup
<rqou>
but basically my opinion is that i don't see the point of integrated lipo circuitry unless they have all the bells and whistles
<awygle>
are those expensive?
<awygle>
the WLCSP switchers I mean
<TD-Linux>
rqou, because you need it for safe charging?
<rqou>
no
<rqou>
basically imo unless you integrate a charger, gas gauge, and voltage regulator all in one
<rqou>
you're much better off just paying anker to design the lipo circuit for you
<TD-Linux>
coulomb counting is kinda pointless for little batteries. also it's going to be awful with a cheap adc
<rqou>
and then you can buy it on amazon for a very small amount of money
<TD-Linux>
not a $1 lipo you can't
<tinyfpga>
awygle: they are cheap
<awygle>
any reason not to just standardize on them? Lol
<tinyfpga>
awygle: check their price at the octopart bom
<awygle>
I am on my phone, I'll look more closely in the morning
<tinyfpga>
awygle: I will use them for all my boards...unless I have a board with tons of space
<rqou>
in general for most applications i'm finding it harder and harder to justify why i shouldn't just pay anker to make my lipo problems go away
<tinyfpga>
awygle: the LDO regulators are still cheaper, like 10 cents or less, the switchers are 30 cents or so and then I need the inductor
<TD-Linux>
because you can just slap a sot-23-6 chip pin on your board instead?
<TD-Linux>
(to rqou)
<awygle>
dang, in qty 1?
<awygle>
or reel qty
<rqou>
i mean, you _can_
<rqou>
it rarely seems useful
<tinyfpga>
awygle: something like that...I never bought just before XD
<awygle>
wow I gotta try those. Thanks!
<tinyfpga>
awygle: so in small quantities the switchers are like 60 cents, in larger quantities like 1000 they are 30 cents
<awygle>
whew
<awygle>
that's awesome
<awygle>
arright sleep for real. thanks again!
<rqou>
also TD-Linux you kinda need more than a sot-23-6
<rqou>
you also need the voltage regulator circuits
<TD-Linux>
you usually just need two, you need one for protection and one for a linear charging circuit. you presumably already have 3.3v regulators etc
<TD-Linux>
there are some that have protection and charging in one.
<rqou>
sure, you can use those
<rqou>
but they tend to charge slowly
<rqou>
i would only bother for really small stuff
<rqou>
anything larger it just seems easier to rely on commodity products that already solved the problem
<TD-Linux>
in the cases I usually have I'm limited by battery charge rate more due to it being so tiny
<rqou>
last i looked into this for my projects it ended up being not worth it to go with a custom solution
<rqou>
but i can't find where the design files went
ayjay_t has quit [Read error: Connection reset by peer]
<rqou>
but basically when i added up the cost of all the miscellaneous stuff like inductors and blinkenlights and sourcing a battery that wasn't awful, it ended up being no less expensive than just ordering a usb battery pack
ayjay_t has joined ##openfpga
<rqou>
but anyways TD-Linux i'll run through the design space again with the new parts tinyfpga mentioned
<rqou>
this isn't just me making a 80% solution and calling it good
<TD-Linux>
ok. those parts will also probably be lower cost because of their very high frequency, letting the inductors be pretty small
<rqou>
yeah, my old design was some generic 100khz switcher that wasn't particularly good at anything
<TD-Linux>
it's probably efficient :)
<rqou>
iirc it wasn't chosen for efficiency either
<TD-Linux>
actually the ex parts are shockingly efficient
<rqou>
iirc i used one of the TI nonlinear "don't need to mess with control loop compensation" parts
<TD-Linux>
I guess the low input voltage range helps, but it's still surprising
<TD-Linux>
rqou, yeah that's what I used to use, and I remember achieving results similar to yours
<s_frit>
m_t_: thanks. would you recommend using both iverilog and verilator for general simulation tasks (e.g. outputting waveforms for inspection)?
<ZipCPU>
s_frit: I would recommend Verilator for general simulation tasks
<ZipCPU>
I'm not recommending iverilog simply because I haven't used it. I'll leave that one to others to recommend.
<s_frit>
ZipCPU: my concern right now is getting quick results, without having to dive into C++ stuff. even just setting up a basic testbench in verilator looks like i'm going to have to mess around with custom Makefiles etc
<ZipCPU>
s_frit: What are you simulating? Are you co-simulating external hardware?
<ZipCPU>
... or is this just a simple bench test you wish to accomplish? At which point I would recommend formal methods rather than simulation. ;)
<s_frit>
ZipCPU: i'm working up to simulating this CDR thingy. i'll be simulating the input too
<ZipCPU>
CDR?
<s_frit>
ZipCPU: keep in mind that i'm still learning the basics. at some point i will definitely want to use verilator to output PLL tracking data that I can visualise with numpy, and at some point sure, i will learn yosys
<daveshah>
clock data recovery?
<s_frit>
^^^
<s_frit>
at the moment i'm in the pre-formal explore-the-problem-and-solution-domain stage
<daveshah>
Sounds fun
<daveshah>
What data rate/protocol?
<s_frit>
hopefully it stays fun :)
<s_frit>
for my first run it will be spdif, but the target is the adat protocol (which is similar enough that i should be able to reuse my learnings)
<daveshah>
Neat
<s_frit>
in a future iteration i'm hoping to use the pll in the up5k for jitter cleaning, but i think that will be a stretch
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 252 seconds]
wpwrak has quit [Ping timeout: 268 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
wpwrak has joined ##openfpga
Bike has joined ##openfpga
ayjay_t has quit [Read error: Connection reset by peer]
ayjay_t has joined ##openfpga
rohitksingh has joined ##openfpga
genii has joined ##openfpga
emeb has joined ##openfpga
xdeller__ has joined ##openfpga
xdeller_ has quit [Remote host closed the connection]
massi_ has quit [Ping timeout: 268 seconds]
m4ssi has quit [Ping timeout: 268 seconds]
m4ssi has joined ##openfpga
massi_ has joined ##openfpga
m4ssi has quit [Quit: Leaving]
moho2 has quit [Quit: WeeChat 2.0.1]
moho1 has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
oni has quit [Read error: Connection reset by peer]
Dolu has joined ##openfpga
rohitksingh has joined ##openfpga
emeb has quit [Ping timeout: 252 seconds]
emeb has joined ##openfpga
massi_ has quit [Remote host closed the connection]
m_w has joined ##openfpga
Miyu has joined ##openfpga
s_frit has quit [Remote host closed the connection]
s_frit has joined ##openfpga
florolf has quit [Quit: Reconnecting]
florolf has joined ##openfpga
florolf has quit [Client Quit]
keesj has quit [Ping timeout: 244 seconds]
<sorear>
is there a good reason they keep blowing horns on the B&A when the nearest grade crossing is ten miles away
<prpplague>
sorear: stress relief?
<gruetzkopf>
people too close to infrastructure
florolf has joined ##openfpga
azonenberg_work has joined ##openfpga
Hamilton has joined ##openfpga
X-Scale has quit [Ping timeout: 244 seconds]
oeuf has joined ##openfpga
azonenberg_work has quit [Ping timeout: 252 seconds]
<TD-Linux>
(maybe delete the tracking bit I accidentally pasted)
<TD-Linux>
really want to make a version of the vesc with that chip
<tnt>
Got the same email :) It's actually one of the mail that I wish was more personalized to my field of interest with "big data" analytics. But heh, it's fun to see random parts.
azonenberg_work has joined ##openfpga
m_w has quit [Quit: Leaving]
<TD-Linux>
it would actually be fun to do a ice40 motor controller with a picorv32 and vesc derived firmwrae
<TD-Linux>
I've always wanted to do a 3 phase motor controller with sigma delta
<TD-Linux>
anyone used v-rail or 8020 extrusions? preferred vendor?
<awygle>
8020 is cool
<oeuf>
fseidel: easter me
specing has joined ##openfpga
<TD-Linux>
v-slot is 20mm but 8020.net seems to have more 25mm
Bike has joined ##openfpga
<rqou>
am i the only one who finds Compliance(TM) wording rather awkward and hilarious?
<rqou>
e.g. "opportunities for malicious activity such as hacking"
<awygle>
yes
s_frit has quit [Remote host closed the connection]