<re_irc>
< (@xiugaze:matrix.org)> I am trying to figure out a way to be able to pass the same timer based delay to multiple driver instances if thats even possible, but I can't seem to figure out a way to pass even one
<re_irc>
< (@xiugaze:matrix.org)> I don't think I have a great understanding of how "embedded_hal" traits work with my hal which is "stm32f4xx_hal"
<re_irc>
< (@xiugaze:matrix.org)> Whats does the intended use for these delays look like
<re_irc>
< (@xiugaze:matrix.org)> The error I'm getting is
<re_irc>
the trait bound `stm32f4xx_hal::timer::Delay<stm32f4xx_hal::pac::TIM2, 1000000>: stm32f4xx_hal::timer::Instance` is not satisfied
<re_irc>
the following other types implement trait `stm32f4xx_hal::timer::Instance`:
<re_irc>
< (@adamgreig:matrix.org)> sorry, I don't really know about this, though you're not the first to find this annoying, I think currently the delays based on a hardware timer can't be shared, only owned by one thing at a time, so if the driver wants to take complete ownershp of it (rather than be given a reference) you need to use one timer per driver
<re_irc>
< (@adamgreig:matrix.org)> or use the cortex-m systick delay or something maybe
<re_irc>
< (@xiugaze:matrix.org)> What would be the downsides to using systick delay
<re_irc>
< (@xiugaze:matrix.org)> I know there's less features but my embedded prof kind of glossed over them
<re_irc>
< (@xiugaze:matrix.org)> or should I really be looking for ways to avoid using delays
<re_irc>
< (@adamgreig:matrix.org)> depends on what you're using it for I guess, it's generally less configurable so e.g. if you want long delays it might not work/have more software overhead to keep track of rollover
<re_irc>
< (@adamgreig:matrix.org)> if you can avoid delays that's always better in my experience, but often you do just need a delay
<re_irc>
< (@adamgreig:matrix.org)> in general it should be possible to share delays, I think just the current stm32f4xx-hal ones based on hardware timers aren't set up to do that
<re_irc>
< (@adamgreig:matrix.org)> i'm not the best person to ask though.. might be worth searching the matrix history or github for examples
<re_irc>
< (@xiugaze:matrix.org)> hm okay
<re_irc>
< (@dirbaio:matrix.org)> it's not possible to share timers with stm32-rs hals, ho
<re_irc>
< (@dirbaio:matrix.org)> * no
<re_irc>
< (@dirbaio:matrix.org)> use something that allows sharing instead
<re_irc>
< (@dirbaio:matrix.org)> like rtic's monotonic or embassy's embassy-time
<re_irc>
< (@xiugaze:matrix.org)> Ok
<re_irc>
< (@xiugaze:matrix.org)> so in this driver which is for a similar delay, they use generic types to implement delay
<re_irc>
< (@dirbaio:matrix.org)> how does cortex-m systick delay allow sharing? I'm not sure it can
<re_irc>
< (@xiugaze:matrix.org)> Would directly accessing timer registers be a viable option
<re_irc>
< (@xiugaze:matrix.org)> A lot of the coursework I'm doing is assembly language, which isn't exactly fun, but it seems like the rust HAL introduces more limitaitons
<re_irc>
< (@xiugaze:matrix.org)> I don't know if I'm just doing it wrong though
<re_irc>
< (@adamgreig:matrix.org)> the nuisance is just specific to some HAL implementations
<re_irc>
< (@xiugaze:matrix.org)> okay i see
<re_irc>
< (@adamgreig:matrix.org)> in principle you could write a delay driver that uses the stm32 hardware timer to produce as many Delays as you wanted that can each be owned by drivers and shared and copied and stuff
<re_irc>
< (@xiugaze:matrix.org)> I have not heard of "embassy" before now, this sounds promising
<re_irc>
< (@adamgreig:matrix.org)> but for whatever reason that's not how the stm32f4xx-hal does it (yet)
<re_irc>
< (@dirbaio:matrix.org)> ? seems like systick delay takes exclusive ownership of the delay too? am I missing something? :D
<re_irc>
< (@dirbaio:matrix.org)> * systick
<re_irc>
< (@adamgreig:matrix.org)> oh yea I just mean you can get another delay out of it without using up a hardware timer
<re_irc>
< (@dirbaio:matrix.org)> ah okay
<re_irc>
< (@dirbaio:matrix.org)> but just 1, not N?
<re_irc>
< (@xiugaze:matrix.org)> Ok here's kind of the bigger question then: would it be viable to make my own microcontroller board and write a hal for it
<re_irc>
< (@adamgreig:matrix.org)> one could also make a niceish global delay provider based on systick I guess but you'd probably be stick to quite coarse time resolution maybe 1ms
<re_irc>
< (@adamgreig:matrix.org)> for sure, or even just adapt an existing hal, depends which microcontroller you pick
<re_irc>
< (@adamgreig:matrix.org)> in general the hal is built for a microcontroller, not a board, so usually one would make a board and use an existing hal
<re_irc>
< (@xiugaze:matrix.org)> oh right
<re_irc>
< (@adamgreig:matrix.org)> it's just if you want to use a microcontroller that doesn't already have a hal, or you want to write your own hal for whatever reason, that you'd need to write a hal
<re_irc>
< (@xiugaze:matrix.org)> That does make sense
<re_irc>
< (@adamgreig:matrix.org)> or you can not have a hal, and use the "PAC" directly to read/write the microcontroller registers
<re_irc>
< (@adamgreig:matrix.org)> but this means it's generally hard to run your code on different microcontrollers later, and it's usually more work to do
<re_irc>
< (@adamgreig:matrix.org)> but the HAL isn't magic, it's just reading/writing those registers for you, you can do without it if you wanted to
<re_irc>
< (@xiugaze:matrix.org)> Right
<re_irc>
< (@xiugaze:matrix.org)> All the work that I've done with embedded systems outside of rust has been direct memory access so I still need to get used to the HAL paradigm
<re_irc>
< (@xiugaze:matrix.org)> : what would be the disadvantages of using embassy
<re_irc>
< (@dirbaio:matrix.org)> - faster development, so somewhat more frequent breaking changes
<re_irc>
- needs nightly if you want to use async (you can not use async though!)
<re_irc>
- less mature than the most popular stm32-rs hals, though nowadays not so much, most of the stuff is already supported
<re_irc>
< (@dirbaio:matrix.org)> * don't have to
conplan has quit [Remote host closed the connection]
<re_irc>
< (@xiugaze:matrix.org)> Ok so lets say I don't care about ownership. How do I declare and use this: https://github.com/dotcypress/st7032i driver in code
<re_irc>
< (@xiugaze:matrix.org)> what does my main function look like
<re_irc>
< (@dirbaio:matrix.org)> with embassy-stm32:
<re_irc>
< (@dirbaio:matrix.org)> "embassy_time::Delay" is what allows sharing the delay. You can create infinitely many of these, by just writing "Delay". They all share a single automatically configured hardware timer
<re_irc>
< (@xiugaze:matrix.org)> So when I call "ST7032i::new(i2c, Delay)", thats passing a type?
<re_irc>
< (@xiugaze:matrix.org)> not an instance
<re_irc>
< (@dirbaio:matrix.org)> it's an "empty struct"
<re_irc>
< (@dirbaio:matrix.org)> Rust allows "empty" structs like that
<re_irc>
< (@dirbaio:matrix.org)> if it's declared as "struct Delay;" instead of "struct Delay {...}" then you can create an instance of it by writing just "Delay"
<re_irc>
< (@xiugaze:matrix.org)> i see, this is very confusing
<re_irc>
< (@dirbaio:matrix.org)> so it's an instance
<re_irc>
< (@dirbaio:matrix.org)> yeah... think of it as if it was "Delay::new()"
<re_irc>
< (@xiugaze:matrix.org)> So cargo's throwing an error when trying to import embassy:
<re_irc>
< (@xiugaze:matrix.org)> error: failed to select a version for the requirement `embassy-stm32 = "^0.1.0"`
<re_irc>
candidate versions found which didn't match: 0.0.0
<re_irc>
required by package `display_async v0.1.0 (/mnt/c/formula stuff/formula/display_async)`
<re_irc>
location searched: crates.io index
<re_irc>
< (@xiugaze:matrix.org)> looks like embassy-stm32 is at 0.1.0 according to docs
<re_irc>
< (@dirbaio:matrix.org)> it's available from git only, add this at the bottom of Cargo.toml
<re_irc>
< (@dirbaio:matrix.org)> the basic minimum for what you want to do is
<re_irc>
< (@dirbaio:matrix.org)> embassy-time = { version = "0.1.0", path = "../../embassy-time", features = ["tick-hz-32_768"] }
<re_irc>
embassy-stm32 = { version = "0.1.0", path = "../../embassy-stm32", features = ["stm32f429zi", "memory-x", "time-driver-any"] }
<re_irc>
< (@dirbaio:matrix.org)> change "stm32f429zi" with your chip name
<re_irc>
< (@xiugaze:matrix.org)> Okay
<re_irc>
< (@xiugaze:matrix.org)> so I still need a linker script
<re_irc>
< (@xiugaze:matrix.org)> what should my .cargo/config have
<re_irc>
< (@dirbaio:matrix.org)> the feature "memory-x" autogenerates a "memory.x"
<re_irc>
< (@dirbaio:matrix.org)> (you can still remove it and provide your own)
<re_irc>
< (@dirbaio:matrix.org)> : same as without embassy
<re_irc>
< (@xiugaze:matrix.org)> warning: patch for `embassy-executor` uses the features mechanism. default-features and features will not take effect because the patch dependency does not support this mechanism
<re_irc>
warning: patch for `embassy-stm32` uses the features mechanism. default-features and features will not take effect because the patch dependency does not support this mechanism
<re_irc>
warning: patch for `embassy-sync` uses the features mechanism. default-features and features will not take effect because the patch dependency does not support this mechanism
<re_irc>
warning: patch for `embassy-time` uses the features mechanism. default-features and features will not take effect because the patch dependency does not support this mechanism
<re_irc>
< (@xiugaze:matrix.org)> : this is perfect
<re_irc>
< (@xiugaze:matrix.org)> do i need to be on nightly for all of this
conplan has joined #rust-embedded
<conplan>
is anyone looking forward to the release of the Ox64? it's a microcontroller/single board computer thats open source and super capable. it will be a lot of fun to work with. Would be nice to have a rust hal on day one!
<re_irc>
< (@9names:matrix.org)> BL808 already has a PAC, and I assume at least one person in the community will have one before you do
<re_irc>
< (@9names:matrix.org)> Some of the simpler peripherals are pretty similar to bl602/bl702 so porting should not take long
<re_irc>
< (@9names:matrix.org)> Though, it must be said that those HALs are in a pretty rough state. Not many contributors, not many users.
<re_irc>
<duskmoon (Campbell He)⚡️> I believe is working on pac of other bl soc.
<re_irc>
<duskmoon (Campbell He)⚡️> Maybe he has plan of making hal
<re_irc>
<duskmoon (Campbell He)⚡️> (He is the maintainer of bl808-pac)
<re_irc>
< (@xiugaze:matrix.org)> Anyone know how to resolve this error?
<re_irc>
error[E0425]: cannot find function `__basepri_r` in module `crate::asm::inline`
<re_irc>
< (@xiugaze:matrix.org)> this is when trying to compile cortex_m
<re_irc>
< (@duskmoon:matrix.org)> Can anyone guide me on how to set the feature of pac for "critical-section"?
<re_irc>
I haven't used the "critical-section" before and just found out that "svd2rust" places "take()" inside "#[cfg(feature = "critical-section")]". Thus, users can not access "take()" by default. Can I put "critical-section" in "default"? If not, how to use "xx-pac/critical-section"?
<re_irc>
< (@grantm11235:matrix.org)> Enable the "critical-section-single-core" feature in "cortex-m"
<conplan>
duskmoon: I also added critical section as an optional dependency... don't know if that is neccesary
hwj has joined #rust-embedded
<re_irc>
< (@duskmoon:matrix.org)> : So, if one is using "a-pac", which supports a "cortex-m" soc "a", he/she needs to add "cortex-m" in the dependencies and enables "critical-section-single-core"?
<re_irc>
< (@duskmoon:matrix.org)> Or just "a-pac = { ..., features = ["critical-section"] }"?
<conplan>
I see. I tried a-pac = {... as you just described. didn't work
<re_irc>
< (@duskmoon:matrix.org)> Though it is for "riscv", I think they are quite similar
<conplan>
does riscv have critical sections
<re_irc>
< (@boondocker:matrix.org)> Yes
causal has quit [Quit: WeeChat 3.6]
<re_irc>
< (@duskmoon:matrix.org)> There is a "critical-section-single-hart" feature and "critical-section" is in dependencies
bpye has joined #rust-embedded
<re_irc>
< (@duskmoon:matrix.org)> emmm, it seems the feature is not in "v0.9.0"
hwj has quit [Quit: Leaving]
hwj has joined #rust-embedded
<conplan>
Redox
<re_irc>
< (@duskmoon:matrix.org)> I just took a look at "critical-section". It seems that the "pac" may provide implementation through "critical-section-single-core = ["cortex-m/critical-section-single-core"]" or users provide an implementation by themselves.
<re_irc>
Don't know am I right.
<re_irc>
< (@duskmoon:matrix.org)> I tried a few ways and found solutions:
<re_irc>
To allow user of a pac (riscv) to call "take()", one can add
<re_irc>
< (@9names:matrix.org)> yeah. it's expected to be handled at the HAL level, not within the PAC itself.
<re_irc>
< (@duskmoon:matrix.org)> I see
<re_irc>
< (@9names:matrix.org)> I'm not saying you can't do it this way, it's certainly not breaking any rules. it should be exposed via a feature either way, to allow a user to chose a different critical-section impl.
<re_irc>
< (@duskmoon:matrix.org)> Agree. I'm just trying to solve the problem of "not able to call "take()"".
<re_irc>
Thinking of adding this to the doc of "svd2rust"
<re_irc>
So, to go from non-secure to secure, you have to branch into an "SG" instruction. What I think is going wrong is that the code I wrote uses the "BX" instruction because I'm jumping to a pointer and not to a label.
conplan has quit [Remote host closed the connection]
<re_irc>
< (@jamesmunns:beeper.com)> You could try writing a small, divergent inline asm function?
<re_irc>
< (@jamesmunns:beeper.com)> Not so familiar with trustzone low levels tho
<re_irc>
< (@diondokter:matrix.org)> Well maybe? Could try yeah
<re_irc>
< (@jamesmunns:beeper.com)> Using BX instead of BL would mean you don't push the branch register
<re_irc>
< (@jamesmunns:beeper.com)> is your function marked as divergent (when it shouldn't be?)
<re_irc>
< (@jamesmunns:beeper.com)> Using BX instead of BL would mean you don't push the link register
<re_irc>
< (@jamesmunns:beeper.com)> (this would be a problem if you try and return past that point? since it would pop garbage off the stack on return
<re_irc>
< (@diondokter:matrix.org)> I think it does that because in my code the function call is the last call after which the function returns. So using the existing LR is an optimization so that the callee doesn't return to the caller, but instead returns to the caller of the caller.
<re_irc>
I believe this should be fine
<re_irc>
< (@diondokter:matrix.org)> "BL" can only be used with labels while "BX" and "BXL" can jump to a register value:
<re_irc>
< (@jamesmunns:beeper.com)> Yeah, I just didn't know if the ABI (?) of the trustzone stuff expects anything meaningful to be in the link register at call time
<re_irc>
< (@jamesmunns:beeper.com)> but if that's not it... then I have no idea.
<re_irc>
< (@diondokter:matrix.org)> No, it's pretty chill about that. It's up to the callee to return using "bxns lr" to go back to the non-secure world
<re_irc>
< (@jamesmunns:beeper.com)> yeah, if returning to the "caller of caller" is fine, then maybe that's okay?
<re_irc>
< (@diondokter:matrix.org)> It is and if it wasn't, then the crashing would happen when the callee returned and not when the callee was entered
<re_irc>
< (@jamesmunns:beeper.com)> Fair!
<re_irc>
<riskable> EMBEDDED RUST IS AWESOME! OMG I love the stuff I'm making thanks to the work of this community. Thanks guys!
<re_irc>
< (@diondokter:matrix.org)> Well, I've just sent a mail to ARM. Hopefully they have a response
<re_irc>
< (@jamesmunns:beeper.com)> I mean, if you make that a shim function and mark it "#[inline(always)]", I don't think it'd end up being a big deal?
<re_irc>
< (@diondokter:matrix.org)> So the thing is that I want to make this work automatically. So this has to be generated and I don't know the address before hand. This is just in my experimentation project.
<re_irc>
< (@diondokter:matrix.org)> So right now it can search for the address and get a function pointer to it. But you can't call a function pointer using BL. Only with other instructions
<re_irc>
< (@jamesmunns:beeper.com)> oh :(
<re_irc>
< (@hyphened:matrix.org)> Do you have control over what instructions exist at _NSC_VENEERS?
<re_irc>
< (@hyphened:matrix.org)> If you do you could just manually place a BL to the next instruction, and jump to that BL with a pointer
<re_irc>
< (@diondokter:matrix.org)> Well kinda... But that's part of another binary and it's even more setup. That specifically is in the wrong memory region as well, so I'd have to do that in het another memory region.
<re_irc>
I know what Arm's solution is, but to use that I would get a much more complex linking situation and I'd probably have to make a breaking change to cortex-m-rt
emerent is now known as Guest6114
emerent has joined #rust-embedded
Guest6114 has quit [Ping timeout: 276 seconds]
hwj has joined #rust-embedded
<re_irc>
< (@diondokter:matrix.org)> Ooohhh, perhaps I can cheat and generate the BL in ram and then jump to that
oak- has quit [Quit: Bridge terminating on SIGTERM]
hwj has quit [Ping timeout: 276 seconds]
oak- has joined #rust-embedded
oak- has quit [Quit: Reconnecting]
oak- has joined #rust-embedded
GenTooMan has quit [Ping timeout: 272 seconds]
<re_irc>
< (@diondokter:matrix.org)> WOW! I got it working! :D :D :D
<re_irc>
So, I went to the gym and this was still stuck in my head. Why won't it work!? Why is BL different from BX? It makes no sense why one would work and the other wouldn't. That would be terrible design.
<re_irc>
So what does BL do? It jumps to a function. Does it need to do anything fancy? No, the compiler just knows what it's doing.
<re_irc>
So what does BX do? It jumps to a function. But most importantly, there is something fancy going on with this instruction. See, the X means that it can jump to both ARM and Thumb functions. How does it distinguish this? The Thumb bit! The last bit is used to indicate if it is Thumb or ARM.
<re_irc>
< (@diondokter:matrix.org)> That "| 1" has kept it from working FOR DAYS
<re_irc>
< (@diondokter:matrix.org)> * The absence
<re_irc>
< (@diondokter:matrix.org)> +of
<re_irc>
< (@firefrommoonlight:matrix.org)> Thx for being proficient in the ASM stuff, so I can benefit from just coding in register-level and higher for my programs!
<re_irc>
< (@firefrommoonlight:matrix.org)> * stuff that underlies all we do,
<re_irc>
< (@diondokter:matrix.org)> I'm not proficient haha, this is the first time diving so deep for me :P
<re_irc>
< (@firefrommoonlight:matrix.org)> Hey, someone has got to do it!
<re_irc>
< (@diondokter:matrix.org)> That is tru!
<re_irc>
< (@diondokter:matrix.org)> * true!
<re_irc>
< (@diondokter:matrix.org)> Oh man, I can finally get rid of all the debugging gunk
hwj has joined #rust-embedded
m5zs7k has quit [*.net *.split]
thomas25 has quit [*.net *.split]
re_irc has quit [*.net *.split]
rektide has quit [*.net *.split]
limpkin has quit [*.net *.split]
re_irc has joined #rust-embedded
limpkin has joined #rust-embedded
rektide has joined #rust-embedded
thomas25 has joined #rust-embedded
m5zs7k has joined #rust-embedded
GenTooMan has joined #rust-embedded
genpaku has quit [Remote host closed the connection]
genpaku has joined #rust-embedded
hwj has quit [Ping timeout: 260 seconds]
<re_irc>
< (@sparky:matrix.possumlodge.me)> bit of an odd question but... looking at this datasheet it seems to only indicate it has SPI for an interface, yet all the nomenclature used in the command definitions maps to i2c. is there a standardized way to "translate" from one to the other im not aware of?
<re_irc>
< (@sparky:matrix.possumlodge.me)> like, page 64 defines a 4 wire interface with SCL and SDA in it... yet as far as im aware, SPI doesnt have that and it only mentions SPI on page 7 when talking about its supported interfaces
<re_irc>
< (@sparky:matrix.possumlodge.me)> then like, on page 140, it mentions DC/X, RDX, WRX, and then doesnt touch on what pin handles the actual data for read/writes...
<re_irc>
< (@sparky:matrix.possumlodge.me)> * read/writes. still trying to learn how to read all these things, and every manufacturer seems to do it slightly differently
<re_irc>
< (@ithinuel:matrix.org)> The datasheet has a peculiar naming convention that's not your usual spi nor i2c
<re_irc>
< (@grantm11235:matrix.org)> It is bidirectional spi, where MISO and MOSI are combined into SDA
<re_irc>
< (@ithinuel:matrix.org)> You can have a look at 7.1.10. SDA is used for both input and output lines.
<re_irc>
< (@grantm11235:matrix.org)> If don't care about reading from the display you can just treat SDA as MOSI
<re_irc>
< (@ithinuel:matrix.org)> Oh indeed
<re_irc>
< (@sparky:matrix.possumlodge.me)> well, im hoping to read
<re_irc>
< (@sparky:matrix.possumlodge.me)> and it looks like this is the physical pinout used is this
<re_irc>
< (@ithinuel:matrix.org)> The 4th wire is D/CX so it's not a regular spi :P
<re_irc>
< (@sparky:matrix.possumlodge.me)> the thing is, i see 5 wires in the devices documented pinout
<re_irc>
< (@sparky:matrix.possumlodge.me)> its one of those "all in one" embedded platforms, where it has a screen integrated into a case that also has an esp32 MCU
<re_irc>
< (@grantm11235:matrix.org)> That board might have a circuit to combine MISO and MOSI into one pin before it is connected to the display
<re_irc>
< (@sparky:matrix.possumlodge.me)> but it specifies two distinct GPIO pins?
<re_irc>
< (@sparky:matrix.possumlodge.me)> like, in the image linked
<re_irc>
< (@grantm11235:matrix.org)> Do you have a schematic for the board?
<re_irc>
< (@sparky:matrix.possumlodge.me)> https://docs.m5stack.com/en/core/core2 theres a schematic link on the left hand side. cant directly link to it cause stupid site
<re_irc>
< (@sparky:matrix.possumlodge.me)> i dont see such a merging in the schematic
<re_irc>
< (@sparky:matrix.possumlodge.me)> but im also a total novice...
<re_irc>
< (@ithinuel:matrix.org)> : From the table chapter 5, there's only 1 SDA pin.
<re_irc>
< (@sparky:matrix.possumlodge.me)> yeah, hence all my confusion lol
<re_irc>
< (@grantm11235:matrix.org)> I can't find a schematic for the lcd daughterboard
<re_irc>
< (@grantm11235:matrix.org)> I think that's where the merging would be
<re_irc>
< (@sparky:matrix.possumlodge.me)> so, id just assume that MISO or MOSI is SDA then and ill just have to try
<re_irc>
< (@sparky:matrix.possumlodge.me)> +to figure it out
<re_irc>
< (@ithinuel:matrix.org)> That's likely this, on the mcu side it's seen as a regular spi (because it's only half duplex it's transparent for the mcu) but there's probably some diode/transistor to merge/split the two lines from the LCD controller
dc740 has joined #rust-embedded
<re_irc>
< (@sparky:matrix.possumlodge.me)> theres a CPP driver for this, i just... really suck at reading CPP
<re_irc>
< (@sparky:matrix.possumlodge.me)> : so, to make sure i understand id use MOSI/MISO wires as is in my code, but on the LCD/in the data sheet, itd appear as only SDA?
<re_irc>
< (@grantm11235:matrix.org)> By the way, there are a bunch of rust drivers for this type of display. I think "mipidsi" is the most actively maintained
<re_irc>
< (@sparky:matrix.possumlodge.me)> is there? i looked based on the model and found nothing lol
<re_irc>
< (@grantm11235:matrix.org)> They all use the same interface and commands, but with different resolutions/etc
<re_irc>
< (@sparky:matrix.possumlodge.me)> gotcha. that saves a lot of time over trying to cobble together my own 😆
dc740 has quit [Remote host closed the connection]