Raspberry Pi 2 and Fletch


So I received my Raspberry Pi (2) on Friday evening. I spent the evenings this weekend playing with it. The Raspberry Pi’s are nothing new, and I’m admittedly late to the game here. While I’ve been interested, I didn’t have the money or time to invest into one before. There just wasn’t a factor to say “Hey look at me!” for it. However with my new position with DG Logik, working with IoT, it becomes more interesting subject for me to look into. And recently, the Dart team at Google started a side project called Fletch, which is designed not just to run on this, but eventually on a plethora of embedded, IoT devices. I missed my chance to be part of the first users of the Raspberry Pi and making “oh cool look!” projects. And honestly, it probably wouldn’t have been the right time for me to do so, as my limited knowledge with electronics would have kept me to more the OS level anyways.

But now with Fletch, I get to be one of the first users of Dart in this capacity on the Raspberry Pi. It is true, you can compile the Dart VM, SDK to ARM7 and run the full VM on the OS anyways. And I will do so too no doubt. But Fletch starts with the idea of getting right to the hardware level. It currently comes with packages all set for accessing the GPIO pins on the board, plus some gentle changes to how the VM runs.

The biggest change they made changes the VM to be two different parts. The first is a compiler. Dart compiles to bytecode. This bytecode is then sent over the wire to a smaller VM running on your Pi which executes it and returns any output back over the wire. Additionally, they made the decision to allow Dart to be blocking, but at the same time does not hog the CPU. If the VM is blocking on some operation, it can actually hand control back to the CPU until its done. This will be much more important when it comes to running on smaller devices in the future and makes for simpler programming for those devices, more akin to how they may be written now in Python (for the Pi) or C.

But please don’t take my word for it, as I’m sure I’ll mess up some of the finer details. Please check out the Fletch Homepage¬†and get the details directly (who am I fooling, if you’re reading my blog, you’ve already checked out the page long before now).

The Fletch page has some nice samples to check out as well. I recommend doing the first couple verbatim, especially if you’ve not used electronics a lot yourself in the past. However after that I recommend that you actually start writing your own source copying the existing source and making alterations where you need to, this will generally be things like specifying different GPIO pins to work easier with what you have hardwired. I actually ran into issues with the second project due to a hardware issue which is known to happen. Basically there was feedback too close to the GPIO pin I was using, and it caused the pin to be in a state called “floating”. Where the input thought there was input based on background nose, and not actual value flowing into the pin (in fact it was totally disconnected from any wiring at all and still showed the same).

There are ways to resolve a floating value with both hardware, and internally. It’s called a pull up resistor, or a pull down resistor. One configuration will set the default value to ‘on’ and the other will set it to ‘off’. Because they’re so frequently used, particularly when using switches/buttons, each GPIO on the Raspberry Pi has it built in. In the Python libraries that comes with the Pi, it’s possible to set this value when setting up the GPIO pin for use. However, currently this same functionality is missing from the Fletch packages. I’ve filed a bug. Fortunately I was able to overcome that issue by using a different GPIO pin in the end, as well as using a GPIO Extension Board. (Not all extension boards are created equally. I have two, one from Sunfounder and one from Vilros, and the Vilros one I have is a much nicer extension board in layout.

That’s, however, not the only issue I’ve run into with Fletch at this point. The other main one, would be documentation. The API is fairly similar to Dart in most cases. However, particularly with the built in packages, there is no API documentation. The few times I’ve wanted to look up a method/function, it involved manually digging through the repository and trying to find the right package a method came from and hope there are doc comments there. For instance, what does SysfsGPIO.waitFor actually take for arguments (what’s the true and -1 from the samples?). Oh.

There’s a lot more I’d like to broach on the Raspberry Pi, and my experiences. But it’s getting late and I have a busy day tomorrow. More on it soon. It’s fun!

This entry was posted in Dart and tagged , . Bookmark the permalink.

Have Something To Add?

Loading Facebook Comments ...
Loading Disqus Comments ...