crabbedhaloablut has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
agg has quit [*.net *.split]
agg has joined #rust-embedded
cr1901_ has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
lehmrob has joined #rust-embedded
lehmrob has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
jmanches[m] has joined #rust-embedded
<jmanches[m]>
Hi all, I need to implement a HAL for a new SoC, and to me choosing the "right" approach is proving to be quite challenging. Starting with the PAC, I've found at least 3 different ways: svd2rust, chiptool and RAL (like stm32-ral or imxrt-rs). Is there any recommendation for new projects? Is there any article comparing the benefits of one... (full message at
<ryan-summers[m]>
<jmanches[m]> "Hi all, I need to implement a..." <- > <@jmanches:matrix.org> Hi all, I need to implement a HAL for a new SoC, and to me choosing the "right" approach is proving to be quite challenging. Starting with the PAC, I've found at least 3 different ways: svd2rust, chiptool and RAL (like stm32-ral or... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/WFUoSToDUYQlWZqDzvfKwoyB>)
<ryan-summers[m]>
If you're using an STM32 part (you referenced lots of stm32 HALs), maybe take a look and see if embassy could easily support your chip? They take an approach of making common drivers based on the underlying silicon IP within the chips and then reusing drivers for many different processors
<ryan-summers[m]>
gith
<jmanches[m]>
<ryan-summers[m]> "> <@jmanches:matrix.org> Hi all,..." <- > <@ryan-summers:matrix.org> My view on the matter is that typestates within the HAL often makes it far more difficult to use flexibly in an end application. Anything that needs to store the type-stated object then needs to have a container that can store... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/kVGeOjNVkWKMKqPyybfPwIOO>)
M9names[m] has joined #rust-embedded
<M9names[m]>
which chip family is it, if you don't mind me asking?
<ryan-summers[m]>
Typestate is useful for some things, like I've found it nice for verifying things like getting GPIO into the right alternative function for i.e. i2c implementations
<ryan-summers[m]>
But generally its most useful for things that are typestated at setup time and not changed during runtime
<mameluc[m]>
<dagsbirta[m]> "Hello! I am new to embedded..." <- what binary optimizations do you have? 'cargo tree -d' is useful for finding duplicate dependencies. 'cargo bloat' are pretty useful to see where some of the heft comes from. defmt is awesome. watch out for generics that duplicate a lot of code. idk what your fw does but 128k can be tight. for reference I run lorawan and a bunch of sensors on 80k. idk about bootloaders and qspi for
<mameluc[m]>
expanding memory
<dagsbirta[m]>
<mameluc[m]> "what binary optimizations do you..." <- Thanks for the tip with the cargo tree, will take a closer look. I remember some of the crates used different versions of the same crates. I love defmt, but also noticed when turning it off improves the size of the binary :D... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ybBgTGQLGIPvyXzAOIVOOWIm>)
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
dagsbirta[m]: sanity check: you are running with `--release` right? I have forgotten that and wondered wtf was going on too many times haha
<dagsbirta[m]>
RockBoynton[m]: And realize that even if I manage to fit the PoC within 128k, the project and the codebase will continue growing, and I would need to have an MCU with more flash, or move to something like RT1070 and running code on the OSPI there. Now I want to go through the exercise of understanding how to do it at least on the STM32.
<dagsbirta[m]>
dagsbirta[m]: Rock Boynton: oh yeah, definitely. there is no way I could do even a simpler with dev profile without maxing out the FLASH :D
<dagsbirta[m]>
dagsbirta[m]: debugging has been fun, I had to basically create an empty project and just work with one peripheral at a time, just to root cause an issue...
<dagsbirta[m]>
* Rock Boynton: oh yeah, definitely. there is no way I could do even a simple program with dev profile without maxing out the FLASH :D
<RockBoynton[m]>
dagsbirta[m]: defmt_rtt and print debugging has been useful for me in a release app, are you using that?
<dagsbirta[m]>
RockBoynton[m]: Yes, all setup. This is basically the way I debug most of the time.
<dagsbirta[m]>
s/setup/set up/
<dagsbirta[m]>
dagsbirta[m]: `cargo tree -d` does show quite a few duplicates, actually. Let's see if I can fix some without destroying anything haha
<mameluc[m]>
<dagsbirta[m]> "`cargo tree -d` does show..." <- you can change the optimizations per crate in Cargo.toml. should be in the embedded book iirc. bigger flash is always nice for messing around. optimizing for size can wait
<dagsbirta[m]>
<mameluc[m]> "you can change the optimizations..." <- Was doing something similar when debugging for SDMMC, had to compile the HAL crate for release keeping the sdmmc and my fw unoptimized and debugger friendly. I am finally going through the book and Mastering STM32 on the side just to understand what I am dealing with on a deeper level.
<dagsbirta[m]>
Working without defmt keeps me around 84k compared to 104k before. `core::fmt::float::float_to_decimal_common_exact` takes a whopping 6.2k, but I am not sure if I can leave without it, since all audio is laden with f32 processing.
<dagsbirta[m]>
But you are right, bigger flash is definitely more welcome. Just a little tired of doing this custodian optimizations just to win another 10k just to fill it up in a few days. Hence wanted to see, whether I can put all of that to QSPI and continue with this board until I need to make something bigger.
Alistair[m] has quit [Quit: Idle timeout reached: 172800s]
jngo102[m] has quit [Quit: Idle timeout reached: 172800s]