TTGO T-Eight and Espruino

TTGO T-Eight is a small ESP32 board from here. Small OLED, left/right/select input method, microSD slot, and 4 MB PSRAM, LiPo connector, plus of course WiFi/Bluetooth is a good combination of features. The problem as usual is the lack of documentation. The situation is even worse in this particular case:

  1. The official git repo is outdated and describes only the OLED part of the old revision of the board.
  2. There's an old and new revision of the board. Luckily the silkscreen is updated, but if you copy&paste old code, you'll be possibly surprised that it won't work.
  3. There's a TTGO T8 which is similar but different. They could have called it T9, or T8a or T8D.
  4. There's no schematics so finding out what connects to what pin is somewhere between "Trust the docs" and "Detective work"

Anyway, here is what I found:

  1. SDA/SCL is Pin 21/22 as printed on the silk screen (old version: 5 and 4)
  2. microSD would then be at 5/23/18/19 as per silk screen (untested)
  3. Input is Pin 37/38/39 for right/center/left
  4. 4 blue LEDs and one red LED on the back: no idea yet. Blue could be LiPo voltage, and red one simply power

So here a small minimal Espruino program which uses the display and which can read the buttons:

// TTGO T-Eight

I2C1.setup({sda: 21, scl: 22, bitrate: 400000});

function gstart(){
 g.drawString("Hello World!",2,2);
 g.flip(); 
}

// I2C
var g = require("SH1106").connect(I2C1, gstart, {height:64});

// g.clear(); g.drawCircle(50, 32, 30); g.flip();

// Note: pushing will trigger several times (for repeat: true)
// Need to software de-bounce

setWatch(function(e) {
console.log("Right");
}, D37, { repeat: false, edge: "falling"});

setWatch(function(e) {
console.log("Click");
}, D38, { repeat: false, edge: "falling"});

setWatch(function(e) {
console.log("Left");
}, D39, { repeat: false, edge: "falling"});
Comments

Node.js v10 has fs module with promises!

I did not realize that Node.js v10 has promise support for the fs module. Why is this a big thing? It makes it possible to write call-back free code like this:

items = await fs.readdir(path);
for (var i=0; i<items.length; i++) {
  console.log(items[i]);
  }

instead of the older call-back-style:

fs.readdir(path, function(err, items) {
    for (var i=0; i<items.length; i++) {
        console.log(items[i]);
    }
});

Also error handling is so much easier now via a simple try..catch block.

And in case you get the dreaded(?) warning message from node "UnhandledPromiseRejectionWarning: Unhandled promise rejection.", then simply add try..catch blocks or explicit catch handler for promises.

Comments

Azure is more expensive than I expected

Azure has a habit of charging me more than I expect. Neither AWS nor GC does that and in both of the latter cases I'm either fully aware of the costs, or it's lower than expected thanks to the moderately generous free tiers, which I usually fall under.

But Azure is different.

During a workshop I used an "integration account" which costs staggering (about) US$30/day. To be fair, it's for enterprises, so it's actually not too expensive for what it does, but I used this by accident and it consumes all of the US$200 of have-fun-and-play-with-it in 7 days. I was not even using it for 6 of those 7 days.

The second time I try the very good Build a serverless web app in Azure. I like it a lot. Instructive, with command line instead of mouse clicking. Really nice and highly recommended. It's using a Dynamo DB database. I use 170 MB at 100 RU/s. That's 5 Yen in total for storage (no issue here), and 96 Yen per day for the reserved capacity. Does not sound too bad, but it's 3000 Yen (about US$30) per month while not using it.

AWS does have some tricky items too (load balancers, RDS instances, RedShift etc.) which costs, but I am aware of those and avoid them if I can. Google is usually cheaper than expected and I never had a negative price surprise either.

But Azure...twice they got me. There will be no third time. I'll have to learn their costing model before I'll use Azure again.

Comments

Sony Wena Wrist Battery Replacement

Replacing a battery from a normal watch is not that difficult with the right tools. The problem is: do you have the right tools? That was the question when I wanted to replace the battery of my Sony Wena Wrist (3 Hands).

Turned out to be easier than expected.

Simple Instructions

First flip the watch over and use a small flat screw driver to open the 4 screws visible in the back. They are not hard to open, so no excessive force needed.

Flip the watch back and carefully pull of the watch part from the strap part.

I was surprised how empty the watch actually is. Mechanical watches are full of stuff. Non-mechanical ones are full of...air and plastic spacer.

There is a thin black O-ring which is either attached to the top (watch) part of the bottom (base). It's supposed to be in the groove in the bottom base. If you lose or break it, the watch is no longer water proof...In my case it was stuck to the top part, so I had to take it and put back on the base bottom into its groove.

You can pull out the white plastic space lifting it from the knob side. Note the notch on the white plastic spacer. That side goes out last.

Then loosen the marked screw a bit. Then you can push out the old battery with a screw driver. Just push it gently from the direction of the center of the watch outwards. Put back a new battery. SR626. Once the new batter is in, tighten the marked screw again. And re-insert the spacer.

Flip it back on the base and screw it back with the 4 screws in the back. Done! 2.5 years no need to change the battery again.

Comments

WebStorm and TypeScript

Watching Uncle Bob's videos (those in particular where he refactors stuff with ease thanks to IntelliJ IDEA), I always wanted to try those IntelliJ IDEs out. Not for Java though as I'm not a big fan if it. When JetBrains did a special discount sale, I had to try it out: WebStorm for JavaScript that is. And heck, it's good. It's also complicated to set up, but it figures out a lot of things by itself, e.g. it understands package.json files, the run scripts inside, it knows linters, transpilers and so much more. But the learning curve is steep. And it takes quite some (about 20) seconds to get started. Sublime Text is way faster to start (less than 1 second), so that'll stay my go-to-choice for smaller things, but once a full project is set up, WebStorm is very helpful to have.

So this weekend I took some time to set up WebStorm for TypeScript with its transpiler, linter, unit tests etc. This video was a great help to get everything set up in a sensible way. I used another boilerplate setup for no particular reason. This is the result.

Once cloned and WebStorm is started, it'll ask to run "npm install". Let it do that. Open the file structure (top left) and you should see all files. Find "package.json" and double-click on it. Go to the section of "scripts". You should find them all automatically marked with a triangle:

If you click on the triangle for "test" and let it run it, WebStorm will:

  1. run tslint
  2. run tsc to transpile TypeScript into JavaScript into ./build/ for both source (in ./src) and tests (in ./__test__)
  3. run the tests incl. coverage checks
  4. report the result of all commands in the "run" pane
  5. Also you now have "TEST" in the configuration:

Neat! I start to like WebStorm as I can see that it's made to solve the little problems programmers have. But there's a lot of keyboard shortcuts to memorize...

Comments