KevinLy[m] has quit [Quit: Idle timeout reached: 172800s]
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
MariusKriegerows has joined #rust-embedded
<MariusKriegerows>
<sirhcel[m]> "Has anyone a good example/best..." <- Not sure if it helps but I ran into a similar problem once and created a little macro that only compiles a test when a specific environment variable was set. It has limitations. E.g. it does not work with async code and is rather specific to the problem I once had. But if you like give it a try
<thejpster[m]>
<JamesMunns[m]> "yeah, extern unmangled pre_init..." <- GCC has a solution for this. You put a bunch of function pointers in a section and they are all called one after the other at start-up.
<thejpster[m]>
This could work for pre-init, with a macro attribute that checks the function signature and stuffs a pointer to it into a static in the right section. We could then execute these after globals are initialised but before main
thomas25 has joined #rust-embedded
ruabmbua[m] has joined #rust-embedded
<ruabmbua[m]>
Yes that does work indeed. I am doing the same for initializing drivers in my rust codebase.
<ruabmbua[m]>
You need to take care, that the compiler does not remove stuff because it's unused, but that can be easily solved by wrapping the functionality inside a normal macro.
<ruabmbua[m]>
Doing it only with function pointers is probably a bit simpler.
<JamesMunns[m]>
fwiw: the linkme crate does this for you, kind of, and this works until you depend on the ordering of initializers (you can't), e.g. if A needs to be initialized before B because B needs something from A.
<JamesMunns[m]>
This is essentially C++'s static initializer lists, iirc
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
AtleoS has quit [Ping timeout: 256 seconds]
AtleoS has joined #rust-embedded
<jannic[m]>
These suggestions look like a lot of complexity added for a simple task that essentially boils down to "write a single register" (or 32 if you want to clear all spinlocks and not only the one used by critical_section).
jotthyr[m] has joined #rust-embedded
<jotthyr[m]>
Hi guys! I'm new to rust embedded and have strong issue disallowing me to continue my rust journey. Anyone can help here?
<JamesMunns[m]>
yep, this is the best place to ask, go for it!
<jotthyr[m]>
The main problem is to flash my nucleo board using binary stemming from rust, I've tried STM32CubeProgrammer as well as cargo flash
<JamesMunns[m]>
Are you still using the raw PAC, or have you tried using stm32f3xx-hal or embassy-stm32 yet?
<JamesMunns[m]>
If you're new to both Rust and STM32, I'd suggest starting with the HAL examples, there's a lot of ground to cover to get started, it'll help make sure you have everything set up right
<jotthyr[m]>
I've tried only stm32f3xx-hal from above
<JamesMunns[m]>
the docs seem to say that chip only has 64K of RAM, if you access addresses beyond the end, it might just crash immediately. This would be where your stack was placed.
<jotthyr[m]>
wow, that's my major mistake
<jotthyr[m]>
wait a second I will check RAM case
<diondokter[m]>
Nice one James :)
<diondokter[m]>
jotthyr[m]: Easy to miss!
<JamesMunns[m]>
jotthyr[m]: oh is it working now?
<JamesMunns[m]>
I think it's 80KiB of SRAM TOTAL, but 64KiB is mapped to 0x2000_0000, and 16KiB mapped at CCM RAM at 0x1000_0000
<JamesMunns[m]>
they just count it as 80KiB, but its not continuous
<JamesMunns[m]>
if that DOES work, you can increase to 64KiB instead of 32KiB, I was just still reading the docs and wasn't sure
<jotthyr[m]>
hahaha, you're legend!
<jotthyr[m]>
Awesome operation, thank you so much you've rescued my embedded rust journey. Hope I'll get much of it
<jotthyr[m]>
I was thinking that's too hard to get started but it's not! I was working previously on BFF in rust as a frontend DEV and got idea to get started with embedded. So guys, if I could ask question, I have experience with AVR atmega and I've worked on registers only and now moving to rust I have doubts if more benefinicial is to start writing with HAL or PAC? I want to get my rust skills on next level and not be as far from hardware
<JamesMunns[m]>
really, really, start with the HALs.
<JamesMunns[m]>
they are not "far" from the hardware, they are just the things that you definitely will need to be doing, and there are so many complicated details for every single chip, there is so little need for you to learn every part of that the hard way.
<JamesMunns[m]>
if you really want to, you can always look at the souce! It is generally MUCH more readable IMO than the vendor's HAL code, which is often autogenerated and gross and hard to follow
<JamesMunns[m]>
I'm biased, but I'd recommend you start with `embassy-stm32`, even if you aren't using async. stm32f3xx-hal is good too, but embassy-stm32 was started later, which means it has a lot of the lessons we've learned over the past years of "how to write a good Rust HAL". Lots of the UX papercuts are solved.
<JamesMunns[m]>
AFAIK embassy-stm32 is more actively maintained, as well (but 3xx-hal is not by any means abandoned or bad!)
<JamesMunns[m]>
(but this is much more opinion than science, so take it for what its worth
<JamesMunns[m]>
gotta run, glad you have something working!
<JamesMunns[m]>
oh, also check out the probe-rs CLI, new tools like probe-rs run with defmt+rtt logging vs cargo flash is so much nicer.
<jotthyr[m]>
Thanks a lot!
<Lumpio->
Maybe I'll give embassy a try oneday
<Lumpio->
Did they already make a more ergonomic USB implementation? :-)
haobogu[m] has joined #rust-embedded
<haobogu[m]>
there's embassy-usb, quite good imo
<Lumpio->
Looks pretty neat
<Lumpio->
...a bit wordy to set up maybe
<jotthyr[m]>
I'm just curious, maybe it's (not sure if that's a proper sentence) swinging in the clouds but is it even possible to rewrite this to only rust, using tft color touch screen? I'm not so familiar with ARM capabilities and as I said rust embedded https://www.youtube.com/watch?v=ziTqwE7VYRk
<Lumpio->
Rust running on a microcontroller?
<Lumpio->
I mean "TFT color touch screen and ARM" could mean a microcontroller or a full blown Linux PC heh
<diondokter[m]>
If you want to have a screen, check out embedded-graphics and maybe also slint
<jotthyr[m]>
rather a microcontroller
<K900>
Well you'd need a pretty big microcontroller to do real time object detection
<K900>
But it does not sound impossible
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
<jotthyr[m]>
and probably use RTOS?
<diondokter[m]>
STM and NXP have microcontrollers that run into many hundred megahertzes
<K900>
Why do you need an RTOS?
<K900>
Like, I'm not saying you shouldn't need an RTOS
<K900>
But I feel like you might be assuming that an RTOS will do more for you than it actually will
<jotthyr[m]>
From now it looks like mission impossible for me, but who knows
<Lumpio->
I'd say it's _possible_ to do on a microcontroller but probably would take more effort than just doing it on a computer.
<Lumpio->
Not impossible, just a lot of effort.
<K900>
Honestly I think the really hard part is the image recognition
<Lumpio->
E.g. if you want it to work or time is money, use a computer, if you think it'll be fun to learn how to do it on a microcontroller and time is free, use a microcontroller.
<K900>
The rest is just doing a little bit of physics and driving servos to move the thing
<Lumpio->
Yeah the math does not look like it'd be a hurdle on anything powerful enough to do the image recognition and GUI stuff
<K900>
But getting the image recognition part working consistently on a microcontroller will be tricky
<Lumpio->
Which in and of itself doesn't require _that_ crazy amounts of processing power - just more manual work to get it to work.
<K900>
Though you can probably go with something VERY simple especially if you choose better colors
<K900>
Like if you have a black ball on a white table it'll probably be a decent enough heuristic
<Lumpio->
I mean if you have a black background and a reflective ball an infrared camera should pretty much give you a dot exactly where the ball is no?
<K900>
But then you need an IR camera
<Lumpio->
Which is just a normal camera with a different filter
<jotthyr[m]>
The camera type is lesser problem I think
<jotthyr[m]>
The problem is to spin up whole thing
<Lumpio->
I would say that doing this on a microcontroller, with Rust currently, given a fast enough MCU, I would say that the main problems are hooking up a camera and drawing a complex GUI on a screen
<Lumpio->
Correct me if there's libraries out there that work for this already
<K900>
Slint can definitely work for the GUI
<jotthyr[m]>
I could easily change that camera if its not too costy
<jotthyr[m]>
Ok, basically good to know it's even possible, but I bet It would be pretty hard. For sure I will start from something simpler then I will estimate my abilities and resources
cesnel[m] has joined #rust-embedded
<cesnel[m]>
Hello there,
<cesnel[m]>
I presume all projects listed there are open-source, right?
<cesnel[m]>
I see that most of the crates/repos listed in awesome-embedded-rust are developed under MIT or Apache-2 license
<K900>
I don't think I understand the question
<K900>
Are you asking if that specific license is open source?
<K900>
Or are you asking if all the projects on that list are open source?
<K900>
And how do you define "open source" exactly?
<cesnel[m]>
I was wondering if all project listed have also an open source license (not necessary MIT or Apache)
<cesnel[m]>
Im not really an expert in license, but IINM both MIT and Apache are open source licenses.
<K900>
I'm not sure anyone can answer that
<K900>
Except the people maintaining that list
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]>
(the embedded WG maintains that list, fwiw)
<JamesMunns[m]>
afaik cesnel we have no specific license requirement, most inclusions on that list are people adding their own projects
<JamesMunns[m]>
So, I'd check the specific projects for questions regarding licenses. MIT and/or Apache2 are certainly the most common licenses in both Rust and Rust Embedded communities, but it's by no means required. I've also seen gpl, mpl, bsd, and others
<firefrommoonligh>
Another approach, in line with Lumpio's: Do the whole thing on the PC program, and use an off-the-shelf USB-to-CAN or USB-to-PWM bridge.
<firefrommoonligh>
That would probably be simpler because you only need to set up one program and have an allocator, but I'm always hesitant to pass a realtime, latency-sensitive system (Which this is) through a GPOS's scheduler.
<firefrommoonligh>
I would do the GUI and user-interface code on the PC program, and run the PID, servo control, data ingest/filtering and processing from sensors on the MCU
<firefrommoonligh>
The tricky part I'm not sure about is how/where to handle the camera. Probably the PC program because of the high display buffer storage space and CV requirements.
<firefrommoonligh>
Use OpenCV if sufficient, and something like Torch/OpenVINO/TensorFlow if you want fancier.
<firefrommoonligh>
(OpenCV is battle-tested, and very fast)
<firefrommoonligh>
As Lumpio said, you could probably do the CV on a MCU (Go for something like STM32H7, maybe with external flash), but it will be much easier to handle on PC
caligari[m] has quit [Quit: Idle timeout reached: 172800s]
python_destroyer has joined #rust-embedded
python_destroyer has quit [Quit: python_destroyer]