Toit open-source language claims to be 30x faster than MicroPython on ESP32

Developed by a team of former Google employees, Toit is a complete IoT platform with remote management, firmware updates for fleets of devices with features similar to the one offered by solutions such as balena, Microsoft Azure, or Particle edge-to-cloud platform.

Toit currently works on ESP32 microcontrollers using lightweight containers, and after seeing existing high-level languages MicroPython and Javascript were not fast enough on low-end microcontrollers platforms, the team at Toit started to develop the Toit language in 2018, and has just made it open-source with the release of the compiler, virtual machine, and standard libraries on Github under an LGPL-2.1 license.

Toit language

One of the main reasons to switch from MicroPython to the Toit language is if your application is limited by performance or you operate ESP32 from a battery, as Toit claims up to 30x faster performance with Toit on ESP32:

We went into crunch mode and some months later, we had the first results. We were executing code more than 30x faster than MicroPython on an ESP32 with a high-level language that abstracts away memory allocation and that can be learned in a few hours by a Python developer: the Toit language.

So let’s have a deeper look by trying it out in Ubuntu 20.04. The virtual machine is based on a fork of the ESP-IDF with custom malloc implementation,  allocation fixes for UART, and LWIP fixes. That’s what we’ll need to install first:

Now install ESP32 tools:

and build toit and samples to run on the host machine:

We can now run the hello world sample:

as follows:

That’s all good but what’s about building the sample for ESP32? Easy:

This will create a Toit firmware file (toit.bin) preloaded with the hello world sample and that can be flashed with esptool:

Good, but surely we can check a sample with Wi-Fi, and indeed there’s the http.toit sample:

That neat and simple example simple download Google page and reports the number of bytes downloaded. But wait… Where do we configure Wi-Fi credentials? This can be done at build time:

or you can change the default program and configure the WiFi SSID and password in the Makefile:

I do not have an ESP32 up and running to test it out, but I’d assume you’d be able to modify the hello.toit on the device itself after flashing Toit firmware the first time. OTA firmware update should be enabled too based on the output from the make esp32 command. The complete Toit platform is free to use for up to 10 devices, and besides the Github page, you can also find additional information on the documentation website not only about the firmware and Toit language we’ve used here, but also the Cloud API and Toit platform as a whole.

Share this:
FacebookTwitterHacker NewsSlashdotRedditLinkedInPinterestFlipboardMeWeLineEmailShare

Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress

ROCK 5 ITX RK3588 mini-ITX motherboard

21 Replies to “Toit open-source language claims to be 30x faster than MicroPython on ESP32”

  1. Thanks for mentioning the free and open source Toit language. If you build your firmware on top of it, you will still be using Espressif’s esptool to flash it into your device, so your compile-flash-run workflow will be similar to how it works with the widely used ESP-IDF framework. You will, however, write your code in a memory-safe and efficient high-level language, which is the main selling point for lots of developers.

    Do let me know if you have any further questions!

    1. I previously looked into this language, but I felt the overhead from learning a new language to high.
      Also, the “compile-flash-run” workflow is pretty much useless doing anything more complicated than reading sensors and sending som post request. Not sure why you’d need to run “30 times faster than python” for these use cases.

    2. How do you debug an application using the Toit language? I could not find any mention in the documentation.

    3. What was the rationale for creating a whole new language instead of creating a faster MicroPython/Lua/Go compiler/interpreter for MCU? Using the same syntax allows reusing existing libraries.

    1. Not sure there is a cpp API for esp32, but as I said in my other comment: comparing performance is basically pointless, because the use cases where theses languages skulle be used don’t really need to be fast – the development. Quick and dirty, nothing production worthy

      1. Ah well espressif idf or arduino ide are C++?
        and it’s not really the dev performance i am interested, but code size and execution speed, since those are the limiting factors, but yeah, just for reading sensors, its polntless,…

  2. I don’t know why so many negative comments. Not all work is just “dirty development”, for small DIY projects, or smaller professional projects, where developing in c++ is expensive and unnecessary, and micropython consumes too many resources, this is a great solution.
    I have to take the time to test it in the next couple of weeks!

  3. So is there just in time on device compilation or is it only precompiled byte code? Is that why it is 30x faster or was it compared to precompiled micropython bytecode?

  4. “that can be learned in a few hours by a Python developer: the Toit language.” … I’m a Python programmer, but Toit looks quite strange to me.

  5. “The complete Toit platform is free to use for up to 10 devices” … ok, and what above 10 devices? License fees? What prices?

    1. I did not go into details because that post is mostly about the Toit language, so there’s no need to pay anything if you’re not using their cloud.

      But to answer your question, they charge $0.50 per serviced device per month when more than 10 devices are used with the Toit platform.

    2. As far as I understand the language and runtime are available under LGPL v2.1, which doesn’t make any such restriction.

  6. Arduino supports all kind of hardware to control actuators, sensors, displays, etc – there are hundreds of them.
    The reason Arduino have out-competed other micro-controller ecosystems is because some heroic people read datasheets and wrote libraries for Arduino rather than for other platforms.

    Python has some device libraries too.

    Those libraries are community-tested and most of the time pretty reliable.

    How about Toit?
    I can see only a very rudimentary stuff. If you need anything beyond “Hello World”, be prepared to read datasheets and re-invent all the wheels and be a guinea-pig tester of their code. Be prepared that your software development beyond “Hello World” will be 30x slower than on Arduino or in Python.

    “Hello World” is 30x faster than Python, though. Incredible!

  7. I seem to be seeing a lot of unfairly negative comments.

    While I don’t like complicated languages like Python that require a web browser constantly loaded on StackOverflow and that do not even resist to copy-paste, there are already some devices in field relying on these. And I think that encouraging developers to move to more energy-efficient languages is good in general.

    The “30 times faster” argument is not the right one in my opinion, most people do not care about execution time. They should instead advertise “does the same using 30 times less power”, or “30 times longer battery life”. This is much more of a selling argument for IoT. Recharge your battery every month instead of every day without having to learn C! Or maybe further, add a tiny solar cell that will be enough to compensate for the small consumption.

    If those using scripting languages can accommodate to this one, why not give it its chance ?

    1. The thig is that C is the most energy efficient programming language (apart from ASM), so it is almost impossible to beat it. Rust is close, but no cigar.

      1. I’m not speaking about trying to beat it nor even come very close, just be reasonably efficient. There’s always some static consumption, and the way peripherals are used on an MCU, or the device is put to sleep, count a lot as well. The time it takes to resume and suspend as well. And the time spent in the low-level system primitives as well. So if overall a moderately efficient language maintains the whole product’s efficiency within 20-30% of the optimal situation it’s not that bad, and in any case it’s much better than being 30 times less efficient.

Leave a Reply

Your email address will not be published. Required fields are marked *

Khadas VIM4 SBC
Khadas VIM4 SBC