#Intro This is a step-by-step guide to show you how to build the mbed OS and JerryScript together into the STM32F4 and STM32F429ZI boards.
JerryScript is the lightweight JavaScript engine intended to run on a very constrained devices such as microcontrollers: only few kilobytes of RAM available to the engine (<64 KB RAM) constrained ROM space for the code of the engine (<200 KB ROM). The engine supports on-device compilation, execution and provides access to peripherals from JavaScript. If you want to know more about the JerryScript, check out its official project site.
mbed OS is the operating system which is created for mbed-enabled boards. It allows your C++ applications to run on these boards by providing APIs that you can use from your application to control the hardware. The system is designed specifically for constrained devices. So, it works behind the scenes to automatically make the most of the limited hardware and network resources available. This is the first native OS support for thread, first inclusion of BLE. If you want know more about the systematic, visit this link.
Yotta is the build system, we’ll get into the details of it later, but what you need to understand at this point is that mbed OS applications cannot be built without yotta. Yotta combines our application code with the mbed OS code-base and any other module that which might be needed. To tell yotta what our application needs, we have to add a list of dependencies to each new application. The easiest way to add this system to our application is to describe the component mbed-drivers as a dependency of our application. For more detailed information and guides you should check out the official guide of yotta.
Now, you probably see what we are up to. No? Let’s get into the details!
The mbed OS allows you to run your C++ application on your board. The JerryScript is a JavaScript engine which is written in C/C++. It means the JerryScript is able to run your board under (or co-operative with) mbed OS. So, you can parse and run any JavaScript code on your board with extended hardware and network resources. There are so many people who do not want to (or do not know how to) write an application in C++ language, but they already to know how to write an application in JavaScript language (and they love the JS language :) ). So, there is a solution to run your JavaScript application, script, funny code on your own board with the help of the mbedOS widely tools.
#Dependencies
##Yotta (version: 0.13.0) Yotta is a tool that ARM team building at mbed to help themself and others build better software for C-family languages by making it easier to share and re-use software modules.Yotta is not only a command line tool but also a culture of building software components that do one thing well, declare a clear interface, and can be re-used. Yotta installing link. There are Linux, Windows and Mac guide too on the yotta website. Please follow the Linux guide to install yotta to your computer. We use Ubuntu for all these tutorials.
##GCC If yotta is available on your machine, then let's check your gcc in terminal with
gcc --version
command. We recommend the gcc version of 5.2.1, we build with this. You need a cross toolchain for it:
sudo add-apt-repository ppa:terry.guo/gcc-arm-embedded
sudo apt-get update
sudo apt-get install gcc-arm-none-eabi
NOTE:To remove installed toolchain, just input "sudo apt-get remove gcc-arm-none-eabi”.
If you do not have any GCC compiler installed and you don’t have apt-get install commmand, please check out this site to download GCC 5.2.1 which was tested for building JerryScript for stm boards.
##GIT
Git allows groups of people to work on the same documents (often code) at the same time, and without stepping on each other's toes. It's a distributed version control system. So you will need to have git, you can install that with sudo apt-get install git command.
There is some easy tutorial to learn about how to use it
- rogerdudler.github.io/git-guide - just a simple guide for getting started with git.
- try.github.io - a short practice exercises
- atlassian.com/git/tutorials - become a git guru
##ST-LINK For the boards to send files and binaries we use ST-LINK v2. It is a linux command line program. There is a step-by-step guide how to download and use it for our microcontrollers: First of all, you need to install dependencies. In terminal, type
sudo apt-get install libusb-1.0-0-dev git
Now you need to make a directory where you install the ST-LINK. In my case there is a 'work/stlinkv2' directory for that. We have one more dependency, the pkg-config but it's already installed in most of Ubuntu.
Now we clone the GitHub repository. Download and build the project/sources by the following steps:
cd stling.git
./autogen.sh
./configure
make```
And we are ready, now if you connected the board for your computer, use the st-flash binary to flashing data to the board. There is not necesary step, unless you don’t want to test the st-link.
```st-flash write 0x08000000 file.bin```
The 0x0800000 is an memory code adress, so if you working with other board type there will be different. For your information when you use st-flash command you should be in the folder where the st-flash binary exists. This command will result the binaries flashing to the boards. After flashing process it is recommended to restart the device..
Here is a trick that makes your life easier:
After that, you need to make a softlink for st-flash. To make links between files you need to use ‘ln’ command. A soft link consists of special type if file that servers as a reference to another file or directory. Linux like operating system often uses symbolic links. To creat soft links you need to enter:
```ln -s ~/work/stlinkv2/stlink.git/st-flash st-flash```
You can check if its working in /usr/bin/ folder to do “ls -la” and you see that next to the st-flash link: “st-flash -> /home/$USER/work/stlink/st-flash”. If you see that it’s ready to use everywhere the st-flash command, and you don’t need to there where is st-flash is exist.
Sometimes the tool drop the __WARN src/stlink-common.c: unknown chip id!__, you can solve this problem with this 3 simple steps:
1. short the BOOT0 pin with VDD
2. push the reset button on the board
3. enter #st-flash erase# in terminal where you has the ST-LINK v2 files.
*This trick can solve this problem.*
##Minicom
If you want to benchmarking your program, you have so many option, we used ‘minicom’ for this. Minicom is a text-based serial communication program. It is used to talk to external devices such as mobile phones, microcontrollers. Install the program with
```sudo apt-get install minicom```
#JerryScript
##Repository download & make
Let's start with the JerryScript repository. Now, you have to clone the JerryScript into your local repository:
git clone https://github.com/Samsung/jerryscript.git
After you cloned the source from github, build a release for linux, for check everything is ok.
cd JerryScript make release.linux -j
If everything finished with no error, let's enter to the targets folder.
cd targets
This folder contains the target board specific codes. There are a few official targets and a tools folder. So, if you need a new target go ahead and turn the page!
##Creat new targets
We need to create new targets if you want, to use other boards, because mbed OS not supported any boards… yet. So we build JerryScript for the STM32F429ZI and the STM32F4 boards, the former is easier, because arm supported this board. The Latter is more difficult, because there is no support, but it is not impossible. Let’s start with the easier, if you have the other board you can skip this guide, or the second.
###New target for STM32F429ZI
Let's create a new target for STM32F429ZI board. We have a source repository for this board: [here](https://github.com/knightburton/mbedstm32f429i). Clone this repository into the current (jr/targets/) folder. The repository contains the source code for the target. Check [readme](https://github.com/knightburton/mbedstm32f429i/blob/master/readme.md) for the details.
git clone https://github.com/knightburton/mbedstm32f429i
Now you have a new target source. Let's see what we’ve got in this repository.
* There is a **js folder**. In this folder contains the JavaScript files, those files which will be executed by JerryScript. There are two JavaScript files at the moment: main.js and blink.js. In the main.js file there is a function called 'sysloop'. This function is the main entry point of the JavaScript. //TODO: sysloop information
* There is a **Makefile.mbedstm32f429i file**. This file is necessary for the build JerryScript, build yotta target and flash. In this file you can modify some extra switch for compiler (e.g.: compile optimisation). You can modify the JerryScript Heap size in kByte and the target dir for the mounted board.
* **module.json:** yotta configuration file that contains: the build name, the build version, description, author, licence information and dependencies. In the beginning there is just one dependency: mbed-drivers. This one pulls the other dependencies. If you want to know more about the yotta configuration and usage, please visit the yotta documentation [site](http://yottadocs.mbed.com/).
* There is a **.yotta.json file**. Contains the build target name for yotta.
* There is a **source folder**. This folder contains all of the c and c++ files and these headers. Let's look into it:
Let's see in order:
**jerry_extapi** - contains some macros for JerryScript object, function and number validation and this file contains the “low level” extended APIs. So if you want to reach some mbedOS function in your javascript, you have an opportunity to expand that js API with system calls, for example led blinking.
**jerry_port** - this file contains some error and log message implementation for JerryScript.
**jerry_run** - contains the core JerryScript API. If you want to know more about Jerry API, please visit the JerryScript API documentation [site](http://samsung.github.io/jerryscript/API/).
**jerry_targetjs.h** - this contains your JavaScript code.
**main** - obviously this is the main entry point of the mbed OS. This file contains the app_start() function which is the main() function in the OS.
**makejerry.cmake** - The yotta build calls this file. This effect some settings,
* set application name
* set compile flags
* include the jerry-core
* link the jerryscript
**native_mbedstm32f429i** - this contains the led blinky function implementation in C++. This file contains the “high level” API. These APIs will be used in the jerry_extapi file.
###New target for STM32F4
This board is supported, but there are more problem with this than the STM32F429ZI target, fortunately it is just a few target specific dependency problem. Let’s fix this.
First of all, you have to enter the JerryScript/targets folder (we want to create a new target here, and the command assumes you are in the JerryScript root folder).
cd targets
We have a repository for this target. So, you have to clone our repository into this folder.
git clone https://github.com/knightburton/mbedstm32f4.git
You have to enter the mbedstm32f4 folder:
cd mbedstm32f4
now, you have to select the yotta target. This board does not supported yet (as I mentioned before), but there is an early target for this. So, type the following command into the terminal:
yotta target stm32f4-disco-gcc
Now, you have to add the main module to the yotta dependencies for mbed OS. This is the mbed-drivers module. So, just type the following command into the terminal:
yotta install mbed-drivers
This command will install the mbed-drivers module, and some other module for your target, e.g.: uvisor-lib, ualloc, cmisi-core, …
if you want to know more about this modules, please visit the official mbed GitHub page.
(link: https://github.com/ARMmbed/mbed-os )
So, now you have an incorrect yotta dependency tree, because two board specific definition are missing from that. You have to add the following modules:
hal-st-stm32f407vg
cmsis-core-stm32f407xg
You have to add these module by manually. These modules will define the missing headers.
Let’s see the first module, which is the hal-st-stm32f407vg. You have to enter the root mbed hal module. Just type the following commands line by line (if you are int the JerryScript/targets/mbedstm32f4 folder):
cd yotta_modules/mbed-hal-st-stm32f4/
Now, you have to open the mbed-hal-st-stm32f4 module json file. Open the module.json file with favorite editor, and you have to add the following lines to the targetDependencies block:
"stm32f4": { "mbed-hal-st-stm32f407vg": "^0.0.1" }
It should look like this:
"targetDependencies": { "stm32f407vg": { "mbed-hal-st-stm32f407vg": "^0.0.1" }, "stm32f401re-no-inherit": { "mbed-hal-st-stm32f401re": "~0.1.0" }, "stm32f429zi-no-inherit": { "mbed-hal-st-stm32f429zi": "^1.0.0" }, "stm32f439zi-no-inherit": { "mbed-hal-st-stm32f429zi": "^1.0.0" } }
Let’s see the second problem. You have to go back one folder and have to enter the cmsis-core-st! So, type the following command into the terminal:
cd ../cmsis-core-stm32f4
There is a module.json file agein, which is decribe some information for this module (like before). You have to open an editor this file. After you opened this, you ahve to add the following lines into the targetDependencies block:
"stm32f407xg": { "cmsis-core-stm32f407xg": "^0.0.1" }
it should look like:
"targetDependencies": { "stm32f407xg": { "cmsis-core-stm32f407xg": "^0.0.1" }, "stm32f401xe-no-inherit": { "cmsis-core-stm32f401xe": "~0.1.0" }, "stm32f429xi-no-inherit": { "cmsis-core-stm32f429xi": "^1.0.0" }, "stm32f439zi-no-inherit": { "cmsis-core-stm32f439zi": "~0.1.0" } }
Now dependencies are fixed.
If you want to compare STM32F4 and STM32F429ZI dependency tree, just go back to the jr/targets/mbedstm32f4 folder, and run the yotta ls command. You have to get this result:
jerry 0.0.0 ┗━ mbed-drivers 1.1.0 ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal ┃ ┗━ mbed-hal-st 1.0.0 yotta_modules/mbed-hal-st ┃ ┗━ mbed-hal-st-stm32f4 1.2.0 yotta_modules/mbed-hal-st-stm32f4 ┃ ┣━ uvisor-lib 1.0.13 yotta_modules/uvisor-lib ┃ ┣━ mbed-hal-st-stm32cubef4 1.0.2 yotta_modules/mbed-hal-st-stm32cubef4 ┃ ┗━ mbed-hal-st-stm32f407vg 0.0.1 yotta_modules/mbed-hal-st-stm32f407vg ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core ┃ ┗━ cmsis-core-st 1.0.0 yotta_modules/cmsis-core-st ┃ ┗━ cmsis-core-stm32f4 1.1.0 yotta_modules/cmsis-core-stm32f4 ┃ ┗━ cmsis-core-stm32f407xg 0.0.1 yotta_modules/cmsis-core-stm32f407xg ┣━ ualloc 1.0.3 yotta_modules/ualloc ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc ┣━ minar 1.0.4 yotta_modules/minar ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform ┃ ┗━ minar-platform-mbed 1.1.2 yotta_modules/minar-platform-mbed ┣━ core-util 1.5.2 yotta_modules/core-util ┗━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill
##JerryScript & mbed build
Here is the tutorial to build JerryScript, end of the tutorial we make a little program wich blinking the board leds. So keep going on the tutorial. :) If the yotta, gcc and st-link is works fine, let's see how to build JerryScript for the board. There is a Makefile.mbedstm32f429i file in the cloned target source. You have to go back to the JerryScript root folder. Assuming that you are in the targets folder.
cd ..
First, clean the build:
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i clean
Then, you have to run the makefile with the jerry rule.
The jerry rule
creates the build folder in the targets/mbedstm32f429i
builds the JerryScript to the build folder (JerryScript/build)
copy the jerry libraries into the targets/mbedstm32f429i/libjerry
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i jerry
Let’s create the mbed binary.
For achieve this, you have to convert the JavaScript (the main.js and the blink.js in the targets/mbedstm32f429i/js/) to C language. This is gonna be easy for you, because there is a python script in the JerryScript/targets/tools folder for this. This python script create a C header file which is contains your JavaScript code (without comment and whitespace) as String. You can use this script with the following command:
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i js2c
The C file will be generated at targets/mbedstm32f429i/source folder as jerry_targetjs.h.
So, if everything was good, then you have to build yotta for mbed OS. The first one is this way:
You have to enter the targets/mbedstm32f429i folder
cd targets/mbedstm32f429i
Then you have to select the correct target for the yotta. Target descriptions allow yotta to compile the same code for different target platforms (different desktop operating systems, or different embedded devices).
Each target description contains information both about how to run the compiler to compile (or cross-compile), and configuration information describing the hardware or environment that the target represents.
So, type the following command into the terminal:
yotta target stm32f429i-disco-gcc
Now, you have to wait until the yotta finish installing the mBed modules. After it is finished with no error, you can check the current yotta dependency tree (this tree will show you which modules are installed) just type the following command into the terminal:
yotta ls
The output should look like:
jerry 0.0.0 ┗━ mbed-drivers 0.12.0 ┣━ mbed-hal 1.2.2 yotta_modules/mbed-hal ┃ ┗━ mbed-hal-st 1.0.0 yotta_modules/mbed-hal-st ┃ ┗━ mbed-hal-st-stm32f4 1.2.0 yotta_modules/mbed-hal-st-stm32f4 ┃ ┣━ uvisor-lib 1.0.12 yotta_modules/uvisor-lib ┃ ┣━ mbed-hal-st-stm32cubef4 1.0.2 yotta_modules/mbed-hal-st-stm32cubef4 ┃ ┗━ mbed-hal-st-stm32f429zi 1.0.5 yotta_modules/mbed-hal-st-stm32f429zi ┣━ cmsis-core 1.1.2 yotta_modules/cmsis-core ┃ ┗━ cmsis-core-st 1.0.0 yotta_modules/cmsis-core-st ┃ ┗━ cmsis-core-stm32f4 1.1.0 yotta_modules/cmsis-core-stm32f4 ┃ ┗━ cmsis-core-stm32f429xi 1.0.3 yotta_modules/cmsis-core-stm32f429xi ┣━ ualloc 1.0.3 yotta_modules/ualloc ┃ ┗━ dlmalloc 1.0.0 yotta_modules/dlmalloc ┣━ minar 1.0.4 yotta_modules/minar ┃ ┗━ minar-platform 1.0.0 yotta_modules/minar-platform ┃ ┗━ minar-platform-mbed 1.1.2 yotta_modules/minar-platform-mbed ┣━ core-util 1.4.0 yotta_modules/core-util ┗━ compiler-polyfill 1.2.1 yotta_modules/compiler-polyfill
You can able to add some optional module to yotta. It is very easy for you, just type this into the terminal:
yotta install
Help: The yotta modules list is available here: http://yotta.mbed.com/ you can find a module by name, description or keywords.
Next step: build yotta
Go to the ($ROOT), then run the following command:
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i yotta
Or you can do this manually. Go to the ($TARGET) folder, and run this:
yotta build
The executable file is generated at targets/mbedstm32f429i/build/stm32f429i-disco-gcc/source/jerry.bin.
##JerryScript flashing to the board
If you want to test it, you have to flash the binary into the board. If you configured the ST-LINK correctly, just type the following command into the terminal:
st-flash write targets/mbedstm32f429i/build/stm32f429i-disco-gcc/source/jerry.bin 0x08000000
Or, if you do not want to do this, just pick the shorter way:
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i flash
At this point, you have to wait until the led near the USB port stop blinking. When it is done reset the board and LED1 will blink in every seconds.
##How to blink program works
All .js files in js folder are executed, with main.js in first order. sysloop() function in main.js is called periodically in every 100msec by below code in main.cpp by jerry_loop(), which calls js_loop().
minar::Scheduler::postCallback(jerry_loop).period(minar::milliseconds(100))
sysloop() then calls blink() in blink.js which blinks the LED in every second.
#Benchmark tests
Let’s see in action the JerryScript and mBedOS together. Performance, code size and memory benchmark tests.
##Performance
So now benchmarking the program, you have so many option, we used ‘minicom’ for this, what you already have installed if you read the ##Minicom article. We use for the communication USB-TTL so if you want to reproduce our process, you need to have this part. For STM32F4 board we need to connect pin PA3 to TXD and PA2 to RXD with breadboard jumper wire to have the communication right. In the JerryScript folder targets/stm32f4/yotta_target/stm32f4-disco-gcc/target.json file have the information for this, to other boards. After you connected your board to the pc enter ```dmesg | grep STM``` to the terminal, you can check the usb devices, and there is showed up the STM32 STLink. You need to modify your main.cpp in JerryScript/targets/stm32f4/source/main.cpp to print the lines. Add the highlighted lines to main.cpp:
#include "mbed-drivers/mbed.h" #include "jerry-core/jerry.h" #include "jerry_run.h" #include "jerry_targetjs.h"
Serial pc(USBTX, USBRX); //tx, rx
static int jerry_init(void) { int retcode; int src;
DECLARE_JS_CODES;
/* run main.js / pc.printf("Run main.js...\r\n"); retcode = js_entry(js_codes[0].source, js_codes[0].length); if (retcode != 0) { printf("js_entry failed code(%d) [%s]\r\n", retcode, js_codes[0].name); js_exit(); return -1; } / run rest of the js files */ pc.printf("Run rest of the .js files...\r\n"); for (src=1; js_codes[src].source; src++) { retcode = js_eval(js_codes[src].source, js_codes[src].length); if (retcode != 0) { printf("js_eval failed code(%d) [%s]\r\n", retcode, js_codes[src].name); js_exit(); return -2; } } // end return 0; }
static void jerry_loop(void) { static uint32_t _jcount = 0; js_loop(_jcount++); }
void app_start(int, char**){ int i; if (jerry_init() == 0) { for(i=0; i<=10; i++){ jerry_loop(); js_exit(); pc.printf("READY.. \r\n"); } } }
These changes results as you can read the time between the “Run rest of the .js files…” and “READY...“. Build the program with yotta and flashed into the board with st-link. Now we are move on the minicom. So your program flashed into the board, and want to do some measurement. Type ‘sudo minicom -s’ to the terminal. Configure serial port as follows:
+-----------------------------------------------------------------------+
| A - Serial Device : /dev/ttyUSB0 |
| B - Lockfile Location : /tmp/ |
| C - Callin Program : |
| D - Callout Program : |
| E - Bps/Par/Bits : 9600 8N1 |
| F - Hardware Flow Control : No |
| G - Software Flow Control : No |
+-----------------------------------------------------------------------+
Now you can quit from the options, and in configurations select the simple ‘exit’. Now you in minicom:
push N key - we want to know how fast is our program select ‘Timestamp Toggle’
push N - reapeat it for one more, because know the timestamp is in millisecond
push U - for the good readability push in the function menu the ‘Add Carriage Ret’
restar the board - now you can see the time spent in your program
So, you can use the timestamps for calculate the real running time defference between the fisrt pc.printf() timestamp and second pc.printf() timestamp.
##Size
To get the size of the binary files use a simple ‘size jerry’ command in terminal. The ‘jerry’ file next to the generated binary file in jerryscript/targets/stm32f4/build/stm32f429i-disco-gcc/source/. You will get a simple size statistic. e.g.:
text data bss dec hex filename
254136 408 203960 458504 6ff08 jerry
##Memory
There are two options to measure and track the memory in our project. The first one is trace the mbed OS memory allocation, reallocation and free command results, and the second one is the JerryScript memory statistics. So, let’s see in order:
###mbed OS memory trace
If you want to enable the memory trace option in mbed OS, you have to do the following. There is a simple solution in the ualloc module.
Navigate to the yotta_targets folder. It assumes the current folder is the JerryScript root folder.
cd targets/mbedstm32f429i/yotta_targets/stm32f429i-disco-gcc
Edit target.json:
subl target.json
You have to add the following lines into the config block. These lines will be turn on the memory trace in the ualloc module. This is a temporary solution, the ARM team really want to find a better way for this.
"debug": { "options": { "memory-trace": true } }
Now, you have to build the yotta again!
Go back to the JerryScript root folder, and use the makefile for this.
cd ../../../.. make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i yotta
Now if you flash your program into the board.
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i flash
When you alloc, realloc or free a memory space, you will get a simple log message, or a simple error message if something is not okay.
e.g.:
UAL:L ua c:0x803b1b1 s:4 m:0x2001ab78 UAL:L ua c:0x803b1b1 s:48 m:0x2001b140 UAL:L ua c:0x8039ed5 s:212 m:0x2002ff2c UAL:L ua c:0x803b1b1 s:20 m:0x2001b178 UAL:L ua c:0x803a06d s:3420 m:0x2002f1d0 UAL:L ua c:0x803b1b5 s:16 m:0x2002c290 UAL:L uf c:0x800bd67 m:0x2002c290
Note: If you do not receive the trace message when you running your program on the board, you have to check the ualloc module, it might be outdated or modified. Please check the ARM team ualloc module repository, and check the current state of this module.
https://github.com/ARMmbed/ualloc
If your module is outdated, you have to update it! Just go to the target root folder (jr/targets/mbedstm32f429i), and run the following command:
yotta update
OR if you are that kind of person, change the ualloc module source code manually :).
####JerryScript mem-stat
Okay, now let’s see how you can enable the memory statistic in JerryScript. This is a little bit longer than the mbed OS memory trace solution.
First of all, navigate to the target folder. It assumes the current folder is the JerryScript root folder.
cd targets/mbedstm32f429i
Edit Makefile.mbedstm32f49i:
subl Makefile.mbedstm32f429i
You have to add the following switch option to the `EXT_CFLAGS`:
-DMEM_STAT
It should look like:
EXT_CFLAGS := -D__TARGET_MBED_STM32F4 EXT_CFLAGS += -mlittle-endian -mthumb -mcpu=cortex-m4 EXT_CFLAGS += -Wno-error=format= EXT_CFLAGS += -DMEM_STAT
Save the file but do not close it yet!
You have to modify the jerry block too. You will find the jerry block around the 30th line.
There is a make command with one switch and two arguments around the 45-46. lines. You have to modify the second argument.
Change the `.external` suffix to the `external-mem_stats`.
It should look like:
make -C
Then, under the `make` command, there are three `cp` commands. You have to modify all of them. These cp command will copy the jerry core libs into our targets libjerry folder.
In the first `cp` command, you have to change the `external` keyword to the `external-mem_stats`.
cp cat $(INTERM)/$(TYPE).external-mem_stats/list $(OUTPUT)/.
In the second and the third `cp` command, you have to modify the same thing.
Add the `-mem_stats` keyword after the `lib$(TYPE)`.
cp
When you finish, it should look like:
make -C cat $(INTERM)/$(TYPE).external-mem_stats/list
We have done with that! Now, we have to change something in the source files.
This is the `targets/mbedstm32f429i/source` folder.
cd source
Open the `jerry_run.cpp` file with an editor and modify the `jerry_init flags` in the `jerry_init` function. So, ...
subl jerry_run.cpp
Around the 32th line, there is a `jerry_flag_t flags = JERRY_FLAG_EMPTY;` command.
Modify the`JERRY_FLAG_EMPTY` value to the `JERRY_FLAG_MEM_STATS` value.
jerry_flag_t flags = JERRY_FLAG_MEM_STATS;
Save and close the jerry_run.cpp file and open the `main.cpp` with an editor. In this file, you have to add the `js_exit()` call after the `jerry_loop()` call, because of the memory statistic does not show up without this. The memory statistic will run after the js engine stop working.
I mean something like this in the main.cpp:
void app_start(int, char**) { pc.printf ("\r\nJerryScript in mbed STM32F429ZI\r\n"); if (jerry_init() == 0) { jerry_loop(); js_exit(); } }
Save and close thr main.cpp file! Now you have to go back to the JerryScript root folder and build jerry again!
It assumes you are in the jr/targets/mbedstm32f429i/source folder:
cd ../../.. make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i jerry
If the Jerry build finished with no error, run js2c to convert your javascript code into c code, build yotta and flash the binary to your board! Follow the next few command:
make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i js2c yotta make -f targets/mbedstm32f429i/Makefile.mbedstm32f429i flash
So, when the js is finished with no error on your board, you will get a memory statistic report in the terminal!
e.g.:
Heap stats: Heap size = 63488 bytes Chunk size = 64 bytes Allocated chunks count = 0 Allocated = 0 bytes Waste = 0 bytes Peak allocated chunks count = 759 Peak allocated = 47988 bytes Peak waste = 660 bytes
Pools stats: Chunk size: 8 Pools: 0 Allocated chunks: 0 Free chunks: 0 Peak pools: 719 Peak allocated chunks: 5752
*NOTE:
If the JerryScript memory statistic does not print any value, you have to go to the definition of the mem-stat printf (you will find this in `JerryScript/jerry-core/mem/mem-allocator.cpp` and `JerryScript/jerry-core/mem/mem-heap.cpp`) and you have to modify the printf format, because of the default print format is `%zu` (maybe this format is not good for you).*