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
<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]>
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
<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.
<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>
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
<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.)
<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]>
("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.
<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.
<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]