Online Embedded Rust Simulator
wokwi.com
wokwi.com
Looks like they're stuck on very old crates...
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.
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.
even with the above, you'll likely to make the odd mistake here and there. but esp32 are fairly forgiving
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
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.
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!
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.
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.