redstarcomrade has quit [Read error: Connection reset by peer]
redstarcomrade has joined #glasgow
tom has quit [Ping timeout: 246 seconds]
josHua[m] has quit [Quit: Idle timeout reached: 172800s]
bvernoux has joined #glasgow
josHua[m] has joined #glasgow
<josHua[m]>
hm, I wonde4r how tricky it would be to wire a glasgow UART applet up using CUSE
<josHua[m]>
I think the particularly tricky part of this woudl be to have the character device in some way survive glasgow reprogramming / glasgow CUSE daemon restarts, with obviously an interruption in dataflow but without kicking applications off the bus (i.e., analogous to what would happen if you unplugged the UART end of it)
<josHua[m]>
but this would be particularly nice for my current application, which is growing UARTs and GPIOs at an absolutely alarming pace (current status: two UARTs from an i.MX8, one UART from the mainboard FPGA, one UART from the remote FPGA, SPI link to the mainboard FPGA, and some reset pins), and is rapidly outgrowing the number of tigards that I can support on my desk
gatecat[m] has quit [Quit: Idle timeout reached: 172800s]
redstarcomrade has quit [Read error: Connection reset by peer]
<Attie[m]>
what is CUSE?
<ari>
Attie[m]: character device in userspace
<Attie[m]>
ah, of course
FFY00 has quit [Read error: Connection reset by peer]
wheresheisnt[m] has quit [Quit: Idle timeout reached: 172800s]
jmi2k[m] has quit [Quit: Idle timeout reached: 172800s]
<sorear>
CUSE probably makes sense for a lot of applets but a UART, specifically, is a _serial port with a software defined backend protocol_, in other words a pseudoterminal
<sorear>
POSIX ptys are unnamed on the ptmx side so if you wanted a userspace process to transparently connect to multiple daemons, you'd need a separate long lived process to hold the fd. BSD ptys (/dev/ptyXY, CONFIG_LEGACY_PTYS=y, not part of the default linux build for quite a few years; not looking at other kernels since you started by asking about CUSE) are named and it might be possible to reopen the same pty device
cr1901_ is now known as cr1901
benny2366[m] has quit [Quit: Idle timeout reached: 172800s]
duskwuff[m] has quit [Quit: Idle timeout reached: 172800s]
omnitechnomancer has quit [Quit: Idle timeout reached: 172800s]
<josHua[m]>
the separate long lived process is indeed what I was thinking
<josHua[m]>
I wanted CUSE specifically so that I could set various UART parameters on it with traditional UART tools (picocom, etc), I think
<whitequark[cis]>
<josHua[m]> "hm, I wonde4r how tricky it..." <- glasgow can already give you a PTY
<whitequark[cis]>
<josHua[m]> "I wanted CUSE specifically so..." <- oh I see
<whitequark[cis]>
okay, i looked into using CUSE
<whitequark[cis]>
terrible interface that requires depending on terrible linux software
<whitequark[cis]>
basically the one way in which i expect i may accept that contribution is by writing a high-quality CUSE driver from scratch and including it in the glasgow tree
<sorear>
what is the scope of a "CUSE driver"?
<whitequark[cis]>
the scope is whatever's needed to implemenet a ttyS, plus whatever you feel like testing on top of that
<tpw_rules>
is CUSE a part of the FUSE tree? you mean not depending on libfuse?
<whitequark[cis]>
i looked at https://github.com/faith91/cusepy, which suggests you need to depend on libfuse and do some weird ctypes stuff on top
<tpw_rules>
so the driver part would be that userspace code?
<whitequark[cis]>
yeah
<tpw_rules>
ok. (maybe "drivee"? i thought you meant a linux kernel module and was confused)
<whitequark[cis]>
like if you need to do something involving GCC-XML and ctypes anyway then you might as well reimplement libfuse on top of it
<whitequark[cis]>
tpw_rules: no, a driver (since CUSE is a (virtual) device)
<whitequark[cis]>
it's a device that can be used to create more devices, kind of like a PCI bridge or something
<whitequark[cis]>
so, on further review it looks like libfuse is the public API for CUSE, but you also need linux ioctl info on top of that
icb[m] has quit [Quit: Idle timeout reached: 172800s]
<josHua[m]>
I have also never looked into CUSE before
<whitequark[cis]>
yeah this looks like a total nightmare
<josHua[m]>
the extent to which I had heard of it was the name and the idea
<josHua[m]>
I have implemented something on top of libfuse before also, and libfuse also suffers the other big problem that many things in this world have
<josHua[m]>
that is to say, it sucks ass
<josHua[m]>
(more specifically, it religiously picks the wrong abstraction at every oportunity)
<josHua[m]>
s/oportunity/opportunity/
<whitequark[cis]>
yeah
<whitequark[cis]>
maybe someone™ needs to get a virtual-serial-port driver in the kernel :p
<josHua[m]>
I guess I wanted to believe that CUSE was not awful, but it may be from the era of Linux UAPI design where the review process was 'lol, git push'
<whitequark[cis]>
CUSE is definitely awful
<josHua[m]>
I mean, you can always commit terrorism, I guess?
<josHua[m]>
and expose a usb/ip ... FTDI ... device
<tpw_rules>
what would good abstraction look like
<whitequark[cis]>
that escalated quickly
<whitequark[cis]>
usb/ip is the interface that can panic your system if you look at it wrong, right?
<josHua[m]>
which, terrorism or usb/ip ftdi
<josHua[m]>
I haven't managed to emit a kp out of usb/ip but I have hung a host USB stack with it, yes
<josHua[m]>
tpw_rules (@_discord_285821454715715585:catircservices.org) good abstraction would be inode-based, with path-based API emulation on top of that if needed, not 'refer to absolute paths at all times'
<whitequark[cis]>
josHua[m]: tbf what's the difference, all my input devices are usb
<josHua[m]>
I think you can hang a host USB stack if you send half of a URB back during enumeration and then disconnect
<josHua[m]>
but, like, don't do that
<whitequark[cis]>
what if your program crashes
<sorear>
i thought fuse was inode-based at least at the internal abi level
<sorear>
it seems to match the linux vfs oo interface fairly well, say about that what you will
<whitequark[cis]>
we're talking about the public API, no?
get0rix[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
well. i actually wouldn't mind a bunch of code in glasgow that just invokes FUSE ioctls directly but given that the FUSE ioctl version is at twenty six i can see some potential issues with htat
<sorear>
(I am a heretic that thinks making open file descriptions part of the *semantic model* of unix was a mistake, and everything that follows from that, including the behavior of fds when the underlying file is deleted or renamed; the windows model can at least be forwarded over a network with a stateless, unprivileged server)
esden[m] has quit [Quit: Idle timeout reached: 172800s]
prop_head_mania[ has quit [Quit: Idle timeout reached: 172800s]
<josHua[m]>
race conditions can be avoided by making atomic sections appropriately short (?)
<josHua[m]>
404, it seems
bvernoux has quit [Quit: Leaving]
<whitequark[cis]>
yes, i never actually did it
<whitequark[cis]>
but it's how i feel about fuse
<josHua[m]>
o.
<josHua[m]>
I think the usbip ftdi emulation is actually the least terrible of these ideas, and is extra funny given the concept of Glasgow as an ersatz FTDI
<josHua[m]>
(or usbip cdcacm, or whatever)
<whitequark[cis]>
over my dead body
<whitequark[cis]>
willing to meet you in the waffle house parking lot
<josHua[m]>
the only way you can stop me is by forcing esden to rev the board!
<chuckmcm[m]>
Old message but I'm wondering what you mean "incorporate SDR" and "do FT8". I ask because I breadboarded a small SDR FT8 tranceiver but the 'radio' front end was a selector/mixer/LNA that brought the spectrum of interest (in my case 40M) down to baseband. I have some interest in doing an FPGA implementation of the FT8 protocol but that is a ways off at this point.
prop_head_mania[ has joined #glasgow
<prop_head_mania[>
Im currently learning all the bits and pieces , I have been recommended FT8 software which can use soundcard - I however actually build things and want to know the code and design - if it can be squished into a microcontroller OR is dependant on processing abilities of a RasPi chuckmcm (@_discord_169936075697946624:catircservices.org)
<chuckmcm[m]>
Oh it can definitely fit in a microcontroller, I've written a modulator for STM32G4's, the QEX article on FT8 is really super helpful there, I learned a lot by reading it. Depending on how you implement it the challenge on FPGAs will be ensuring you're effectively using all the DSP hardblocks. (multiply-accumlators) as implementing frequency detectors works better with FFTs (in my experience)
<whitequark[cis]>
ice40hx8k does not have any DSP hardblocks
<chuckmcm[m]>
Hmmm, that means building the multipliers in gateware, which might consume too much space (tbh I haven't tried doing that, how many gates does it use if your verilog has a 16 bit multiply?)
<whitequark[cis]>
dunno but it's a LUT4 architecture with hard carries
<whitequark[cis]>
by 16 bit do you mean 16x16->32?
<chuckmcm[m]>
Yeah. (on the 16 x 16 -> 32) although you might have enough discrimination with 12 x 12 -> 24. ARGH! Get away from me rabbit hole! Be gone! 🤣
<prop_head_mania[>
10 million links -- books --- articles , not enough building
Foxyloxy has joined #glasgow
<whitequark[cis]>
chuckmcm: about 10% of the FPGA for a single 16x16->32 1-cycle multiplier
<chuckmcm[m]>
Hmm, okay, that's not oo bad. So 40% for four of them. (that gives you a complex multiply in one cycle which is what the FFT's are built on).
<whitequark[cis]>
roughly, though i did not look at delay