cr1901 has quit [Read error: Connection reset by peer]
dcz_ has joined #rust-embedded
<re_irc>
<@willeml:matrix.org> Any recommendations on powerful risc-v microcontrollers for a rust project? (over 200mhz, 256K ram and decent storage or at least external storage possibilities)
<re_irc>
<@willeml:matrix.org> as well as spi for display and stuff
<re_irc>
<@willeml:matrix.org> "powerful"
<re_irc>
<@willeml:matrix.org> I am mostly just curious as to how much it would cost and where I would get it...
<dcz_>
I don't know if you can get the microcontroller separately
<dcz_>
seems only to have 16KiB RAM though
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@therealprof:matrix.org> SiFive (like any manufacturer) would love to sell MCUs separately. 😉
<Lumpio->
But can't due to fab availability shortages or what
fabic has joined #rust-embedded
<dcz_>
SiFive are not much of a manufacturer, they sell designs
<re_irc>
<@9names:matrix.org> willeml: K210 is sufficient for those needs (400mhz, dual core, 8MB SRAM). guess it depends on your definition of "decent storage" and microcontroller though.
<re_irc>
<@9names:matrix.org> it doesn't really have many peripherals. it is reasonably low power. you can operate it without an MMU (which is for the best, because that is kinda broken)
<Lumpio->
o
<re_irc>
<@therealprof:matrix.org> dcz_: That is true. But they have partners which do. And they belong to Intel now so things might change. 😉
<dcz_>
do they? I thought they didnt get sold yet
<dcz_>
also, I haven't seen a single design by SiFive being sold by anyone else to the general public
<re_irc>
<@therealprof:matrix.org> dcz_: Hm, again you're right. Officially it's still only a collaboration to produce chips in Intel fabs.
<re_irc>
<@therealprof:matrix.org> I thought that was a done deal already.
<dcz_>
nice catch with the Bouffalo, that's at least one public design. I still couldn't find anywhere to buy them after a quick search
<re_irc>
<@9names:matrix.org> you can get them from pine64, seeedstudio, aliexpress
<re_irc>
<@9names:matrix.org> doesn't quite meet your reqs though - they don't run above 200Mhz, and once you allocate RAM for the flash accelerator you're below 256K SRAM
<re_irc>
<@eldruin:matrix.org> jbeaurivage: There are a few of them here. feel free to ask
<re_irc>
<@jbeaurivage:matrix.org> Recently I can't seem to be able to initialize my cards. I've tried multiple cards on two (seemingly) identical boards with no success.
<re_irc>
<@jbeaurivage:matrix.org> ```rust
<re_irc>
<@jbeaurivage:matrix.org> let spi_bus = bsc::spi_master(
<re_irc>
<@eldruin:matrix.org> inevitable answer: what changed in software or hardware?
<re_irc>
<@jbeaurivage:matrix.org> No change in hardware, there were some changes to the SPI driver in `atsamd-hal` recently
<re_irc>
<@jbeaurivage:matrix.org> I'm also wondering what could've changed in embedded-sdmmc, though the last commit was December 5 2020 so unlikely that broke
<re_irc>
<@eldruin:matrix.org> have you always been using the same embedded-sdmmc version?
<re_irc>
<@jbeaurivage:matrix.org> Pretty sure I've been using 0.3 since the beginning of the project
<re_irc>
<@eldruin:matrix.org> alright, have you tried reverting to an earlier atsamd-hal version?
<re_irc>
<@jbeaurivage:matrix.org> I'm doing that now. So far without success
<re_irc>
<@jbeaurivage:matrix.org> Do you happen to know which SPI mode/bit order SD cards operate under? I suspect the defaults might've changed with increasing HAL versions
<re_irc>
<@eldruin:matrix.org> I do not know from the top of my head
<re_irc>
<@lachlansneff:matrix.org> Is there a reasonable way use an embedded peripheral/device driver that runs on top of an rtos abstraction on embedded rust? e.g. The driver requires you to implement a way to create threads
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
tokomak has quit [Read error: Connection reset by peer]
dcz_ has quit [Ping timeout: 255 seconds]
<re_irc>
<@jamesmunns:matrix.org> Lachlan Sneff: I know the espressif folks are wondering the same thing right now.
<re_irc>
<@jamesmunns:matrix.org> As esp-idf is currently based on freertos, for example
<re_irc>
<@dirbaio:matrix.org> sounds like a bad driver if it requires threads :D
cr19011 has joined #rust-embedded
cr19011 is now known as cr1901
<re_irc>
<@adamgreig:matrix.org> in cmsis land there's cmsis-rtos which most RTOSs targetting cortex-m implement, and provides a common set of methods that applications and drivers can use
<re_irc>
<@adamgreig:matrix.org> i haven't seen such a thing in rust yet but there's not exactly an abundance of rust rtoses either
<re_irc>
<@adamgreig:matrix.org> but in principle you could totally have something akin to the e-h traits but for rtos functionality
<re_irc>
<@dirbaio:matrix.org> I'd love such a thing to *keep not-existing* 🤣
<re_irc>
<@dirbaio:matrix.org> otherwise drivers will start using it, and then you suddenly need an RTOS
<re_irc>
<@dirbaio:matrix.org> and many of the reasons to use an RTOS in C don't apply to Rust
<re_irc>
<@orvi:matrix.org> how do drivers normally handle async stuff? or are the drivers themselves wrapped in threads?
<re_irc>
<@dirbaio:matrix.org> concurrency? IMO async/await is way better
<re_irc>
<@dirbaio:matrix.org> uniform vendor-independent API for uart/spi/i2c/etc? we have embedded-hal for that
<re_irc>
<@dirbaio:matrix.org> integrated networking? again, with the power of Rust traits you can super easily and foolproofly wire up combinations like smoltcp + stm32-eth + stm32xxx-hal
<re_irc>
<@dirbaio:matrix.org> orvi: currently most rust drives are simply blocking...
<re_irc>
<@dirbaio:matrix.org> or at most "hey please call this function on irq"
<re_irc>
<@dirbaio:matrix.org> with async the drivers would have `async fns` in the public api, user calls them and the driver does things asynchronously without blocking
<zBeeble>
OK. I must admit to being a bit lost. I'm trying to get rust to bootstrap on RISCV64 on FreeBSD. I'm having trouble finding a good set of instructions and/or instrucations I find no longer work.
neceve has quit [Ping timeout: 245 seconds]
<zBeeble>
I think that I have an acceptable resource file (.rs file) but ./configure on the crossbuild host ends up saying "unknown cpu type: riscv" or, alternatively. option '--enable-rustbuild' is not recognised (following different sets of directions)
<re_irc>
<@lachlansneff:matrix.org> dirbaio: I'm still not sure how to get drivers to be async around an irq without the user doing that extra work.
<re_irc>
<@dirbaio:matrix.org> the HAL would do it
<re_irc>
<@dirbaio:matrix.org> for example
<re_irc>
<@dirbaio:matrix.org> - HAL manages the SPI regs + irq, produces a struct that impls `eh::futures::spi::Transfer`
<re_irc>
<@dirbaio:matrix.org> so there's a chain of futures: user -> driver -> hal
<re_irc>
<@dirbaio:matrix.org> the HAL is responsible for managing the irq. When the irq fires, the hal wakes some waker if needed, which causes the executor to poll the futures again
<re_irc>
<@dirbaio:matrix.org> everything is interrupt-driven under the hood, but neither driver code or user code has to worry about interrupts
<re_irc>
<@lachlansneff:matrix.org> Ah, awesome, I see.
<re_irc>
<@lachlansneff:matrix.org> And so, the spi struct in the hal would require an owned interrupt to be created?
<re_irc>
<@dirbaio:matrix.org> embassy does it with owned interrupts yep
<re_irc>
<@dirbaio:matrix.org> there are other ways
<re_irc>
<@dirbaio:matrix.org> out of the experimentation I've done, owned interrupts are the best way I've found...
<re_irc>
<@dirbaio:matrix.org> for example HALs can outright register the interrupts themselves with `#[interrupt]` directly
<re_irc>
<@dirbaio:matrix.org> but then there's no way for the user to register the interrupts if they want to do something custom
<re_irc>
<@lachlansneff:matrix.org> dirbaio: For sure it is, but it's a binary blob. There's nothing I can do about it.
<re_irc>
<@lachlansneff:matrix.org> Wifi driver
<re_irc>
<@dirbaio:matrix.org> which chip?
<re_irc>
<@lachlansneff:matrix.org> I don't actually need it, but I was curious if I could use it.