How to Use RXTX Library for Java & Arduino Communication

I have been thinking about doing this project for a while, and since I've been riding a tech/craft wave lately, I thought there was no better time. *Note to reader, this tutorial is crafted to a Mac OS X environment and its quirks, if you need a tutorial for another environment start here: Arduino Java Interfacing Tutorial

What: Programming an arduino and java application to perform serial communication.

Why: Why not?! Think about it. Once you have that neat arduino project, you add in 'duino-PC communication and now you're really taking it to the next level! Back during my computer science undergrad, I built an anemometer for an IEEE event when I was first getting started with arduinos and learning about EE stuff. When it was hooked up to the arduino IDE, I could read its output values, but that's it. Now, if I was to hook it back up, add in some serial communication, I could start logging that data! If logging data doesn't do it for you, there are tons of other things you can do with this. Let's get started.

Things you will need:

-Arduino : I am using an Arduino Uno v3

-Computing Environment : I am using a Macbook Air running OS X El Capitan (10.11.3) with Java 1.8, and coding my application using Eclipse.

-RXTX Libraries : Can be downloaded at: RXTX Libraries (Warning - If you need the 64 bit libraries, you will have to source them elsewhere. If you need the more rare mac os x 64 bit JNI library, you can get it here: RXTX 64 bit Library)

Getting Started: The first thing you want to do is download the correct RXTX libraries and install them. You can add them as extensions to the java runtime environment you have installed or load them into your project directly. What's the difference? Well the guys who built the binaries for RXTX say that adding them directly to your runtime environment can be dangerous if you are writing cross platform functionality. If you are not concerned, copy the libraries (.jar and .jnilib) to the path "/Library/Java/Extensions". You will likely need to provide your password in order to modify this directory. If you are concerned, copy the libraries into your project using an IDE like Eclipse, add them to your classpath in your makefile, etc.

Once that is done, copy the code example from the tutorial in the following link: Arduino Java Interfacing Tutorial. It is important that you understand each step of the code and what each piece accomplishes. This will allow you to improve upon the example code in whatever ways your project demands. I will be posting a heavily-commented version of this tutorial to my github at the following link: Basic Tutorial

Status check. You have the libraries installed, you have the source code, arduino is ready to go. Plug that arduino in and run your program. I bet you probably got an exception didn't you? Follow the error resolution steps and see if it can't get you unstuck.

Error: "java.lang.UnsatisfiedLinkError"

Solution: You are on a newer Mac and have a 64 bit architecture running with a 32 bit library. Download the 64 bit JNI library I linked to above.

Error: "gnu.io.PortInUseException"

Solution: Create a directory named 'lock' in the path '/var' with permissions 777. If you are not sure how to do this, open a utility application on your mac called Terminal. Next, type the following command and then hit enter: 'sudo mkdir /var/lock'. It will likely prompt you for your password. Next, enter the additional command and hit enter: 'sudo chmod 777 /var/lock'.

Good job! If you made it this far, you should be past all the frustrating parts, and your arduino is happily chirping "Hello World" over and over into your console! What's next? Experiment and add functionality for sending data TO the arduino. Good luck!

Playing with Computers at Work (I/O vs Compute)

I used computer science at work and it was fun.

A coworker and I were talking just the other day about a situation where our code would need to enumerate every open file for a given process. We had a binary tree structure in memory that maintained the list for our process as well as the option of retrieving the information via '/proc'. Since we needed to touch every element in our tree in memory, that's easily identifiable as O(n), but what was unclear for our now group of four deliberators was whether the enumerating of the /proc/[pid]/fd file would be just as fast, faster, or slower. Ultimately, a couple of them settled on the fact that it would be the same speed since you still needed to enumerate every file descriptor, and it would be just as fast to make the system call to retrieve the proc info. I disagreed. My argument was that compute is always going to be faster than I/O, and even though it's a system call to a pseudo-filesystem, it makes sense to crawl the tree instead of getting it from proc. To prove my suspicion, I created the following experiment:

1. Run a program that opens and holds 2**x file descriptors.
2. Run a script to build a tree of 2**x levels in memory.
3. Using the same script, walk the tree using a depth first search. (Time this function)
4. Using the same script, attempt to read the list of FDs from /proc/[pid]/fd. (Time this function)
5. Compare the result of the function timers.

Results: At 10 levels, the tree enumeration took 0 milliseconds, while the I/O required about 55 milliseconds to complete. When I increased the size of the tree to 16 levels, the time required to walk the structure increased to around 25 milliseconds. Compute was faster.

Notes:
1. This is not bleeding edge accurate. The python package 'psutil' is essentially a piece of middleware that could influence the time it takes to return the list of file descriptors, but I think still accurately simulates what enumerating the proc file would require.
2. The accuracy of the time.time() value used for the experiment is two decimal places on my test machine.

You can find the experiment files HERE.