<M9names[m]>
<RockBoynton[m]> "Try adding this to your `.cargo..." <- Since people keep providing optimisation suggestions instead of answering your question, I'll just say it: yes you should write a bootloader to initialise QSPI XIP and write your app there.
<dagsbirta[m]>
<M9names[m]> "Since people keep providing..." <- As opposed to using something from ST? I also found a few bootloaders written in Rust, but they seem a little bit "too production ready" with encryption, signing and all that.
<dagsbirta[m]>
dagsbirta[m]: In any case, thank you to everyone! I will try to go at it and write a minimal bootloader for this
<M9names[m]>
<dagsbirta[m]> "In any case, thank you to..." <- > as opposed to using something from ST
<M9names[m]>
I had assumed that since we're having this discussion you would prefer not to, but using ST's bootloader is a perfectly valid option
<Lumpio->
djdisodo[m]: Would read operations work without a &mut..?
<dagsbirta[m]>
M9names[m]: I think what I wanted to know, whether this is going to be a herculean task for me to tackle as a beginner, and it would make more sense to deal with the issues of the ST bootloader, rather than creating something from scratch.
<dagsbirta[m]>
Guess on top of that what I am looking for are the people who have implemented something like this, and probably have some gotchas. Googling this topic wasn't successful unfortunately.
<djdisodo[m]>
Lumpio-: idk but maybe it can't
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
<dagsbirta[m]> "I think what I wanted to know..." <- As someone who's been working on STM32 audio projects for some years now, I have to say that 128k of flash is not really sufficient in most cases. Even with plain C code.
<JamesMunns[m]>
sourcebox[m]: Yep! bbq2 isn't written/updated for that yet, but I have a variant of bbqueue in mnemos that is/was intended for IPC, and could be useful across architectures (tho for now I still use usizes, which won't work)
therealprof[m] has joined #rust-embedded
<therealprof[m]>
@room Hi all, you may have wondered about my long absence and unresponsiveness to personal messages and you deserve to know why that is: Recently, my partner unpredictably passed away and I've been busy to deal with the fallout and adjusting my daily life and my family to the new situation. Unfortunately I won't have any bandwidth for the foreseeable time to care about side gigs like embedded Rust and I'll have to go dark again
<therealprof[m]>
for some time to focus on other stuff.
K900 has joined #rust-embedded
<K900>
Please take care
<K900>
Oh god
<JamesMunns[m]>
therealprof[m]: I'm so sorry to hear that, if there is anything I can do to help, please let me know.
<diondokter[m]>
Oh man. That sucks. Take as much time as you need
<diondokter[m]>
* Oh man. That's horrible. Take as much time as you need
glaeqen[m] has joined #rust-embedded
<glaeqen[m]>
@therealprof My condolences, all the best to you and your close ones ❤️
PedroFerreira[m] has joined #rust-embedded
<PedroFerreira[m]>
therealprof[m]: I am so sorry. My condolences, and I hope that you will get back on your feet quickly and with as little pain as the situation allows. Take care!
jannic[m] has joined #rust-embedded
<jannic[m]>
If there's anything you want us to take care of, just ask! (And don't worry about being unresponsive. That's totally fine, there are much more important things than this computer stuff...)
calisti[m] has joined #rust-embedded
<calisti[m]>
My heartfelt condolences to you. 🖤
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
adamhott[m] has joined #rust-embedded
<adamhott[m]>
<therealprof[m]> "@room Hi all, you may have..." <- No words, I'm so sorry this happened.
<dagsbirta[m]>
<sourcebox[m]> "As someone who's been working on..." <- That was my biggest concern going into this. I remember anecdotally and somewhat personally that Rust binaries are quite heavy compared to that of C. Was also contemplating maybe I should start learning embedded with a traditional way, bite the bullet and remember how to C. I guess the first interactions with STM32 HAL kinda killed all the enthusiasm about it and I
<dagsbirta[m]>
discovered embedded-hal is so much nicer to work with, with all the zero-cost abstractions of Rust. Nice to hear that I would have experienced the same problems there haha
<ryan-summers[m]>
<therealprof[m]> "@room Hi all, you may have..." <- To reiterate with what others have said here, I'm incredibly sorry - I can't imagine what you're going through. By all means, take all the time you need
jmanches[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
<dagsbirta[m]> "That was my biggest concern..." <- I would not even consider to use the Daisy board for any serious project in whatever language because of the 128k flash memory. Think of all the stuff you have to include e.g. USB stack, fonts if you attach a display, file system code.
<sourcebox[m]>
sourcebox[m]: A typical custom bootloader I've written with sd card support and some font to display messages to the user takes about 24k with ST-HAL.
<dagsbirta[m]>
sourcebox[m]: Completely agree with you. I didn't know better, and I had it laying around. I am building a sampler, so having a decently sized SDRAM was more important. Now that I've been tinkering with it for a while, I see all the limitations. The flash is annoying, the digital noise is also a big pain, ADC is extremely noisy... You live you learn I guess
<sourcebox[m]>
dagsbirta[m]: So having 256k flash is not a bad thing for most cases.
<sourcebox[m]>
sourcebox[m]: ADC noise is something you have to live with in any MCU. This is because of having too much high speed signals within µm range on the die.
<dagsbirta[m]>
sourcebox[m]: Would it make sense to write the bootloader with Rust or it's just a better option?
<dagsbirta[m]>
sourcebox[m]: I was getting around 500ma peak to peak, and had to throw a bunch of capacitors at it. Was down to 150-200ma and stopped there. I switched completely to MIDI control because it was more stable. It's a shame though that the resolution had suffered
<sourcebox[m]>
dagsbirta[m]: I didn't write a bootloader with Rust yet. But I think if you use all the usual tricks to minimize code size, it should be comparable. But if you're just starting with embedded Rust, I would do something simpler as a start.
<dagsbirta[m]>
sourcebox[m]: Thank you. There is a chapter about bootloaders in Mastering STM32, I guess I will use that as a start.
<sourcebox[m]>
dagsbirta[m]: When using the internal ADCs, enable 16x oversampling and some dynamic filtering. I've written a crate for that here: https://crates.io/crates/dyn-smooth
<dagsbirta[m]>
sourcebox[m]: In general, I was thinking of making a custom board, as I would also like to have a better codec (more channels), and perhaps a better MCU for that reason. Was thinking as well of separating the analog and digital parts on the pcb, hoping that it would alleviate the noisy ADCs
<sourcebox[m]>
dagsbirta[m]: For audio, use an external codec in any case. The ADCs are usable for pots, CV in etc.
<dagsbirta[m]>
dagsbirta[m]: Separating it came from the general sentiment in Daisy that both the codec and ADC is noisy, because the board is just too tight
<dagsbirta[m]>
sourcebox[m]: 100%, already have my eyes on a few that I found in Mouser. But I think this would be down the line. I've never designed a board before, but I am surprised how much learning material is out there to hold your hand
<sourcebox[m]>
dagsbirta[m]: You can use a codec breakout board.
<dagsbirta[m]>
sourcebox[m]: Might be a first good step to make a breakout board, I need more channels unfortunately, and failed to find a ready-made solution. Thanks!
<dagsbirta[m]>
dagsbirta[m]: I was inspired by https://www.youtube.com/watch?v=AA_ls_9YdYk and was thinking of doing something similar, where I would have the board with all the analog and audio stuff, and could exchange the compute module, if I needed to try something more powerful without redoing the whole board.
<sourcebox[m]>
dagsbirta[m]: Yes, but you need to be familar enough with PCB design.
<dagsbirta[m]>
sourcebox[m]: Yeah, I have limited experience and realized that it is going to take quite some time to grok it, but I think that would be my goal for the next months and potentially years.
<dagsbirta[m]>
dagsbirta[m]: Thank you for your advice, really appreciate it. I will give it a shot and write a small bootloader with ST hal.
<sourcebox[m]>
<dagsbirta[m]> "Thank you for your advice..." <- Not sure if this was already mentioned, but it's some general reading how to get the code size down: https://github.com/johnthagen/min-sized-rust
<sourcebox[m]>
sourcebox[m]: If you like to experiment, take what you currently have and apply the suggestions. Would be interesting how much it gives.
lehmrob has quit [Quit: Konversation terminated!]
towynlin[m] has joined #rust-embedded
<towynlin[m]>
So sorry for your loss. Take care. Wishing you and your family and friends peace and healing.
freakingpenguin has quit [Ping timeout: 252 seconds]
Henk[m] has joined #rust-embedded
<Henk[m]>
<therealprof[m]> "@room Hi all, you may have..." <- That is horrible. So sorry for your loss. Take care of yourself
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
GeorgesP[m] has joined #rust-embedded
<GeorgesP[m]>
therealprof: hi, we need to update your INA260 crate to support async and update embedded-hal to 1.0.0. Can we make a PR so you can merge and publish a new crate version ?
<GeorgesP[m]>
Oops sorry I didn't read your message above. Take your time, we will figure out how to do it. Wish you strength to overcome this difficult times.
<PhilMarkgraf[m]>
In a "Rust is not C" moment, I've discovered that Rust does not guarantee the order of data in structs (unless you set the repr attribute.) I have deployed hardware with firmware written in Rust that has data in a Rust data structure written to flash memory that I now realize does not have the fields in the order I expected. (I've also realizes that the read order can change when the compiler updates.)
<PhilMarkgraf[m]>
How can I determine the current layout of the data structure in memory? (I'm hoping there is some nice bit of tooling. If I have to reverse engineer this... the data structure is not so large/complex as to make it unmanageable.)
<PhilMarkgraf[m]>
Now that I write it out... I think I can use core::ptr::addr_of() and defmt that information off of the device.
<diondokter[m]>
I'm off to sleep now. But I'd look at the debug info generated
<diondokter[m]>
Something like `readelf --debug-dump your/elf/file > out.txt`
<diondokter[m]>
Then search for the name of your struct in the output file.
<diondokter[m]>
You can also use GUI tools to look at it like Dwex, a python thing.