dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
<re_irc>
< (@firefrommoonlight:matrix.org)> Have y'all used Risc-V? What do you think?
<re_irc>
< (@firefrommoonlight:matrix.org)> I want to be an embedded programmer... Not an Arm programmer! Am in danger
<re_irc>
< (@xiretza:xiretza.xyz)> I've built a RISC-V MCU, it's a pretty nice architecture from that point of view
<re_irc>
< (@jessebraham:matrix.org)> We support the ESP-C2/C3 in "esp-hal" now which are both RISC-V, been pleasant enough to work with. Haven't had any issues and it's nice having support for the architecture in the mainline compiler.
<re_irc>
< (@jessebraham:matrix.org)> Worked with a student that designed a RISC-V MCU as well, he seems to be a fan 😄
<re_irc>
< (@dkhayes117:matrix.org)> I worked with the E310 for my senior design project back in 2020. I like RV a lot.
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
< (@oop584:matrix.org)> I do RISC-V stuff full-time, I'm a big fan. Great ISA for learning both embedded and comp arch.
explore has joined #rust-embedded
<re_irc>
< (@oop584:matrix.org)> * firmware
<re_irc>
< (@762spr:matrix.org)> anyone on here have experience with hosting a web page from their embedded device? I want to use a NINA/ESP32 as a wifi coprocessor to host an offline configuration interface (like a router, or 3dprinter).
<re_irc>
There seem to be thousands of examples of how to serve boilerplate HTML to toggle an LED, but I haven't found much on doing more advanced things. I have been looking at https://adminlte.io/themes/v3/index3.html and Mainsail https://docs.mainsail.xyz/ based on vuetify... That all seems pretty straightforward as far as the front end goes. I have been following several courses and making the page doesn't seem that hard.
<re_irc>
But I am a little lost on how the interaction with the host mcu actually happens? I would need to send out several files presumably, not just some inline HTML, and would need to interact with data stored on a local file system. Can someone point me to what I need to look into to learn such things? There seems to be so many different/competing/overlapping systems in the web realm it it tough to sort out exactly what I need to...
<re_irc>
... learn...
<re_irc>
< (@762spr:matrix.org)> sorry, I know this isn't strictly rust related, but I am hoping that someone on here has experience in this area that could direct me where to learn or inquire
<re_irc>
< (@firefrommoonlight:matrix.org)> : Nice! Might try that next if I want wifi
<re_irc>
< (@hegza:matrix.org)> : Super nice but I'm an academic, I don't think I'm allowed other opinions. Simple assembly is quick to learn and readable. Only thing I've found not too much fun is that parts of the specification were only recently frozen, so there's some things like non-standard interrupt architectures going around and along with supposedly "RISC-V" platforms.
<re_irc>
< (@almindor:matrix.org)> i like the base risc-v and basic extensions (e.g. IMAC) but am a bit nervous about it becoming a mess of extensions soon. Sort of opengl style
<re_irc>
< (@oop584:matrix.org)> : It's definitely getting hard to keep track of everything flying around. However, I think profiles (https://github.com/riscv/riscv-profiles/blob/main/profiles.adoc) will make this less of an issue when trying to develop portable software (assuming it gets ratified, of course)
<re_irc>
< (@oop584:matrix.org)> Not so helpful for trying to write portable M-mode software though
explore has quit [Quit: Connection closed for inactivity]
explore has joined #rust-embedded
conplan has joined #rust-embedded
<conplan>
how do you store peripherals globally in a thread safe way if mutexes dont work
<re_irc>
< (@adamgreig:matrix.org)> you can use a mutex for your platform, e.g. the cortex-m crate has a mutex based on a critical section
<conplan>
adamreig: yeah, I'm already using them. But aparently mutexes work only for single threaded systems?
<conplan>
they at least don't gaurantee safety in the same way
<re_irc>
< (@adamgreig:matrix.org)> if you have multiple cores, you need to use a critical section that works with multiple cores
<re_irc>
< (@adamgreig:matrix.org)> this is where the critical-section crate comes in, it allows you to plug in your own implementation; for single-core situations the cortex-m and riscv crates provide a simple implementation by disabling all interrupts, but other platforms can do other things, e.g. the rp2040 HAL can use special hardware to ensure both cores cannot enter the critical section together
hwj has joined #rust-embedded
<conplan>
that's so cool! does this mean I could write critical sections that only didn;t respond to some interrupts, but not others?
<re_irc>
< (@adamgreig:matrix.org)> indeed, with some care, that's done for the nrf softdevices for example I believe
<re_irc>
< (@adamgreig:matrix.org)> though (if you're on cortex-m) you might want to check out RTIC (rtic.rs) which provides a very nice framework for sharing resources between different interrupts as precisely as possible, without globally disabling interrupts
<conplan>
I am working on a cortex m system. I'm building an IC tester with an MSP432p401r. It's a cortex M4F, which IIRC has multithreading. I would like to use mulithreading to blink the leds if possible
<re_irc>
< (@adamgreig:matrix.org)> "multithreading" is really only a concept in operating systems, where multiple threads are time-scheduled onto one or more CPU cores
<re_irc>
< (@adamgreig:matrix.org)> the cortex-m4f is a single cpu, and I don't think any of the msp432 have more than one of them, so you only have one cpu core, and thus only one thread of execution at a time
<re_irc>
< (@adamgreig:matrix.org)> so the only "threads" to worry about are the different interrupts and the main thread
<re_irc>
< (@adamgreig:matrix.org)> in other words, the normal critical-section from the cortex-m crate (which disables all [other] interrupts) is fine and safe
<re_irc>
< (@adamgreig:matrix.org)> but you may find using rtic makes your life a lot easier, or you could also check out embassy (https://embassy.dev/) for another approach which uses async