In a previous post, I considered how to make the set-up of a RaspberryPi–Arduino EPICS system more user-friendly. Well, after a long, Java-based, digression that ended in a several-thousand lines-of-code deadend, I have ended up with a working solution.
Without going into the details of the various paths I explored, I ultimately decided to go for an entirely web-based solution. This has the drawback that I could no longer leverage the power of having direct access to the user’s computer in order to compile code natively, or to create files wherever I wanted (modulo the usual permissions issues), but it had some considerable benefits that out-weighed this.
Firstly, I was well aware that the first few (many) releases of the code would contain a lot of bugs, some of which could immediately cause a user to lose trust in the system. A web-based system would allow me to propagate bug-fixes to all users immediately, without having to engineer an update-tool.
In addition, moving towards a well-supported web platform such as Google’s App Engine meant that I would be able to rely on a lot of heavy machinery without having to code it myself. As well as including a lot of tools in the software libraries provided by Google, I could also make use of their servers, thereby allowing me to forget about having to keep a server running myself.
Another way to state the previous two points is that I no longer had to figure out how to deploy my application. Beyond uploading it to Google’s servers (a one-line command), all the heavy-lifting was done for me.
Lastly, a considerable incentive for me to move to a browser-based solution was that it was an opportunity for me to learn — both to learn how to develop an online application, but also the chance to learn Google’s Go language. The software industry advances quickly, and it would be very easy to get left behind. Although my choice of development language from the set offered by Google’s App Engine tools is not of fundamental importance to my users, I think that learning opportunities are not to be ignored lightly.
In order to allow multiple users at one time, I decided to insist that people sign in using their Google accounts. This will be a limitation for some people who do not have or want a login, however I considered this to be an acceptable trade-off in terms of the reduced development time (the ability to make use of the existing software libraries and infrastructure).
When the user logs in, they are presented with a page containing an HTML form that they can fill in to populate the various signal fields (signal name, serial string, data type, etc.). Submitting the form with the “Create” button then persists this information to the Google datastore, and edits the protocol and db files underneath the form. The idea being that the user will create all their signals, and can then copy’n’paste the code into the relevant EPICS IOC files.
In addition, signal creation also results in the generation of a skeleton Arduino file that can be used as a starting point for the microcontroller code.
To make use of the proto and db files provided by this tool, you need to have a working EPICS environment along with an empty IOC ready for compilation on your Raspberry Pi. Getting to that stage is relative easy (following the instructions I gave in previous posts), but a little boring & repetitive, with lots of room for typos.
To help with that, I provided a couple of download links.
The first provides a shell script that downloads and installs EPICS, ASYN Driver, and StreamDevice. This needs to be run by root (to allow the soft-links to be made in /usr/local), but requires no user intervention. It takes a little bit of time to run due to the time it takes to compile EPICS, but go get a beer and it’ll be finished before you are.
The second is a tarred & zipped IOC. All the user needs to do is to add the arduino.proto and arduino.db files to the appropriate place, and then “make” and run the IOC.
Although extra functionality can be added to this tool, it addresses almost all the steps needed to get an Arduino/Raspberry-Pi system up and running, and certainly reduces most of the friction involved in doing so.
Watch this space for future developments…