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
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.
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.
This kit connects a BBC Microbit v2 to a USB-chargeable Li-Ion battery on a mountable expansion board with connectors for Motors for LEGOs ® and a sonar:bit ultrasonic sensor:
"ELECFREAKS micro:bit 32 IN 1 Wonder Building Kit, Programmable K12 Educational Learning Kit with [MOC blocks / Technics®] Building Blocks/Sensors/Wukong Expansion Board" https://shop.elecfreaks.com/products/elecfreaks-micro-bit-32...
> For future people who come across this issue: you can still simulate Rust on Raspberry Pi Pico with Wokwi, but you'll have to compile the firmware yourself. Then you can load it into Wokwi for VS Code or Wokwi for Intellij.
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)
Think of each pin as a single I/O hose nozzle facing the outside world. Behind that nozzle(pin), inside the micro, there is a wall of function nozzles, each labeled with a different ability/function. This room with one nozzle on one wall, and an array on the other wall is called a "Port", these rooms, ports, are labeled Port A0,A1...B0,B1...etc.
It's on you to tell the micro which function nozzle in which port to connect to the I/O nozzle that goes to the outside world. You also need to tell it whether it needs to use an input or an output hose for the connection.
So you end up needing to write something like "Port C5, Connect ADC nozzle to I/O nozzle, use input hose." And now you can route outside signals into the pin and to the ADC module in the micro.(Note that the Arduino IDE does a lot of this for you, but underneath this is what is happening)
This is probably why you are getting hung up. The pins are multifunctional, and you need to define how they are used before using them.
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
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.
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
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.
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.
Wokwi also supports Pi Pico w/ Python: https://news.ycombinator.com/item?id=38034530 , https://news.ycombinator.com/item?id=36970206
This kit connects a BBC Microbit v2 to a USB-chargeable Li-Ion battery on a mountable expansion board with connectors for Motors for LEGOs ® and a sonar:bit ultrasonic sensor: "ELECFREAKS micro:bit 32 IN 1 Wonder Building Kit, Programmable K12 Educational Learning Kit with [MOC blocks / Technics®] Building Blocks/Sensors/Wukong Expansion Board" https://shop.elecfreaks.com/products/elecfreaks-micro-bit-32...
There are docs on GitHub for the kit: https://github.com/elecfreaks/learn-en/tree/master/microbitK... .. web: https://wiki.elecfreaks.com/en/microbit/building-blocks/wond...
"Raspberry Pico Rust support" https://github.com/wokwi/wokwi-features/issues/469#issuecomm... :
> For future people who come across this issue: you can still simulate Rust on Raspberry Pi Pico with Wokwi, but you'll have to compile the firmware yourself. Then you can load it into Wokwi for VS Code or Wokwi for Intellij.
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?
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)
Were the authors responsive to reports?
Think of each pin as a single I/O hose nozzle facing the outside world. Behind that nozzle(pin), inside the micro, there is a wall of function nozzles, each labeled with a different ability/function. This room with one nozzle on one wall, and an array on the other wall is called a "Port", these rooms, ports, are labeled Port A0,A1...B0,B1...etc.
It's on you to tell the micro which function nozzle in which port to connect to the I/O nozzle that goes to the outside world. You also need to tell it whether it needs to use an input or an output hose for the connection.
So you end up needing to write something like "Port C5, Connect ADC nozzle to I/O nozzle, use input hose." And now you can route outside signals into the pin and to the ADC module in the micro.(Note that the Arduino IDE does a lot of this for you, but underneath this is what is happening)
This is probably why you are getting hung up. The pins are multifunctional, and you need to define how they are used before using them.
Hope this helps clear some confusion!
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
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.
This is one attribute of Platform IO tooling that was always insanely lacking... any real form of on-platform integration testing. Even emulation.
Their vscode experience is also really good. Super fast turnaround for Rust ESP32 development and testing.
Super cool! Thank you so much!
[flagged]