Category: Node.js

jetson nano developers kit version b01

whbeebe1 Comment

My second Jetson Nano Developer’s Kit arrived Monday. Following Nvidia’s directions I had their version of Ubuntu up and running in about thirty minutes. I’ve mounted the Noctua NF-A4x20 5V PWM fan on top with nylon ties, exactly like the first. One reason for buying the B01 is it now comes with two MIPI CSI camera connectors on the edge, CAM0 (right) and CAM1 (left). All versions before this had only one, CAM0. The power selection block is now further inboard, and wonder of wonders, it comes with a shorting block. In the photo the shorting block is in place to select the barrel connector and I have a 5VDC 4A power supply connected via the barrel connector.

A minor editorial comment: I’ve now installed and worked with two Jetson Nano boards, the A02 and B01. In both instances I never once encountered any issues configuring, installing the OS and software tools, or attaching devices. This is counter to the insanely stupid complaints I read on Amazon where a number of knuckleheads gave the board 1 star and bitched about how terrible the Jetson Nano was. The boards are great and work just fine. But you can’t be an idiot around them, or you will break them.

Rather than give screen shots running software you already know about, this is a screen shot where I downloaded and built Visual Studio Code. VSCode for ARM isn’t provided from the same source as all other operating systems. There is a third-party DEB file, built from a year-or-two-older version of VSCode, but no thanks. Instead, I followed the directions here ( “Building Visual Studio Code on Jetson Nano”, https://www.clarenceho.net/2019/05/building-visual-studio-code-on-jetson.html ). I made one major modification to Clarence’s directions, and that was to install NodeJS version 12 instead of 10 using setup_12.x. That’s because the current LTS is version 12. Nevertheless it built, and I was gob-smacked when it came up with the introductory screen the first time I ran it. I was then able to open Bash, C/C++, and Python source files.

The only issue right now is I can’t install any extensions. The extension list is empty. There is a fix I have not tried yet, but which I will the next time I build VSCode. I’m building on my Crucial MX500 .5TiB SSD, so I have plenty of space to just re-clone and re-build with that fix on Clarence’s web page. I wanted to see if it would at least build without errors before I made any modifications to the product.json file. Since it obviously does work, the next step is to try and get the extensions working.

I am so happy to have this building and working on any ARM-based system.

In case you’re curious we’re running with standard Ubuntu 18.04.4.

This is the fully built Visual Studio Code version, from trunk. Note that it’s version greater than the current official installable release, which is 1.44.2.

raspberry pi and java 8

whbeebe

What you’re looking at is the SwingSet2 demo, something rather old now, running via the latest Java release, Java 8 on my Raspberry Pi, on the twm desktop and on top of the latest Arch Linux for ARM. What a mouthful…

It’s been almost a month now since my last Raspberry Pi post; I was on a business trip in Kansas for three weeks. During that period of time Oracle released Java 8 on 18 March. One of the Java implementations was for ARM V6, compiled for hard float (chip-supported floating point math). As a test I also dropped the demo package on my RPi and fired up one of the demos. To be honest it was slow starting, but not horribly slow. It was slow like my computers from a good decade ago, the ones running early Pentium chips (back when Intel still called their chips Pentiums). I don’t intend to run graphical Java applications as much as service type applications.

I’m looking at Java 8 to run JavaScript via Java 8’s built-in JavaScript engine, Nashorn. The key reason is not to abandon node.js, but to shift the JavaScript portion (if possible) to run on Nashorn as apposed to Google’s V8. There are a number of reasons for doing this, one of which is security; I believe Java 8 has far more than V8. Before you bust a gasket telling me about Java’s security sins, know that the vector for Java security breaches was with older versions of Java using applets. That’s not what we’re about here. A second key reason is that I can call down into the Java libraries via JavaScript. And I can investigate manipulating the RPi’s various I/O devices via Java 8.

I don’t know when I’ll release a new image. Compressed, my 8GB images are now at 1GB, which makes it a chore to upload them, and I’m sure a chore for you to download. Although I’ve seen downloads from Sourceforge, they’ve pretty much dried up. I may make an image with Java 8 available on April 1, like I had originally intended. It’ll have Arch Linux fully up to date as well as Java 8.

For now tax season looms and other work is making my life very busy. I’ve got another two week business trip coming up, and more business travel after that. It’s a long busy stretch ahead.

Update


I installed Apache ant and built one of the sample applications, Scriptpad. In this simple example JavaScript is calling Java’s JFrame class and instantiating a running instance with a simple title. It took all of five lines of JavaScript to invoke a Java class instance. Not too shabby. This is, of course, just a trivial proof of concept. But it does illustrate the power of the JVM.