
“Why?”, “What the hell is this?”, “Perversion!”, “
Phe-poo-poo-poo ” are some of the many statements we heard when we released the
Iskra JS board on the
Espruino core.
What for
When the right electronics engineer hears that something is done on the Arduino, his body temperature rises by about half a degree: hatred".
')
But you can go even further. Take the Cortex M4 microcontroller, which is ten times richer than what is on the same Arduino Uno, stuff a JavaScript interpreter into it and do JavaScript projects!
I think that at this moment those who are not ready for such an abuse of the holy chips have already burst. I will continue for the rest.
In hobby electronics for the vast majority of projects, the Arduino Uno is enough for the eyes. And it doesn’t even matter whether it works on regular 16 MHz or 4 MHz: whether the backlight of the bed turns on or the pump in the country for 1 ms or 10 ms does not matter.
What matters is that C ++ is complex and wooden. Yes, it is close to hardware, but this is why it requires a deep understanding of this hardware and computer science. Add to this the syntax with a bunch of nuances, which is the sum of the errors of 30 years of language development. Then deprive what turned out to be adequate arrays, strings, dictionaries, and even better - deprive the dynamic memory altogether. Here, finally we got the Arduino.
Watching the questions on our forum, I see that people spend time on hanging out with the language, and not on the essence of their projects. So why not reduce the gap between iron and people? Iron is cheap and constantly evolving, the time of people is expensive and is not taken from anywhere.
A similar process I observed for many years while working in the development of games. In 2003, it was impossible to imagine that the game could be written on something other than C / C ++. Then the built-in machine script appeared in the engines. And then the creation of a full-fledged product became possible without a single line in C. Only Java, C #, Ruby, Python, JavaScript. This is logical, because the iron began to pull "slow languages", and at the expense of much faster development and more available programmers, it became possible to spend more resources on interesting games, and not on finding memory leaks.
What does JavaScript microcontroller programming look like
Programming is like ... JavaScript. On the development for the browser or Node.js. Here is an example:
This program is engaged in receiving SMS'ki and depending on their text with a running light changes the color of the connected RGB-tape. We did such a project for our Christmas tree, but on the classic Arduino. Code was 4 times more.
Espruino Core
So, the computer has the V8 and SpiderMonkey engines for JavaScript. And microcontrollers have an Espruino engine.
Speaking roughly, the Espruino engine is a firmware (sketch, sketch) for microcontrollers, which in turn can execute JavaScript code that you transmit to the board via a serial connection, for example via USB.
Espruino is an open source project, the founder of which is Gordon Williams. A man who single-handedly implemented most of the entire ecosystem and successfully went with it to KickStarter.
This ecosystem consists of several main parts:
- Espruino Web IDE - programming environment;
- Espruino Firmware - a JavaScript machine that runs on a microcontroller;
- Iron - the boards themselves, which are compatible with Espruino;
- Standard library and external libraries;
- Documentation.
Everything in order.
Programming environment
Writing JavaScript code, loading it into the board and monitoring the output takes place in the Espruino Web IDE. This application is for Google Chrome, so it is put in 1 click and works under all desktop OSes.
For the user, this environment replaces the Arduino IDE.
In terms of functionality, the Espruino IDE is, of course, much simpler than full-length Eclipse or Visual Studio, but it is more advanced than the Arduino IDE.
If you look at the environment window with one glance, you will see the code editor (on the right), the console panel (on the left) and a button for loading the code into the board.
The console is like a Serial Monitor in the Arduino IDE, but unlike it, it not only outputs, but also accepts: you can directly on the fly, without resetting and downloading a new program, call a function, see the value of a variable, break the cycle, etc.
After working more closely, you will encounter a debugger (aha, step-by-step execution, breakpoints), editor prompts, error highlighting on the fly and other nice features.
In addition, right from the IDE, you can upgrade the version of Espruino Firmware itself to the latest. The environment itself downloads the latest available release and uploads it via USB.
Firmware
The heart of the system is the firmware that runs on the microcontroller. It is written in pure C, loaded once in a separate place in the flash memory of the microcontroller and is engaged in the fact that it executes a custom JS code that comes through a serial connection or is located in the user area of flash memory.
If you schematically depict the layout of flash memory for Iskra JS, we get the following picture:

Loader
First comes the bootloader, which is never updated (conditionally). This is a small program, with the execution of which the life of the microcontroller absolutely always begins after switching on or resetting.
The loader does a pretty simple thing:
- If the user button BTN1 is not pressed, it immediately transfers control to the interpreter.
- If the button was pressed at the start, it loops in on itself and waits, either until the button is pressed again to exit to the interpreter, or it is waited until the new version of the interpreter is downloaded via USB. In this case, the bootloader will overwrite the flash memory area with Espruino Firmware, and we will get the latest version of the interpreter on the board.
Interpreter
So, the interpreter, which does the main work, follows the loader.
When it starts, it checks by checking the magic byte whether there is any saved JavaScript in the user's flash memory. If there is, it is accepted to execute it.
If there is no code, or if we manually exit BTN1 with the help of BTN1, nothing will be done to the meeting, we will just get a JS-machine ready for operation.
Free memory
After the interpreter there is a memory space that you can use for non-volatile storage of your data. This is a kind of replacement of the EEPROM with the Arduino, but with its own specifics, and even tens or hundreds of times more.
Custom code
This is the JS program that the interpreter executes. The program is there in the usual text form, one briquette, as is.
For the fact that a lot of connected libraries with their dependencies and your own program turned into one cast and minified briquettes keeps track of when loading IDE.
Rather, all the work is done not by the IDE, but by its GUI-independent part of EspruinoTools, which has a command line interface and an entry point for use as a Node.js module. Therefore, if you wish, you can use Vim, Atom, Eclipse, or whatever is more convenient for you to develop.
Instead of a text briquette, a binary binary image of the RAM, which fully reflects the state of the interpreter at the time of saving, may lie in place of the code. But this is not the technical details for a quick overview.
Libraries
Libraries can be divided into 3 types: standard, built-in and external.
Standard library
The standard library is the functions and objects that can be used together. Among them, both the familiar and specified in the standard language `Date`,` JSON`, `Math`,` Object`, `setInterval`,` setTimeout` and other-other, and Espruino-specific functions for working with pins, interfaces by memory.
Among the functions, you will find the pinMode`, `digitalRead`,` digitalWrite`, `analogRead`,` analogWrite`, familiar to the arduinschik, and the not yet so familiar `setWatch` to monitor the input pins,` digitalPulse` to accurately generate a sequence of digital pulses and many more different pieces to work with peripherals.
By the way, despite the fact that the `pinMode` function is on the platform, by default it works by itself, behind the scenes, so in most scenarios you don’t think about it (at this point the last electronics engineer burst loudly).
What you won't find in the standard library is `delay`. Mamma Mia, how grateful I am for it! It is enough to rebuild thinking a little and it becomes clear that everything is solved through `setInterval`,` setTimeout` without any `delay`.
In gratitude, you get asynchronous performance: you can blink twenty LEDs independently, each with its own frequency. You also get energy efficiency: `delay` is burning processor time, and without` delay` the processor can sleep peacefully while there is nothing to do. In Espruino, while there is no work, the processor falls asleep and consumes tens of times less current.
Built-in libraries
Built-in libraries are the same part of the standard library in the sense that they are firmly sewn into Espruino Firmware, but to access their functionality, they must be syntactically connected using the require programmer, which is familiar to JavaScript programmers.
Among such libraries you will find, for example, `fs` to work with file systems of SD-cards,` http` to create a web-interface to your device, `Waveform` to record / play audio signals, and others.
Standard and built-in libraries are implemented on pure C, and the user is displayed only a JavaScript interface in the form of a set of objects, functions and modules. This allows you to achieve maximum efficiency for the implementation of complex algorithms, while leaving the possibility of accessing them from the high-level code.
You yourself can implement on C something that JavaScript would say no, thank you, and bring only a few tails needed to launch to the outside.
External libraries
External libraries are what form the wealth of the ecosystem. They are written in JavaScript by the authors Espruino, we write, write users Espruino.
They can be stored on a local disk, in a sandbox of the current project, can be in an online repository, can be on GitHub, can lie on NPM.
Libraries are connected, traditionally, with `require`.
When the environment sees `require`, it recursively loads them from a remote source and, when loading the sketch, sticks their contents to the beginning of your program. Thus, for the microcontroller, a solid briquette is formed with the code I mentioned above.
This approach also means that, unlike Arduino, the user does not need to stumble that the library first needs to be found, downloaded, put where it is needed. It is enough just to slyamzit a sketch you like from somewhere and the environment will deal itself with dependencies on libraries.
Iron
Here we come to the most tangible component of the Espruino ecosystem. These are the boards that Espruino Firmware can execute.
These include the original
Espruino Board ,
Espruino Pico , as well as the
Iskra JS released by Amperco. On the listed boards everything is already installed at the factory, they are immediately ready for operation.
You can hit the tambourine several times and put your Espruino core on STM32 Discovery, Nucleo and, suddenly, on ESP8266.
Documentation
There is nothing sadder than something very cool and powerful, but without documentation.
Espruino has good documentation. At
www.espruino.com/Reference you will find many reference and training articles.
We want to do more and better. Therefore, we created a separate section:
js.amperka.ru , remove the video lessons. Work is still in progress, but much has already been covered.
And traditionally for those who love boxed solutions, we created the “
Iodo ” set. In it, Iskra JS, modules and color book.
Here is such parsley. The only mystery remains is, could even one correct electronics engineer read this line up?