<JamesMunns[m]>
SyncUnsafeCell is still nightly only
<wassasin[m]>
You can easily make unsafecell into syncunsafecell where you want to use it though
<wassasin[m]>
Currently Mutex is !Sync, which I would expect it to be
<wassasin[m]>
* Currently Mutex is !Sync, and I would expect it would be Sync
<JamesMunns[m]>
Also I've been pointing folks to https://docs.rs/mutex/latest/mutex/struct.BlockingMutex.html if they want a "static and interrupt safe mutex, that is fine to use from interrupts", as it actually gives you mutable access instead of requiring a RefCell or whatever
<JamesMunns[m]>
(right now it just "looks like" embassy-sync's blocking mutex, the hope is to unify them eventually)
MartinSivk[m]1 has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I think it's quite easy to accidentally refer to the crate as defmt in the generated code, which is fine for 99% of people, but not those who use cargo to rename the package. (defmt-foo = { name = "defmt", version = "..." })
<danielb[m]>
I don't know what the solution should be - as long as `defmt-03` features exist that include the crate as "defmt_03", and that's quite a common pattern I think for <1.0 crates, this problem will exist. But also, `::defmt` is the correct way to generate code, as users might accidentally have a defmt module that IDK, contains some Format impls for whatever reason - I certainly did have `core` somewhere that ended up causing problems
<thejpster[m]>
isn't there special syntax for "the name of the crate this macro came from?"
<danielb[m]>
for proc macros? I don't think so
<JamesMunns[m]>
yeah, decl macros have $crate, there are hacks for proc macros to get that, I think by generating decl macros and using the output? not built in tho
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
I'm still alive but running a few minutes late, be with you soon
<JamesMunns[m]>
(I had a call get moved to 8-9pm Berlin, will be vaguely around but not entirely)
<FreeKill[m]>
JamesMunns[m]: Sounds like a rad start 👍️ Between RTT and postcard RPC it sounded like a lot of the blocks existed so I'm very excited to learn it's being worked on :D
<adamgreig[m]>
ok, let's begin! I've been pretty out of it all week with house stuff so not got much to report, I think main announcement is that the new async digital methods got merged in https://github.com/rust-embedded/embedded-hal/pull/649
<adamgreig[m]>
and getting on for last calls to let me know if you're interested or might be interested in joining the embedded unconf at rustweek (there's still some grants available from rustweek and from rust foundation for wg members, too)
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
I'm planning to cut the triage short and archive the old Disco Book repo next week unless folks object. We're getting more issues on the new book now, and it's getting confusing coordinating them.
<adamgreig[m]>
sounds good!
<thejpster[m]>
defmt 1.0.0 and 1.0.1 happened
<adamgreig[m]>
nice work!
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Want to mention the discussion with the Rust project about target maintenance?
<therealprof[m]>
(Unfortunately I have to leave in a few minutes to pick up my son)
<bartmassey[m]>
Link that discussion again please? I'd like to read it.
<diondokter[m]>
Definitely send a PR to awesome-embedded-rust I'd say
<adamgreig[m]>
i've added it to #rust-embedded-space:matrix.org
<diondokter[m]>
adamgreig[m]: Didn't know this was a thing lol
<i509vcb[m]>
diondokter[m]: I did notice that list has no mention of embassy hals, I imagine thats just missing someone to add it?
<diondokter[m]>
Yeah
<i509vcb[m]>
My hal for these parts lives with embassy stuff
<thejpster[m]>
<adamgreig[m]> "probably thejpster is the most..." <- Sorry was afk. I’m not aware of any plans on how to deal with 16 variations (or whatever it is) of the M55 and M85.
<dngrs[m]>
embassy-stm32 has over 1200 HALs, maybe not wise to add them all to a list
<i509vcb[m]>
dngrs[m]: Yeah, probably just say all
<thejpster[m]>
DSP, FPU of different sizes, vector extensions for int or int+float, pointer authentication, branch target identification. It’s a nightmare.
<adamgreig[m]>
jeez, thanks arm
<i509vcb[m]>
although mspm0 is already pushing about 12 parts and more are coming (I see some unreleased chips in metadata)
<thejpster[m]>
Also there’s a 64-bit Cortex-R82 that is totally unsupported, and the Cortex-R52 is only Tier 3.
<thejpster[m]>
I expect the Arm team to kind of be in maintenance only mode though.
<thejpster[m]>
cortex-ar is ticking along thanks to University of Stuttgart. Google are doing AArch64 arm things off on their own. And I’m doing derive-mmio under the knurling banner.
<thejpster[m]>
derive-mmio could be great for the cortex-m crate btw.
<thejpster[m]>
One solution to the arm target issue is being able to build libcore from source on stable. Is anyone from the WG driving that?
<jannic[m]>
Does RISC-V with all its extensions have the same issue? Or is there some mechanism that allows them to be grouped in a smaller number of targets?
<thejpster[m]>
Same issue afaik.
<thejpster[m]>
As in you can use a ‘worse’ target and it’s fine but you leave performance on the table
<rmsyn[m]>
<jannic[m]> "Does RISC-V with all its..." <- RISC-V is undergoing some changes in how targets/features are exposed by the compiler. I think it is taking the same approach as ARM, and ABI-breaking features emit warnings/errors (I think, the discussion / RFC may still be ongoing)
<rmsyn[m]>
* RISC-V is undergoing some changes in how targets/features are exposed by the compiler. I think it is taking the same approach as ARM, and ABI-breaking features emit warnings/errors (I think, the discussion / RFC may still be ongoing)
<rmsyn[m]>
edit: nvm, I think you are talking about something separate.
<M9names[m]>
Looks like the build-std work is on the roadmap.
jsjuel[m] has joined #rust-embedded
<jsjuel[m]>
I am very much a beginner here. I have what might be quite a dumb question. I am trying to get a basic example of blinky running on my Pico 2. Does anyone have a very simple full example of a blinky program for the Pico 2? I have looked at the example for rp-rs, but files like Cargo.toml, .cargo/config.toml, memory.x have way more stuff than just for blinky. I could just grab everything, but that really defeats the purpose of what I
<jsjuel[m]>
want. I want just a bare minimum working blinky to learn from and move on from. I couldn't find a good one using embassy either. Maybe I am missing something or maybe I am just not smart enough for embedded. Any help would be appreciated.
<korbin[m]>
copy .cargo, Cargo.toml, build.rs, memory.x, src/bin/blinky.rs -> src/main.rs, pop into the Cargo.toml and delete basically everything except the things that are imported in your new main.rs file, remove the embassy `path`s and you are done
<korbin[m]>
you might have to swap rp2040 for rp2350
<Elias[m]>
Hi, I have a quick question or two. Can the aarch64-cpu crate be used with embedded-hal? Is there any way of using embedded-hal in 64 bits arm baremetal? (All examples I'm finding uses 32 bits arm)
<adamgreig[m]>
embedded-hal works on any platform, it's just some shared traits, so e.g. it's useable on hosted 64-bit linux just as well as 8-bit MCUs
<korbin[m]>
^^
<adamgreig[m]>
you need some HAL that implements the embedded-hal traits for your specific microcontroller/peripheral/etc though, or you may need to write one if no-one else has already
<korbin[m]>
i dont know of any 64 bit SOC rust HALs though, i was looking
<M9names[m]>
<korbin[m]> "i dont know of any 64 bit SOC..." <- There is https://github.com/riscv-rust/k210-hal at least, unless you mean 64-bit arm hal?
<korbin[m]>
M9names[m]: this is probably the nicest thing about `rv64` - there's basically no deviation from `rv32`, `armv7` and `aarch64` are different enough that it's more painful to boot the latter
<Elias[m]>
<adamgreig[m]> "you need some HAL that implement..." <- To be clear, there's currently no HAL on crates.io for any aarch64 soc right?