<M9names[m]>
see the "Existing Open-Source Plugin" heading
<M9names[m]>
"This plugin will remain open source and freely available on GitHub and the JetBrains Marketplace. However, moving forward, we will be investing our efforts into RustRover, which is closed source"
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
aka "thanks for the free contributions and feedback, but we'll take it from here 🤑"
<M9names[m]>
pretty much. it doesn't really make sense for a commercial tooling company to give away their only source of income for free though, so I understand the rationale
<dirbaio[m]>
is it better enough than rust-analyzer to justify paying?
<dirbaio[m]>
(never used the intellij rust plugin)
<dirbaio[m]>
* rust plugin myself)
<firefrommoonligh>
From playing around for 30 mins, the performance problems I have with PyCharm haven't showed up yet; promising
<firefrommoonligh>
<dirbaio[m]> "aka "thanks for the free..." <- Their IDEs are outstanding, so I'd prefer they keep doing whatever they're doing
<firefrommoonligh>
dirbaio[m]: Yes
<firefrommoonligh>
Introspection/refactoring/treating projects as separate from one another is smoother
<dirbaio[m]>
for Rust?
<firefrommoonligh>
But this is subjective. It's free currently, so I would try it and see what you think
<dirbaio[m]>
(I did use it a while ago for Java and it was indeed outstanding)
<dirbaio[m]>
(but I guess this depends on the language..?)
<firefrommoonligh>
Also, IIRC they give away licenses to OSS project maintainers; might try playing that card
<M9names[m]>
*non-commercial OSS projects, core maintainers aren't allowed to be paid
<M9names[m]>
i know it's not really a problem we have, but still
<M9names[m]>
i don't know how it works when it's "for work" but all the OSS stuff happens in your non-paid time. they probably wouldn't care for small projects tbh
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
<JamesMunns[m]>
<dirbaio[m]> "aka "thanks for the free..." <- Idk, what is open source today stays open source, they just are going to work on a closed fork now. It's less icky than a license change if it's something permissive now, imo.
<dirbaio[m]>
makes sense to avoid a terraform-style meltdown
<dirbaio[m]>
but if the opensource one stops getting updates and merges the outcome is effectively the same :P
<JamesMunns[m]>
Yeah but business gotta business. Community COULD continue or make their own fork, just not with jetbrains' paid dev hours
<firefrommoonligh>
dirbaio[m]: This is likely
<firefrommoonligh>
With the amount of time I spend using their products, the cost is worth it. Nice mattresss/office chair analogy
<JamesMunns[m]>
Yeah, totally worth it to pay for tools if you can.
<JamesMunns[m]>
(happy sublime text user here :D)
<dirbaio[m]>
sublime text, that's a name I haven't heard in a while :D
<dirbaio[m]>
s/haven/hadn/
<JamesMunns[m]>
Its super quick, and can open multi-gb log files without falling over :D
<JamesMunns[m]>
Plus it has R-A/LSP support, what more could you want
<dirbaio[m]>
oh wow, really? :O
<dirbaio[m]>
so it's a serious competitor to vscode nowadays then
<dirbaio[m]>
I used it back in 2013 to code in PHP 🤪
<JamesMunns[m]>
Yeah, been using it since 2010 or so?
<JamesMunns[m]>
Bought st2, then 3, then 4
<dirbaio[m]>
but then Atom came out
<JamesMunns[m]>
Worth the ~200 I've spent on it across like 13 years, easy lol
<dirbaio[m]>
shit it's 4am again
<dirbaio[m]>
been staring at ST registers for too long, gonna try sleep a bit
<firefrommoonligh>
<JamesMunns[m]> "(happy sublime text user here :D..." <- Same! I use sublime for one-off files, ie not associated with a project
<firefrommoonligh>
It gets points for still being responsive/low-latency in 2023
Darius has quit [Ping timeout: 240 seconds]
Darius has joined #rust-embedded
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #rust-embedded
hifi has quit [Server closed connection]
hifi has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
juliand[m] has joined #rust-embedded
<juliand[m]>
<firefrommoonligh> "https://www.jetbrains.com/rust/..."; <- Didn't jetbrains start their competitor to vscode (fleet) only like a year ago? Seems a bit odd that they start another language-specific IDE now 👀
<K900>
That's a different thing
<K900>
Most of their current products (including this one) are based on IDEA, not Fleet
<K900>
Fleet is more of an experimental product off to the side
<juliand[m]>
So they just want to go down two roads now? Thought fleet was the start of a new paradigm because IDEA was too slow or so.
<K900>
I don't think they have a specific plan for that yet
<K900>
They just want to try it and see where it goes
<juliand[m]>
Hm, I mean if the Rust IDE works a lot better than vscode + RA (as the rust plugin did like 2-3 years ago) it's probably really worth paying for it after all.
<juliand[m]>
K900: True... replacing vs code is going to be difficult
thejpster[m] has joined #rust-embedded
<thejpster[m]>
I stopped using Sublime Text when they did an auto update that ended my licence and started giving me nag screens. I’ve bought two copies so far but I’m not sure I’ll buy a third.
<thejpster[m]>
VS Code has multiple cursors abs that was Sublime’s magic trick.
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
<Farooq>
<firefrommoonligh> "If you think you can do this..." <- Thanks the value line seems a good start!
<Farooq>
<dirbaio[m]> "aka "thanks for the free..." <- isn't the licence copyleft?
<JamesMunns[m]>
Farooq: The plugin was MIT, when I looked briefly
<Farooq>
I know that many are against copyleft. But I am happy I can install a FOSS OS on my phone because the kernel and the gecko part are still open source. If the UI/System app of my phone was also open source, I would have less difficulty writing another System app. My phone is KaiOS.
<Farooq>
* is KaiOS(the mobile OS).
<Farooq>
I haven't got any no_std Rust experience. Is it a good idea to start a prototype with what I've got now which is an ESP32 and when I got the STM32 and the needed radio module, rewrite it? Is it a waste of time?
<Farooq>
As a background, I am trying to turn an RC toy car into a car which can act upon itself and also can be controlled remotely and I can see the camera feed.
s7rul[m] has joined #rust-embedded
<s7rul[m]>
<Farooq> "I haven't got any no_std Rust..." <- Maybe do not start building a prototype but definitely play around with blinking some leds, debugging and maybe I2C or SPI, if you have not done any embedded Rust before. If there is a long time until you get your hands on a STM32 then you can start prototyping parts and use embedded_hal to get it MCU independent.
<s7rul[m]>
Souds like a really cool and fun project BTW
<Farooq>
s7rul[m]: ah okay good idea
<Farooq>
s7rul[m]: I also want to implement AccelWord in it :D
<s7rul[m]>
Cool have not that much experience in robotics but running heavier tasks on a single card computer with a OS and running lower level control on a MCU is a common design. Might be something to consider. Memmory allocation is kind of nice for many things.
<firefrommoonligh>
<thejpster[m]> "I stopped using Sublime Text..." <- That's annoying!
Guest7221 has left #rust-embedded [Error from remote client]
brazuca has quit [Ping timeout: 245 seconds]
<Farooq>
Happy nvim user here
brazuca has joined #rust-embedded
Guest7221 has joined #rust-embedded
notgull has quit [Ping timeout: 240 seconds]
notgull has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
Guest7221 has joined #rust-embedded
<firefrommoonligh>
<Farooq> "As a background, I am trying..." <- FYSA I have a Rust quadcopter project that does that, and a WIP autonomous sailboat I'm about to test
<firefrommoonligh>
Using stm32
<firefrommoonligh>
And Adam launches rockets
<firefrommoonligh>
So this is doable
<Farooq>
firefrommoonlight The thing is that I want to implement AI on the STM32 chip too!
<firefrommoonligh>
I don't know what AI means
<Farooq>
I want to enable the RC car to decide upon itself
<Farooq>
Using vision and audio data
<firefrommoonligh>
Then program that in
<Farooq>
Yeah but some folks think this is not doable using STM32s up to a good scale :)
<firefrommoonligh>
For vision stuff, consider offloading that to an external device like Cortex-A
<firefrommoonligh>
So, I guess consider me in that group
<firefrommoonligh>
Audio is more feasible
<firefrommoonligh>
As are the various other sensors you might ise
<Farooq>
firefrommoonligh: No I want to make it work on Cortex-M :)
<firefrommoonligh>
It's the vision I suspect will be the problem
<Farooq>
firefrommoonligh: That's why it's a good challange :))))
<firefrommoonligh>
Ok try it then
<Farooq>
firefrommoonligh: I want to use an accelometer
<firefrommoonligh>
I (we?) just don't suspect it's the first tool choice here. If the images are small and/or low update rate it could work
<firefrommoonligh>
Farooq: That's easy
<Farooq>
firefrommoonligh: Yeah I want to see if I can use it for audio
<firefrommoonligh>
Stm32's SAI periph is fine for that. Def recommend H7 if it's a high bit rate
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
It depends what kind of image processing you want to do. If you just want to point a camera at the ground and follow a line, you should have plenty of processing power. If you want to use the camera to identify a cat or something, then you might need something more powerful
<ilpalazzo-ojiis4>
It's a big type I've implemented myself, so no dice.
<GrantM11235[m]>
You can also use `Mutex<Cell<Option<T>>>` with `take`, just remember to put the value back when you are done. This works especially well if `T` is a reference
<GrantM11235[m]>
324B for memcpy doesn't sound too unreasonable to me
<timokrgr[m]>
looking at the output of objdump it lookis like memcpy really is that big
<timokrgr[m]>
probably a lot of unrolling
<timokrgr[m]>
with "build-std" and opt-level = "z" memcpy goes down to 154 bytes
<GrantM11235[m]>
When you build without defmt-rtt, does memcpy go away?
<timokrgr[m]>
yeah, withuot defmt-rtt its really just the startup code and the default exceptino handlers
<ilpalazzo-ojiis4>
Out of curiosity: Is there a specific reason why static_cell is preferred here over the ~12 other similar crates such as lazy_static or whatever?
Charles[m] has joined #rust-embedded
<Charles[m]>
Do you mean once_cell? One reason is that once_cell's functionality is in the process of being merged into the standard library
<GrantM11235[m]>
OnceCell can't be sent between threads, and it only gives you a `&T`, not a `&mut T`
<GrantM11235[m]>
I think lazy_static also only gives you a `&T`
<GrantM11235[m]>
static_cell is more like Box::leak
<GrantM11235[m]>
Have you tried a more recent toolchain? You nightly is almost a year old
<GrantM11235[m]>
s/You/Your/
<M9names[m]>
Looks like all the avr templates are using a 2023-08-08 now, might be worth a try
<thejpster[m]>
> +1,290 −952
<thejpster[m]>
Oh no. That's a 6,000 line project.
<thejpster[m]>
https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/95 - I got carried away and kind of totally changed how embedded-sdmmc works. So glad I'm not doing it in C! In Rust you can just hack the structs and then keep fixing compiler errors until you've found all the code that touched those struct fields. C would have happily zero initialised stuff and broken everything.
<thejpster[m]>
Anyway, file handles and directory handles are now integers.
pbsds has quit [Ping timeout: 246 seconds]
pbsds has joined #rust-embedded
PhilMarkgraf[m] has joined #rust-embedded
<PhilMarkgraf[m]>
What approach do folks use for having multiple drivers share a resource like an I2C or SPI bus? For example, I am using eldruin's excellent eeprom24x driver and need to write a driver for an ADC on the same I2C bus. The Eeprom24x driver's new() appears to take and retain ownership of the I2C resource on creation. (I'm certain... (full message at