[HN Gopher] Rust on Espressif chips - 15-07-2022
___________________________________________________________________
Rust on Espressif chips - 15-07-2022
Author : mabez
Score : 164 points
Date : 2022-07-15 10:43 UTC (12 hours ago)
(HTM) web link (mabez.dev)
(TXT) w3m dump (mabez.dev)
| woile wrote:
| Wow! awesome news, I just bought a feather with esp32 to start
| playing with rust, and I'm considering taking the course from
| ferreous-system. Nice to see the progress by the community and
| how nice it looks developing for these devices. I remember having
| to do the same with C when I was studying in the university and
| it was a whole different story.
| taf2 wrote:
| Espressif really has a fun ecosystem - I built status lights for
| our team using tiny pico and a bunch of Neopixels from adafruit.
| Very nice with Wi-Fi to setup
| bcjordan wrote:
| The ESP / ESP32 series chips are just astonishingly useful for
| their price. You can build out a device with a camera / wifi for
| incredibly cheap with them.
| leeoniya wrote:
| the main complaint i keep seeing about them is their power
| inefficiency
| brianhorakh wrote:
| No, that is at best partially incorrect. Worst case wrong.
|
| Esp32-s2 has 3 low power sleep suspend modes. For the speed
| of the dual 240mhz processors are monsters with ~4mb of ram.
| Xtensa core is among best in class, but could be overkill for
| the application wheres STM, etc. might have a smaller much
| lower frequency chip that is. A lot of the esp32 dev boards
| also have bigger than necessary "protect the processor" type
| components which burn power too.
|
| Raspberry pi burns way more power than esp32 per clock cycle
| (its a little toaster) but nobody complains about that.
|
| I suspect the complaints are by hobbyists using arduino on s2
| which can't/dont access them. (requires c++)
|
| Riscv as architecture is not power efficient _yet_ , give it
| time - the fact riscv exists at all still blows my mind.
| R0b0t1 wrote:
| the interfaces are also not really "good" the cameras
| supported for example are quite small
| ClumsyPilot wrote:
| a random general purpose MCU is not really meant to handle
| cameras, this is kinda abuse of the MCU.
| mlindner wrote:
| Putting a proprietary Chinese-manufactured chip in the critical
| supply chain for a product you're designing isn't a good way to
| future proof your business.
| joshka wrote:
| That's an interesting perspective. Right now, though it seems
| like your only argument is "China". Perhaps you expand on what
| you think the problems you'd see in the future would be for
| this, and present some alternatives (which chips are
| manufactured outside China these days)
| nicoburns wrote:
| The Espressif Rust work is super exciting. For those who don't
| know, they actually hired the guy working on it, and now he works
| on it full time and with the team who does the C/C++ support.
| It's also super cool how interoperable the Rust embedded
| ecosystem is.
| childintime wrote:
| Exciting indeed, as this is a high quality effort. What gets me
| most excited is the async work being done around Embassy, which
| has the potential to revolutionize bare-metal programming once
| it graduates to stable. The cool-aid:
|
| - https://embassy.dev/
|
| - https://tweedegolf.nl/en/blog/65/async-rust-vs-rtos-showdown
| nicoburns wrote:
| Yeah, async makes so much sense for embedded. Async is often
| billed as "for IO", but really that's only because IO
| requires waiting for an external hardware peripheral (the
| disk) to do something, leaving the CPU free to do other
| things in the meantime. And embedded is _mostly_ dealing with
| (and often waiting for) external hardware peripherals!
| arwhatever wrote:
| FWIW I've very recently gotten
| https://github.com/ivmarkov/rust-esp32-std-demo (which is a
| pretty comprehensive demo) running on a TinyPICO (w/ESP32) and
| am looking forward to building out my own projects next.
| jamesmunns wrote:
| I think they actually ended up hiring a couple folks (2-3?)
| from the open source project. Pretty awesome to see them
| supporting existing work!
| MrBuddyCasino wrote:
| Damn, an event loop with auto-sleep! This would have been very
| useful a few years ago when the ESP32 didn't have enough memory
| for the needed stack space and coded a shitty custom one. This is
| tarting to get interesting.
| n8henrie wrote:
| I think these esp32 + rust updates are really exciting! I just
| noticed that the temperature logger project linked to in the
| post[0] is also using MQTT -- I've been waiting for a rust-based
| ESP32+wifi+MQTT solution! EDIT: looks like this is the mqtt
| dependency: https://github.com/BlackbirdHQ/mqttrust
|
| [0]: https://github.com/bjoernQ/esp32-rust-nostd-temperature-
| logg...
| pleb_nz wrote:
| Nice.
|
| They mention a rust dev kit. Does this mean you can use rust on
| the standard espressif esp32 devkits? I just bought an espressif
| esp32-S3-wroom to learn on and would love to use rust if
| possible.
| cpascal wrote:
| There's also the ESP32-C3-DevKitC-02 [0] which you can do the
| trainings with albeit making sure you mind that the pinouts are
| slightly different.
|
| [0]: https://docs.espressif.com/projects/esp-
| idf/en/latest/esp32c...
| jamesmunns wrote:
| There is a specific dev kit which is used in training
| materials[0] (the training is paid, but the material is all
| online for free), but you can use Rust with any ESP32 (xtensa
| or risc-v based).
|
| The main esp-rs github organization[1] is a good place to get
| started!
|
| [0]: https://espressif-trainings.ferrous-systems.com/
|
| [1]: https://github.com/esp-rs
| brianhorakh wrote:
| There is presently no jtag debugger support for S2 chip (due to
| xtensa not wanting their IP to be public/open sourced by
| espressif who only licensed the ip for internal use) The jtag
| interface needs to be reverse engineered.
|
| You can target the s2 and flash it using cargo.
|
| However if you are building something complex and want to use
| Probe-rs you will _probably_ want to buy a c3 module.
|
| Also you can emulate and test the riscv in qemu. (useful for
| integration testing on cloud)
|
| Rust for embedded is awesome and doesn't get enough attention
| for how powerful the potential is.
| kelvie wrote:
| What's everyone's read on how successful the new pi pico W is
| going to be?
|
| Undoubtedly the pi pico W will take some amount of mindshare away
| from Espressif, but espressif still has several advantages that
| are important to me (ESPHome, usb-c board availability, ease of
| creating custom PCBs with their small all-in-one modules,
| RISC-V), but the gap will close, and my worry is that the might
| of the Pi community will basically just make it the more well-
| supported chip in the long run.
|
| I know it's impossible to predict the future, but after the
| announcement, I find myself a little less excited to continue
| investing in keeping up with the esp32 stuff, even though right
| now I have something like 10 boards automating various parts of
| my home
|
| (note this is from the lens of a tinkerer, not someone using
| these professionally)
| nicoburns wrote:
| I suspect they'll both be pretty successful, and what we'll see
| is a growth in the market for this kind of product.
| everforward wrote:
| For the tinkerer space, I think it will depend on the SDK and
| docs, as well as availability. Pi's tend to sell out, and it's
| hard to build a community on hardware you can't get. Not sure
| what availability of esp32's is like at the moment.
|
| esp32 is faster than a Pico, but a lot of the examples for the
| Pico are in MicroPython, so I don't think performance is what
| they're pushing anyways.
|
| I still like the esp32 better. It's faster for a pretty
| negligible difference in power consumption, I already kind of
| know the API, and I can get them with cameras and SD card slots
| already in them. I just don't see a compelling reason to
| switch.
|
| I think esp32 will be fine, at least until something
| significantly better comes along and kills the esp32 and Pico.
| danhor wrote:
| The pi pico w has the huge issue of not integrating it all into
| a small module/chip. You can (at least right now) only buy the
| whole pi pico w for integration into a project, so anything
| remotely size constrained will not be able to use it.
|
| Part of what makes esphome/tasmota/... so attractive is reusing
| existing devices with an esp inside. These won't exist for the
| pico w.
|
| I think the enthusiast IoT space will continue to primarily use
| esp32/esp8266 devices.
|
| If the Pi foundation offers a small module akin to the
| esp8266/esp32 modules, that might change.
| kelvie wrote:
| Yeah that's precisely what I meant when I said "ease of
| creating custom PCBs with their small all-in-one modules" --
| the pico-mini modules (I only now realize they're both called
| pico) and the C3 modules with antennas are just crazy for
| what they pack in such a small footprint.
| otoburb wrote:
| Interesting that Espressif recently announced they are moving
| exclusively to RISC-V[1]. This will likely drive costs down even
| further, but unsure if they will improve on the power efficiency
| in the near term. The ESP32-C3 is mentioned in the esp-rs[2].
|
| [1] https://www.eenewseurope.com/en/espressif-moves-
| exclusively-...
|
| [2] https://github.com/esp-rs/esp-hal/pull/76
| brianhorakh wrote:
| Makes sense, its not bound by the xtensa license which prevents
| open source disclosure of the jtag interface (there are
| probably other reasons, but I know xtensa isn't compatible
| w/open source)
|
| Espressif is based in Shanghai. China nationally is moving to
| RISC-V & red linux for all internal cases so they aren't
| reliant on foreign tech/ip. Espressif makes products for the
| ccp (I'd wager it is their single largest client and probably
| directly influencing their board, but that is speculation).
| Most chip manufacturers work pretty close with their govs for
| biz.
|
| Its hard to appreciate today how significant a role esp32 will
| play in future computing trends (but it is probably HUGE imho,
| i love their products and transparency)
| SV_BubbleTime wrote:
___________________________________________________________________
(page generated 2022-07-15 23:01 UTC)