TX for this! My older kid and I are learning Rust with Rustlings, but this will help me add a physical element to it (even though it's simulated), eventually we may get an esp32. Younger kid loves doing Microsoft microbit, he will definitely be interested in this.
Several of the featured projects seem to fail to build if you try and update the code and then restart the simulation, even with just a whitespace change...
Yeah, the templates seem to need a refresh. I was able to manually update my project to use the latest crates, though. esp32c3 blinky template with no standard library works for me, and that's honestly all I need. Everything that I want to do can start with that foundation. https://wokwi.com/projects/424963180600820737
Somewhat off-topic. This is the first page that I have encountered that has given me a insufficient TLS error.
I'm using 1.2 because apparently I'm somewhere that causes pytorch.org and some other github.io connections to break on Chrome and Firefox using 1.3. Something to do with packet splitting on connection I think. Curl was lean enough to work with 1.3. Might go back to 1.3 and see if the Github pages work now. [edit: whatever it was seems to be fixed, I can read pytorch.org docs again using TLS 1.3]
Remember when computers used to just work? Yeah, me neither.
Not sure about MITM, no proof against it but seems hardly likely.
It might have been some weird attempt to reduce latency. Wireshark seemed to show responses that were sent before the request that triggered it had finished transmitting. The handshake seemed really shuffled out of order. Watching curl do the handshake sent far fewer bytes.
I noticed you can create custom chips using Verilog which I will definitely try at some point. Seems like it could be a pretty useful tool to learn/test designs in.
This is super cool. I have a friend who's just getting started with a rust + esp32 project.
I've fiddled with arduino in the past, both in c++ and rust, and the hardest part was figuring out which pin was which. I looked up various specs, and every pin had different names in different documents, plus the code (I had for my own model) was using yet a different set of ids... it was totally opaque. I guess all I want was some clear documentation, but a full simulator isn't any worse.
I feel you. Most of my experience with STM32s is similar. I've gotten use to their system, but I don't envy the newcomer. Things are complicated by dev boards that have their own naming system layered on the MCU's. (And the latter likely already has pin number in footprint mapped to an internal pin number.
I've been ramping up on the embedded Rust ecosystem over the last few weeks. I'm pretty excited about it partly because it makes this aspect of embedded development much more approachable. On https://crates.io I can usually find a driver for whatever peripheral I want to use in my project. And the driver usually implements the embedded-hal [1] interface, so the more I get familiar with that interface, the easier it becomes to implement any arbitrary peripheral into my project. In the event that there does not already exist a crate for my peripheral, I have an extensive ecosystem [2] of open source driver code that I can refer to in order to figure out how to implement the driver.
I think this could help with the "dark art of reading datasheets" problem. E.g. last night I was curious about how the driver for a 28BYJ-48 stepper motor would work, so I looked at the code [3] for its driver and got a pretty good sense of what's going on. If I were to now attempt to read the datasheet, a lot of it would now make sense. In other words I think it's too daunting to read a datasheet and then try to implement code. The way to get comfortable with datasheets is to first look at code and then find the relevant parts of the datasheet. Previously it was hard to find and make sense of relevant code for a particular driver, now it's much easier.
I hope not to dull your excitement, but I encourage you to validate this first impression later, if you stick with it. I came to a very different conclusion!
Most of the driver libs (e.g. using Embedded Hal) are written by one person, and are impractical when applied to a non-toy application. I found flaws that made them unusable in every one I tried. Or, at least, totaled, in the sense that it would be easier to add a file to the drivers folder of my application that configures the peripherals and provides high-level fns, than to repair the Embedded Hal driver.
Makes sense. I also got the impression that the crates implementing embedded-hal aren't super robust. So maybe I should dial back the statement about not needing to roll your own drivers. However, I think it's just a matter of "when", not "if". I.e. Rust seems to have all the pieces in place for a rich and vibrant embedded development ecosystem (standardized HAL, easy to share HALs and tools with others, open source, a community that embraces docs and educational videos)
Reading data sheets is a dark art. What helped me most was watching YouTube tutorials where someone implements a driver, and along the way they refer to the datasheet and translate the information from the datasheet into code right there on-the-spot.
for any microcontrollers esp32/ arduinos etc.. make sure you know which board is which and get a pdf/ print out the pin layout for reference. After a bit you get used to the variation in pin layout for your own boards
even with the above, you'll likely to make the odd mistake here and there. but esp32 are fairly forgiving
TX for this! My older kid and I are learning Rust with Rustlings, but this will help me add a physical element to it (even though it's simulated), eventually we may get an esp32. Younger kid loves doing Microsoft microbit, he will definitely be interested in this.
awesome-embedded-rust is a really good curated list of embedded Rust learning resources: https://github.com/rust-embedded/awesome-embedded-rust?tab=r...
BBC micro:bit?
Several of the featured projects seem to fail to build if you try and update the code and then restart the simulation, even with just a whitespace change...
Looks like they're stuck on very old crates...
Yeah, the templates seem to need a refresh. I was able to manually update my project to use the latest crates, though. esp32c3 blinky template with no standard library works for me, and that's honestly all I need. Everything that I want to do can start with that foundation. https://wokwi.com/projects/424963180600820737
Somewhat off-topic. This is the first page that I have encountered that has given me a insufficient TLS error.
I'm using 1.2 because apparently I'm somewhere that causes pytorch.org and some other github.io connections to break on Chrome and Firefox using 1.3. Something to do with packet splitting on connection I think. Curl was lean enough to work with 1.3. Might go back to 1.3 and see if the Github pages work now. [edit: whatever it was seems to be fixed, I can read pytorch.org docs again using TLS 1.3]
Remember when computers used to just work? Yeah, me neither.
Are you sure you aren't being MITM downgraded? I didn't think TLS 1.3 was packet-boundary aware.
Not sure about MITM, no proof against it but seems hardly likely.
It might have been some weird attempt to reduce latency. Wireshark seemed to show responses that were sent before the request that triggered it had finished transmitting. The handshake seemed really shuffled out of order. Watching curl do the handshake sent far fewer bytes.
I noticed you can create custom chips using Verilog which I will definitely try at some point. Seems like it could be a pretty useful tool to learn/test designs in.
Their vscode experience is also really good. Super fast turnaround for Rust ESP32 development and testing.
This is super cool. I have a friend who's just getting started with a rust + esp32 project.
I've fiddled with arduino in the past, both in c++ and rust, and the hardest part was figuring out which pin was which. I looked up various specs, and every pin had different names in different documents, plus the code (I had for my own model) was using yet a different set of ids... it was totally opaque. I guess all I want was some clear documentation, but a full simulator isn't any worse.
I feel you. Most of my experience with STM32s is similar. I've gotten use to their system, but I don't envy the newcomer. Things are complicated by dev boards that have their own naming system layered on the MCU's. (And the latter likely already has pin number in footprint mapped to an internal pin number.
I've been ramping up on the embedded Rust ecosystem over the last few weeks. I'm pretty excited about it partly because it makes this aspect of embedded development much more approachable. On https://crates.io I can usually find a driver for whatever peripheral I want to use in my project. And the driver usually implements the embedded-hal [1] interface, so the more I get familiar with that interface, the easier it becomes to implement any arbitrary peripheral into my project. In the event that there does not already exist a crate for my peripheral, I have an extensive ecosystem [2] of open source driver code that I can refer to in order to figure out how to implement the driver.
I think this could help with the "dark art of reading datasheets" problem. E.g. last night I was curious about how the driver for a 28BYJ-48 stepper motor would work, so I looked at the code [3] for its driver and got a pretty good sense of what's going on. If I were to now attempt to read the datasheet, a lot of it would now make sense. In other words I think it's too daunting to read a datasheet and then try to implement code. The way to get comfortable with datasheets is to first look at code and then find the relevant parts of the datasheet. Previously it was hard to find and make sense of relevant code for a particular driver, now it's much easier.
[1] https://github.com/rust-embedded/embedded-hal
[2] https://crates.io/keywords/embedded-hal-driver
[3] https://github.com/MnlPhlp/uln2003
I hope not to dull your excitement, but I encourage you to validate this first impression later, if you stick with it. I came to a very different conclusion!
Most of the driver libs (e.g. using Embedded Hal) are written by one person, and are impractical when applied to a non-toy application. I found flaws that made them unusable in every one I tried. Or, at least, totaled, in the sense that it would be easier to add a file to the drivers folder of my application that configures the peripherals and provides high-level fns, than to repair the Embedded Hal driver.
Makes sense. I also got the impression that the crates implementing embedded-hal aren't super robust. So maybe I should dial back the statement about not needing to roll your own drivers. However, I think it's just a matter of "when", not "if". I.e. Rust seems to have all the pieces in place for a rich and vibrant embedded development ecosystem (standardized HAL, easy to share HALs and tools with others, open source, a community that embraces docs and educational videos)
Reading data sheets is a dark art. What helped me most was watching YouTube tutorials where someone implements a driver, and along the way they refer to the datasheet and translate the information from the datasheet into code right there on-the-spot.
for any microcontrollers esp32/ arduinos etc.. make sure you know which board is which and get a pdf/ print out the pin layout for reference. After a bit you get used to the variation in pin layout for your own boards
even with the above, you'll likely to make the odd mistake here and there. but esp32 are fairly forgiving
[flagged]