<JamesMunns[m]>
there's not really a great way to do that, unfortunately. I've seen some proof of concepts around that, or getting llvm to do that, but I probably wouldn't recommend it for anything more for proof of concepts.
crabbedhaloablut has joined #rust-embedded
<JamesMunns[m]>
adinack[m]: > <@adinack:matrix.org> i believe that's what this is for
<JamesMunns[m]>
yeah, this is one of the options - you'd be limited to rust v1.54.0 (from July, 2021), and it doesn't handle borrow checking, so you'd need to compile things in some other way to get those checks
<adinack[m]>
haha WHAT no borrow checking??
<adinack[m]>
C2000 is not worth it!!
<JamesMunns[m]>
the other options I've seen is I think Julia maintains an `llvm-cbe`, or "C backend", that emits C code, but I think it also has problems, and might be based on a very old version of LLVM? I haven't looked in a while
<JamesMunns[m]>
I don't think GCC supports the C2000 either, there's some work (two main efforts, actually) to be able to use Rust with GCC as a backend instead of LLVM, but neither are 100% mature, and it still doesn't help you
<adinack[m]>
why would TI make their chip so untargetable
<JamesMunns[m]>
> C2000 consists of 5 sub-families: the newer C28x + ARM Cortex M3 series, C28x Delfino floating-point series, C28x Piccolo series, C28x fixed-point series, and C240x, an older 16-bit line that is no longer recommended for new development
<JamesMunns[m]>
okay, if it has a Cortex-M core on it, then the probability goes way up!
<adinack[m]>
woah i just looked at the datasheet i didn't see that
<JamesMunns[m]>
but I dunno if that's a "coprocessor" sort of setup, I only touched the much older, classic-DSP style ones about a decade ago
<JamesMunns[m]>
"equivalent to" doesn't mean "is made up of"
<adinack[m]>
that's pretty sick if you can just ignore the C28x LOL
<JamesMunns[m]>
the C2000 is from a chain of DSP cores dating back to like the 90s
<JamesMunns[m]>
adinack[m]: in the old days, ALL MCUs and DSPs required proprietary compilers and toolchains and stuff
<JamesMunns[m]>
well, not ALL
<JamesMunns[m]>
but like, that was the "standard"
<adinack[m]>
sure, the pre-Arm revolution
<adinack[m]>
or pre-Cortex-M*
<JamesMunns[m]>
yeah. AVR and MSP showing up in GCC, then Cortex-M being standard and supported in GCC and LLVM really changed what was reasonable, very very quickly.
<JamesMunns[m]>
but, I imagine a ton of C2000 applications are evolved from "the old ways", for either safety critical stuff, or stuff like motor controllers or power electronics or other stuff where "end users" never deal with it, it's more like "write one bullet proof firmware, then ship millions and millions of black boxes"
<adinack[m]>
i shudder to think any safety critical systems are written in C
<JamesMunns[m]>
adinack[m]: what
<JamesMunns[m]>
like, almost all of them are today
<JamesMunns[m]>
with like, a tiny fraction of Ada and C++ besides that
<adinack[m]>
bro i mean it is better if it was Rust
<JamesMunns[m]>
I do hope Rust will be used for that, starting soon, but like, Ferrous is shipping the first qualified compiler in October of this year, so it's not even an option yet.
<JamesMunns[m]>
there's a very long answer to that, but the short, mostly accurate answer is "you're allowed to use it to write safety critical software for things like cars and industrial machines and airplanes"
<adinack[m]>
gotcha
<adinack[m]>
JamesMunns[m]: i am really enjoying reading this
<adinack[m]>
you wrote this?
<JamesMunns[m]>
I wrote that, and the [follow up](https://ferrous-systems.com/blog/sealed-rust-the-plan/), though I'm no longer at Ferrous (I'm doing [my own thing](onevariable.com/) now), but they've done all the hard "follow through" work to make it happen :)
<adinack[m]>
i can't even click on "your own thing"
<adinack[m]>
so uh sevostyanov97 does that help? 🤣
<sevostyanov97[m]>
No :) But I expected this and really thanks to you for replies. I just want to transfer my project from C to Rust, but it's a library which has to be ported to MCU platforms our partners use. Unfortunately, now they use tms320f28004x from C2000 family. I don't like C2000. I've had some problems with porting the project to it even in C, e.g. C2000 has its specific C compiler and 16-bit byte.
<M9names[m]1>
The 16bit bytes are a hardware limitation though, not a software one. The DSP simply does not allow addressing memory in 8bit increments.
<M9names[m]1>
Rust support would not fix this.
<M9names[m]1>
* 16bit char is probably a more modern way to say this, since we've standardised on 8bit bytes
<M9names[m]1>
Condolences on needing to support this *and* other arch's at the same time, I've never had to do that. Sounds rough.
<sevostyanov97[m]>
I'm not going to fix 16-bit bytes (or char) using Rust, I know it's the hardware feature. I just want to use Rust in the project for interest, no more.
<sevostyanov97[m]>
<M9names[m]1> "Condolences on needing to..." <- Fortunately, it's fully software-based library with no hardware use 😄
<GrantM11235[m]>
You could port a C wasm runtime to your platform and then compile your rust code to wasm. Someone did that to "run" rust code on an 8051 or something. It's probably not the most practical or efficient thing, but it sounds fun
vrakaslabs[m] has joined #rust-embedded
<vrakaslabs[m]>
<dirbaio[m]> "yeah but can multi-ghz signals..." <- No, finding a relay to do this would be very challenging.
<vrakaslabs[m]>
There are parts that do this, analog 2:1 differential mux ICs that are specifically designed for 10Gbe and PCIe, DP and the like. If I recall I used one from TI.
<Emre[m]>
Hello everyone. I am currently doing an internship and I have run into a problem on a certain issue. However, before asking my engineer, I want to try on my own and seek help from you esteemed colleagues who work on embedded systems.
<Emre[m]>
I am using the nRF52840-DK board. I want to read 8 kilobytes of data from the Flash memory. How can I achieve this? For now, I am trying to proceed based on the flash_shell example.
<Emre[m]>
I extend my thanks in advance for your assistance. Have a great day.
<K900>
Well, what have you tried?
<K900>
What doesn't work?
<Emre[m]>
I'm afraid not. Currently, I haven't been able to do anything.
<Emre[m]>
I need to incorporate something into the main function that reads this data and prints it to the command line.
<Lumpio->
Is it a standard SPI flash or
<Emre[m]>
NOR flash
<Lumpio->
But is it hooked up via SPI or what
<Lumpio->
I mean probably is
<Lumpio->
The internet would suggest it is a QSPI flash, so either SPI or QSPI would work I presume
<Lumpio->
It doesn't exactly say _what_ chip it is but SPI flash chips are fairly standard
<Lumpio->
There might be a schematic available with the exact part number, but it'll probably work with a standard SPI flash driver. Probably.
marmrt[m] has joined #rust-embedded
<marmrt[m]>
<Emre[m]> "Hello everyone. I am currently..." <- Just ask your supervisor. They will know much more about the issue you than we do. They're also paid to help you.
<Lumpio->
Personally I'd start by looking up how to set up SPI on your specific chip, and then for a SPI flash driver crate which I'm sure already exists
<marmrt[m]>
marmrt[m]: My point is that I was once an intern who tried to solve my problems on my own instead of bothering my colleagues and that is the wrong approach.
<marmrt[m]>
Maybe you can figure this out with half a day's work and our assistance, but if you talk with your supervisor you'll have a way forward in 10 minutes.
<Lumpio->
Eh, google for 15 minutes before asking a coworker
<Lumpio->
Although in this case it's probably not a 15 minute fix on their own, since it sounds like they might not have used peripherals like this before.
<dirbaio[m]>
Emre: there's 2 possible flashes you can use: there's the internal flash in the nrf52840 which is 1MB, and there's the MX25R64 which is an 8mb external QSPI flash
<dirbaio[m]>
that's assuming you want to use Rust of course. If you want to use Zephyr you'll have better luck asking on their Discord or github or perhaps the Nordic DevZone. This chat is about embedded Rust.
<mameluc[m]>
I think I understand why my RTC doesn't wake the device from stop2 now
<mameluc[m]>
I have set up the interrupt and embassy_stm32::interrupt::RTC_WKUP.enable();
<mameluc[m]>
but this is NVIC I think, I should get EXTI set up instead
<dirbaio[m]>
oh wtf
<mameluc[m]>
but RTC should have "wake up capabillity"
<mameluc[m]>
so it should be fine without NVID or EXTI
<dirbaio[m]>
maybe it's referring to the "high" exti lines?
<dirbaio[m]>
exti lines 0-15 are for GPIO
<dirbaio[m]>
but lines 16+ are wired to random stuff inside the chip, perhaps RTC wakeup is one of them?
<mameluc[m]>
might be, I think I read somewhere that 22 should be it. I have to find it again
<mameluc[m]>
NVIC 22 is "EXTI line [9:5] interrupt through EXTI[9:5]"
<mameluc[m]>
EXTI 20 is RTC wakeup interrupt
<mameluc[m]>
EXTI event mask register (EXTI_EMR1)
<mameluc[m]>
Bit 20 EM20: wakeup with event generation mask on event input 20
<mameluc[m]>
I guess this is what I want
<dirbaio[m]>
yep, that
<mameluc[m]>
so NVIC is not needed I guess
<mameluc[m]>
tadaaa 📯
<mameluc[m]>
RTFM as usual
<mameluc[m]>
but why are there 5 layers of write protection and 3 and a half thing called interrupt. I am sure it makes sense to somebody with a longer beard
<dirbaio[m]>
you're not alone, it doesn't make sense
<dirbaio[m]>
it's ST you're dealing with
<dirbaio[m]>
¯\_(ツ)_/¯
<mameluc[m]>
just ST things. I am sure it makes sense to protect stuff like RTC from tampering and there is this whole VBAT domain to consider
<mameluc[m]>
Id love to have a "dumb bit" to toggle for devs like me
<mameluc[m]>
now tha LSE is "bricked" on one of my modules but not on the other
<mameluc[m]>
probably not bricked but locked somehow
wassasin[m] has joined #rust-embedded
<wassasin[m]>
All that stuff is implemented separately in VLSI and the Cortex-M unit with NVIC is just a small part of the entire thing
<mameluc[m]>
I am not familiar enough with what is cortex-m and what is just chip specific. NVIC is a cortex-m thing right? I should read more
lsc0x80[m] has joined #rust-embedded
<lsc0x80[m]>
can i program UAV with Rust?
<K900>
As in drone? Yes, sure
<K900>
I know some people that are doing that
<JamesMunns[m]>
<mameluc[m]> "I am not familiar enough with..." <- Yeah, NVIC is the "Nested Vectored Interrupt Controller", all Cortex-M chips share the same main NVIC functionality, though there's a little variance between like a Cortex-M0 and M7 (number of priority levels, some stuff is 3/4/7+ specific), but the main functionality is the same on all Cortex-M devices
<mameluc[m]>
thanks
<JamesMunns[m]>
it's a little complicated, compared to "old school" basic interrupt controllers, or even things like the PLIC on RISC-V, but has the benefit that it's "standard", unlike on RISC-V where you have more flexibility (and many different chips handle interrupts, particularly peripheral interrupts, fairly differently)
<JamesMunns[m]>
that being said, it's a very neat thing, and worth learning a bit about :)
<dirbaio[m]>
issue is ST saying "sure NVIC is fancy, but we won't use for wakeups and do our own thing thanks"
<mameluc[m]>
is EXTI an ST thing?
<JamesMunns[m]>
mameluc[m]: yep
<mameluc[m]>
its not that much better in pic32 land iirc. I was very confused but it was also my first 32-bit mcu and their tools are a mess
<mameluc[m]>
felt like you could do almost the whole firmware in hardware if that makes sense. events, triggers, DMA, on and on
<dirbaio[m]>
I mean it makes sense, they probably do it so that they can turn off NVIC itself on stop
<mameluc[m]>
that makes sense
<mameluc[m]>
but I don't understand why the interrupt from the peripheral doesn't wake the CPU
<mameluc[m]>
without any EXTI or NVIC, there is even a mechanism for clearing the flag in hardware
<dirbaio[m]>
because NVIC is off
<dirbaio[m]>
* NVIC is also off
<mameluc[m]>
but it says "external interrupts or peripherals with wake up capability"
<mameluc[m]>
anyway I am happy I got it to work
<JamesMunns[m]>
yeah, so there's usually "light sleep", where the core is *mostly* off, but any interrupt can wake it up. Then there's "deep sleep", where even more stuff is turned off (like the NVIC), so it can't wake you if it's off
<dirbaio[m]>
I think "peripheral with wakeup capability" means "peripheral that's wired to an EXTI line and can therefore be used to wakeup the chip through EXTI"
<JamesMunns[m]>
the reason they do that is "light sleep" might be say, 50uA of current, while "deep sleep" might be like 5uA of current
<JamesMunns[m]>
which are both small numbers, but if you want 5 years of battery life on a coin battery, you're willing to handle the annoyance to get 1/10th of the power usage (which adds up over a long time)
<dirbaio[m]>
it's a bit of ST sucking too, though
<dirbaio[m]>
nRF's go to 3uA sleep and all wakeups still go through the plain old NVIC 🤷
<JamesMunns[m]>
yeah, fair :D
<JamesMunns[m]>
but you can get like super bespoke PICs and stuff that hang out in nA of current in their deepest sleep modes
<dirbaio[m]>
I think they must've heavily modified it though, vs ST decided to keep NVIC as-is and add their own thing (?)
<JamesMunns[m]>
yeah, no idea the implementation details there.
<mameluc[m]>
hunting nanos are kind of fun. So many ways to draw less power
<mameluc[m]>
you know you are don when the current goes up on humid days
<JamesMunns[m]>
yeah, at that point, a lot of other very silly things become drastically drastically important, like what kind of pullups/pulldowns you have, or the gate leakage of transistors, or self-discharge of the batteries themselves, or passivation of the lithium cells
<JamesMunns[m]>
mameluc[m]: that too :D
<mameluc[m]>
yeah, buffer caps can draw a lot too bc they discharge
<JamesMunns[m]>
yep yep
<JamesMunns[m]>
death by 1000 papercuts
<mameluc[m]>
not that I am an expert but I like optimizing and seeing results. it is like a mini game
<adinack[m]>
<lsc0x80[m]> "can i program UAV with Rust?" <- talk to firefrommoonlight
likewise[m] has joined #rust-embedded
<likewise[m]>
Is there a Rust project that directly runs on top of the Linux kernel, a single binary multipurpose userspace init program?
<likewise[m]>
I remember there is one in C, cannot remember its name, that compiles statically against musl for IoT purpose.
<adinack[m]>
i am getting a duplicate symbol error immediately after adding use nrf_softdevice; to my code
<adinack[m]>
nvm lol i think some of the dependencies embassy uses, nrf-softdevice comes with so they overlapped
<JamesMunns[m]>
I think nrf-softdevice brings it's own "critical section" impl, and you need to use that (the softdevice REALLY doesn't like it when you turn *its* interrupts off)
<JamesMunns[m]>
s/it's/its/, s/*its*/_its_/
<adinack[m]>
ah yeah that makes sense
<adinack[m]>
i am running the *ble_bas_peripheral* example and the program seems to just freeze on the line `let sd = Softdevice::enable(&config);`
<adinack[m]>
is there maybe something specific i need to configure for the seeeduino?
<JamesMunns[m]>
Haven't tried, unfortunately, #embassy-rs:matrix.org is probably the best place to ask that tho. The nrf-softdevice also has a pretty extensive FAQ/troubleshooting section, last time I checked.
<adinack[m]>
oh i didn't realize that was a thing thanks
<adinack[m]>
thanks yeah i think i'm figuring it out
gussius[m] has joined #rust-embedded
<gussius[m]>
Hi All, Just wondering if someone could help me understand *Interrupt Service lines*, and what they are for... From the datasheet...
<gussius[m]>
> Each interrupt can be individually enabled by writing ‘1’ or disabled by writing ‘0’ to the corresponding bit in the interrupt enable register (IE). Each interrupt flag can be assigned to one of two interrupt service lines.
meptl[m] has quit [Quit: Idle timeout reached: 172800s]
IAmnesia[m] has quit [Quit: Idle timeout reached: 172800s]
Skill-ton has joined #rust-embedded
Skill-ton has quit [K-Lined]
danielb[m] has quit [Quit: Idle timeout reached: 172800s]