These research questions aim to limit the scope of the study enough to keep it from becoming too wide. They define that more capable hardware systems, such as Raspberry Pi and similar system-on-a-chip, are not included in the scope. They have too much resources to be considered to be low on resources. Such systems are also capable of running more or less full-fledged operating systems which in this case would defeat the entire purpose of this thesis.
It is also defined that the approach should run native code and thereby we are exclud-ing techniques such as virtual machines and interpreters. This is an area that is more researched and outside of the scope of this study.
2 Related Work
Microcontrollers were created to be part of very static, embedded systems and it seems like not a lot of research on breaking this pattern exists. Most of the articles show that the most popular solution to implement is a custom Java Virtual Machine. Java was launched as a ”write once, run everywhere” solution [11] so the choice, to implement it on microcontrollers, makes sense. It is a wide-spread language that is easy to pick up thanks to its many similarities to C and its derivatives. A problem is that the JVM (Java Virtual Machine) is taking up a lot of memory. It requires hundreds of megabytes of RAM, on desktop computers, and the standard library is also a huge pile of code. There exist subsets of Java that are smaller but do not implement the entire language. This makes for an interesting problem when it comes to microcontrollers since high enough hardware specifications, to enable the use of full Java, are hard to find.
When it comes to other alternatives some scripting engines and native solutions were also found. Research articles for these solutions were sparser than the ones about Java implementations but they show that there is some interest in other solutions than Java as well.
2.1 Java
As mentioned earlier, Java (in its conventional, full form) is not suited to be running on microcontrollers. Due to the way virtual machines and interpreted languages work, there is a requirement for a lot of memory. They have a lot of code running, just to execute applications, which consumes a lot of memory. Microcontrollers do not, typically, provide this much memory. However, there have been several attempts at realizing Java for microcontrollers.
2.1 Java
2.1.1 Software
In the results, of our database searches, papers on various Java Virtual Machines and other ways of implementing Java could be found.
2.1.1.1 Tiny Virtual Machines
The idea of having a JVM running on a microcontroller is a very nice one. Being able to write the software once and then be able to run it on any hardware would save any developer a lot of headaches. The problem when trying to implement it on microcontrollers is the hardware limitations, whatever solution chosen there is always going to be limitations imposed upon it which we will discover soon.
Darjeeling, for example, is an open source virtual machine made specifically for hardware lacking the huge amounts of memory Java needs [12]. It is based on a 16-bit architecture, instead of the standard 32-bit that Oracles JVM uses. Darjeeling targets 8 and 16-bit microcontrollers with less than 10kB of RAM and therefore the 16-bit approach is more sensible. It is the reason for the low hardware requirements, using a 16-bit instead of 32-bit architecture saves a lot of memory overhead. Enabling the 16-bit instruction set requires that the Java bytecode is being translated to custom instructions since the original Java code is in 32-bits. However, all this is handled by Darjeeling before execution. Even though it has low hardware requirements the virtual machine is able to implement a substantial subset of Java but it lacks certain features like reflection, synchronised, static methods and 64-bit data types. Object orientation is supported though.
Continuing in the same spirit, simpleRTJ is also a tiny VM running a subset of the Java language [13]. It is implemented in less than 20kB of code memory, enabling usage on very resource-limited microcontrollers. It does, however, require 18-23kB of RAM. This is something not all microcontrollers can boast about, making simpleRTJ a little less universally compatible with low-end microcontrollers’ specifications. Supporting excep-tions and events, it is an interesting option for developers looking to run Java on their microcontrollers.
Another study focuses on running Java on tiny sensors [14]. The project aims to abstract the underlying hardware to enable portable applications for sensors. The runtime acts as an operating system, being responsible for scheduling, loading Java classes, memory management and allowing interaction between Java applications and the hardware. Limits imposed on the system comes from the small code space available. Applications cannot be larger than 1022 Bytes, a requirement possibly hard to meet. Further limitations are no
2. Related Work
multi-threading, exceptions and only integers, bytes and chars can be manipulated. There is support for object-oriented programming with classes though.
2.1.2 Hardware
While building and installing a custom virtual machine on a microcontroller might seem like the most obvious solution, to implement Java, there has actually been (successful) attempts at making Java supported on hardware level [15]. Much like Apple has its ecosystem (where both hardware and software are under strict control) designing a system with both the hardware in mind, just as much as the software, is an approach that could potentially lead to greater success than just focusing on implementing the software.
The Komodo project [15, 16] aims to do just this. Its goal is to create a Java microcontrol-ler, with a JavaVM, that is able to run Java whilst being able to provide timing security identical to conventional C/C++ applications. Being able to ensure the timing, of the processor in the microcontroller, is crucial for real-time applications where the cycles of a processing unit must be countably handled in a predictable fashion [15]. Otherwise dead-lines in the applications can be missed which is unacceptable if it is a real-time application.
Java is not an obvious choice in these contexts since it has several features running in the background (e.g. garbage collection) that cannot be controlled by the developer. If it is not a predictable behaviour than it is impossible for the developers to calculate, develop and test real-time applications.
2.1.2.1 Running Code
The microcontroller, used for the Komodo project, is a multithreaded Java microcontrol-ler. This means a microcontroller running several threads and actually able to execute some Java bytecode natively in the processor. This means that already the Komodo micro-controller has an advantage over pure software solutions since Java code can be executed just as fast as native machine code [15]. A custom virtual machine is running inside the microcontroller. Its responsibilities include loading the Java classes and interpreting the bytecode. It might seem like an unnecessary step to interpret code that can be run natively but there is a clever reason. Conventional Java VMs interpret bytecode and compile it to machine code native to the underlying architecture. What the VM in Komodo can do (running a Java microcontroller) is skipping the compile step and just pass the bytecode instruction to the hardware which can have impressive performance benefits [15].
On the problem of real-time applications, the researchers behind Komodo have taken advantage of the fact that they are running a multithreaded microcontroller. By letting