ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
brazuca has quit [Quit: Client closed]
justacec[m] has quit [Quit: Idle timeout reached: 172800s]
duderonomy has quit [Ping timeout: 255 seconds]
duderonomy has joined #rust-embedded
pbsds has quit [Ping timeout: 240 seconds]
pbsds has joined #rust-embedded
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #rust-embedded
cyrozap has quit [Client Quit]
cyrozap has joined #rust-embedded
cyrozap has quit [Ping timeout: 264 seconds]
_whitelogger has joined #rust-embedded
cyrozap has joined #rust-embedded
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #rust-embedded
cyrozap has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
cyrozap has joined #rust-embedded
notgull has quit [Ping timeout: 260 seconds]
notgull has joined #rust-embedded
lightningwright has quit [Ping timeout: 252 seconds]
lightningwright has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
emerent is now known as Guest6200
emerent has joined #rust-embedded
Guest6200 has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
lightningwright has quit [Ping timeout: 258 seconds]
lightningwright has joined #rust-embedded
lightningwright has quit [Ping timeout: 260 seconds]
lightningwright has joined #rust-embedded
Farooq has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
Guest7221 has left #rust-embedded [Error from remote client]
harishkumaran[m] has joined #rust-embedded
<harishkumaran[m]> Hi Everyone! is it possible to learn embedded development without using any microcontroller using just a simulator?
<harishkumaran[m]> I am a newbie so the question might seem dumb😅
<harishkumaran[m]> If yes please explain any software that could be used for this purpose. Thanks in advance!
<JamesMunns[m]> It's not dumb! It's a very reasonable question!
<JamesMunns[m]> There are some things you could learn with just a simulator: like writing code for smaller devices. The challenge with this is that a lot of embedded/microcontroller development comes down to "how do I interact with the 'accessories' or 'peripherals' that are specific to my chip".
<JamesMunns[m]> These are things like serial ports, or gpios you use to read a button or turn on an LED. They are very different depending on which chip you use
<JamesMunns[m]> QEMU is often used for simulating MCUs, but while it simulates the main CPU, it doesn't simulate very many peripherals.
<JamesMunns[m]> There are newer projects, like wowki, that do simulate more peripherals!
FreeKill[m] has joined #rust-embedded
<FreeKill[m]> I kicked the tyres on Renode a while ago, that also does peripheral simulation
<JamesMunns[m]> https://docs.rust-embedded.org/book/start/qemu.html talks about how to set up QEMU
<FreeKill[m]> And it supports (some) STM32 cores out of the box, which is a great entry point
<JamesMunns[m]> Looking for a guide for wowki now...
<FreeKill[m]> It's also nice because it hosts a GDB server itself, so you can debug the emulated core really really easily
<JamesMunns[m]> But the answer in my opinion is "you could probably start with a simulator, but you would probably want to switch to real hardware pretty quickly, and you will definitely learn a lot of other things once you do"!
<FreeKill[m]> Plus blinking a real LED is the greatest joy we can experience on this earth
<harishkumaran[m]> JamesMunns[m]: that's the problem,, I don't know many basics and I would like to build a strong base first
<harishkumaran[m]> The Rust Embedded book was really good but I am not sure whether I have to bet on rust(since most of the book is based on rust) or start with C since it is more reliable I guess, I am not sure.
<JamesMunns[m]> https://wokwi.com/rust seems to be a good example
<JamesMunns[m]> FreeKill[m]: Ah, renode was the other one I was trying to think of!
<FreeKill[m]> harishkumaran[m]: > <@harishkumaran:tchncs.de> that's the problem,, I don't know many basics and I would like to build a strong base first
<FreeKill[m]> > The Rust Embedded book was really good but I am not sure whether I have to bet on rust(since most of the book is based on rust) or start with C since it is more reliable I guess, I am not sure.
<FreeKill[m]> The hard part of learning embedded is not really the language. The lessons will transfer regardless of where you start :)
<harishkumaran[m]> FreeKill[m]: I have programmed arduino but thats the biigest thing I have done yet lol
<harishkumaran[m]> FreeKill[m]: gr8
<FreeKill[m]> Then you have hardware already ;p
<JamesMunns[m]> We all start somewhere! the most important part of learning is not getting discouraged and wanting to keep trying
<JamesMunns[m]> I would personally suggest doing things in this order:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QeFJpysjuByPPPCSfZGZwEsl>)
<harishkumaran[m]> JamesMunns[m]: could you recommend a good source like "embedded rust book" but that is more geared towards beginners(i was able to understand the embedded rust book easily) but with C?
<JamesMunns[m]> You mean "learning embedded with C"?
<harishkumaran[m]> JamesMunns[m]: yes tbh i dont know what to choose since the rust embedded book itself says that c will have more established stuff related to embedded, if i am wrong pls correct me i want to be corrected
<JamesMunns[m]> I'm sure there are lots of books, but I don't have any I can personally recommend. I learned C + embedded a long time ago, and I hope there are better books now than I had then!
<JamesMunns[m]> Maybe someone else will have a good suggestion. Otherwise we are usually very happy to answer questions here :)
<harishkumaran[m]> JamesMunns[m]: thanks for your patient response for evrything🙏
<FreeKill[m]> I think "Making Embedded Systems" by Elicia White is very good
<FreeKill[m]> It's not completely beginner focused... but if you have programming experience generally, I think you can hang in there
<FreeKill[m]> But again the language side really isn't that hard. An embedded C codebase looks pretty simple most of the time.
<FreeKill[m]> If you're new to embedded I would recommend getting a dev kit or at least MCU that is popular and convenient to work with, and then just start trying to make it do stuff.
<FreeKill[m]> Go into the reference manual, look at the peripherals that you have access to and find ways to try them out. You'll learn a lot just pulling on that thread.
<harishkumaran[m]> FreeKill[m]: > <@larunite:matrix.org> But again the language side really isn't that hard. An embedded C codebase looks pretty simple most of the time.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/SdGZDlXAMhjMAwWqERXwoPVs>)
<FreeKill[m]> And then when you have some ideas about how it works in C, it becomes easy to appreciate the nice things embedded Rust offers you
<FreeKill[m]> That is the typical place to start, yep
pbsds has quit [Ping timeout: 240 seconds]
pbsds has joined #rust-embedded
Guest7221 has joined #rust-embedded
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio> I'll add that STM reference manuals are terrible for learning anything embedded. They assume you're already proficient and really are just for reference
<dngrsspookyvisio> rp2040 is much better in this regard
<FreeKill[m]> Oh I would not agree with that at all, but to each their own
<FreeKill[m]> I suppose the stm manuals won't teach you fundamentals - like they won't explain what buses are or why they're important - but when I was earlier in my career I learnt loads by just going through one peripheral at a time and trying to make it work
GijsBurghoorn[m] has quit [Quit: Idle timeout reached: 172800s]
<likewise[m]> FreeKill: Same here. STM32 was nice, then later I liked the
<likewise[m]> nRF task/event matrix design as well.
<firefrommoonligh> <dngrsspookyvisio> "I'll add that STM reference..." <- They do 2 main things for me:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/oklDJbSEpuVrvZRZyxszCagO>)
<firefrommoonligh> General example: There are a lot of words and I don't know what they are mean; instead of getting overwhelmed, maybe look at the CR register fields and see there are only a handful of ways you can set up the peripheral, and set the flags that seem to make sense
<dngrsspookyvisio> yeah, that's a reference
<thejpster[m]> weee: this was a fun evening exercise - https://github.com/rust-embedded-community/embedded-sdmmc-rs/pull/100. I made a little interactive shell for browsing hard disk images.
ilpalazzo-ojiis4 has joined #rust-embedded
<ilpalazzo-ojiis4> I really hope this question is not AVR-specific:
<ilpalazzo-ojiis4> I have a pin, ordinarily used as a digital input, which needs to be read analogue every once in a while.
<ilpalazzo-ojiis4> But that doesn't work, because into_analog_input apparently consumes the pin.
<ilpalazzo-ojiis4> What do I do in this case?
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]> You could add a function to the hal that turns a `&mut DigitalPin` into a `&mut AnalogPin` or something, or you could do some juggling to work around it in your code
<ilpalazzo-ojiis4> Add a function… to the HAL?
<ilpalazzo-ojiis4> I'd much rather fiddle around with unsafe.
<ilpalazzo-ojiis4> (Which is what I'm doing already, except it ends up miscompiling and I'm pretty sure it's because of this.)
<ilpalazzo-ojiis4> The pin is part of another data-type, so I can't really do that.
rjmp[m] has joined #rust-embedded
<rjmp[m]> You can use 'steal' to get a second copy if the pin. Youll need to handle configuring it back to IO after each adc read.
<rjmp[m]> Or that :)
<ilpalazzo-ojiis4> rjmp[m]: This is exactly what I'm doing right now, with `steal`. But after using the function the digital I/O stops working, and I don't know why. You, however, seem to know! What sort of “configuring it back to IO” will I need to do?
<rjmp[m]> Im not sure of all the details, and it probably varies from HAL to HAL, but does the analig pin have a method to convert back to a digital input? That should update whatever registers are needed
<GrantM11235[m]> Yeah, that's what the analog.into_input_floating() in my code snippet is for
<GrantM11235[m]> (or whichever mode it was in before)
<GrantM11235[m]> There is no real reason it should be this difficult though imo. If the hal supported it, you could just do... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DepBIoxGnIhAxjtdYyGAHHZR>)
<GrantM11235[m]> ("no real reason" is a bit unfair. The obvious reason is that although it is possible for the hal to support that, it's nontrivial, and I assume the status quo works well enough for most people)
<ilpalazzo-ojiis4> Does transmute consume its argument?
<ilpalazzo-ojiis4> If so I'd need to transmute a reference.
K900 has joined #rust-embedded
<K900> Yes
<ilpalazzo-ojiis4> Right, so the code snippet that uses it can't be used as-is.
<K900> You can't transmute anyway
<K900> It likely needs to reconfigure the pin
<GrantM11235[m]> <GrantM11235[m]> "let pin_copy: Pin<mode::..." <- > <@grantm11235:matrix.org> ```rust... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DLhJmJjnLaHknQDYVgfelEnK>)
<GrantM11235[m]> (basically just stealing)
<ilpalazzo-ojiis4> Ohhhhh! I thought I was meant to put something inside the transmute.
<ilpalazzo-ojiis4> Your point is that all those Pin data-types are zero-sized, so a () can be transmuted to one. Did I understand correctly?
<GrantM11235[m]> Yup. If the pin isn't zerosized, I believe it is a compile-time error
<ilpalazzo-ojiis4> Hmmmmmmmmmmmmmmmmmmm.
<ilpalazzo-ojiis4> Right, this appears promising, but it's past midnight and I need to sleep.
<ilpalazzo-ojiis4> So, I bid you adieu for now.
<JamesMunns[m]> Real quick - why DON'T you want to modify the HAL?
<ilpalazzo-ojiis4> Thank you for the help.
<JamesMunns[m]> like, this would probably be WAY easier to fix there.
<ilpalazzo-ojiis4> Because the HAL is upstream of my crate, and I don't know if opening a PR, testing, merging, and using it in my crate is feasible in a reasonable amount of time.
<GrantM11235[m]> GrantM11235[m]: yup https://doc.rust-lang.org/stable/error_codes/E0512.html
<ilpalazzo-ojiis4> Plus, fixing the HAL would require me to insert yet another code-base in my brain, and I'm not sure I have the mental capacity.
<JamesMunns[m]> ilpalazzo-ojiis4: If you haven't seen https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html, it's useful for this, allowing you to fork, modify, use the modified version 1:1, EXCEPT for publishing
<JamesMunns[m]> but, was just wondering, you do you :)
<JamesMunns[m]> just wanted to make you (and others) aware that modifying an existing crate is usually a pretty straightforward action. I've even ended up publishing my forks temporarily in cases where the upstream maintainer wasn't responsive.
<JamesMunns[m]> JamesMunns[m]: but again, you know your situation better than I do, for sure.
<ilpalazzo-ojiis4> That's good to know, for sure! It immediately takes care of problem no. 1.
<ilpalazzo-ojiis4> Were I to make changes in the HAL, the first change would be to ensure that a blocking analogue read no longer requires an exclusive reference to the ADC.
<ilpalazzo-ojiis4> The second change would be the ability to read some digital lines as analogue without changing the data-type.
<JamesMunns[m]> I have no idea of how the AVR works well enough to tell you if those are actually good ideas or wildly unsafe, but you certainly could try it before opening a PR!
<K900> Wildly unsafe, definitely
<K900> At least on some AVRs
<GrantM11235[m]> ilpalazzo-ojiis4: That one is a bit tricky, since I believe that it does actually need to prevent the adc from being used in other interrupts
<K900> Also, I'm pretty sure the reason you need a reference to the ADC is because it needs to be configured
<ilpalazzo-ojiis4> Hence why I added the “blocking” part.
<K900> As in the read process is configure-read-reset
<K900> And not configure-read-read-read-read
<K900> So you have to poke it every time which obviously needs R/W access
<ilpalazzo-ojiis4> I think the Arduino C++ libraries don't bother with that, though.
<K900> That doesn't mean it's safe
<K900> There's a lot of stupid things you can do with the Arduino libraries
<K900> Doesn't mean it's a good idea
<JamesMunns[m]> <ilpalazzo-ojiis4> "So, I bid you adieu for now." <- Sorry for keeping you from bed :p
<GrantM11235[m]> You would need to disable interrupts for the entire duration of the adc conversion, which isn't great
<GrantM11235[m]> You can get the same effect by putting the adc in a mutex
<ilpalazzo-ojiis4> It isn't great, agreed. But it's a possibility.
<ilpalazzo-ojiis4> Lulz, I found a work-around.
<ilpalazzo-ojiis4> From the analogue read onwards, none of the serial communication protocol I had so carefully created would work…
<ilpalazzo-ojiis4> …so I did all the communications before-hand, and read the ADC at the end.
<ilpalazzo-ojiis4> A pitiful work-around, as far as I'm concerned, but one that I'm not going to pursue further.
dirbaio[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7221 has left #rust-embedded [Error from remote client]
crabbedhaloablut has quit []
gussius[m] has quit [Quit: Idle timeout reached: 172800s]