The End...For Now

After the split of the OpenMRS group, Austin, Zach and I decided to work on the Transterpreter for the rest of the term. The Transterpreter is an open-source and highly portable virtual machine designed to exploit concurrency on embedded systems, for running process-oriented programs written in the occam-pi programming language.



Existing interfaces for working with the Transterpreter were not cross-platform, well maintained, or user friendly. The lack of an active community has left the project fairly stagnant. There is a need to create a new method by which users may ship to the server, receive the compiled code, and flash it to an Arduino. There is also a desire to renew the Transterpreter project, by revitalizing certain aspects of it in a way that makes it easier to work with and maintain.

The desired platform for implementation was in the form of an Atom package, as Atom is very well documented and maintained and widely compatible.

The basic workflow as per the design is as such:

• Toggle on Transterpreter plugin
• Specify arduino type
• Select desired project
• Package occam-pi files within directory (JSON)
• Ship to server
• 
  
• Receive compiled occam-pi from server
• Flash to arduino via AVRDUDE

Our lack of familiarity with the tools and environment that we were to be working in prevented us from generating a more detailed design plan, and our ideas of how we would implement certain aspects changed on multiple occasions throughout the work on the project.

Supported board types are retrieved from the server whenever the Transterpreter-plugin is made active via toggling on and clicking the Transterpreter logo.
We started with a package template generated by the Atom package creator. Tools used include: CoffeeScript, JQuery, Node.JS, AVRDUDE.

We used these tools to generate a JSON structure that allows for packaging of all code within the current open directory, specifying which file is the “main” file.
One of the major challenges we had during the implementation of the plugin was handling the way scoping works in CoffeeScript. This issue presented itself while we were trying to execute deactivation of the event listeners, in order to prevent repeated uses from repeating payload generations.

There are still some steps left to be completed in order for the plugin to become a fully-functioning solution.

Code to specify and retrieve contents of the "main" file for packaging to send to server
Changes made on the server side to reflect differences in the generated JSON structure between Plumb and the Atom Plugin.
Function to retrieve the returned code compiled by server
AVRDUDE program execution within plugin to flash compiled code to the arduino.

All in all I think that this was a great learning experience. The project was fun and interesting, and Austin, Zach, and Dr. Matt Jadud have been phenomenal to work with.