<alex[m]1>
Is it possible to use multiple HALs for one project? For example I'd like to use stm32-hal2 for the GPIO and embassy-stm32 for the rest of the project
igiona[m] has joined #rust-embedded
<igiona[m]>
<huayra1[m]> "in D i could do inheritance with..." <- Side note: Not being able to do inheritance is actually a good thing imho 😅
GolfMike has joined #rust-embedded
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
GolfMike has quit [Ping timeout: 256 seconds]
<AlexandrosLiarok>
anyone aware of any async drivers for 25series spi flashes ?
<AlexandrosLiarok>
* anyone aware of any async drivers for series 25 spi flashes ?
GolfMike has joined #rust-embedded
GolfMike has quit [Quit: Client closed]
<diondokter[m]>
<AlexandrosLiarok> "anyone aware of any async..." <- Generic? No. But you might be able to adapt this one to your chip: https://github.com/tweedegolf/w25q32jv
<AlexandrosLiarok>
It has generic support for series25 memories, so you just configure the sizes at construction.
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
cbjamo[m] has joined #rust-embedded
<cbjamo[m]>
Does anyone here know of a usb-c power delivery device (either source or sink) that actually uses extended messages? None of my usb-c power supplies do so I can't test my pd code. I could set up a loopback/use 2 devices, but I'm worried I'll make a not-quite-pd thing that's perfectly happy talking to itself but doesn't follow the spec in some subtle way.
Koen[m] has joined #rust-embedded
<Koen[m]>
And you assume that any consumer PD device doesn't have some subtle dialect in the implementation? :)
<cbjamo[m]>
I try not to think about that.
<cbjamo[m]>
I think most devices probably handle control and data messages correctly, they're just not that hard (also your device just won't work if you do it wrong). Extended messages have enough back-and-forth and subtlety that I wouldn't be surprised if compatibility problems were common. Except that I'm not sure extended messages actually exist.
<cbjamo[m]>
Well, I think (not actually sure) that EPR needs to use extended messages.
<Koen[m]>
Is there a way to find out if a charger (for example) supports extended messages from Linux?
<cbjamo[m]>
Hmm, maybe? I would expect most pd stuff to be handled by the mobo's embedded controller, but it might report up/give an interface to the kernel.
<Koen[m]>
<cbjamo[m]> "I think most devices probably..." <- A tad off topic, but it reminds me of a case I had a while ago. A hotel room came with a type C charger port outlet next to the bed. My phone charged just fine, but my laptop refused to charge from it even though all info indicated that the port could deliver the right combo of voltage and current.
<Koen[m]>
Koen[m]: So yeah, probably a lot of subtle bugs around in these devices
<thejpster[m]>
You may want to consider whether it makes sense to be maintainers and what SLA you’re offering (possibly none at all!) because I sort of forced it on you when it said you really wanted to be part of the Rust Project
ivche has quit [Quit: %bye%]
ivche has joined #rust-embedded
<sourcebox[m]>
thejpster: Some days ago, you proposed to have a `MutexCell` for the `critical_section` crate. I'm not sure what your main idea behind that was. Is it because people are using `Mutex<RefCell>` all the time?
<sourcebox[m]>
I'm also currently doing it and asking my self if it really has to be a RefCell.
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! i'm back and so also back to running, many thanks to James Munns and bartmassey for helping out while I was away! the agenda for this week is https://github.com/rust-embedded/wg/discussions/798, as usual please add anything you'd like to announce or discuss and we'll start in a few minutes
<thejpster[m]>
<sourcebox[m]> "thejpster: Some days ago, you..." <- Yes. The Mutex by itself isn’t very useful because it doesn’t give you mut because it’s reentrant
<adamgreig[m]>
ok, let's start! I'm only just back so still catching up on the last couple weeks of activity, and don't have any announcements myself
<adamgreig[m]>
great, thanks! looking forward to it
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Put another note about the upcoming Book Sprint in the minutes. Please consider joining us! It can be a lot of fun and get a lot done in a short time.
<rmsyn[m]>
bartmassey: is a MB2 board required / experience programming for MB2, or can someone contribute with only simulator access?
<omani[m]>
hi all. Im new here. is this a live stream meeting? where can I watch it?
<bartmassey[m]>
There isn't really a simulator for the MB2 (sadly) that I'm aware of, but there's plenty to do without an MB2 in terms of writing general text and proofing stuff
<jannic[m]>
omani[m]: It's only this chat.
<bartmassey[m]>
omani: Welcome!
<adamgreig[m]>
ok, let's work through the open issues from this week's agenda and then we could look to recap any older ones if need be
<adamgreig[m]>
first up rmsyn do you wanna talk about those riscv PRs? are you looking for anyone specifically to review them or generally discuss?
d3zd3z[m] has joined #rust-embedded
<d3zd3z[m]>
Re #1 and the UnsafeCell. In implementing Mutex on top of Zephyr's primitives, I did need to put the data itself in a `UnsafeCell<T>`.
<rmsyn[m]>
not much to discuss, just wanted any other members (or anyone interested) to review the PRs before merging.
<adamgreig[m]>
is there anything you want to discuss specifically or just get some attention to the PR?
<thejpster[m]>
well the target is owned by the Cortex-M team. So there's a wider question around SLAs for target maintenance.
<adamgreig[m]>
what's the difference between fpregs and soft-float, btw?I guess I shoukld read the zulip thread..
<thejpster[m]>
also, not my job to do this stuff. I resigned from this group. But I find myself being pulled into long Zulip discussions and I don't see many other people from here showing up with opinions.
<thejpster[m]>
if people from EDWG don't show up on zulip with expertise about these targets, they will languish.
<thejpster[m]>
I'll leave it at that.
<adamgreig[m]>
understood, thanks for all your recent work on the fp support and flags and such!
<adamgreig[m]>
i guess we should also try and get the zulip ping group we discussed sorted out for this sort of thing
<adamgreig[m]>
anyway, the pr for fpregs seems sensible enough given that background
<thejpster[m]>
and a github ping group, perhaps. Arm were pinged on the cortex-m stuff but they have repeatedly said they don't support Rust on Cortex-M, only the Tier 1 Aarch64 target.
<adamgreig[m]>
a pain it's all quite esoteric llvm stuff
<thejpster[m]>
the route forward for these kinds of issues usually involves an arm expert, a rustc expert and an llvm expert
<adamgreig[m]>
I'll leave a review on the PR after the meeting but it broadly lgtm
<thejpster[m]>
yeah, that was fun. Doing a PROVIDE(foo = bar) and then not using foo causes bar to be gc'd by the linker, and then produces "can't find bar" linker errors.
<thejpster[m]>
You probably need some canary builds. Although as jannic says in the agenda, maybe it's just a weird issue that only affects my training repo
<thejpster[m]>
(I see it because I define a defmt::panic_handler and then don't use it)
<adamgreig[m]>
s/on nightly//, s/ think/_think_/
<jannic[m]>
Yes, I build on beta by default locally, and I didn't run into the issue.
<adamgreig[m]>
so I guess it's more a gap in our test coverage, although a lot of people do regularly use nightly aiui so I'm surprised it wasn't spotted sooner
<adamgreig[m]>
possibly mostly pinned nightlies
<thejpster[m]>
to be fair, there was a ticket about it on defmt back in late August, but I missed it
<jannic[m]>
I guess the combination of defining the panic handler and then not using it is not too common.
<adamgreig[m]>
is this something that could be caught with scheduled CI for defmt specifically?
<adamgreig[m]>
it's not like this was a cortex-m-specific bug, so I don't know if we'd necessarily feel like it was our omission to have not caught it
<thejpster[m]>
in general I wouldn't play whack-a-mole with this issue. I'd think about how you catch the next linker issue.
<jannic[m]>
And still nobody noticed.
<adamgreig[m]>
yea, fair
<thejpster[m]>
Being particually aware of LLVM upgrades and doing some kind of embedded crater run may be usefuil
<adamgreig[m]>
I think the answer there is "run cortex-m-rt scheduled CI against beta as well as stable"
<adamgreig[m]>
it tests a wide combination of different linkers and linker settings
<jannic[m]>
Perhaps also on nightly, to catch issues earlier? Or would that cause too much noise?
<thejpster[m]>
jannic[m]: I am probably overly sensitive because it was my training material that broken
<adamgreig[m]>
I'd worry about noise, since it has to open an issue on cron failure
<thejpster[m]>
s/broken/broke. In a training./
<jannic[m]>
Yes, then beta may be the better choice.
<adamgreig[m]>
but testing on beta might have caught this a little sooner
<thejpster[m]>
perhaps you could collect suggestions for big projects you could put into an embedded crater run
<adamgreig[m]>
that would be nice too, but it's a lot more work to set up than adding beta to the c-m-rt weekly CI
<thejpster[m]>
although compile failure is one thing, catching mis-compiles is another (like the compiler-builtins infinite recursion bug)
<adamgreig[m]>
well, probably. maybe it's just a repo with some projects and a GHA script
korken89[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
ok, that's all the points from this week, it looks like there are a couple points from last week that probably need HAL team specifically, is there anything else anyone wants to discuss now?
<jannic[m]>
thejpster[m]: Testing with hardware would be great, but also much more effort, both to set it up and to keep it running.
<thejpster[m]>
as a developer on a compiler that requires tests to run and pass in order to get qualification, I can say yes, yes it is.
<therealprof[m]>
I sprinkled my (unauthoritative) approval upon it.
<adamgreig[m]>
ok, let's call it there for this week then, thanks all! if there's anything else that needs attention now I'm back please let me know and I'll try and get it sorted today or tomorrow
<JomerDev[m]>
Ah, nice, that was much easier than I thought
<JomerDev[m]>
It did compile... and now the pico crashed. Dang it
<JomerDev[m]>
* I thought. Thank you!
<JomerDev[m]>
Is there a way to enable defmt without controlling the memory.x file?
<omani[m]>
anybody know of mpsc or channels in genereal for no_std (embedded) environments? (beside embassy-sync that is).
<omani[m]>
s/?//, s/(//, s/that is)./?/
<omani[m]>
* anybody know of mpsc or channels in genereal for no_std (embedded) environments beside embassy-sync? more generic no_std channel implementations.
<dirbaio[m]>
heapless has a few too
<dirbaio[m]>
and bbqueue is also interesting if what you're sending is binary messages of varying size
<dirbaio[m]>
(note embassy-sync works in all async executors tho, you don't need to be running the embassy executor)
nandnor[m] has quit [Quit: Idle timeout reached: 172800s]
<omani[m]>
<dirbaio[m]> "heapless has a few too" <- thank. works like a charm.