Skip to content

Latest commit

 

History

History
103 lines (72 loc) · 4.06 KB

HowtoBareMetal.md

File metadata and controls

103 lines (72 loc) · 4.06 KB

How to run on bare metal platforms

A bare metal platform usually runs a minimal real-time operating system (RTOS) or no conventional operating system at all. Usual services like paging, memory allocation primitives, a file system, etc may not be available at all. There may not even be an interrupt handler, with all code running in a busy polled bit banging loop. There is usually no libc or only parts (often noncompliant) of one.

Duktape has been designed to run on bare metal targets: platform dependencies have been carefully minimized, and all access to platform functions goes through wrapper macros defined in duk_config.h. As such they can be easily replaced with custom providers.

This document discusses the usual issues in compiling and running Duktape on a bare metal target. See also:

Footprint expectations

Duktape configuration options affect the final footprint a great deal. The following configuration compiles to around 160kB on an ARM platform, and can run (very minimally) with 32kB RAM.

It's possible to reduce footprint much below 160kB by dropping ECMAScript built-in bindings:

  • For example, a "stripped" build in Duktape master allows a command line eval tool to compile to less than 80kB on x86 (not including libc etc). However, in a stripped build built-ins like Array.prototype.forEach() are missing. You can customize the bindings more accurately, e.g. remove only specific bindings, using the YAML metadata.

Typical porting steps

Configuration and duk_config.h

Compiling and running

This is obviously compiler specific, but it's important to use options that minimize footprint, remove any unused functions in final linking, etc. See for example:

Enabling "execute in place" is often necessary to allow code to run directly from flash.