Will JavaScript type annotations kill TypeScript?
The creators of Svelte and Turbo 8 both dropped TS recently saying that "it's not worth it".
Yes: If JavaScript gets type annotations then there's no reason for TypeScript to exist.
No: TypeScript remains the best language for structuring large enterprise applications.
TBD: The existing user base and its corpensource owner means that TypeScript isn’t likely to reach EOL without a putting up a fight.
I hope they both die. I mean, if you really need strong types in the browser then you could leverage WASM and use a real programming language.
I don’t know and I don’t care.
Tech Life

Off-The-Shelf Hacker: Use the Processing Programming Language to Build an On-Screen Gauge

Aug 30th, 2017 12:00pm by
Featued image for: Off-The-Shelf Hacker: Use the Processing Programming Language to Build an On-Screen Gauge

Last week we looked at using a servo as a gauge. The project had its difficulties: I attributed the crazy operation of the servo to timing issues.

Not being able to leave well enough alone, I looked into using one of my old gauge programs written in the Processing programming language, to replace the servo-based gauge in my steampunk conference badge. The on-screen response is much better, although it would still be fun to have a physical analog-type gauge, sweeping it’s little hand up and down on the front of the badge.

To get an on-screen gauge working, we’ll need to change a few things. What’s cool about many physical computing projects is that if you’re clever with the hardware, lots of behaviors and features are easily altered through software updates.

First, we’ll have to mod the servo code, a bit, for the Arduino Pro Mini. Then, we’ll have to load the Processing language on the Raspberry Pi 3. Finally, there’s also that small matter of the code for the gauge.

I like Processing because it’s easy to use and designed for visual applications. It runs on Linux, on both notebooks and the Raspberry Pi. The development environment and code structure are identical to what we use to program the Arduino Pro Mini, as well. If you can code for an Arduino, you can certainly code in Processing.

Start with the Pro Mini Servo Code

Making the Arduino code from the servo gauge project work with an on-screen gauge was pretty trivial. The changes are highlighted in bold.

The only real changes I made to the Arduino code were to comment out the “out-of-range,” “in” and “val” serial print statements. That information was used to make the output readable for humans. We don’t need to include those things when sending distance values over the serial line to the Raspberry Pi and a Processing program.

I left the code for the servo, in the program, thinking that I might come back and try to tweak it in the future. By simply unplugging the servo from the connector, we don’t waste valuable battery power and it really didn’t hurt anything to leave those lines in the code. I like to use connectors and sockets to add hardware components to my projects. It takes a little extra time to solder things together but makes it much easier to adjust your design.

Here’s a shot of the three-wire servo connector, with a piece of tape over it to prevent shorts.

3 Wire Servo Connector, Insulated With Scotch Tape

After the changes, I compiled and uploaded the code to the Pro Mini, using the usual techniques. I checked the data coming from the serial port by starting the Arduino’s embedded serial console.

Install Processing on the Pi 3

The Processing package has to be installed on the Pi 3 before using the on-screen gauge code. I used wget on the command line to download the 3.3 (ARM) version to the Pi:

Once the file is on the Pi, use tar to unzip it into a directory:

Using Processing is pretty straightforward, with one caveat: You’ll have to set the serial port first so that the data coming in over the serial port matches what the program expects, particularly the bit rate.

Lots of times, I’ve issued the cat command to read data streaming in on the serial line (or USB) only to sit there and wonder why there weren’t any values scrolling down the screen. I chose a bit-rate of 115,200. You can use any speed you like, just as long as you set the serial line (using stty) and both the Arduino and Processing gauge code, all to the same value. If the serial line speed or what’s in the code is off, you’ll get a bunch of funny characters, at best or nothing at all, at worst. Not issuing a stty before starting the Processing program, causes the gauge to simply not show a pointer.

With that done, go into the directory and start the Processing interactive development environment (IDE). It works the same way as the Arduino IDE.

Processing IDE on the Raspberry Pi 3 screen.

Click the File dropdown and then the “New” menu item.

Since I developed the Processing code on my Linux notebook, I had to get the code over to the Pi. The easiest way is to simply scp the code from the notebook to the Pi.

Readers can copy/paste the text, from this story, into a new Processing file, then save it to the sketchbook.

Here’s the Processing code for the Pi on-screen gauge:

There are a couple of things of note in the code.

The wired serial port on a Raspberry Pi before version 3, was designated as /dev/ttyAMA0. Raspberry Pi 3’s have reassigned that name to the Bluetooth interface. Instead, use /dev/ttyS0 for the wired serial port on the Pi and everything will work fine. Of course, if you want to pull data in from a USB connected device, use the regular /dev/ttyUSB0, /dev/ttyUSB1, etc. names.

Another interesting thing about the program is that angle measurements are calculated in radians, not degrees. I had to scale the distance, from 0 to 200 inches, to from 0 to 180 degrees, which is a sweep of the hand from the horizontal left (0 degrees) to horizontal right (180-degrees). The 1.8 value scales the measurement from 0-180 to 0-200.

Lastly, the tick values for the reading on the gauge are placed on the gauge face with the “text” lines, near the bottom of the program. I simply selected X and Y values to make it look right. Sure, there was a little trial and error, to get it right.

Save the program to a file name, like “gauge” and then press the “Run” arrow button in the Processing IDE. After a short wait, the gauge should appear on the LCD screen and sweep through an arc, according to the distance detected by the ultrasonic range finder. Make sure the Arduino is powered up and don’t forget about that stty statement, before starting Processing.

The gauge worked very well and was pretty responsive. Holding my hand about a foot in front of the badge showed about 12 inches, on the gauge. With the badge sitting on my desk, the gauge showed about 70 inches, which was the distance up to the ceiling.

What’s Next

The on-screen gauge worked much better than the servo model. The readings were consistent and fast. And, there essentially were no changes to the hardware. That is the beauty of the physical computing stack.

My prototype gadgets are designed to attract attention through outlandish design, a color video screen, sometimes lights and the strong steampunk vibe. Of course, they also serve as test beds for various real-world physical computing ideas that I use in the Off-The-Shelf Hacker column.

Why use boring old white plastic breadboards, on projects that will only live in a workshop, when we can build things that you can wear, touch and demonstrate to people?

Group Created with Sketch.
TNS owner Insight Partners is an investor in: Shelf.
THE NEW STACK UPDATE A newsletter digest of the week’s most important stories & analyses.