<diondokter[m]>
<danielb[m]> "are you decompiling the loader..." <- Ah interesting!
<diondokter[m]>
I just wanted to see how the header interacts with the rest of the instruction. Well, basically it doesn't haha
<diondokter[m]>
s/instruction/instructions/
<diondokter[m]>
It's so weird how the smaller header causes problems... The rest of the code of the loader is all the same at the same address in RAM
<diondokter[m]>
One thing that's curious is that the uninit routine after flashing seems to have ended just fine. Things start crashing when RTT is being connected to. Just before that there's this log: `Reason for halt has changed, old reason was Halted(Breakpoint(Unknown)), new reason is Exception timeout=100ms`
<diondokter[m]>
Not entirely sure what that means. Is the MCU hardfaulting?
kenny has quit [Quit: WeeChat 4.4.4]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
flx has quit [Quit: WeeChat 4.4.3]
fsinger has joined #rust-embedded
fsinger is now known as flx
Makarov has joined #rust-embedded
Makarov has quit [Quit: Client closed]
Makarov has joined #rust-embedded
Makarov has quit [Ping timeout: 240 seconds]
<thejpster[m]>
<chrysn[m]> "Around defmt, I'm currently..." <- That sounds fine, and is backwards compatible. Is CBOR self describing like JSON?
Foxyloxy_ has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
<chrysn[m]>
<thejpster[m]> "That sounds fine, and is..." <- yes.
dandels has quit [Ping timeout: 260 seconds]
kenny has joined #rust-embedded
kenny has quit [Quit: WeeChat 4.4.4]
flx has quit [Quit: WeeChat 4.4.3]
fsinger has joined #rust-embedded
fsinger is now known as flx
RockBoynton[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandervanSaas has joined #rust-embedded
<AlexandervanSaas>
Is there a crate for private key signatures that works without alloc? I'm currently using rsa but I would like to get rid of alloc in my application.
<AlexandervanSaas>
I'm not set on any specific algorithm. As long as it's cryptographically secure.
<danielb[m]>
<dirbaio[m]> "RSA is not state-of-the-art..." <- and (literal) back doors included?
rafael[m] has joined #rust-embedded
<rafael[m]>
Good evening, I want to integrate a MPU-6050 in my project, I have found this driver: https://crates.io/crates/mpu6050-dmp by barafael I believe, at least if there are not two people with the same nickname 🙂 The GitHub version even has async support. Now to my question: Are there any good examples of this in action? I find a few on GitHub, but only one looks like somewhat complete, and there a lot of code in uncommented... never
<rafael[m]>
a good sign 🙂
<danielb[m]>
* doors included? just how ironic would it be? 🤔🙃
<rafael[m]>
s/in/is/
rahix[m] has quit [Quit: Idle timeout reached: 172800s]
Noah[m] has quit [Quit: Idle timeout reached: 172800s]
barafael[m] has joined #rust-embedded
<barafael[m]>
Hi! I lifted this driver from the drogue ecosystem, brought it into e-hal. Added e-hal 1.0. I didn't port the example yet because at the time the stm32f1 hal didn't support e-hal 1
<rafael[m]>
Ah but the example would still be educatiinal I guess?
<barafael[m]>
In general I would recommend using a bno085
<barafael[m]>
rafael[m]: Yes, once I can write it! Needs e-hal 1 obvs
<rafael[m]>
barafael[m]: For now the cheap thing I found in a box in my basement must do 😅
<danielb[m]>
it's still possible to buy MPU6050? wasn't that thing NRND like 7 years ago?
<barafael[m]>
About the docs,I can't do much there, only half understand it
<barafael[m]>
mpu6050 will be around in 50yrs I swear...
<rafael[m]>
barafael[m]: I meant ir may still make sense for me to look at it, even if outdated.
<barafael[m]>
In that case - isn't there a full stm32f1 example in the repo?
<barafael[m]>
Ah no, but it is linked in the range
<rafael[m]>
I will have a look later, did not think to check the repo You forked from.
<barafael[m]>
s/range/readme/
<barafael[m]>
rafael[m]: Wouldn't recommend that, it's super old. There are 2 demo projects in the readme, f1 and f4
<barafael[m]>
Let me know if you have any issues. Or success
<rafael[m]>
danielb[m]: I do not know about pro suppliers, but hobbyist places have them
<rafael[m]>
barafael[m]: If I have success I can PR an example
<rafael[m]>
If not I will yell for help
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<hjeldin__[m]>
is it possible to change the system clock at runtime? i'm following the low_power example from the embassy-stm32 crate where it states that it "may" be required that the clock is lower than 16mhz, but i'd like to keep chugging along at 80mhz until it's time to sleep. calling init again panics and chatgpt is telling me to manually edit the registers so it's either unsupported or a bad idea
<dirbaio[m]>
<danielb[m]> "and (literal) back doors..." <- We're using in in prod, so hopefully not :D
<danielb[m]>
dirbaio[m]: and how many back doors are your product installed on? 🙃
<danielb[m]>
oh wait the other way around
<dirbaio[m]>
danielb[m]: These back doors have no back doors okay?
<dirbaio[m]>
<hjeldin__[m]> "is it possible to change the..." <- embassy-stm32 doesn't currently support changing clocks dynamically, no. You shouldn't need it though. Where does "it states that it "may" be required that the clock is lower than 16mhz" come from?
<dirbaio[m]>
it might be a bug with the impl for that particular chip, there's no reason the hardware needs that afaik. i'd try ignoring that and see if it works.
<dirbaio[m]>
especially if you're not using h5
<hjeldin__[m]>
it doesn't 😄 i'm starting to guess that the issue is not the clock speed
<hjeldin__[m]>
i get a "TRACE low power: stop with rtc configured
<hjeldin__[m]>
TRACE low power: not ready to stop" and it keeps on saying it's not ready to stop, which led me into a rabbit hole trying to gather how REFCOUNT_STOP2 is used. it appears i need to manually disable rcc and or all peripherals?
<hjeldin__[m]>
* i get a "TRACE low power: stop with rtc configured
<hjeldin__[m]>
TRACE low power: not ready to stop" and it keeps on saying it's not ready to stop, which led me into a rabbit hole trying to gather how REFCOUNT\_STOP2 is used. it appears i need to manually disable rcc and or all peripherals (i2c/spi/usart)?
<dirbaio[m]>
yes, to go to STOP mode you need to disable all peripherals that need clock
<dirbaio[m]>
* that need the run-mode clock
<dirbaio[m]>
when all tasks go to sleep, the executor checks whether you have one of these peripherals created
<dirbaio[m]>
if you do, it sleeps only the CPU (with WFE), to prevent these peripherals from breaking
<dirbaio[m]>
if you don't, it goes to STOP mode
<hjeldin__[m]>
and that is probably the reason why the bare bone example works, gotcha. thank you very much!
<dirbaio[m]>
which peripherals need which clock is documented ...somewhere... in the RM
<dirbaio[m]>
you can create these peripherals with `&mut` on the singletons so you can dynamically drop+recreate them
<dirbaio[m]>
^ this is an example for nrf, but the same idea works for stm32
<dirbaio[m]>
so for example for spi, i2c you can dynamically create+use+delete the peripheral every time you need to use it, instead of leaving it always created
<dirbaio[m]>
yes, it'll be a bit slower, but not that much. initializing i2c/spi is reasonably fast
<hjeldin__[m]>
and as long as it only happens once per resume from sleep it's ok, my requirements are not that strict