<M9names[m]>
That readme explains why we want a lighter version of Mutex, but doesn't explain the value of giving it the same name.
<M9names[m]>
It really sucks that we have to teach people who already know Rust that Mutex doesn't mean the same thing that they think it does.
<thejpster[m]>
> either by nesting critical sections or Copying an existing token
<thejpster[m]>
It feels like we could create an api that would fix that
<thejpster[m]>
I’d be happier if it was called a SharedLock or something. But maybe it’s too late?
<thejpster[m]>
The “Syncifier”
<wassasin[m]>
Or some scheme that allows checking for nesting at compile time
<thejpster[m]>
You could do that with an atomicbool
<wassasin[m]>
That's at runtime though, and is basically the same as using the RefCell as described in the doc
<M9names[m]>
we could also just implement Mutex again in a different crate? that would give us something that is portable between arch's, unlike the current system.
<M9names[m]>
any lib crate using cortex-m::Mutex needs a fork to run anywhere else currently anyway, which is fine for 99% of current users but kinda sucks for anyone else.
<M9names[m]>
sure, but how often do we just tell people to do Mutex<Refcell>>
<thejpster[m]>
I think people use critical_section::Mutex now?
<thejpster[m]>
but yeah, I'd love an embedded_mutex::Mutex which worked more like std::sync::Mutex
<M9names[m]>
ah yeah, forgot about critical_section::Mutex
<M9names[m]>
just make critical_section::sync::Mutex 🙈
diondokter[m] has joined #rust-embedded
<diondokter[m]>
<thejpster[m]> "but yeah, I'd love an embedded_m..." <- How would you do that though? I can see it in an executor, but bare metal?
<thejpster[m]>
Worked like as in gave me &mut. It would be a cs Mutex and a ref cell in a trench coat b
<thejpster[m]>
* trench coat.
<diondokter[m]>
Ah ok
<diondokter[m]>
And just panic
<diondokter[m]>
Yeah I think I agree. All of my mutexes are with a refcell too. Just get rid of having to type the extra refcell would be nice
<thejpster[m]>
the panic would be "you grabbed the lock whilst you already had the lock", which I think would be a programming error.
<thejpster[m]>
what does std::io::Mutex do if you double lock it? I can't remember. deadlock probably.
<wassasin[m]>
Which currently is impossible unless you have a nested CS
<diondokter[m]>
wassasin[m]: You can do that in the same CS too
<diondokter[m]>
thejpster[m]: If from two different threads, then one thread will wait until the other thread unlocks it.
<diondokter[m]>
On the same thread it deadlocks yeah
<diondokter[m]>
With the rust model, it's not safe to have reentrant locks
<wassasin[m]>
Ah yes because CriticalSection is Coyp
<wassasin[m]>
s//`/, s//`/, s/Coyp/`Copy`/
<thejpster[m]>
I had some training clients who were quite horrified how easy it was to deadlock this “safe” language
mabez[m] has joined #rust-embedded
<mabez[m]>
thejpster[m]: The docs don't specify whether std::Mutex is reentrant or not, so I guess it's platform specific
<thejpster[m]>
It can’t be re entrant because that would alias a &mut
<M9names[m]>
could always convince the lang team to give us a no_ref trait. return a pointer instead, only safe to use via volatile or atomic writes.
<M9names[m]>
i'm sure that would be popular 🤪
<M9names[m]>
but actually no_ref might make FFI a little bit easier to not violate the aliasing rules
<mabez[m]>
Sorry I meant the behaviour of what happens if you do double lock it, I think Linux deadlocks but windows seems to detect it and panic, based on various issues around the topic
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
starblue has joined #rust-embedded
starblue has quit [Client Quit]
brazuca has joined #rust-embedded
Farooq has joined #rust-embedded
<Farooq>
Where can I get a STM32H7 board? Waveshare has got only one model and I am not sure it's the right choice.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
* stm32 nucleo boards are nice and reasonably cheap
<dirbaio[m]>
stm32 nucleos are nice and reasonably cheap
<dirbaio[m]>
reserve a bit of flash area, from the end for example. it has to be at least 1 sector if you want to be able to erase+write it independently from the firmware
<dirbaio[m]>
shorten FLASH in memory.x so the firmware won't use it
<dirbaio[m]>
on the PC side, encode the config to bytes (either manually, or write a tool)
<dirbaio[m]>
then flash it to the reserved flash area: probe-rs flash --chip BLAH --format bin --base-address 0x0800f000 my_config.bin
<dirbaio[m]>
and from the firmware side you can read it like this:
<dirbaio[m]>
```rust
<dirbaio[m]>
let my_config = unsafe { (0x0800f000 as *const MyConfig).read() };
<dirbaio[m]>
this is very "MVP", in a real-world project you probably want to
<dirbaio[m]>
- use a format more flexible than repr(C), perhaps postcard
<dirbaio[m]>
- add CRCs so you can detect missing or corrupted config
<dirbaio[m]>
s//`/, s/flash/download/, s//`/
<coljnr9[m]>
Okay thanks!! Sounds reasonable
<coljnr9[m]>
I'm using the `env` route right now, but compiling between flashing every device is kinda lame.
<coljnr9[m]>
I'm already using postcard everywhere, I'll see if I can get something working with your suggestion 👍️
<dirbaio[m]>
if you need more advanced stuff it might be worth it to make it a rust binary. using probe-rs as a lib to flash some elf/bin is super easy
<dirbaio[m]>
and before you know it you've reinvented a turbo-probe-run that does factory tests, speaks to a server to allocate serial numbers, generate keys, download the firmware binary, generate the config, flash it, report back, print labels with serial numbers 🤪
<JamesMunns[m]>
dirbaio[m]: quick ask him how he knows :)
<dirbaio[m]>
as a statically linked .exe you can email to your factory in China
<adamgreig[m]>
@room ok, meeting time again! agenda is https://hackmd.io/tp-JScYDTCG3UEWbrfcKGg, please add anything you'd like to announce or discuss and we'll kick off in a minute
<dirbaio[m]>
10/10 would recommend
<JamesMunns[m]>
:D :D :D
<adamgreig[m]>
right, I guess let's start! I've been away most of the week though so don't have much on the agenda... quick announcement that rust 1.72.1 is out today with some small fixes
<adamgreig[m]>
always curious when there's a prerelease announcement for a patch release whether it will be a security update 👀 but not in this case
<dirbaio[m]>
including a fix for a giant async compile time regression 🤪
<JamesMunns[m]>
there was definitely one compile time regression
<adamgreig[m]>
wonder how that made it to a stable release
<dirbaio[m]>
I reported it before the release, they just didn't backport it
<dirbaio[m]>
until after the release more people complained
<dirbaio[m]>
¯\_(ツ)_/¯
<thejpster[m]>
maybe it wasn't the reason for the release, but once a release was required they threw it in anyway
<adamgreig[m]>
oh well, at least it's out now
<adamgreig[m]>
I think let's go right to the new agenda item then, Charles ⚡️ did you add the point about Mjolnir?
Charles[m] has joined #rust-embedded
<Charles[m]>
yes
<Charles[m]>
hopefully it was intended i do that
<adamgreig[m]>
could you summarise the suggestion?
<JamesMunns[m]>
I think the suggestion was just "use the ruma automod, because it's already catching spammers in other rooms"
<Charles[m]>
the most useful feature of the bot is that you can use it to subscribe to banlists, which can then be shared across rooms. the most useful one is the "community moderation effort" banlist, which essentially only bans spambots, so it helps to cut down on that with a lot less manual intervention
<thejpster[m]>
what's the ban rate with our current manual system? one a day?
<JamesMunns[m]>
Probably not even that, but if the cost is low, it'd also be nice if it happens while all of europe is asleep :)
<thejpster[m]>
just want to check if the cure is proportionate to the ailment
<adamgreig[m]>
I think it's more like one a week or so at the moment
<adamgreig[m]>
but the advantage is it could catch a lot of those cases before they even enter and spam people
<JamesMunns[m]>
(I suggested Charles mention it in the meeting, I'm generally positive on it, and if it gets too ban heavy we can just demod it)
<adamgreig[m]>
the downside being we potentially ban people we didn't intend to
<thejpster[m]>
and how would we know if it did that?
<thejpster[m]>
I don't want to end up with something like the UK voter ID policy.
<adamgreig[m]>
we'll see any ban entries, and I like to hope anyone it catches accidentally could message someone... but then I don't know how they'd know who to message.
<Charles[m]>
there's a control room you can join to mess with the bot, including viewing who it banned, from what room, why, and based on what banlist
<thejpster[m]>
ok. well we could give it a trial I guess.
<thejpster[m]>
someone will need to take the action to review the ban logs.
<adamgreig[m]>
for the last two or three spammers, it'd been pointed out that they'd already been banned by this bot, so it seems it would be effective at antispam if nothing else
<JamesMunns[m]>
happy to join the control room
<adamgreig[m]>
yea, same
<adamgreig[m]>
at the moment we only have 30 banned users or so, it might be a shame if the channel banlist gets egregiously long
<adamgreig[m]>
but I suppose we could probably unban very old entries, I don't think many of the spammers are reusing old accounts
<thejpster[m]>
lifetime bans?
<adamgreig[m]>
right now that's all matrix does, I don't know if the bot has a way to unban after a while
<thejpster[m]>
even spammers have a right to be forgotten
<Charles[m]>
adamgreig[m]: fwiw, it does only ban when the user actually joins, probably for the purpose of cutting down on state events
<JamesMunns[m]>
I don't think we've ever banned NON spam bots
<adamgreig[m]>
ah cool, that does help
<adamgreig[m]>
do you know if a banned user can still see the userlist/admin list?
<Charles[m]>
like, in the room they were banned from? not sure
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Charles[m]: I think the bug on element, that you can't anonymously read the channel is still not fixed.
<therealprof[m]>
therealprof[m]: Yep, still there. So no userlist inspection either.
<adamgreig[m]>
just pondering how someone who found themselves unexpectedly/unfairly banned would know who to message about it
<therealprof[m]>
Currently: no way, unless we publish usernames on e.g. the embedded WG pages.
<Charles[m]>
yeah good question tbh
<JamesMunns[m]>
yeah, chances are you could open an issue in the wg repo, probably wouldn't help if you joined the matrix room
<adamgreig[m]>
shame you can't anonymously read the channel, but I guess in the worst case you could make a new account fairly quickly to join the room
<therealprof[m]>
It would certainly help if element would get their act together and fix this annoying bug to anonymously use chats in read-only mode.
<Charles[m]>
(fwiw i think it's totally reasonable if you don't want to add the bot, i just thought i'd suggest it since we've found it pretty useful elsewhere)
<dirbaio[m]>
yuo can anonymously read, at least it works for me
<therealprof[m]>
dirbaio[m]: How?
<dirbaio[m]>
ah no it doesn't work anymore ??
<dirbaio[m]>
a while ago I swear you could go to https://app.element.io/#/room/#rust-embedded:matrix.org in a private browser window and read
<therealprof[m]>
Nope, hasn't worked for a while. Opened an issue many moons ago but no reply yet.
<dirbaio[m]>
embassy is set to "anyone" and it does work
<dirbaio[m]>
you can also see the people list, and who is admin/mod
<adamgreig[m]>
given overall it seems like it won't ban many people and will ban most of our spammers before they start, I'm up for trying it out for a bit, and if we find any over-eager bans we can reconsider? given we can see why a user was banned and other channels are using the same thing hopefully there won't be many instances
<JamesMunns[m]>
thejpster[m]: ah yes a blank slate :)
<dirbaio[m]>
ahhh it only works from the point of enabling that setting 🤣
<therealprof[m]>
WTH?
<adamgreig[m]>
yea, rubbish
<thejpster[m]>
it'll never look like that again! glad I grabbed it for posterity.
<thejpster[m]>
it's fine. No-one ever scrolls back more than a few hours in matrix anyway. It's live chat, not an archive.
<dirbaio[m]>
makes a bit of sense, you don't want an admin to be able to make public a private conversation
<dirbaio[m]>
though it's weird for a chat that anyone could join in the past anyway
<adamgreig[m]>
it should be an archive! we specifically use it as a record of meetings and a ton of technical discussions, lol
<dirbaio[m]>
since that makes it effectively public..
<therealprof[m]>
I'm pretty sure that I've changed everything that requires changing and all of a sudden it works?
<adamgreig[m]>
thankfully it is archived on the irc side
<dirbaio[m]>
the setting was set to "members only" 🤷
<dirbaio[m]>
perhaps a bug in the settings?
<therealprof[m]>
I've tweaked the settings many times for months now, trying to get it back.
<adamgreig[m]>
I just set it back now successfully
<adamgreig[m]>
Shrug
<Charles[m]>
element moment
<adamgreig[m]>
yep lol
<adamgreig[m]>
so, that resolved, any other concerns about trying out the bot?
<therealprof[m]>
If you look at the issue I opened in July, they specifically double checked that the settings were correct.
<adamgreig[m]>
But someone else did post saying the settings were wrong?
<therealprof[m]>
... and confirmed by inspecting the communication that it was a bug on matrix.
<adamgreig[m]>
Their screenshot shows the error about room previews disabled, at the same time as your screenshot showing them enabled
<adamgreig[m]>
Bug in the settings page perhaps
<therealprof[m]>
But I did change them multiple times since about December, trying to get it back.
<therealprof[m]>
Oh well.
<adamgreig[m]>
Ok, let's give the bot a try then? Charles ⚡️: , how do we actually enable?
<Charles[m]>
give it an invite and give it enough power level to give people the boot
<Charles[m]>
maybe also send a command in the control room
<adamgreig[m]>
Thanks!
<adamgreig[m]>
Ok, if anyone notices any issues let one of the admins know
<adamgreig[m]>
Next up, James Munns ?
<JamesMunns[m]>
I attended RIOT-OS's riot summit to give a talk, and it seemed surprisingly topical, as they started supporting rust applications a bit ago, and there was some interest in potentially moving more bits of the OS in the future from C to Rust
<JamesMunns[m]>
(using rust is still a discussion on their end tho), mostly wanted to mention it, since I pointed a lot of folks this way, and they might say hi at some point :)
<therealprof[m]>
thejpster[m]: We have people here who are to blame for that. 😉
<JamesMunns[m]>
chrysn 👋
<JamesMunns[m]>
But yeah! there were a surprising number of discussions regarding Rust, and they (informally) are doing some experiments now of "what could we/could we not easily move over to rust, if we wanted to"
<JamesMunns[m]>
got to show off a lot of cool tooling like probe-rs, and demoed embassy to some folks (which some folks there had been playing around with)
<JamesMunns[m]>
spent a lot of time talking about Rust (who me?)
<adamgreig[m]>
thejpster: do you wanna mention your item now?
<thejpster[m]>
My blocking, non-async, "prioritise code organisation over performance", SD Card and FAT16/FAT32 library continues to receive interest. I recently re-wrote quite a bit of the API but I could use a second/third look-over, as it's had some fairly catastrophic bugs in the past that I didn't notice because I mainly use it in read-only mode.
<thejpster[m]>
Also rust-embedded-community doesn't have a good mechanism to pick a random reviewer. Suggestions on how to fix that will be gratefully received. And if you want to sign up to review/maintain "community" projects like this, do let me know.
<thejpster[m]>
(have my points pre-prepared and ready to paste? I would never)
<JamesMunns[m]>
My $0.02, I think it makes sense to yolo merge for r-e-c, though my understanding is that it would be more like rust-bus, so if a maintainer went MIA, someone else could merge or publish crates on request
<thejpster[m]>
not really an REWG thing so I snuck it in at the end
<thejpster[m]>
we'll I'd yolo too, except now I get issues from people saying "I get this weird panic from my many devices which I've deployed in the field"
<thejpster[m]>
and all the "NO WARRANTY IS GIVEN OR IMPLIED" doesn't stop me feeling bad about that
<thejpster[m]>
s/we'll/well/
<JamesMunns[m]>
I'm working on a "technical readiness level"/"expectation management" writeup, so I can say "this is free to use but I maintain it when I feel like it" :p
<JamesMunns[m]>
but, not saying that should also be your policy!
<adamgreig[m]>
thejpster[m]: Yea, people still want their working sd card library huh
<thejpster[m]>
for free, yeah
<dirbaio[m]>
setting up a bot to randomly assign reviewers won't magically make the assignee review it
<adamgreig[m]>
Maybe the bot could do the review too then :p
<therealprof[m]>
thejpster[m]: If it's free, I'll have three!
<adamgreig[m]>
Anyway, I guess that's all for this meeting, thanks everyone!
<therealprof[m]>
adamgreig[m]: AI review bot?
newam[m] has joined #rust-embedded
<newam[m]>
therealprof[m]: These do exist - not great for embedded/RTL in my experience though
<dirbaio[m]>
like, either a maintainer is interested in the lib in which case they'll already be subscribed to the repo or at least check it occasionally and review stuff
<dirbaio[m]>
or is not, in which case they won't review even if a bot assigns them
<thejpster[m]>
you do not want a filesystem implementation from a weighted random word generator
<thejpster[m]>
I left some comments on a Linked In post and the guy replied "Oh, Chat GPT told me that doing it this was was best practice!" - it was two nested match statements :/
<Charles[m]>
therealprof[m]: someone tried one of these at $WORK and immediately regretted it lol
<newam[m]>
thejpster[m]: when you say it like that it sounds like fun to see what the result would be 😆
jannic[m] has joined #rust-embedded
<jannic[m]>
Btw, I feel a little bit bad about doing a quick drive-by review, and next thing I read is your comment about spending 5 hours reorganizing the code.
<therealprof[m]>
Well, this AI didn't want to anyway...
<thejpster[m]>
jannic: that's on my and my neuro divergence, not you!
<thejpster[m]>
and I wanted to fix it for a while so ... it was nice to just get into the flow for five hours non stop.
<thejpster[m]>
s/my/me/
<adamgreig[m]>
I downloaded a full dump of this room's history and history_visibility has never been changed from world_readable, go figure
<adamgreig[m]>
Just Matrix Things
<adamgreig[m]>
back in a bit. if anyone wants the 200MB JSON dump lmk I guess, I wonder if we can use this to make a nice archive webpage
<JamesMunns[m]>
wait what do we do for minutes now, do we just smash the mf merge button?
<JamesMunns[m]>
I miss bors
<newam[m]>
yeah, or if it's smashed just approve and it merges
<jannic[m]>
I guess somewhere in the matrix terms and conditions was a sentence about implied warranties...
<thejpster[m]>
I won't be here next week (probably) because I'm talking to ESA at the Software Product Assurance workshop about Rust and Rust on SPARC. But before y'all go I want to remind everyone not to miss the Ferrocene product launch on 4 October. We've worked very hard on it and it'll be very exciting news.
<thejpster[m]>
then I am here for a week, and then I'm out again on my way to EuroRust (unless I can join this meeting on the train or something...)
<thejpster[m]>
hopefully we can do some kind of embedded rust hang-out in Brussels around Eurorust
<thejpster[m]>
also, my Neotron talk got added. So ... at some point I should write that.
<thejpster[m]>
It goes into the history of embedded rust too, which has been kind of fun to dig up.
<adamgreig[m]>
<thejpster[m]> "I won't be here next week (..." <- Ah cool, glad someone is talking to them! I was at the conference last time but couldn't make it this time
brazuca has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
Noah[m] has joined #rust-embedded
<Noah[m]>
<JamesMunns[m]> "got to show off a lot of cool..." <- nice! I still wonder why one needs an embedded RTOS with rust :) feels so much smoother with the crate ecosystem, embassy and RTIC that I don't feel like I need an RTOS :)
<thejpster[m]>
Sometimes you want threads and queues and HISRs and that stuff.
likewise[m] has joined #rust-embedded
<likewise[m]>
s/cast/case/
<likewise[m]>
I think it comes down to deterministic worst-cast real-time response behaviour where an RTOS is sometimes required?
<thejpster[m]>
Actually I think that’s literally the point of RTIC, bounded WCET.
<thejpster[m]>
But it seems more for hard real time, not like a big modem with many many layers.
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1>
is it too far to say that RTOS is a C-ism? 🤪
perlindgren[m] has joined #rust-embedded
<perlindgren[m]>
I think the need for a traditional RTOS may be run-time loading of applications. Regarding a single application you can express most needs through tasks and async functions.
<Noah[m]>
<perlindgren[m]> "I think the need for a tradition..." <- that is exactly my perception too and imo most embedded appliances are precompiled and not runtime loaded.
<perlindgren[m]>
RTIC is geared towards a declarative task/resource model, you can encode "dynamic" behavior by e.g., heapless statically allocated dynamic data structures, and spawning can be seen as creating a task execution instance.
<Noah[m]>
<thejpster[m]> "Sometimes you want threads and..." <- I mean we get queues with things like RTIC and embassy too. I don't necessarily see the absolute need for threads. But yeah maybe there is some applications that depend on it. imo it's for lack of better abstraction that threads are so common in C.
<perlindgren[m]>
But the "task" can keep local state (similar to actors).
<dirbaio[m]>
yeah people use C RTOSs to get threads, queues, mutexes, semaphores...
<dirbaio[m]>
becaues that's the only way to get them in C
<adamgreig[m]>
tbh a lot they use RTOSs to get a HAL
<dirbaio[m]>
in Rust async is built into the language, and gives you the same ergonomics as classic threads
<perlindgren[m]>
All of the above holds true, and unfortunately, threads are typically taught at Uni as THE means for concurrency.
<perlindgren[m]>
Async by itself is kind of orthogonal to preemption.
<dirbaio[m]>
you don't need classic threads for preemption
<perlindgren[m]>
Indeed, classic threads don't give you preemption, the OS does.
<dirbaio[m]>
:|
<perlindgren[m]>
perlindgren[m]: ... in ways very hard to reason on ...
<dirbaio[m]>
I mean you don't need an OS that implements classic threads to get preemption
<dirbaio[m]>
by "classic threads" I mean stackful threads/tasks where the OS does context switching by saving/restoring registers
<perlindgren[m]>
That is also true, there needs to be some sort of scheduler/executor.
<dirbaio[m]>
and since we got async in Rust, there's very little need for classic threads :P
<perlindgren[m]>
dirbaio[m]: Indeed.
<dirbaio[m]>
in fact, my opinion is you don't want classic threads
<dirbaio[m]>
espscially not both
<dirbaio[m]>
if you use a classic thread RTOS and then async on top (like you would on top of LInux) you get the worst of both worlds
<dirbaio[m]>
in complexity, code size, speed
<likewise[m]>
Is the example using interrupt pre-emption? And if so, is it based on interrupt contexts pre-empting each other?
<dirbaio[m]>
likewise[m]: yes
<likewise[m]>
So that's like pre-RTOS era C?
<perlindgren[m]>
Well, the concept of threads (at OS level) is deeply rooted, and it will take time until we get a thread free general purpose operating systems.
<perlindgren[m]>
s/a//
<likewise[m]>
In pre-RTOS time you would use interrupt pre-emption, with all the classical problems of priority inversion etc.
<likewise[m]>
I'm still not seeing how async solves that.
<dirbaio[m]>
likewise[m]: no, you can run an arbitrary number of task at each priority level, you need one software interrupt for each level. so you get the same ergonomics as a C RTOS with classic threads where you can set a priority to each
<dirbaio[m]>
you can still have priority inversion etc in a classic thread C RTOS
<dirbaio[m]>
it's not the C RTOS that fixes it, it's the mutex implementation
<dirbaio[m]>
that does the priority ceiling or whatever protocol
<perlindgren[m]>
Traditionally in an operating system environment interrupts are seen as the "odd man out", and supposedly short lived, with crippled access to system resources and OS support.
<dirbaio[m]>
and you can implenent async mutexes that have priority ceilings or whatever you want too
<dirbaio[m]>
(embassy mutexes today don't do that, i'm not aware of any impl that does, but I can't see why it wouldn't be possible)
<JamesMunns[m]>
perlindgren[m]: Working on it now :D
<perlindgren[m]>
Using RTIC on single cores, we can rely on the benefits of the Stack Resource Policy based scheduling, which gives guarantees, to deadlock freedom, bounded priority inversion, shared stack execution etc.
<dirbaio[m]>
perlindgren[m]: not on async tho 🙃
<dirbaio[m]>
it's same issue as embassy, it'd need fun special async mutex implementations
<perlindgren[m]>
I would say, it goes for async as well, you cannot hold on to any lock when yielding.
<JamesMunns[m]>
(MnemOS only offers async/cooperative Multitasking in the kernel, we will likely have preemptive scheduling for separate user processes, tho we expect each user process to also be primarily async/cooperative as well)
<dirbaio[m]>
yes, so the locks aren't usable with async. you can use them from within an async task, but you can't do async things with the object behind the lock
<dirbaio[m]>
for example you can't put an async SPI in an RTIC lock and use it to share it across tasks that do async SPI transfers
<perlindgren[m]>
You can of course end up in a live lock, meaning that you may be be stuck awaiting something that never happens, but that is very different from a "mutex" like deadlock.
<perlindgren[m]>
Using RTIC2 you can leverage on async where you benefit from ergonomics of async, and leverage of task/resource based modelling for the "hard real time" part.
<perlindgren[m]>
Which is kind of typical for "mixed" critical systems.
<dirbaio[m]>
if you want to share async stuff you have to use rtic_sync::arbiter::Arbiter
<dirbaio[m]>
which is equivalent to embassy_sync::Mutex
<dirbaio[m]>
and that's vulnerable to deadlocks
<dirbaio[m]>
task A holds mutex 1, awaiting mutex 2
<dirbaio[m]>
task B holds mutex 2, awaiting mutex 1
<dirbaio[m]>
* and both are vulnerable to deadlocks
<perlindgren[m]>
Indeed, it would be interesting to see if one could inject some sort of fail mechanism, that resolves this by await producing a Result perhaps.
<perlindgren[m]>
And error out in case a cycle is introduced.
<perlindgren[m]>
You can still run into problems, but that would give you a chance to go home and re-think your life sort of ...
<dirbaio[m]>
you can impl the async version of the blocking rtic locks
<dirbaio[m]>
associate a prio with each mutex. if a task holds a mutex at prio N forbid all other tasks from locking any other mutex at prio <=N
<dirbaio[m]>
or something like that
<dirbaio[m]>
and then you do get deadlock-free guarantees
<perlindgren[m]>
So some sort of fallible Mutex you mean.
<dirbaio[m]>
no, the task just waits
<dirbaio[m]>
and gets the mutex when the other task releases theirs
<perlindgren[m]>
so its not allowed to lock you mean.
<dirbaio[m]>
yea
<perlindgren[m]>
yea, that might work.
<dirbaio[m]>
it's the same model as RTIC
<perlindgren[m]>
But enforced at run-time.
<dirbaio[m]>
RTIC also kinda enforces it at runtime
<dirbaio[m]>
in RTIC if a task locks a mutex at prio N, all tasks at prio <=N are prevented from running by raising BASEPRI
<perlindgren[m]>
Well the ceilings are statically computed.
<dirbaio[m]>
in this model, if an async task locks a mutex at prio N, all tasks at prio <=N are prevented from acquiring mutexes
<dirbaio[m]>
you don't even need to block tasks at prio <=N from running, just from acquiring mutexes
<perlindgren[m]>
Did you already implement this?
<dirbaio[m]>
no
<dirbaio[m]>
I don't think I will, plain old mutexes are serving me fine for now 🙃
<dirbaio[m]>
you could even do the same macro magic as rtic to statically compute ceilings too.
<perlindgren[m]>
Let's discuss further, I'll send you a PM.
<dirbaio[m]>
lol the ban spam
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
were those all spam bots that were already in the room?
<adamgreig[m]>
I sure hope so lol
<JamesMunns[m]>
A lot, yeah. Others were CoC violations (from other channels I guess?)
<Charles[m]>
the three banlists the bot is subscribed to is ruma's own coc banlist, matrix.org coc banlist, and cme-bans (which is essentially just for spam)
brazuca has quit [Quit: Client closed]
ninjasource[m] has joined #rust-embedded
<ninjasource[m]>
Hi guys, has anyone here used octospi to read NOR flash memory (MX25LM51245G) in memory-mapped mode on an stm32h7 before? The only way I am able to use nor flash on my stm32h735g-dk is to "pipe it" through SDRAM (hyperram) using my linker script by reading all the nor flash manually on startup and then having it available in SDRAM as a side effect (which is gross IMO). This is problematic because of bandwidth issues on the
<ninjasource[m]>
nor flash chip and the an5050-octospi-interface-on-stm32 document more intimately I would be most pleased.
<ninjasource[m]>
SDRAM being used for other stuff (an lcd display and a global allocator). It would be nice to execute code directly from nor flash like I keep reading about. I know that it's possible because there is an STM32CubeH7 example written in c which is a little rambling and complicated because it tries to do too much. If I should post this on a more specific group please let me know! If I can spare the trouble of getting to know the
crabbedhaloablut has quit []
brazuca has joined #rust-embedded
IlPalazzo-ojiisa has quit [Remote host closed the connection]