<re_irc>
<@abser:matrix.org> hey, guys, I'd found that svg
<re_irc>
<@abser:matrix.org> * svg2rust
<re_irc>
<@abser:matrix.org> * svg2rust, because of the https://github.com/topics/infineon?l=rust ,Automotive Safety and Cybersecurity: Infineon's AURIX™ TC3xx, TC4x, TRAVEO™ T2G & PSoC families of microcontrollers support Rust, I just want to say, really a great work.
<re_irc>
<@jamesmunns:beeper.com> I probably should be able to get faster, but I'm not doing any pipelining at all, and "load the entire ram in <1s" is probably fast enough for what I'm doing now :D
<re_irc>
<@halfbit:matrix.org> neat! why does that seem a lot faster than the typical debug probe
<re_irc>
<@halfbit:matrix.org> I don't feel like I can get nearly that fast with RTT
<re_irc>
<@jamesmunns:beeper.com> because I'm using USB directly instead of going via a debug probe
<re_irc>
<@jamesmunns:beeper.com> and I'm writing to RAM, and not flash
<re_irc>
<@jamesmunns:beeper.com> (so no erasing, which is the really slow part)
<re_irc>
<@halfbit:matrix.org> I get that, RTT is a also sram, but right the swd protocol just can't get that fast? I still haven't dug into the debug probe protocols nearly as much as I should I guess
<re_irc>
<@jamesmunns:beeper.com> ah yeah, I dunno how fast rtt can go, throughput wise. I know the probe-rs folks are looking at how to get the "RTT reading" logic closer to the debug probe itself, so you don't have to make as many host<->debugger round trips, which I think slows things down a lot.
<re_irc>
<@jamesmunns:beeper.com> (with rusty probe and such)
<re_irc>
<@halfbit:matrix.org> right that makes sense
<re_irc>
<@halfbit:matrix.org> like "read sram addr X" and then you have a whole round trip
<re_irc>
<@halfbit:matrix.org> to get maybe a word or whatever
<re_irc>
<@halfbit:matrix.org> or maybe some block, but still..
<re_irc>
<@jamesmunns:beeper.com> yeah, ns/us to read, then 1ms frame time lol
<re_irc>
<@jamesmunns:beeper.com> this does have round trips, though it batches 256 byte frames at a time, so it'll probably be something like 4-5 frames out, wait, 4-5 frames back
<re_irc>
<@halfbit:matrix.org> because I mean, as I understand it anyways, reading/writing random addresses on the SoC bus is basically what the probe lets you do
<re_irc>
<@halfbit:matrix.org> along with maybe some other stuff
<re_irc>
<@halfbit:matrix.org> e.g. set some hardware breaks, pull registers, yeah I dunno, like I said its something I should really read more about!
fabic has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Yeah, thanks to probe-rs, I know remarkably little about that :D
fabic_ has quit [Ping timeout: 255 seconds]
<re_irc>
<@jamesmunns:beeper.com> This work is for a little "recovery bootloader" that lets you load programs into RAM to set up the rest of the system.
<re_irc>
<@halfbit:matrix.org> ah nice
<re_irc>
<@jamesmunns:beeper.com> (and I'm loading programs into RAM so you can use it to pivot and load programs into flash without stalling the flash bus, which is usually a pain on most chips)
<re_irc>
<@ryankurte:matrix.org> ahh a classic programmer / bootloader misadventure that one eh
<re_irc>
<@jamesmunns:beeper.com> yeah, also for "hey usually the fun little scratch programs I wrote aren't persistent anyway, and 256KiB is enough for both program and program RAM, so why not make loading everything faster anyway"
<re_irc>
<@jamesmunns:beeper.com> (which is a trick from some of jorge's experiments that later became probe-run, tho that part didn't)
<re_irc>
<@ryankurte:matrix.org> you could get some more overhead in there with ghostfat if you didn't want a custom tool :-P but it's prolly better to just do usb
<re_irc>
<@jamesmunns:beeper.com> I have other plans for ghostfat :D
<re_irc>
<@halfbit:matrix.org> Is Jorge still pretty active? I haven't seen the sheer insane volume of stuff that I remember seeing early on
<re_irc>
<@halfbit:matrix.org> or is he off busy making checks like he should
<re_irc>
<@halfbit:matrix.org> :-)
<re_irc>
<@halfbit:matrix.org> or is he off busy making checks like he should with that talent
<re_irc>
<@ryankurte:matrix.org> most programmers work that way afaik? load up a flashstub that executes from ram then use that to transfer the app, tho i guess not at runtime
<re_irc>
<@jamesmunns:beeper.com> Last I heard, he is staying pretty busy at Ferrous, working on things (I'm out of the loop with that tho)
<re_irc>
<@jamesmunns:beeper.com> : yeah, that's how all the flash algo stuff works
fabic has quit [Ping timeout: 255 seconds]
<re_irc>
<@jamesmunns:beeper.com> little bb programs you shove in RAM to program the flash
fabic has joined #rust-embedded
<re_irc>
<@ryankurte:matrix.org> mmm i tripped and fixed some of the stub loading for esp32s a while back 😅 fortunately just the selection / loading not the stubs
<re_irc>
<@jamesmunns:beeper.com> eventually, I want to mess around with writing a PIC loader (if JP doesn't beat me to it first), and want to do things like use ghostfat to load dynamic modules. This is still all very far off tho lol
<re_irc>
<@jamesmunns:beeper.com> anyway, I'll share when I have things that are more than just ideas eventually :D
<re_irc>
<@jamesmunns:beeper.com> ( this is the project that I might end up "backing into" mnemos in one way or another)
<re_irc>
<@halfbit:matrix.org> seeing PIC just makes me think of microchip PIC, and I run to hide
<re_irc>
<@jamesmunns:beeper.com> :D
<re_irc>
<@jamesmunns:beeper.com> Position Independent Code
<re_irc>
<@ryankurte:matrix.org> ooh last i looked at it i discovered that LLVM doesn't really believe in PIC / likes to use non-relative addresses for data even when you ask it nicely...
<re_irc>
<@halfbit:matrix.org> I can't believe they are still making new PICs... dsPIC doesn't seem that old
<re_irc>
<@jamesmunns:beeper.com> ropi/rwpi doesn't work, but "real PIC" does, AFAIK
<re_irc>
<@jamesmunns:beeper.com> the latter needs an actual dynamic loader
<re_irc>
<@ryankurte:matrix.org> right right, PIC with an elf-loader or equivalent should be workable
<re_irc>
<@jamesmunns:beeper.com> the former uses r9 as an "offset register" to remove the need for offset table applications
<re_irc>
<@halfbit:matrix.org> "dsPIC, now 100MHz with DSP MAC instructions"
<re_irc>
<@ryankurte:matrix.org> i did expect rwpi to work, tho?
<re_irc>
<@jamesmunns:beeper.com> : atm my plan is to pre-process the elf file, pull the relocations and the firmware image into a postcard format, so you can just apply the changes at load time without doing full elf parsing
<re_irc>
<@ryankurte:matrix.org> > "dsPIC, now 100MHz with DSP MAC instructions"
<re_irc>
@halfbit -area damage effect-
<re_irc>
<@halfbit:matrix.org> position independent code seems really useful, I mean once you have that you could more or less have a spawn process type function along with mmu/tlb fun?
<re_irc>
<@ryankurte:matrix.org> * area damage effect
<re_irc>
<@halfbit:matrix.org> what does that even entail really?
<re_irc>
<@halfbit:matrix.org> load elf, elf has compile options setup to have addresses moveable in some way?
<re_irc>
<@halfbit:matrix.org> or offset?
<re_irc>
<@ryankurte:matrix.org> you can already do this without PIC provided you only have one app because you can put it in a consistent place, it mostly means you can move apps round (or have more than one) and relocate calls back to the OS
<re_irc>
<@ryankurte:matrix.org> +data and
<re_irc>
<@jamesmunns:beeper.com> it's a list of "make changes to these addresses with the base address of your choosing"
<re_irc>
<@halfbit:matrix.org> oh interesting
<re_irc>
<@jamesmunns:beeper.com> so like, an array of addresses you need to patch
<re_irc>
<@halfbit:matrix.org> yeah that makes sense
<re_irc>
<@halfbit:matrix.org> that's stored as some elf metadata somewhere?
<re_irc>
<@jamesmunns:beeper.com> halfbit: Yeah, there are special elf metadata sections
<re_irc>
<@jamesmunns:beeper.com> He builds... a lot of things from scratch we don't necessarily need to (which is good for teaching!), but especially if I preprocess on desktop, I can use existing elf parsers, and just spit out the "relocation todo list" in a fairly dense postcard format, where you just need to apply changes as you are loading to RAM (or flash)
<re_irc>
<@halfbit:matrix.org> isn't it crazy intel has a syscall instruction, its crazy to me
<re_irc>
<@ryankurte:matrix.org> halfbit: is it? i kindof think of computing as three(million) syscalls in a trenchcoat?
<re_irc>
<@ryankurte:matrix.org> at least in the world of OS'
<re_irc>
<@halfbit:matrix.org> true facts, but that it became such a thing that the "throw some stuff in regsiters and fire a soft interrupt" became a bottleneck worth getting a custom op for
<re_irc>
<@halfbit:matrix.org> its cool, and crazy
<re_irc>
<@halfbit:matrix.org> true facts, but that it became such a thing that the "throw some stuff in registers and fire a soft interrupt" became a bottleneck worth getting a custom op for
<re_irc>
<@ryankurte:matrix.org> huh, true. i guess if you've got interrupt infrastructure in the processor already...
<re_irc>
<@ryankurte:matrix.org> when you start needing to switch rings (or whatever they were called in time long past) idk how else you'd do it really
<re_irc>
<@ryankurte:matrix.org> carcinisation but for interrupts
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> Has anyone else here moved to KiCAD 7 and gotten CI to work with that? Previously I've been using the "setsoft" images, but I can't find anything for v7
fabic has quit [Ping timeout: 248 seconds]
<re_irc>
<@thejpster:matrix.org> I think there’s a bug that kibot needs fixing
<re_irc>
<@thejpster:matrix.org> So, no, I’m on 6. But maybe I can throw away kibot and use the CLI now? I might have to reimplement the JLCPCB rotation thing though. And I don’t know if the CLI can make an ibom
dc740 has joined #rust-embedded
<re_irc>
<@korken89:matrix.org> I tried the CLI, but it does not support ERC / DRC AFAICT
<re_irc>
<@thejpster:matrix.org> Looong list of things that needed fixing
<re_irc>
<@thejpster:matrix.org> As always, wait for .1
<re_irc>
<@thejpster:matrix.org> Although it sucks because they won’t fix 6 anymore, so if you have a bug in 6, tough
<re_irc>
<@thejpster:matrix.org> It’s like Ubuntu 20.04 going out of support the day 22.04 drops.
<re_irc>
<@mathias_koch:matrix.org> Hi! I know this is a bit off-topic for this room, but is anyone here an expert in yocto/bitbake by any chance? :p
fabic has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> : "ekv", this can be used as alternative to LittleFS? I guess compared to a filesystem you always have to read/write whole records, not just parts of it.
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@mehmet:grusbv.com> Lately I have checked mybinary and realized that there are a lot of host development PATHs in it.
<re_irc>
<@mehmet:grusbv.com> Even, I guess for debug = 0
<re_irc>
<@sourcebox:matrix.org> : Really all? They're talking about specific ones with side effects.
<re_irc>
<@thejpster:matrix.org> : What memory mapped peripheral register doesn’t have side effects?
<re_irc>
<@thejpster:matrix.org> A memory location with no side effects is just memory.
<re_irc>
<@sourcebox:matrix.org> I guess their definition of side effects is somewhat different.
<re_irc>
<@thejpster:matrix.org> They are at least proposing it is opt-in.
<re_irc>
<@thejpster:matrix.org> But I’m minded to agree. Hardware is a big ball of mutable state and there isn’t really enough info in an svd file to say what is always on and what is sometimes not ok.
<re_irc>
<@thejpster:matrix.org> Like writing to the UART with the clock and power still gated. Boom. Hard fault.
<re_irc>
<@sourcebox:matrix.org> : That's likely what they mean.
<re_irc>
<@sourcebox:matrix.org> It's btw. not UB, it will crash 100% of the time ;-)
<re_irc>
<@cloufisz:matrix.org> Are there any resources/tips on how to start with Emulating Embedded Software with QEMU for Rust Programs?
<re_irc>
Or is it to just read qemu docs?
<re_irc>
<@dngrs:matrix.org> There's an example in the embedded book I think?
fabic has joined #rust-embedded
<re_irc>
<@jannic:matrix.org> : The argument has some merit, but with the same reasoning, one could say that filesystem access should be unsafe in std rust. Remember this hilarious example where transmute was implemented without unsafe rust, by accessing "/proc/self/mem"?
<re_irc>
<@adamgreig:matrix.org> : At least on stm32 this just doesn't do anything/the write is ignored, though I'm sure there's some where this could cause a fault... but a fault isn't ub or memory unsafe
<re_irc>
<@adamgreig:matrix.org> I think there's merit in Embassy's approach of marking all pac access unsafe and simultaneously deleting the owned singletons, and also I think even with owned singletons some fields possibly should be unsafe (like DMA memory addresses), but for almost all mmio it's hard to say how it's ub, and the filesystem example is a reasonable counterpoint to making DMA unsafe too, it's basically the same concept
<re_irc>
<@adamgreig:matrix.org> (I mean that with DMA it's clear how it might UB, but with most other peripherals I think it's usually not ub even if it's possibly not what you wanted)
<re_irc>
<@jannic:matrix.org> Note that I'm not arguing against making pac access unsafe. I'm just opposing the reasoning "this API can somehow cause UB" ⇒ "it must be "unsafe"". IMHO we must be careful defining the guarantees safe code can provide. And it would be difficult, if even possible, to define a sufficiently powerful safe API which can guarantee "no UB whatsoever".
<re_irc>
<@adamgreig:matrix.org> Though keeping soundness holes to a minimum is probably wise, eg I wouldn't want to just allow global unsynchronized safe access to all the mmio
<re_irc>
<@adamgreig:matrix.org> Because that is asking for trouble with read-modify-write racing with interrupts
<re_irc>
<@adamgreig:matrix.org> (on the other hand, if you have a platform that could provide that atomically... 🤔
<re_irc>
<@thejpster:matrix.org> The ticket implies SVD has a flag that can be set on registers and the proposal is to only marked the flagged ones as unsafe. And then only if you set an option at code Gen time.
<re_irc>
<@thejpster:matrix.org> Which seems reasonable.
<re_irc>
<@thejpster:matrix.org> Then it’s not it’s choosing what is unsafe, it’s the SVD author.
<re_irc>
<@thejpster:matrix.org> * us
<re_irc>
<@adamgreig:matrix.org> I wonder what flag they're referring to though, all I can think of is readAction which is for things like "reading this field causes it to reset to 0"
<re_irc>
<@adamgreig:matrix.org> And doesn't really have any impact on memory safety or cover things like dma
<re_irc>
<@jannic:matrix.org> One reason to make register access "unsafe" by default is that those mmio registers were never designed to provide a safe API. So the comparison with FFI made in the ticket is valid.
<re_irc>
And it's often possible to define as safe API on top if that, which would be the API used by actual application code. (That's also a difference compared to the "std::fs" issue mentioned: There, it's not obvious how a safer API could look at all.)
<re_irc>
<@adamgreig:matrix.org> I guess it's worth remembering that svd2rust only allows safe access when a writeConstraint or enuneratedValues is present for a field , too
<re_irc>
<@adamgreig:matrix.org> So currently DMA fields will generally not be safe to write, and if specific peripheral mmio shouldn't be safe that's also easily avoided, but it does somewhat overload the semantics of those attributes
<re_irc>
<@adamgreig:matrix.org> (typically, at least so far, manufacturers rarely if ever specified those attributes, so most PACs required unsafe for all access)
<re_irc>
<@adamgreig:matrix.org> (except for those fields specifically and manually patched by the PAC author)
<re_irc>
<@jannic:matrix.org> For MMIO, read access can also have side effects, like resetting flags on read. And while I can't think of an example right now where the read itself would cause UB, it surely makes defining a safe wrapper much harder if the code must consider concurrent read accesses at any time.
<re_irc>
<@adamgreig:matrix.org> Well it needn't - the current owned singleton model prohibits it
<re_irc>
<@jannic:matrix.org> Ok, sure. I was thinking of the embassy variant without owned singletons.
<re_irc>
<@adamgreig:matrix.org> In that case all pac access is unsafe and the HAL is responsible for the safe wrapper, so should still be able to handle the read side effects as well as anything else?
<re_irc>
<@jannic:matrix.org> With owned singletons, I think it doesn't matter much, practically speaking, whether accessing the PAC is unsafe or not. The code accessing the registers would be localized to some kind of HAL anyways, and whether the code inside the HAL needs to use "unsafe" blocks or not doesn't change much.
<re_irc>
<@jannic:matrix.org> So the reasonable choices are what svd2rust does now (owned singletons & access without unsafe), and what embassy does (everybody can access the pac, but it's "unsafe").
<re_irc>
<@jannic:matrix.org> At least that's how I understand it.
<re_irc>
<@adamgreig:matrix.org> If you're happy using unsafe for all pac access the the owned singletons are pointless, you can already unsafely access everything without them
<re_irc>
<@adamgreig:matrix.org> Right, I think we are violently agreeing :p
<re_irc>
<@jannic:matrix.org> And I've seen and written a lot of code were the owned singletons are circumvented. Which is probably a sign that the embassy approach is closer to reality.
<re_irc>
<@jamesmunns:beeper.com> : You're checking the bin, not the elf, yeah? If so, you could still end up with paths if you use panic. I think defmt provides its own panic/unwrap macros, which might help, tho your deps may not use it.
<re_irc>
<@mehmet:grusbv.com> : yep, the bin. I feel that half of the ro sections are long paths
<re_irc>
<@mehmet:grusbv.com> That might be it.
<re_irc>
<@mehmet:grusbv.com> Like it will save every possible path that might have a panic, right?
<re_irc>
<@jamesmunns:beeper.com> I'd guess if youre surprised they are there, they are part of panic formatting.
<re_irc>
<@jamesmunns:beeper.com> Yeppers
<re_irc>
<@jamesmunns:beeper.com> You could try the panic immediately Abort trick to confirm they dissapear
<re_irc>
<@mehmet:grusbv.com> So without defmt panic handlers, they won't be?
<re_irc>
<@jamesmunns:beeper.com> * disappear
<re_irc>
<@mehmet:grusbv.com> Let me see
<re_irc>
<@jamesmunns:beeper.com> : Too many double negatives, not sure what you mean :)
<re_irc>
<@jamesmunns:beeper.com> And by this I mean the nightly build-std option
<re_irc>
<@mehmet:grusbv.com> : Argh yes. So if defmt does not handle the panics, we won't have these paths in the bin.
<re_irc>
<@mehmet:grusbv.com> this std is NOT std lib right?
<re_irc>
<@mehmet:grusbv.com> more like, std config of cargo
<re_irc>
<@mehmet:grusbv.com> Let's try
<re_irc>
<@jamesmunns:beeper.com> Uhh, if you use "defmt::panic!()" and "defmt::unwrap" instead of regular panic/unwrap, it might remove the strings from the binary, because then it is deferred
<re_irc>
<@jamesmunns:beeper.com> : build std is for rebuild core/alloc/std at build time.
<re_irc>
<@jamesmunns:beeper.com> * rebuilding
<re_irc>
<@jamesmunns:beeper.com> But if you "regular panic" into the panic-probe handler, you are still passing a runtime string formatter to the defmt handler, so the strings still exist at runtime, if that makes sense.
<re_irc>
<@mehmet:grusbv.com> Hmm.. There were some crates that I made "independent" from the embedded ecosystem.
<re_irc>
<@mehmet:grusbv.com> They use core panic
<re_irc>
<@jamesmunns:beeper.com> Yeah, if those have panics, not much you can do sadly.
<re_irc>
<@mehmet:grusbv.com> : I added these two lines, no avail.
<re_irc>
<@jamesmunns:beeper.com> Building with optimizations, right?
<re_irc>
<@mehmet:grusbv.com> but this is a really good pointer.
<re_irc>
<@mehmet:grusbv.com> yes, opt 's'
<re_irc>
<@jamesmunns:beeper.com> You might need pia+opt+LTO to really smash things out
<re_irc>
<@mehmet:grusbv.com> okay let me do that
<re_irc>
<@mehmet:grusbv.com> And add these two lines to the crates that I have mentioned
<re_irc>
<@mehmet:grusbv.com> I just added them to the one that is being compiled as bin
<re_irc>
<@jamesmunns:beeper.com> But if you have that, and they are still there, those strings might be something else?
<re_irc>
<@jamesmunns:beeper.com> Yeah it only is needed in the bin crate
<re_irc>
<@jamesmunns:beeper.com> And you have to be using a nightly compiler
<re_irc>
<@mehmet:grusbv.com> yep
<re_irc>
<@jamesmunns:beeper.com> Otherwise those flags are ignored
<re_irc>
<@dirbaio:matrix.org> : yeah, it's a database, not a filesystem. If you have many small keys, a DB will perform better. If you have few big files, a FS is better.
<re_irc>
<@sourcebox:matrix.org> : I have used LittleFS in a recent project, there are files of about 2k each. These consist of a header with metadata and the binary content. The header is only 32 bytes or so and should be read separately. So the question is if it makes sense to store the metadata as separate key with ekv. What would that mean regarding storage size? In the readme, you say a page must be erased for each entry. I think what you mean is a...
<re_irc>
... sector (like 4k), because that's the granularity of erase in NOR flash.
<re_irc>
<@dirbaio:matrix.org> > I think what you mean is a sector (like 4k), because that's the granularity of erase in NOR flash.
<re_irc>
Yes, what "ekv" calls "pages" some manufacturers call "sectors". it's the "erase block".
<re_irc>
<@dirbaio:matrix.org> > In the readme, you say a page must be erased for each entry.
<re_irc>
- If you open transaction, write 400 10-byte keys, commit -> that'll do only 1 4k erase
<re_irc>
it's a limitation of the implementation on write transactions. Say you got 4k pages.
<re_irc>
- If you repeat 400 times "open transaction, write one 10-byte key, commit" -> that'll do 400 4k erases
<re_irc>
<@sourcebox:matrix.org> : On SPI flash you typically have page/sector/block/chip. Don't know if these terms are specified in the JEDEC docs.
<re_irc>
<@dirbaio:matrix.org> I decided to call these "pages". Nordic calls them pages. 🤷
<re_irc>
Also an EKV page doesn't have to correspond to a flash sector, for example if your flash ahas 256byte sectors and you don't want to waste much space in page headers, you could make 1 EKV page = 16 flash sectors, so 4kb.
<re_irc>
<@dirbaio:matrix.org> if your "keys" are 2k then your max overhead is 2x, which is the same a regular FS would give you, so you're not impacted by this limitation much
<re_irc>
<@dirbaio:matrix.org> > The header is only 32 bytes or so and should be read separately. So the question is if it makes sense to store the metadata as separate key with ekv
<re_irc>
ekv reads whole pages, so it probably won't gain you much
<re_irc>
<@dirbaio:matrix.org> anyway, as your key size approaches the order of magnitude of the page size, a regular FS might perform better
<re_irc>
<@sourcebox:matrix.org> I would have to check that out because in the existing project, all entries are 16-bit keys and values whereas with ekv I would use serde with postcard.
<re_irc>
<@dirbaio:matrix.org> if your keys were larger, say 16k, i'd tell you to definitely use an FS, and not EKV
<re_irc>
<@dirbaio:matrix.org> 2k is kinda in the middle
<re_irc>
<@dirbaio:matrix.org> it'll definitely work
<re_irc>
<@sourcebox:matrix.org> Storing the metadata separately would take too much space because they're only 32 bytes written in separate transactions.
<re_irc>
<@dirbaio:matrix.org> but if you want the best perf possible, try both EKV and an FS and compare benchmarks 😅
<re_irc>
<@dirbaio:matrix.org> you can do multiple writes in the same transaction
<re_irc>
<@sourcebox:matrix.org> The business logic does not allow that.
<re_irc>
<@dirbaio:matrix.org> and once the writes are committed, they can get compacted into the same pages as the other keys
<re_irc>
<@dirbaio:matrix.org> so it's not like you pay the space overhead permanently, it's just perf overhead at the time of writing
<re_irc>
<@sourcebox:matrix.org> I'm currently evaluating possible solutions, the mentioned project using LittleFS is in C++, so with Rust I would have to use a wrapper like https://github.com/nickray/littlefs2 or a different FS.
<re_irc>
<@nickray:solokeys.com> This is now maintained under trussed-dev/littlefs2 FYI
Dr_Who has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> : Yeah, seen this already. Have to update my links.
dc740 has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> : And ST calls them either depending on MCU variant!
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@dirbaio:matrix.org> classic ST
Socke has quit [Ping timeout: 276 seconds]
Socke has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
<re_irc>
<@yandrik:matrix.org> How do I set the interrupt priority manually on a NRF52 using the non-Embassy HAL?
<re_irc>
<@diondokter:matrix.org> Or use a framework like RTIC that does it for you
<re_irc>
<@yandrik:matrix.org> Can I set the priority of an interrupt in RTIC without creating a software task for it? Or,, is it fine to create a software task in RTIC and then triggering the associated interrupt from the outside?
<re_irc>
<@yandrik:matrix.org> Can I set the priority of an interrupt in RTIC without creating a software task for it? Or, is it fine to create a software task in RTIC and then triggering the associated interrupt from the outside?
<re_irc>
(edit: grammar)
<re_irc>
<@diondokter:matrix.org> I don't know what you mean with triggering a software task from the outside
<re_irc>
<@diondokter:matrix.org> You can create 'hardware' tasks and trigger those in theory. And you can set the priority on them
<re_irc>
<@yandrik:matrix.org> My bad, I had something else in my head, something that certainly won't work. The hardware task approach is exactly what I'm looking for, thanks for the help!
thomas25 has joined #rust-embedded
<re_irc>
<@diondokter:matrix.org> yandrik: Though I believe it's currently possible to call the spawn function from outside of the RTIC app module. Could try that as well. Should be less hacky
<re_irc>
<@yandrik:matrix.org> I didn't know that, thanks for the tip!
bjc has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> any riscv/e310x peeps around to help with https://github.com/riscv-rust/e310x/pull/28 ? I'd like to update the PAC for use with new svd2rust but it's a big change and would like more 👀 on it
rektide_ is now known as rektide
<re_irc>
<@romancardenas:matrix.org> I can check it this weekend, I think