<re_irc>
< (@CyReVolt:matrix.org)> yup e.g. Minicom wouldn't do it, but you can configure it to auto newline
<re_irc>
< (@CyReVolt:matrix.org)> anyway, I got the counter interrupt to work, thank you so much!
<re_irc>
< (@CyReVolt:matrix.org)> just had to hack in the pac because it marked the interrupt flag read-only - while it's actually writable (how else would one clear it ^^)
<re_irc>
< (@CyReVolt:matrix.org)> so the pac got some PRs now 🥳
<re_irc>
< (@9names:matrix.org)> Picocom has a bunch of options for handling line-endings
<re_irc>
< (@9names:matrix.org)> Yeah I don't really understand what andelf is doing with all these PACs, I put in pr's to fix up the bl702 one because it wasn't really usable...
<re_irc>
< (@CyReVolt:matrix.org)> addendum: _and_ enable the RISC-V interrupts ☝
<re_irc>
< (@CyReVolt:matrix.org)> : maybe andelf also just got started, trying their best...
<re_irc>
< (@9names:matrix.org)> They've been on GitHub since 2009, contributing to rust projects since 2014, embedded rust since 2020...
<re_irc>
< (@CyReVolt:matrix.org)> : oh cool stuff, you started a HAL for the BL702 :)
<re_irc>
< (@CyReVolt:matrix.org)> One of my next targets is the BL808, already have two and will get a handful more soon.
<re_irc>
< (@9names:matrix.org)> I've got some ordered, no idea when they'll turn up.
<re_irc>
The peripherals on bl602/bl702 are basically the same, I expect bl808 will be too. Would be nice to have one HAL covering all 3.
<re_irc>
You're going to have basically 3 HALs in one for bl808 anyway, one for each core.
<re_irc>
< (@9names:matrix.org)> Can rust even target rv32e? I haven't looked...
dc740 has quit [Remote host closed the connection]
<re_irc>
< (@CyReVolt:matrix.org)> > RV32E base integer instruction set, which is a reduced version of RV32I designed for embedded systems. The only change is to reduce the number of integer registers to 16.
<re_irc>
well...
<re_irc>
< (@CyReVolt:matrix.org)> if that's not in Rust yet, it should be simple to add
<re_irc>
< (@jamesmunns:beeper.com)> If rust doesn't have a target for it already, you can make a custom target json and use build-std with nightly
<re_irc>
< (@CyReVolt:matrix.org)> * that shall do?
<re_irc>
< (@jamesmunns:beeper.com)> Oh neat, I didn't know target features covered that already
<re_irc>
< (@jamesmunns:beeper.com)> You could probably add those to your rustflags in your .cargo/config file so you don't have to keep re-entering the cli flags
<re_irc>
< (@jamesmunns:beeper.com)> For the BL stuff, it's probably worth pinging about it, I think I've seen them working on those targets?
<re_irc>
< (@stillinbeta:matrix.org)> hey all, I'm working on adding stm32g0b1 support to stm32g0xx_hal. A thing I've noticed is that in more than one place, stm32g0b1 has a set of alternative pins, i.e. https://docs.rs/stm32g0/0.15.1/stm32g0/stm32g0c1/usart1/struct.RegisterBlock.html#method.cr1_fifo_enabled, where another device might have a plain field:...
<re_irc>
< (@korken89:matrix.org)> : Global static mutable things are generally not allowed in Rust as you will have multiple mutable references which is UB
<re_irc>
< (@korken89:matrix.org)> You would need to wrap it in some kind of lock that prevents this
<re_irc>
< (@korken89:matrix.org)> Either manual mutexes, or using primitives in OSes such as RTIC or embassy
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
< (@chemicstry:matrix.org)> any recommendations for a filesystem lib for sd card? I was looking at "littlefs2", but was wondering if there is something without a C dependency
tokomak has joined #rust-embedded
<re_irc>
< (@anand21:matrix.org)> : Yeah, We are aware that Global static mutable must be avoided.
<re_irc>
As we have only single threaded application, We need to know how can we make this work?
<re_irc>
< (@anand21:matrix.org)> Yeah we will wrap it in Mutex.
<re_irc>
We would like to know
<re_irc>
How do we instantiate the timer peripheral of HAL as static global mutable ?
<re_irc>
< (@anand21:matrix.org)> : Yeah we will wrap it in Mutex.
<re_irc>
how do we instantiate the timer peripheral of HAL as global static mutable?
<re_irc>
We would like to know,
<re_irc>
< (@nihal.pasham:matrix.org)> : are you looking for a specific filesystem? If "fat" is all you need, I'd recommend "[fatfs](https://github.com/rafalh/rust-fatfs)". Its written in pure rust and "no_std" ready
<re_irc>
< (@chemicstry:matrix.org)> : I'm open for options. I don't like FAT as it is prone to corruption on power loss, which is a possibility in my application. I'm okay with some data loss, but if I understand it correctly FAT can experience a total fs failure in case of power loss
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
< (@nihal.pasham:matrix.org)> cant confirm whether "fat"'s design makes it susceptible to (complete) failure on power loss. But yes, writes to fat partitions or table can be corrupted in the event of a power loss. However, fat's design uses a backup, so we'd probably end-up with backup (mostly)
<re_irc>
< (@nihal.pasham:matrix.org)> * backup (fat-table), so we'd probably end-up with backup (mostly) and some data loss
<re_irc>
< (@dirbaio:matrix.org)> : as an alternative, embassy-stm32 already supports stm32g0b1
causal has quit [Ping timeout: 256 seconds]
causal has joined #rust-embedded
<re_irc>
< (@jamesmunns:beeper.com)> : This might also be worth asking in the #stm32-rs:matrix.org (https://matrix.to/#/#stm32-rs:matrix.org) channel!
<re_irc>
< (@thejpster:matrix.org)> So I wrote embedded-sdmmc as a pure Rust SD card and FAT library.
<re_irc>
< (@thejpster:matrix.org)> Probably not as complete as fatfs though. Not sure it existed when I started.
<re_irc>
< (@thejpster:matrix.org)> But yes, FAT can crap itself because you are doing a read-modify-write on a 32-bit value inside a 512 byte sector to make a linked-list of sectors. And no-one ever really bothers with the backup FAT.
<re_irc>
< (@thejpster:matrix.org)> * clusters (a cluster is a consecutive list of sectors, typically 4K or 8K or something).
bjc has quit [Remote host closed the connection]
<re_irc>
< (@thejpster:matrix.org)> If you pre-allocate the files, and only write to sectors within clusters which are with the existing file, it's much harder to corrupt anything.
<re_irc>
< (@thejpster:matrix.org)> So, a 1GB raw disk image stored as "harddisk.img" stored on a FAT32 SD card is probably fine - provided the image itself is of a journalled file system.
<re_irc>
<Stephen D> I'm having a strange issue where modifying a timer's period seems to cause it to stop working eventually. This is on an stm32f411
<re_irc>
fn main() -> ! {
<re_irc>
let dp = pac::Peripherals::take().unwrap();
<re_irc>
let buzzer = dp.GPIOA.split().pa0.into_alternate();
tokomak has quit [Read error: Connection reset by peer]
bjc has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> hi room, meeting time again! agenda is https://hackmd.io/IQ86oyJhQNWbJqaApHo97A, please add anything you'd like to announce or discuss and we'll start in 5 mins :)
<re_irc>
< (@adamgreig:matrix.org)> couple of quick release announcements, we released critical-section 0.2.8 after last week's discussion, it causes some breakage for people still using critical-section 0.2 which includes defmt-rtt 0.3 and heapless, so be on the lookout for that...
<re_irc>
< (@adamgreig:matrix.org)> we should probably get something on the wg blog too
<re_irc>
< (@adamgreig:matrix.org)> but besides that anticipated breakage, it seems to otherwise be working ok?
<re_irc>
< (@adamgreig:matrix.org)> and, aarch64-cpu (was cortex-a) released 0.9.1, enabling building on stable
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> there's also some recent issue activity that may be worth highlighting, one for suggesting some new methods on embedded-can's "Id" type to turn it into a u32: https://github.com/rust-embedded/embedded-hal/pull/428
<re_irc>
< (@adamgreig:matrix.org)> on alloc-cortex-m, I think we discussed at the time that it is no longer cortex-m specific really, so it might make more sense for either the upstream linked_list_allocator crate to gain a critical-section feature and provide a global alloc, or possibly to rename the crate to something like embedded-alloc, and then use critical-section (and maybe in the future change the allocator algorithm)
<re_irc>
< (@dirbaio:matrix.org)> "embedded-alloc" sounds great
<re_irc>
< (@adamgreig:matrix.org)> linked-list-allocator is actively maintained and last published 2 months ago, but i don't know if they'd be interested in using critical-section
<re_irc>
< (@adamgreig:matrix.org)> yea, that might be a nice way to provide an easy to use "here's an allocator for your embedded system" crate with our "best practices" ie critical-section and whatever algorithm ready to go
<re_irc>
< (@dirbaio:matrix.org)> I guess it makes sense for LLA to be "just the algorithm", and have"embedded-alloc" as the "glue"
<re_irc>
< (@adamgreig:matrix.org)> yea
<re_irc>
< (@adamgreig:matrix.org)> well, maybe update that PR to rename the crate and once merged I can rename the repo? we can publish a deprecation readme to alloc-cortex-m afterwards?
<re_irc>
< (@eldruin:matrix.org)> I think separate PRs for that sound easier to review. the will be a high amount of churn for the rename but anyway, just my 2c
<re_irc>
< (@adamgreig:matrix.org)> the current PR is only 8 lines diff, so including the rename probably won't add much?
<re_irc>
< (@adamgreig:matrix.org)> the rename sort of goes along with this PR, because otherwise it's still cortex-m specific
<re_irc>
< (@adamgreig:matrix.org)> i'd be happy to merge pr and then do rename though, don't mind
<re_irc>
< (@eldruin:matrix.org)> I did not look into it :D
<re_irc>
< (@adamgreig:matrix.org)> I guess my only remaining hesitation is that LLA already provides a spin-lock based global allocator behind a default feature flag that you use exactly the same way you currently use alloc-cortex-m
<re_irc>
< (@adamgreig:matrix.org)> so it does seem like they could fairly easily just add another feature flag for a CSHeap or whatever
<re_irc>
< (@adamgreig:matrix.org)> but given the recent discussion around swapping to a tslf or some other kind of allocator it seems nice enough to have something for this?
<re_irc>
< (@dirbaio:matrix.org)> Rename pushed
<re_irc>
< (@dirbaio:matrix.org)> ugh conflicts
<re_irc>
< (@adamgreig:matrix.org)> did anyone have anything else for this week?
<re_irc>
< (@thejpster:matrix.org)> I came here to plug our blog post but you did it.
<re_irc>
< (@adamgreig:matrix.org)> thanks for writing it!
<re_irc>
< (@thejpster:matrix.org)> Mara is asking about stable ABI use cases over on Mastodon. Chip in if you can think of any.
<re_irc>
< (@thejpster:matrix.org)> Curious mix of “yes please” and “oh hell no”.
<re_irc>
< (@thejpster:matrix.org)> Are we doing a This Year in Embedded Rust again? Now seems like a good time to start planning.
<re_irc>
< (@eldruin:matrix.org)> I think we should, especially because we did not update the blog much
<re_irc>
< (@dirbaio:matrix.org)> fixed, ci green, should be good to go
<re_irc>
< (@thejpster:matrix.org)> I wonder if I can find those scripts that grokked all our repos and generated git stats
<re_irc>
< (@thejpster:matrix.org)> Gives you a guide of which areas had the most work and therefore maybe the most lines in the blog.
<re_irc>
< (@adamgreig:matrix.org)> oh yea, that would be nice
<re_irc>
< (@adamgreig:matrix.org)> helps remember what changed too
<re_irc>
< (@CyReVolt:matrix.org)> : That'd be cool! 🆒🦀 Something like number of PAC/HAL/BSC comparison chart, recap / current state of embedded HAL close to 1.0.0 stable and stuff like that, or what do you have in mind? :)
<re_irc>
< (@jlogan:matrix.org)> Sup, folks - I'm looking for ideas for a bare-metal project to work on that would improve the embedded rust landscape and get me some more experience outside the TI ecosystem. Current best thought is to work on a board crate for NXP's i.MX 1170 now that they're coming back in stock. Anyone have suggestions for other chips that need HALs/etc, boards that need crates or examples, low-level utilities (like...
<re_irc>
... panic-never compatible slice operations), or such?
dc740 has joined #rust-embedded
genpaku has quit [Remote host closed the connection]