Remote Toolchain

Approaches

2 options are available if you do not want to gun the Emulator locally.

VM-based approach

Use the same image as the recommended one for the local setup (LINK) and import it into VirtualBox. Before booting the machine, you have to do a small change in the Host Network Section VirtualBox of the Settings. You should find it here:

• Windows: TODO
• Ubuntu: TODO
• MacOS: Menu Bar -> File -> Host Network Manager -> vboxnet -> DHCP Server

Make sure to disable the DHCP Server for the Network vboxnet1 to enable static IP configuration inside the virtual machine. From now on, you just have to keep an instance of the VM running. No interaction with the OS should be required except sending inputs to the running Emulator and observing the results.

You may want to use the Desktop Shortcut called ZOOM as explained with the VirtualBox Image to have a scaled look at the Emulator Window. After you‘re done, shut down the system either with the VirtualBox controls or using the menu in the rightmost corner of the taskbar.

Container-based approach

To setup the toolchain on your OS, please follow the following instructions: TODO

Makefile Targets

The two Makefiles supplied for both approaches can be found in the !docker! and !remote! directory. If you are using an IDE, you should not have to bother with them very much. Anyway you may have to get back to them to debug problems with the toolchain, kill hanging sessions or changing some constants. TODO

Development Environment

The provided IDE configuration should make your life easier, especially if you are not very experienced with the command line. It you allow browsing your project and even doing version control (Git) visually as well as support compiling, running and debugging the Emulator on the remote machine while being able to develop on your everyday computer. The support is not complete but should be done well enough to work with it easily.

As The Eclipse IDE is not supported, yet, please stick with VSCode for now. (If possible) If you are an VIM-enthusiast, you might want to configure the YCM plugin as explained here to use it as an "Integrated Development Environment", too.

Modifications: Feel free to change the provided workspace settings and install additional extensions, but be aware of the fact, that the contents of the !.vscode! directory is overwritten every time you run CMake. As a workaround you might want to change the templates for the VSCode configuration which can be found in config/vscode/ or if required comment the related configure_file statements out in the files init_local_projects.cmake’ and init_remote_projects.cmake`.

Caveats

While this approaches allow you to development in your normal system (f.e. Windows OS) with few slowdowns when editing files and navigating though the project, The performance when building and running the emulator isn’t that great due to the overheads of the remote development setup.

Especially starting a Debugging session takes some time as a gdbserver has to be launched on the Guest every time before entering the Debug Console is possible.

While the Docker-based setup is way more lightweight that the VirtualBox image, there are additional latencies running most of the make targets, as they first have to ensure that the latest version of the container image is downloaded and booted.

At the moment, it is not possible to have a look at the SYSOUT of the running executable, so you have to rely on the possibility to print out variable contents inside the GDB (Debugger) console or display them using Drawing statements.

Typical Problems:

In the future workarounds and fixes for typically issues with the remote development setup should be listed here.

• IP Configuration
• SMB Share
• SSH Connection
• Screen Resolution
• Debugging
• Compiling
• Running
• CMake
• Hanging Session
• Keyboard Layout
• Files not in Sync
• Many Containers running -> Bad performance: Shut down containers
• Docker not running!
• ...