PhilMarkgraf[m] has quit [Quit: Idle timeout reached: 172800s]
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
<badyjoke[m]> "Hello, what do you think of RTIC..." <- RTIC is a bit nicer than managing shared resources using Mutexes and critical sections
trinhtuan[m] has joined #rust-embedded
<trinhtuan[m]>
Hi all,
<trinhtuan[m]>
Does Rust have any tool/command like `cpp` (for C++) for doing pre-processor of the source code e.g. when we just want to view/check all the macro's expansion? (not compile nor link the source code)
<trinhtuan[m]>
haobogu[m]: Thank you for the suggestion of `cargo-expand`, let me try. I am aware of `cargo check` but it is not what I am looking for.
<trinhtuan[m]>
Do you know how to expand completely all the macros? I've done an expanding test using `cargo expand` but it does not expand all the macros, there still some macros as in below screenshot (left is the source code and right is result from `cargo expand`) e.g `#[inline(always)]`, etc.
<trinhtuan[m]>
trinhtuan[m]: Do you know how to expand completely all the macros? I've done an expanding test using `cargo expand` but it does not expand all the macros, there still some macros as in below screenshot (left is the source code and right is result from `cargo expand`) e.g `#[inline(always)]`, etc.
<trinhtuan[m]>
Thanks,
<JamesMunns[m]>
<trinhtuan[m]> "Do you know how to expand..." <- > <@trinhtuan:matrix.org> Do you know how to expand completely all the macros? I've done an expanding test using `cargo expand` but it does not expand all the macros, there still some macros as in below screenshot (left is the source code and right is result from... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/GlcDerldCoaUnuPbQxWSPsGd>)
<ryan-summers[m]>
link445645[m]: This is probably a result of your wiring. 100KHz is not a super high I2C speed, but glad to hear you got it working. Generally, I would imagine this means there's too much capacitance on your I2C lines
<ryan-summers[m]>
If you have a logic analyzer you could plug in or an oscilloscope, that would help you see what's happening at the hardware level :)
AtleoS has joined #rust-embedded
<ryan-summers[m]>
I have a similar problem at home right now with some I2C breadboard sensors and am bringing my logic analyzer from the office to take a look at it :) I2C over wires can be a pain
<JamesMunns[m]>
Also, check the pullups are a reasonable number. If you are only using internal pullups (usually 30-50k, instead of a more typical 2-10k!), OR if you have a bunch of devices with a very low pullup value, that can also slow it down
<JamesMunns[m]>
most i2c dev boards I see today come with 10k pullups, but it's not necessarily guaranteed
<thejpster[m]>
Phil's Lab has a good youtube video describing how pull-up min and max values are calculated from bus capacitance, and provides some good guideline values.
<link445645[m]>
<ryan-summers[m]> "If you have a logic analyzer you..." <- im not that far down the rabbit hole haha, but im getting there
<link445645[m]>
JamesMunns[m]: yeah i saw so many different values online, im now using 1K pull up resistors, but I saw values from 1-10K in different threads
korken89[m] has joined #rust-embedded
<korken89[m]>
What I'm trying to do is to share a thing between 2 arms of a `select` statement, and the `NoopMutex` internally uses a `RefCell`.
<korken89[m]>
To my other `async` aficionados, does anyone know of a way to not poison the future generated from async to become `!Send` when a `RefCell` is used across an `.await` point? I don't think it's possible to get around, but better to check. This as the `RefCell` needs to be stored in the anonymous "enum" type that encodes the state, and then that type would be poisoned by the `RefCell` to also be `!Send`.
<JamesMunns[m]>
link445645[m]: 1k is probably a little too strong, 3-5k is usually pretty good for 100k, but also make sure you don't have any other pullups on any dev boards, if you have 1k pullups AND 5k or 10k pullups on the dev boards, it'll be way too much
<korken89[m]>
s/arms/futures/
<JamesMunns[m]>
korken89[m]: > <@korken89:matrix.org> To my other `async` aficionados, does anyone know of a way to not poison the future generated from async to become `!Send` when a `RefCell` is used across an `.await` point? I don't think it's possible to get around, but better to check. This as the `RefCell` needs to be... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KUJDFGfDzoFYyGNiqdopBGIS>)
<ryan-summers[m]>
For some reason, 2.2k ohm comes to my mind as a sweet spot for i2c pullups, don't remember why though
<JamesMunns[m]>
JamesMunns[m]: so, "you can't, but that's probably not a problem in embassy, like it would be in tokio"
<korken89[m]>
JamesMunns[m]: Yeah I know, we do the same in RTIC but the lib I'm writing needs to work on tokio and `no_std`
<JamesMunns[m]>
ryan-summers[m]: yeah, without referencing the phil's lab video, 5-10k is usually ok for 100khz imo, 2-5k is usually fine for 400khz
<korken89[m]>
Rather than just pulling in a full-blown Mutex youknow. But it looks like I'll be forced to do just that.
<JamesMunns[m]>
korken89[m]: then you can't, because the refcell is a borrow of a value that can't necessarily be Send
<korken89[m]>
Yeah, I'll need to craft some other mutex for it.
<JamesMunns[m]>
Maybe there's a different way to shape what you're trying to do? You usually wouldn't want to hold a mutex locked while selecting on two futures, IMO.
<JamesMunns[m]>
(the two futures can't use the mutex contents simultaneously, so the only point of the mutex is to prevent something ELSE taking the mutex while those two futures are running?)
<korken89[m]>
Ah no, it's to share a resource so the 2 futures in the select statement can access the resource.
<korken89[m]>
The select is the RX and TX futures in my case, and they need to share the cryptographic accelerator
<korken89[m]>
* cryptographic accelerator to encode/decode messages
<korken89[m]>
And the cryptographic accelerator has an async API
<korken89[m]>
So I want the arm that does not have access to essentially wait for the other path to finish using the accelerator
<JamesMunns[m]>
how would the two futures have simultaneous &mut access?
<korken89[m]>
Via a mutex
<korken89[m]>
The mutex will return Poll::Pending if it's locked right
<korken89[m]>
So that path will have to wait until the other path is using the accelerator
<korken89[m]>
After that the executor needs to be woken so the lock can be retried
<JamesMunns[m]>
so on desktop, you use a CriticalSection raw mutex that is Send, and on embassy/rtic you can use Noop/ThreadMode mutex which is cheaper?
<JamesMunns[m]>
sorta blindly guessing at the shape of the actual problem tho :)
<korken89[m]>
Yeah, I'm sort-of leaning towards that
<JamesMunns[m]>
embassy-sync::Mutex is `impl<M: RawMutex + Send, T: ?Sized + Send> Send for Mutex<M, T>`
<korken89[m]>
I'm currently experimenting a little with that I know that if the lock was taken and the other path also tried to lock I only need to re wake the executor
<korken89[m]>
* the executor to make sure the lock retry happen
<korken89[m]>
* the executor to make sure the lock retry happens
<korken89[m]>
So far it seems to do what I expect
<JamesMunns[m]>
releasing the mutex should wake the future of a task that is waiting on the lock
<JamesMunns[m]>
like, if you select on both, one gets it, makes some progress, the other one tries to lock it, it's pending, when the first one releases it, it rewakes the future, which allows the second to make progress
<JamesMunns[m]>
but remember that on embedded you usually have a biased select, where on desktop you have a randomizer to be fair to both futures
<JamesMunns[m]>
with biased select you can end up starving the other arms if tx is always ready, for example
<korken89[m]>
I'll experiment some more, thanks for the discussion :D
kevlan[m] has joined #rust-embedded
<kevlan[m]>
If anyone knows any EE/CS engineering students in Colorado we are looking for an intern to join the team at LUCI: https://luci.box.com/s/uvybgggp6d2irbwz2p8mvntsrg6880tx There will very likely be some Rust firmware projects to work on!
tiwalun[m] has quit [Quit: Idle timeout reached: 172800s]
ninjasource[m] has joined #rust-embedded
<ninjasource[m]>
Hi guys, I've been attempting to add hyperbus support (via the octospi peripheral) to embassy-stm32 and specifically to get it to work on an stm32h735-dk which uses the stm32h735ig mcu with 16MB of attached PSRAM. I'm a little stuck on trying to figure out why the stm32-data library does not generate the appropriate pins for OCTOSPI1 and OCTOSPI2. An empty list in both cases. Only OCTOSPIM has pins and I'm a little confused by
<ninjasource[m]>
why this is even a different peripheral. The PERIMAP in chips.rs looks correct to me although it is importing both octospi_v1.rs and octospim_v1.rs. I'm wondering if I need to make changes to the build.rs file the embassy-stm32 project or if this is better solved in the stm32-data crate which ultimately builds the stm32-metapac. I have tried adding support for the differently named signals for octospi in embassy-stm32
<ninjasource[m]>
build.rs but these are not matched because of the empty pins lists mentioned earlier. I hope this all makes sense!
<vollbrecht[m]>
yeah that's the std part. the no_std xtensa part was added 3 weeks ago i think. Making noise here so upstream may want to look more at the outstanding patches for xtensa llvm ;D
okhsunrog[m] has joined #rust-embedded
<okhsunrog[m]>
Wow, does it mean that now we can build for xtensa std targets with official nightly rust toolchain?
<TomB[m]>
I’m looking forward to the hifi extension support
mabez[m] has joined #rust-embedded
<mabez[m]>
<okhsunrog[m]> "Wow, does it mean that now we..." <- Not yet (which is why we've been kinda quiet about it :D) upstream LLVM still needs some more patches, and the version of LLVM that Rust is using is quite old and missing some more recent patches
<mabez[m]>
Those patches landing in rust are somewhat inert for now, but it makes my life easier and paves the path forward
Mebus[m]1 has quit [Quit: Idle timeout reached: 172800s]
newam[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Remote host closed the connection]
adamhott[m] has quit [Quit: Idle timeout reached: 172800s]
Henk[m] has quit [Quit: Idle timeout reached: 172800s]
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
BrassPin88 has joined #rust-embedded
<BrassPin88>
Hi, is this official rust channel>
<BrassPin88>
?
<BrassPin88>
what is embedded and how is it different than VLSI?
<firefrommoonligh>
embedded generally refers to writing code for microcontrollers and other devices that are not general purpose PCs
<firefrommoonligh>
It is still generally writing code that looks like what you'd write on PCs, while VLSI looks like a different beast
<BrassPin88>
how do you distinguish bw microcontrollers and micocomputers now that beasts like NPUs, TPUs etc exist
<firefrommoonligh>
Use the categorization and names in a way that is useful to your purpose, whatever that is.