Jaguar is the tooling to enable rapid development. It consists of two parts: one that runs on the ESP32 and another one that runs on your computer.
Whenever a new program is ready, it gets pushed (over WiFi) to the device. The whole process only updates the actual program (not the whole OS), thus making the development cycle really fast.
Compared to MicroPython, Toit is significantly faster. In my (obviously biased) opinion, it's also more robust.
You can't link C drivers directly without modifying the Toit code base, but there is a bridge to talk between C and Toit code. Generally, we prefer to reimplement the drivers in Toit. However, for some bigger ones it clearly makes sense to keep the C version.
Must be because I learned some French as a kid, but I can't help reading the "oi" as a "wa" sound in this context. Probably not what the authors were going for.
Language design is hard. It's impossible to please everyone. What Dart has taught me is that JavaScript is not going to be displaced on the web anytime soon. Dart seems to have found its stride with Flutter, a cross-platform UI framework.
I looked at this the other day! Sadly no way to configure WiFi other than at the point of flashing the device which rules it out for a lot of use cases.
Call me old-fashioned, but I personally do not like the idea of using a garbage-collected language for embedded development in general, and it's just flat out non feasible to use for anything which is timing-sensitive...
In big parts that's true, but there are some good arguments in favor of a GC for these small devices:
- the GC is a sliding compacting GC. As such there is no fragmentation for heap-allocated memory.
- the memory on these devices is tiny. The GC thus doesn't take long time.
- the ESP32 has really good peripherals, making timing sensitive operations very rare. In most cases there is a hardware module that does the job for you. The timing requirements then usually become significant less important.
depends on how the system works. What are the timing requirements? How powerful is the CPU? How much memory do you have? How often will the system be reset? Embedded isn't just 8/16 bit CPUs with < 128k of memory these days.
From a functional PoV, yes, timing seems to be relaxed by publishing sensor data every 60 seconds.
From an embedded system PoV, your sensor might be a 1-Wire protocol device with a super strict signal timing. How do you mix both timing requirements? How do you differentiate embedded projects requiring "precise timing" from those others requiring "every 60 seconds"?
Unless Toit provides drivers for all kind of buses, sensors and peripherals AND it orchestrates the GC with the strict timing requirements. Otherwise it's probably a good fit only if it just runs on a known controlled development board/architecture/platform.
Literally every uC has hardware blocks for that, 99% of the stuff you will ever encounter is a standard. Nobody bitbangs protocols. And even if, the ws2816 driver on the raspberry pi is bitbanged from Linux user-space.
How often are you bitbanging non standard protocols? And if so, which field are you in?
> How often are you bitbanging non standard protocols?
Regarding protocols: bitbanging 1-Wire. Not all microcontrollers have this peripheral. You might be lucky if you can adapt some other peripheral like an UART (with due effort). Or you can use for example an external ds2482 and drive it through I2C.
WS2812B: sometimes you can emulate it with some other peripheral, sometimes you have to do it by bitbanging some GPIO.
I don't bitbang so often in general. But it's not just about available "hardware blocks": introducing undesidered delays in embedded applications is a terrible, terrible idea.
You can have a perfectly working sensor through I2C with DMA, super optimized with 0 CPU intervention. This sensor has an ODR of 1kHz. A GC stopping the microcontroller for 400ms makes you stand behind 400 samples you might be processing in real time (FIFO aside, and because you know you shouldn't be doing any processing in an interrupt handler, right?). You don't lose the buffered samples of course, but your processing is now delayed.
Or perhaps you are doing some 44100, 16-bit stereo audio processing (in or out). You have implemented the perfect I2S/DMA mechanism and all that, combined with perfect SDIO reading. What would happen in a real-time processing audio application if the GC introduces even 20ms delays now and then? Horrible latency and/or artifacts... And because your MCU has 32KB of RAM you don't have the luxury of big buffers, so you have to be quick reading, processing and outputting. Stopping the processing = stopping the output.
Or you might be dealing with some external peripheral that needs an answer within a time limit...
You can see it's not just about "hardware blocks".
Following what I said before, even if "60 seconds" is the application required timing, there are other things that might be happening in the background that require precise timing.
Is Toit a bad language? I don't know. But as I said before, it only makes senses if ran under a known platform like ESP32 where the language developers have tuned everything, and the programer doesn't pretend real-time applications. A generic language for every microcontroller? I am not so sure...
I don't know about Toit, but many embedded applications will not allocate post-initialization time, in which case GC or not GC behave exactly the same with regards to timing.
There are algorithms for doing garbage collection in real-time systems, but these tend to have more overhead in total than stop-the-world GC.
On microcontrollers, which often have very limited RAM, I'd prefer avoiding doing any heap allocation at all. If there is any need for any dynamic allocations, they are within fixed-size memory pools — each with only fixed-size objects or with objects on a stack.
I have sympathy for the sentiment, but e.g. MicroPython on the Raspberry Pico allows cycle-correct deterministic timing using its eight state machines (and a state machine assembler in Python): https://docs.micropython.org/en/latest/library/rp2.StateMach...
That's why you don't use it on small microcontrollers (8/16 bit). And if you absolutely have to, use it once on startup to implement a dynamic memory pool.
I just searched for esp32 projects/libraries on github, the first 3 had malloc calls.
Maybe they don't do[1] dynamic memory allocation in code segments that have real time constraints, or after initialization, etc. (Most embedded projects actually don't have hard real-time constraints, or have them in extremely localized places like bit banging loops...) This is sounds like a good idea and is orthogonal to whether the language's dynamic allocation support is via malloc/free or gc.
Yeah fair. But I think that any gc language for microcontrollers should have a couple features:
1) A compiler flag or similar optional static check that throws a warning if you have dynamic memory allocation. In scripting languages it can be easy to do accidentally
2) A way to block the gc from happening in a time critical section of code, like how you can disable interrupts
3) Some guarantee on the maximum time gc will take
MicroPython provides a way to stop the GC (and an exception will be raised if memory is attempted to be allocated). This provides us with most of the control we require...
Thanks for sharing. Complex examples like these are great to highlight syntax which simpler examples never mention. For example (heart rate sensor excerpt):
remembered_ = List width/2: initial_value
half_height := height / 2
...
min_value := remembered_.reduce: | a b | min a b
These lines (with seemingly context-sensitive meanings for the / and : characters) feel less obvious to me than the examples on the home page.
Excuse my idle curiosity, but... slash for type ascription? How did that happen? The only precedent I can think of is Prolog’s arity annotations (and jq’s, but I suspect a direct influence there). Does this come from some chunk of programming-language lore I’m unaware of?
Wadler’s law or not, I’m not criticising, just curious :) Thank you (and 'EricCorry in sibling comment) for taking the time to answer!
[Yes, colons are nice as block introducers but don’t play nice with colons for type ascription, which is where we got Python’s asinine f(x: int, y: bool) -> str; don’t know why Rust went with that instead of ML’s uniform f(x: int, y bool): str.]
Part of it is that we already used colon for several things.
Also types are optional in Toit, so they are a bit like comments (though they are now checked so they are less like comments now). So they look a little like // comments.
Toit and Ruby are both inspired by Smalltalk, and there are certainly similarities in the syntax but we felt that starting 20 years later we could do a lot better than Ruby syntax.
In particular, Python basically won the significant-indentation argument. Since all programs are formatted with correct indentation the punctuation is redundant clutter.
So for a new language it just feels right to go with indentation instead of curlies.
We also wanted to be free to add type annotations and other enhancements, so it was never going to be compatible with Ruby anyway. And we didn't want to raise expectations of Ruby-compatibility that would immediately be dashed.
As long as Toit is licensed under the GNU Lesser General Public License v2.1, I am unlikely to consider using it. By contrast, MicroPython is licensed under the MIT License (MIT).
As others have noted, Toit seems like a bad name. I suppose non-French speakers will tend to inadvertently mispronounce Toit.
The GPL is for when you have an ideological agenda, the MIT is for when you don't. MIT says "do whatever you like with this but include the license" in less words than the GPL's preamble. GPL says people can use it, but can't without providing all the source code for no more than the cost of media (though I'd have to call a lawyer to be sure that's all it says these days because the damn thing is long and complicated) but it forces users to conform to someone's idea of fairness.
Basically if the thought of your code ever ending up in something that someone might somehow make money from, like maybe in an iOS app, is somehow icky - then GPL is for you! If you just want to put it out there and code, not politics, is your thing - go MIT.
If you just want to use the compiler and VM the license doesn't effect you.
You can write a closed source program in any GPL language using any GPL compiler.
We use it for some of our tools, so it's possible (and works nicely). Our LSP server was initially written in Toit: https://github.com/toitlang/toit/tree/master/tools/lsp/serve...
(To be fair, it uses the compiler underneath for analyzing the sources).
Main restriction is, that we haven't finished the Windows implementation yet. Specifically networking and spawning processes only works on Linux/macOS so far. (The main reason we ported the LSP server to Go).
73 comments
[ 2.6 ms ] story [ 135 ms ] threadWhenever a new program is ready, it gets pushed (over WiFi) to the device. The whole process only updates the actual program (not the whole OS), thus making the development cycle really fast.
Compared to MicroPython, Toit is significantly faster. In my (obviously biased) opinion, it's also more robust.
You can't link C drivers directly without modifying the Toit code base, but there is a bridge to talk between C and Toit code. Generally, we prefer to reimplement the drivers in Toit. However, for some bigger ones it clearly makes sense to keep the C version.
[0] https://en.m.wiktionary.org/wiki/round_tuit
[1] https://toit.io/product/supported-hardware
- the GC is a sliding compacting GC. As such there is no fragmentation for heap-allocated memory.
- the memory on these devices is tiny. The GC thus doesn't take long time.
- the ESP32 has really good peripherals, making timing sensitive operations very rare. In most cases there is a hardware module that does the job for you. The timing requirements then usually become significant less important.
I think you can easily do 90% of iot projects with this. Which means you have more time for the 10% of projects that are actually hard.
From an embedded system PoV, your sensor might be a 1-Wire protocol device with a super strict signal timing. How do you mix both timing requirements? How do you differentiate embedded projects requiring "precise timing" from those others requiring "every 60 seconds"?
Unless Toit provides drivers for all kind of buses, sensors and peripherals AND it orchestrates the GC with the strict timing requirements. Otherwise it's probably a good fit only if it just runs on a known controlled development board/architecture/platform.
For example the 1-wire protocol is implemented using the RMT (remote control) peripheral. The pixel strips driver uses the UART or i2s.
If really necessary, we could drop down to C, but the hardware is usually better (more precise and leaves us to do other things in the meantime).
Maybe the title should be "Toit is a modern high-level language designed specifically for ESP32".
How often are you bitbanging non standard protocols? And if so, which field are you in?
Not true at all.
> How often are you bitbanging non standard protocols?
Regarding protocols: bitbanging 1-Wire. Not all microcontrollers have this peripheral. You might be lucky if you can adapt some other peripheral like an UART (with due effort). Or you can use for example an external ds2482 and drive it through I2C.
WS2812B: sometimes you can emulate it with some other peripheral, sometimes you have to do it by bitbanging some GPIO.
I don't bitbang so often in general. But it's not just about available "hardware blocks": introducing undesidered delays in embedded applications is a terrible, terrible idea.
You can have a perfectly working sensor through I2C with DMA, super optimized with 0 CPU intervention. This sensor has an ODR of 1kHz. A GC stopping the microcontroller for 400ms makes you stand behind 400 samples you might be processing in real time (FIFO aside, and because you know you shouldn't be doing any processing in an interrupt handler, right?). You don't lose the buffered samples of course, but your processing is now delayed.
Or perhaps you are doing some 44100, 16-bit stereo audio processing (in or out). You have implemented the perfect I2S/DMA mechanism and all that, combined with perfect SDIO reading. What would happen in a real-time processing audio application if the GC introduces even 20ms delays now and then? Horrible latency and/or artifacts... And because your MCU has 32KB of RAM you don't have the luxury of big buffers, so you have to be quick reading, processing and outputting. Stopping the processing = stopping the output.
Or you might be dealing with some external peripheral that needs an answer within a time limit...
You can see it's not just about "hardware blocks".
Following what I said before, even if "60 seconds" is the application required timing, there are other things that might be happening in the background that require precise timing.
Is Toit a bad language? I don't know. But as I said before, it only makes senses if ran under a known platform like ESP32 where the language developers have tuned everything, and the programer doesn't pretend real-time applications. A generic language for every microcontroller? I am not so sure...
https://www.astrobe.com/
https://www.ptc.com/en/products/developer-tools/perc
https://www.aicas.com/wp/products-services/jamaicavm/
https://www.microej.com/
Also I should note that many embedded computers in 2022 are supercomputers when compared to the 1961 IBM mainframes running Lisp.
On microcontrollers, which often have very limited RAM, I'd prefer avoiding doing any heap allocation at all. If there is any need for any dynamic allocations, they are within fixed-size memory pools — each with only fixed-size objects or with objects on a stack.
Maybe they don't do[1] dynamic memory allocation in code segments that have real time constraints, or after initialization, etc. (Most embedded projects actually don't have hard real-time constraints, or have them in extremely localized places like bit banging loops...) This is sounds like a good idea and is orthogonal to whether the language's dynamic allocation support is via malloc/free or gc.
1) A compiler flag or similar optional static check that throws a warning if you have dynamic memory allocation. In scripting languages it can be easy to do accidentally
2) A way to block the gc from happening in a time critical section of code, like how you can disable interrupts
3) Some guarantee on the maximum time gc will take
Here is the Toit version of it: https://docs.google.com/document/d/1K-TYea7jbYfj2ecMUmr0T0zd...
And here the MicroPython: https://www.makerfabs.com/desfile/files/Get-Started-MicroPyt...
The `/` are also the same (division), but it's true that we also use `/` to introduce types. For example `x/int`.
I think Toit is relatively easy to learn, but there are definitely a few things that need explaining in the beginning.
We then experimented with different tokens, and `/` felt best.
[Yes, colons are nice as block introducers but don’t play nice with colons for type ascription, which is where we got Python’s asinine f(x: int, y: bool) -> str; don’t know why Rust went with that instead of ML’s uniform f(x: int, y bool): str.]
Also types are optional in Toit, so they are a bit like comments (though they are now checked so they are less like comments now). So they look a little like // comments.
https://mruby.org/
https://microruby.com/
In particular, Python basically won the significant-indentation argument. Since all programs are formatted with correct indentation the punctuation is redundant clutter. So for a new language it just feels right to go with indentation instead of curlies.
We also wanted to be free to add type annotations and other enhancements, so it was never going to be compatible with Ruby anyway. And we didn't want to raise expectations of Ruby-compatibility that would immediately be dashed.
As others have noted, Toit seems like a bad name. I suppose non-French speakers will tend to inadvertently mispronounce Toit.
Getting traction is hard. In my opinion, having a restrictive license and a bad name make it less likely Toit will gain traction. Finally, Toit's licensing reminds me of Mongoose OS https://github.com/cesanta/mongoose-os#mongoose-os---an-iot-....
Basically if the thought of your code ever ending up in something that someone might somehow make money from, like maybe in an iOS app, is somehow icky - then GPL is for you! If you just want to put it out there and code, not politics, is your thing - go MIT.
Source... https://www.reddit.com/r/roguelikedev/comments/4g738z/commen...
Main restriction is, that we haven't finished the Windows implementation yet. Specifically networking and spawning processes only works on Linux/macOS so far. (The main reason we ported the LSP server to Go).
The `host` package (https://pkg.toit.io/package/github.com%2Ftoitlang%2Fpkg-host...) provides some functionality for running things on the desktop.