[HN Gopher] Online Embedded Rust Simulator
___________________________________________________________________
Online Embedded Rust Simulator
Author : kaycebasques
Score : 113 points
Date : 2025-03-09 03:40 UTC (18 hours ago)
(HTM) web link (wokwi.com)
(TXT) w3m dump (wokwi.com)
| pixelesque wrote:
| 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...
| kaycebasques wrote:
| 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
| rendaw wrote:
| 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.
| 123pie123 wrote:
| 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
| kaycebasques wrote:
| 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.
| the__alchemist wrote:
| 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.
| kaycebasques wrote:
| 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
| the__alchemist wrote:
| 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.
| kaycebasques wrote:
| 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)
| maartin0 wrote:
| 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.
| sabujp wrote:
| 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.
| kaycebasques wrote:
| awesome-embedded-rust is a really good curated list of embedded
| Rust learning resources: https://github.com/rust-
| embedded/awesome-embedded-rust?tab=r...
| auselen wrote:
| BBC micro:bit?
| Lerc wrote:
| 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.
| mmastrac wrote:
| Are you sure you aren't being MITM downgraded? I didn't think
| TLS 1.3 was packet-boundary aware.
| Lerc wrote:
| 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.
| whazor wrote:
| Their vscode experience is also really good. Super fast
| turnaround for Rust ESP32 development and testing.
___________________________________________________________________
(page generated 2025-03-09 22:00 UTC)