mbed Blog

mbed OS 5.1.4 Release Available

We are pleased to announce the mbed OS 5.1.4 release is now available.

This release includes many minor enhancements and fixes, adds some target HAL ports in preparation for upcoming new targets (ST Disco F769NI, Delta DFBM NQ620, MTM mtconnect 04S, ST Nucleo f303ze), and some early additions for runtime heap memory tracking features we're working on that we'll share more on soon.

Here is a full list of all changes and fixes in this release...

Ports for Upcoming Targets

  • 2504: [Disco_F769NI] Added new target
  • 2654: DELTA_DFBM_NQ620 platform porting
  • 2615: [MTM_MTCONNECT04S] Added support for MTM_MTCONNECT04S
  • 2548: Nucleof303ze

Fixes and Changes

  • 2678: Fixing NCS36510 compile on Linux
  • 2657: [MAX326xx] Removed echoing of characters and carriage return
  • 2651: Use lp_timer to count time in the deepsleep tests
  • 2645: NUCLEO_F446ZE - Enable mbed5 release version
  • 2643: Fix thread self termination
  • 2634: Updated USBHost for library changes
  • 2633: Updated USBDevice to use Callback
  • 2630: Test names not dependent on disk location of root
  • 2624: CFSTORE Bugfix for realloc() moving KV area and cfstore_file_t data structures not being updated correctly
  • 2623: DISCO_L476VG - Add Serial Flow Control pins + add SERIAL_FC macro
  • 2617: STM32F2xx - Enable Serial Flow Control
  • 2613: Correctly providing directories to build_apis
  • 2607: Fix uvisor memory tracing
  • 2604: Tools - Fix fill section size variation
  • 2601: Adding ON Semiconductor copyright notice to source and header files.
  • 2597: [HAL] Fixed "intrinsic is deprecated" warnings
  • 2596: [HAL] Improve memory tracer
  • 2594: Fix TCPServer constructor
  • 2593: Add app config command line switch for test and make
  • 2589: [NUC472] Fix heap configuration error with armcc
  • 2588: Timing tests drift refactor
  • 2587: add PTEx pins as option for SPI on Hexiwear - for SD Card Interface
  • 2584: Set size of callback irq array to IrqCnt
  • 2583: github issue and PR templates
  • 2582: [GCC_CR] fix runtime hang for baremetal build
  • 2580: lwip - Add check for previously-bound socket
  • 2579: lwip - Fix handling of max sockets in socket_accept
  • 2578: Fix double free in NanostackInterface
  • 2576: Add smoke test that builds example programs with mbed-cli
  • 2575: tools-config! - Allow an empty or mal-formed config to be passed to the config system
  • 2562: Fix GCC lazy init race condition and add test
  • 2559: [utest]: Allow the linker to remove any part of utest if not used
  • 2545: Added define guards for SEQUENTIAL_FLASH_JOURNAL_MAX_LOGGED_BLOBS so
  • 2538: STM32F4xx - Add support of ADC internal channels (Temp, VRef, VBat)
  • 2521: [NUCLEO_F207ZG] Add MBED5 capability
  • 2514: Updated FlexCan and SAI SDK drivers
  • 2487: Runtime dynamic memory tracing
  • 2442: Malloc heap info
  • 2419: [STM32F1] Add asynchronous serial
  • 2393: [tools] Prevent trace-backs from incomplete args
  • 2245: Refactor export subsystem
  • 2130: stm32 : reduce number of device.h files

Using the release

You can fetch the mbed OS 5.1.4 release from the mbed-os GitHub repository, using the tag "mbed-os-5.1.4".

Please feel free to ask any questions or provide feedback on this release here, or to contact us at support@mbed.org.

Fixed exporters in the mbed Online Compiler

We have three ways of developing on top of mbed OS: in the browser using the mbed Online Compiler, offline using mbed CLI, or by using an IDE like µVision or Eclipse. The last option adds a lot of flexibility: you can use mbed RTOS and mbed OS 5 as your application middleware, while still being able to develop and properly debug your application in your favourite editor.

Unfortunately, we had some issues with updating the exporter code to handle the new mbed OS 5 projects, so exporting an mbed OS 5 project from the mbed Online Compiler resulted in a non-compiling project.

The good news: we reworked our exporters and you can export mbed 2.0 and mbed OS 5 projects from the online compiler once again, so if you had trouble exporting a project in the past - give it another shot.

In addition to exporting from the online compiler you can export to IDEs using mbed CLI. This allows you to keep using mbed CLI for library management, but still use a proper debugger.

Depending on your target you can export your mbed projects to:

  • uVision 4
  • uVision 5
  • DS-5
  • LPCXpresso
  • IAR Embedded Workbench
  • CooCox CoIDE
  • Kinetis Design Studio
  • Simplicity Studio
  • Atmel Studio
  • SW4STM32 Systems Workbench
  • e2studio
  • Emblocks

/media/uploads/janjongboom/uvision-nordiv.png

Debugging an mbed OS 5 project in uVision 5.

If you still run into issues with the exporters, please report an issue against ARMmbed/mbed-os and we'll look into it.

-

Jan Jongboom is Developer Evangelist IoT at ARM and loves a good debugging session.

Bringing JavaScript to mbed OS

People may come to IoT development from a variety of software backgrounds, many of them based on high-level languages, and the transition to using a C++ SDK like mbed OS may prove a challenge. Of course, there will be others who may just enjoy the expressiveness and quick design iterations that you get with languages like JavaScript. For these reasons, we're interested in providing access to mbed OS development in high-level languages.

JavaScript for embedded development

Today we'll be looking at bringing support for JavaScript to mbed OS. Imagine the difference in writing a simple program where a button toggles an LED, when you can easily create the function at the point where you pass it as a callback argument:

var led = DigitalOut(LED1);
var button = InterruptIn(SW2);
button.fall(function() { led.write(led.read() ? 0 : 1); });

The equivalent code in the C++ SDK:

DigitalOut led(LED1);
InterruptIn button(SW2);
void toggle_led()
{
    led = !led;
}
int main()
{
    button.fall(&toggle_led);
}

The above example may not exactly inspire you to want to run out and embrace JavaScript just yet, but consider also that this implementation is designed so that interrupt-triggered callbacks are actually executed outside of the interrupt context. This means that you don't have to worry about what you can or cannot do in your callback. You're free to do things like print to the console:

var led = DigitalOut(LED1);
var button = InterruptIn(SW2);
button.fall(function()
{
  led.write(led.read() ? 0 : 1);
  print("Normally you're not allowed to print to the console in an Interrupt Service Routine!");
  print("(but this isn't being executed in an ISR...)");
});

The equivalent code in C++ would require you to use a Mailbox or Queue to mark whenever the button is pressed, and then the main() function will need to wait for messages to appear in the Mailbox, and perform the printing there, in an infinite loop. The JavaScript code might look more appealing now.

Using JerryScript on mbed OS

In order to support JavaScript on mbed OS, we have been working on integrating the JerryScript VM into mbed OS 5. JerryScript is an ECMAScript 5.1 compatible implementation of JavaScript. It's designed to fit within 200KB of ROM, and needs at least 64KB of RAM; it can easily fit into many mbed Enabled boards - including the NXP FRDM-K64F, Nordic Semiconductors NRF52-DK, or ST Nucleo-F401RE. Our initial porting effort has been made available in JerryScript, but it is not an officially supported mbed OS 5 project.

The integration of JavaScript with mbed OS is available as a new target in the JerryScript project, under the 'mbedos5' name. Integration in this case means that the JavaScript engine runs within an mbed RTOS thread, and you have access to the familiar mbed classes within your JavaScript code like DigitalOut, I2C, InterruptIn, etc.

Integration details

The majority of our port of JerryScript to mbed OS 5 - including the HAL, build scripts and core libraries - have been submitted as a pull request to the official JerryScript repository. All changes can be found under the 'target/mbedos5' directory. You can check out our fork of JerryScript support on mbed OS here. Other libraries, like js-mbed-easy-connect and js-mbed-simple-cloud-client that provide networking and integration with mbed Device Connector, are hosted as separate projects outside the JerryScript repository.

The targets/mbedos5 directory in ARMmbed’s JerryScript forked repository is set up to resemble any other mbed OS 5 project. The integration between JerryScript and mbed OS lives in jerryscript-mbed, while the C++ code that simply launches the JerryScript engine is in source, and your JavaScript code itself can be found in the js directory.

jerryscript-mbed directory

This project is the heart of the integration between JerryScript and mbed OS. It's important to know that any C/C++ API that you wish to access from JavaScript code needs to first have wrapper code written for the relevant functions and classes. Developers of any C++ libraries are welcome to provide a JS-wrapper library that presents a nice JS interface to their library.

The most important parts of this project are:

  1. The entrypoint for starting a JerryScript engine in your project (for example, the jsmbed_js_launch() function).
  2. The API that wrappers should use to provide JavaScript access to the code they are wrapping.
  3. The wrappers for the mbed HAL API (giving you access to classes like DigitalOut and InterruptIn).

source directory

This folder is an example of how to integrate the JerryScript engine into your mbed OS project. In this case it simply indicates that the mbed-drivers base wrappers should be loaded, by calling JERRY_USE_MBED_LIBRARY(base). Then it launches the JerryScript engine by calling jsmbed_js_launch(). You can extend this if you wish to implement any extra functionality outside of JavaScript, as it is a completely normal mbed OS 5 project.

js directory

Finally we have the js directory, where your JavaScript code lives.

The files in the js directory must be processed into a C++ source array of bytes in order to be loaded by JerryScript when it initialises. You can do this manually by running the provided tools/js2c.py script. This script will process the JavaScript code in such a way that the JerryScript engine will execute main.js first, and then all other scripts. Note however that the normal method of building your JavaScript project as described below will automatically run the tools/js2c.py script for you.

The js directory will also contain a pins.js file once tools/js2c.py has been run. This will contain the definitions of all pins available on your board.

After building and flashing your program onto the board, you can reset the board to run your JavaScript application. At this point, the engine will:

  1. Run all of the code found in main.js.
  2. Run all of the code found in all other files in _alphabetical order_ (case-insensitive).
  3. The engine will loop, waiting to receive callbacks. This means that if you want to periodically execute a function, you can achieve this easily with the use of setInterval():

setInterval(function() {
    print("This is called every 3.5 seconds!");
}, 3500);

NOTE: pins.js will be not be executed like other JS files. Any variables defined in this file are available for use in all other files, but are loaded in a special way by JerryScript, ensuring that you have more memory available for writing your application. This file should only contain lines like var VARIABLE = VALUE;. Any other code will not be executed!

How to quickly run some JavaScript on your device

  1. Clone or download the JerryScript project.
  2. From your terminal, navigate to targets/mbedos5.
  3. Run make getlibs to pull in the mbed OS dependencies. - On Windows you will need GNU Make or Cygwin installed.
  4. Make any changes you wish to the JavaScript found in the js directory. - main.js should always exist, and is always executed first. - All files (apart from main.js and pins.js) are executed in alphabetical order.
  5. Compile your project using make BOARD=boardname. For FRDM-K64F, use K64F. For the NRF52 development kit, use NRF52_DK. - To find out the name of your board, connect your development board to your computer and run mbed detect.
  6. The compiled firmware is located at .build/[BOARDNAME]/GCC_ARM and is either named mbedos5.bin or mbedos5.hex. Drag the firmware file onto your development board - which mounts as a USB mass storage device.

Conclusion

We have produced a prototype that provides access to mbed APIs within JavaScript code. So far we have the JerryScript VM running within the mbed RTOS, with access to some mbed HAL API classes available from JavaScript.

By closely following the classes and functions provided by the mbed C++ API in JavaScript, first-time IoT app developers (who may be coming from a web background) can get started with JavaScript mbed OS development, and then may feel more comfortable transitioning to the C++ SDK later.

In the coming week we will publish a number of new blog posts and libraries related to JavaScript on mbed OS 5. First, we will publish instructions on porting existing C++ mbed libraries to JerryScript. Second, we will publish a JavaScript library for mbed Client - allowing you to write connected IoT applications using mbed Device Connector. And third, we will publish a JavaScript library for BLE - allowing you to access the mbed Bluetooth stack from JS. Keep a close watch to this blog for updates.

We'd really like to take this work further, so if you're a developer who is itching to write your IoT projects in JavaScript, we're keen to hear from you!

-

This blog post was written by Stephen Kyle, Software Engineer at ARM, and one of the driving forces behind JerryScript on mbed OS.

Win an Oculus Rift! Hexiwear Design Contest

ARM mbed has joined up with the ‘Hexiwear: The Do-Anything Device!’ contest on Hackster.io. The Hexiwear platform is a wearables Internet of Things (IoT) development platform that is energy efficient, packed with loads of sensors and is designed to reduce time to market for wearables devices. The platform was created collaboratively by NXP and MikroElektronica and is now mbed Enabled™ for mbed OS 5.

Win an Oculus Rift!

/media/uploads/katiedmo/oculusrift.png

ARM mbed will be giving away an Oculus Rift (valued at $600 USD) to one lucky applicant for the ‘Best design using mbed’ in their development. The contest has already begun so be sure to get your entry in before 30th September 2016!

Free Getting Started Webinar

To help you get started we will also be hosting a webinar on ‘Getting stared with your Hexiwear application development using mbed OS 5’ on Thursday August 25th at 11am CDT (4pm GMT). Sign up for the webinar here!

Webinar Topics:

  • Introduction to mbed OS 5
  • mbed OS development environments and tools
  • Creating applications with mbed OS
  • Using drivers, libraries, stacks available from mbed & the mbed ecosystem
  • Building, testing, debugging
  • Code management and publishing your applications
  • Q&A

Visit the Hackester.io contest page for more information on application requirements.

Introducing mbed OS 5

I'm very pleased to share the newest update to mbed; the introduction of mbed OS 5 and our 5.1 release!

This release marks significant changes and enhancements that have accelerated features of our roadmap, opened up the applicability of mbed OS to many more Internet of Things (IoT) use cases, and unlocked compatibility with our mbed OS 2 (“Classic”) ecosystem.

Here are some of the headline features...

/media/uploads/simon/osrelease.png

RTOS

mbed OS now incorporates an RTOS in the core of the operating system. This much-requested feature provides native thread support to the OS and applications, simplifying development and integration of complex and robust application components like networking stacks. It also enables both blocking and non-blocking design patterns. The RTOS requires very limited system overhead.

We've worked to integrate the RTOS with our peripheral drivers, 6LoWPAN and networking stacks, BLE support and uVisor in such a way that most changes are hidden. The RTOS is even initialised ahead of entering the `main()` thread, making it transparent and easy to write composable components even if the application itself is single-threaded. We're also extending the eventing model by re-introducing it as a library such that it can be used within threads of the RTOS.

/media/uploads/simon/mbedcli.png

Tooling

To simplify the tooling, we are introducing a new Command Line Interface (mbed CLI) that works on Windows, Mac OS X and Linux to build the OS and associated developer applications and components.

We've also, added native support for building across the ARM Compiler 5, ARM GCC Embedded and IAR compiler toolchains. We now test all code against these three compilers.

Finally, we've upgraded the mbed Online Compiler to support mbed OS, giving instant access to working development environment in the cloud.

2 + 3 = 5

The introduction of the RTOS and changes in tooling have also allowed us to bring together the original mbed OS 2 (“Classic”) and mbed OS 3 (“Eventing OS”) codelines, re-basing and merging the two development lines so that we now have just one platform.

/media/uploads/dirons/codeline-merge.png

As a developer, this means you can take advantage of all the existing and new technology features that have been worked on in mbed OS up till now, the RTOS functionality and the vast component library that has been developed and contributed over the years and that continues to grow. This is also great for the future, as we can all invest in one codebase, website and ecosystem as we develop mbed OS further.

/media/uploads/simon/boards.png

Board support

A goal for this release was to achieve much wider platform support for mbed OS, and set a target of 15 boards by the time we were ready to share - but thanks to the incredible efforts of our partners, we've more than doubled that to greater than 35 supported boards in this release!

More target support will be picked up in bi-weekly releases as mbed Enabled™ criteria is met, as will refinement and fixes to existing platform support.

And there’s more

While the RTOS, codeline merge and expanded target/toolchain support are definitely headline features, we’ve also been busy on many other improvements.

It is worth a read of the full release note for even more details on what has made it in to this release:

Finally

Enabling all this has taken a lot of innovation, pragmatism, and ultimately plain hard work from all of the mbed team and our mbed partners, and we're really proud of what we've managed to achieve. We hope you like the results!

We'll be sharing more details, explanations and tutorials over the next weeks, and no doubt ironing out problems and issues that are identified. If you have any questions or spot issues, feel free to get in touch.

What next