dc740 has quit [Remote host closed the connection]
Darius has quit [Ping timeout: 246 seconds]
Darius has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
id_tam has joined #rust-embedded
duderonomy has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<re_irc>
<@whitequark:matrix.org> : a friend did bringup for DWC_usb_otg3
<re_irc>
<@whitequark:matrix.org> but she worked on it on silicon side, on the software side it's just XHCI, you don't even need to configure registers
<re_irc>
<@whitequark:matrix.org> cuz the reset values work fine
<re_irc>
<@whitequark:matrix.org> : a friend did bringup for DWC_usb3
<re_irc>
<@jamesmunns:beeper.com> Is that the same IP blob? I'm planning to bring it up on "bare metal" rather than Linux. I've not uh, actually written any drivers for USB stuff before, but hoping to get it integrated with embassy-usb, at least to support FS mode, so we don't need a separate UART console for the kernel
<re_irc>
<@whitequark:matrix.org> no completely unrelated
<re_irc>
<@whitequark:matrix.org> you asked a general question so i gave additional information
<re_irc>
<@whitequark:matrix.org> neither of us worked with MG IP I think
<re_irc>
<@jamesmunns:beeper.com> I did find that pdf, and the sunxi wiki had some more guides.
<re_irc>
<@jamesmunns:beeper.com> : Totally fair!
<re_irc>
<@whitequark:matrix.org> though USB IP is all kinda samey
<re_irc>
<@whitequark:matrix.org> if you have USB questions i'm here i guess lol
<re_irc>
<@jamesmunns:beeper.com> I was actually thinking of your doc archive when I was looking for the datasheet
<re_irc>
<@whitequark:matrix.org> it was funny, at her old job programmers would come to her asking things like "why is our custom bare metal XHCI stack doesn't work" and she'd tell them which line of their firmware has an error based on AXI waveforms in the simulator. i found that very impressive
<re_irc>
<@jamesmunns:beeper.com> Very cool :)
<re_irc>
<@whitequark:matrix.org> so turns out that if you do that for the programming department they kind of never learn to read the XHCI spec and instead just rely on you to decipher their bugs...
<re_irc>
<@jamesmunns:beeper.com> I should probably go reread the USB spec :/
<re_irc>
<@whitequark:matrix.org> it helps
<re_irc>
<@whitequark:matrix.org> but a lot of things in these specs is like... it only makes sense if you already know what it's supposed to mean
<re_irc>
<@whitequark:matrix.org> and/or if you wrote USB IP
<re_irc>
<@jamesmunns:beeper.com> I did (mostly) a while back, but was lucky enough that other people made progress faster than I could for things like the usb-device crate and embassy-usb
<re_irc>
<@whitequark:matrix.org> so if you're just a programmer with no HDL experience, it will be very unlikely you can write a bug-free XHCI driver
<re_irc>
<@jamesmunns:beeper.com> Luckily I at least have embassy-usb to integrate against
<re_irc>
<@whitequark:matrix.org> she found a bug in the Linux XHCI implementation that was there since basically initial commit. by coincidence someone fixed it like two or three months before (she was working with an older tree)
<re_irc>
<@whitequark:matrix.org> and it was in one of the most commonly used paths
<re_irc>
<@jamesmunns:beeper.com> My other nemesis right now is getting something like Realtek wifi chips also supported. The Linux driver module for that family is 400kloc, about 250kloc if you strip it down to the one chip
<re_irc>
<@whitequark:matrix.org> it was uh... when doing command ring abort with a 64-bit XHCI implementation, Linux would unintentionally clear half of the command ring address field because the explanation of how to do an abort in the spec only makes sense if you wrote HDL
<re_irc>
<@whitequark:matrix.org> : oh no wifi is nightmarish
<re_irc>
<@jamesmunns:beeper.com> I might just spin my own board with an esp32c3 instead because that is less mind bogglingly large of a scope
<re_irc>
<@jamesmunns:beeper.com> A ton of the D1 boards use rtl8723 something, but yeah, afaict the only public "docs" for that is the Linux driver, which is... a lot.
<re_irc>
<@whitequark:matrix.org> yesyesyesyesyes i would suggest going for esp32c3
<re_irc>
<@whitequark:matrix.org> the data rate you get from a c3 is way lower of course
<re_irc>
<@whitequark:matrix.org> though, hm, maybe "way lower" is an overestimation? they're both bgn implementations. but if i recall people don't get much throughput out of cheaper esp32s
<re_irc>
<@whitequark:matrix.org> +1t1r
<re_irc>
<@jamesmunns:beeper.com> C3 is SPI, so yeah, much slower, I think the C5/C6 might reintroduce SDIO, not sure
<re_irc>
<@whitequark:matrix.org> you could do parallel transfers i think
<re_irc>
<@whitequark:matrix.org> i don't think you have enough for 16 bits but, what's your host?
<re_irc>
<@jamesmunns:beeper.com> But yeah I'm not dying for bandwidth right now. We have a 115200 UART and a 400x240 monochrome screen right now heh
<re_irc>
<@jamesmunns:beeper.com> : Allwinner D1
<re_irc>
<@whitequark:matrix.org> oh nice, all risc-v
<re_irc>
<@whitequark:matrix.org> right so your options are SPI or software parallel transfer
<re_irc>
<@jamesmunns:beeper.com> Well, plus an rp2040 as an i/o+(sorta)pmic for now :D
<re_irc>
<@whitequark:matrix.org> i think you could potentially get more out of software parallel transfer than out of spi
<re_irc>
<@whitequark:matrix.org> iirc on the c3 you can do single cycle gpio in/out
<re_irc>
<@jamesmunns:beeper.com> : I'll look into it! I sorta expect/want to write my own esp32c3 firmware as well
<re_irc>
<@whitequark:matrix.org> the CPU core goes up to 120, the GPIO i don't remember which bus it's on, i think it's tightly coupled to the CPU? or was it only a bit of it?
<re_irc>
<@jamesmunns:beeper.com> OH, i just realized you meant "bit bang a parallel bus"
<re_irc>
<@whitequark:matrix.org> yes
<re_irc>
<@whitequark:matrix.org> you could probably do that at like 20 MHz fairly reasonably and that gives you 160 Mbps, which you can't possibly get out of SPI
<re_irc>
<@whitequark:matrix.org> even half that would be a lot
<re_irc>
<@jamesmunns:beeper.com> It's possible, I have to look at what the gpio DMA looks like on the D1, being able to DMA offload all the SPI transfers is very compelling
<re_irc>
<@whitequark:matrix.org> what i'm thinking of is emulating source synchronous transfers over GPIO, since they probably run off different clocks
<re_irc>
<@whitequark:matrix.org> meaning you need to explicitly synchronize on some pin, like a bitbanged clock or maybe a request/ack
<re_irc>
<@whitequark:matrix.org> if you can have them run on an integer multiple of the same clock that would be way easier
<re_irc>
<@whitequark:matrix.org> configure the DMA and blast away really
<re_irc>
<@jamesmunns:beeper.com> Makes sense! Definitely going for "a bunch of stuff works" before I'm trying to max out the perf of anything, but I'm following what you're suggesting.
<re_irc>
<@whitequark:matrix.org> next level cursed setup (pointless due to the relatively low on-air data rate here but i think the idea is potentially useful): use a programmable clock generator like si5351 or something to clock the c3 and the allwinner so that you have the right phase offset for 1 word / 1 max-frequency cycle transfer
<re_irc>
<@whitequark:matrix.org> which gives you some obscene data rates on the inter-CPU link
<re_irc>
<@whitequark:matrix.org> unfortunately this sort of setup is very sensitive to things like "allwinner has a clock divider somewhere in the fabric that you have to use and they don't give you any way to reset the counter within"
<re_irc>
<@whitequark:matrix.org> but yeah if you're stuck between a rock and a hard place aka "has to deliver >>Mbps between two devices that don't have any high speed interface" something like this could help one ship it
<re_irc>
<@jamesmunns:beeper.com> This is a much more relaxed hobby/research project, so for now "done soon but kinda slow" is a very appealing goal :)
<re_irc>
<@whitequark:matrix.org> nice
<re_irc>
<@jamesmunns:beeper.com> (we're writing a small, general purpose OS, for the big MCU/small processor space that's a little big for an rtos and a little small for Linux)
<re_irc>
<@jamesmunns:beeper.com> Or at least that's the goal :)
<re_irc>
<@thejpster:matrix.org> It seems to be the in thing these days - writing your own OS in Rust.
<re_irc>
<@jamesmunns:beeper.com> Tock-OS, Monotron, Xous, Mnemos, Hubris, definitely lots more that I've seen.
<re_irc>
<@jamesmunns:beeper.com> +Mycelium,
<re_irc>
<@jamesmunns:beeper.com> Embassy and RTIC probably also count as RTOSs, in a non-traditional sense.
<re_irc>
<@jamesmunns:beeper.com> oh, intermezzos, blog-os too
<re_irc>
<@jamesmunns:beeper.com> Tock-OS, Neotron/Monotron, Xous, Mnemos, Hubris, Mycelium, definitely lots more that I've seen.
<re_irc>
<@thejpster:matrix.org> Redox too.
<re_irc>
<@thejpster:matrix.org> OxidOS, which I think is TockOS (or at least based on TockOS - I don't know how much it differs from upstream)
<re_irc>
<@diondokter:matrix.org> : Yeah, from what I've heard it's TockOS + some extensions and professional support
<re_irc>
<@thejpster:matrix.org> I set my stack up to span two memory regions (as understood by the RP2040 target in probe-rs) and probe-run got confused.
duderonomy has quit [Remote host closed the connection]
duderonomy has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
Subjective has quit [Quit: Leaving]
dc740 has quit [Remote host closed the connection]