DEV Community: Alessandro Genova

My First Arduino Project - Film Photography Memo Device and Light Meter

Alessandro Genova — Fri, 20 Jan 2023 20:14:43 +0000

It's been a while since I worked on a tech-related personal project.

During the holidays I picked up an Arduino-like board, to play around with.

I was wondering what project I would have fun doing with it, and decided to combine it with another hobby I picked up last year: photography and film photography.

A digital camera stores all kinds of metadata alongside each picture it takes. Arguably the most important metadata it stores are the exposure settings that were selected when taking that picture (aperture, shutter speed, ISO).

An analog film camera typically doesn't store any of this information. Some photographers carry around a notebook where they write the exposure settings for each picture they take.

Moreover, most film cameras include some electronic circuitry to determine the amount of light in the scene and help guide the photographer in picking the aperture and shutter settings to produce a correctly exposed picture. Many old film cameras, while still being mechanically working, have a long dead light meter.

I never take notes, and all my cameras have working light meters. But I needed an excuse to start a project, so here I am.

See it in action

Below is a short video where I demonstrate the usage of the device: I create a roll and save a couple of frames.

Video Demo

Source Code

The full source code for the film memo device can be found at https://github.com/alesgenova/film-memo.

Parts List

Microcontroller: Adafruit ItsyBitsy 32u4 3.3V. I needed a board with enough pins to manage the various controls, display, and sensors that I had in mind. I also wanted something fairly constrained in terms of speed and memory available, to make it a bit more of a fun challenge, and to ensure that it would have acceptable battery life. The ItsyBitsy costs just $9 and seemed like a suitable choice.
Display: I opted for a widely available 128x64 OLED display with a SSD1306 controller that communicates with the main board via I2C. A 5-pack of this kind of display costs $15 on Amazon.
Controls: I used two standard rotary encoder from Adafruit (~$4 each). Originally, I planned to add two additional push buttons, but once I started soldering the parts I realized I wouldn't have enough space, and decided to just use the buttons integrated in the rotary encoders.
Light Meter: The light meter circuit is made up of a photo transistor and a 1kOhm resistor. The light meter has a useable range between 10EV and 16EV. While it's not nearly as good as an actual camera TTL reflective meter, it can be used in a pinch. And with proper calibration it could probably be pretty accurate as an incident light meter. Total cost less than $1.
Battery: I used a 350mAh lithium battery from Adafruit, as well as a charging board. Cost for both ~$10.
Enclosure: The enclosure is a random plastic box from Amazon that I eyeballed being an acceptable size for the project. It was later poorly cut up with household tools in order to fit the various component.
Hot Shoe Mount: Taken from an old flash unit I had around.
Other: Strip PCB boards, wires, capacitors to debounce the controls signals, on/off button, etc. ~$10.

While the nominal price of the parts is about $40, realistically I spent almost an order of magnitude more once you factor in extra parts bought for testing or to account for possible mistakes and the tools needed (soldering station). At least now I have plenty of spare parts for future projects.

It definitely turned out more expensive than a similar (and probably better) device I could have bought off the shelf.

Software

The application is written in C++. I used the Arduino library to help with things such as reading/writing voltage from/to a IO pin, and the Adafruit SSD1306 library to help with driving the display.

The rest was written from scratch:

Controls: I created some abstractions to detect changes on the pins attached to the rotary encoders and buttons using the interrupts available on the ItsyBitsy. These low-level events are queued and interpreted in the main application loop and composed into high level event such as button click, button longpress, rotary left, rotary right.
App State: The application is a state machine. Each different page in the app is modeled as a separate AppState. An AppState can react to the event coming from the controls appropriately, and cause the transition to another AppState.

Minimizing Memory usage

The ItsyBitsy 32u4 has:

2kb of RAM
28kb of Flash for the program instructions
1kb of EEPROM to store persistent data

By the end of the project I started hitting the limits on both RAM and Flash.

On the RAM side I was able to achieve the biggest optimization by reworking the Frame struct. Since each Roll of film has 36 Frames and there can be multiple rolls in the app, Frames take up a large portion of the available RAM.

In my initial implementation of the Frame struct, I had two member variables enums to represent Aperture and Shutter. The sizeof() this struct is 4 bytes.

By refactoring Frame so that it has a single uint8 member variable, and by providing getter/setter member functions that take/return the enums and using bit masks and bitwise operations I was able to reduce the sizeof() of the struct to 1 byte.

enum class ApertureValue {/* ... */};
enum class ShutterSpeed {/* ... */};

// An instance of BloatedFrame uses 4 bytes of memory
class BloatedFrame {
public:
  ApertureValue aperture() const { return m_aperture; }

  ShutterSpeed shutter() const { return m_shutter; }

protected:
  ApertureValue m_aperture;
  ShutterSpeed m_shutter;
};

// An instance of Frame uses 1 byte of memory
class Frame {
public:
  ApertureValue aperture() const {
    return (ApertureValue)(m_data & 0b00001111);
  }

  ShutterSpeed shutter() const {
    return (ShutterSpeed)((m_data & 0b11110000) >> 4);
  }

protected:
  uint8_t m_data;
};

On the program size front things were not any easier. In its current form the application uses 28,588 bytes out of the 28,672 bytes (99.7%) available on the board. I had to convert some templated classes into non-templated classes to save a few bytes here and there. I'm not sure how to reduce the binary size any further, if I want to add new features in the future.

"Manufacturing"

I did solder a few times in the past and I was never good.

At the beginning of this project I hit a new low in the quality of my soldering, and briefly considered giving up.

A breakthrough came when I switched the soldering tips that came with my iron (conical shape) to tips with a chisel shape.

It definitely wasn't smooth sailing after getting the better tips, and working under the relatively small space constrain of the enclosure I picked didn't help. But I did get a working device in the end.

The image below shows the wiring diagram of the main components of the device. Omitted is the circuitry for the lithium battery and its charger.

In the actual device I separated the components between to boards:

Bottom board: main microcontroller, connection for the camera hotshoe, light meter, battery, charger.
Top board: rotary encoders and OLED display.

The two boards can be stacked similarly to an Arduino hat: the male/female connections between them keeps the two parts together, and the assembly fits in the enclosure by the tightest of margins.

Conclusion

Completing the project was fun and challenging and it taught me a thing or two.

MPI-like Parallel Programming in JavaScript

Alessandro Genova — Wed, 10 Feb 2021 14:57:03 +0000

I did it again. After my latest experiment, I took things too far once again.

I recently wrote @post-me/mpi, a library to write parallel algorithms that can run on a pool of web workers, using an API similar to MPI.

A worker pool is a set of workers that are mutually interconnected. Each worker can communicate directly with any other worker in the pool.

The low level communication between workers and the parent application is managed by another library I wrote, post-me.

Usage

Below is a small example of using @post-me/mpi in practice. In this example we will be sorting an array in parallel.

Worker code:

import { joinPool } from '@post-me/mpi';

const connection = await joinPool(self);

// The parallel sort method
const sort = (communicator) => async (array) => {
  const root = 0;
  let subArray = await communicator.scatter(array, root);
  subArray.sort((a, b) => a - b);
  const sorted = await communicator.reduce(subArray, merge, root);

  return sorted;
}

// Expose parallel methods to the application
connection.registerMethods({ sort });

// Merge two sorted arrays into a single sorted array
function merge(a0, a1) {/* ... */}

Parent code:

import { createPool } from '@post-me/mpi';

const array = new Float32Array(1024);
const N_WORKERS = 4;

// Create the workers
const workers: Worker[] = [];
for (let i = 0; i < N_WORKERS; ++i) {
  workers.push(new Worker('./worker.js'));
}

// Create a pool of mutually interconnected workers
const workerPool = await createPool(workers);

// Pass different parameter to the parallel method based on the rank of the worker
const root = 0;
const args = (rank) => rank === root ? array : null;
const transfer = (rank, [arr]) => rank === root ? [arr.buffer] : [];

// Call the parallel method 'sort'
const result = await workerPool.call('sort', args, transfer);

// The sorted array is returned by the root worker
const sortedArray = result[root];

MPI Operations

The following MPI operations are already implemented in @post-me/mpi:

send
recv
bcast
scatter
gather
reduce
barrier
allGather
allReduce

Typescript

The library has extensive typescript support, all arguments, methods, return types, etc., are all type checked so that most coding mistakes can be caught at compile tim.

Benchmark

Below is a quick non-scientific benchmark that shows that indeed running a parallel algorithm is faster than serial. In the plot I'm showing the speedup obtained when sorting arrays of various length as a function of the number of workers.

Demo

I created a small demo page where you can run a couple of test algorithms yourself (source).

Conclusion

Nobody asked for it, but there you have it. You can write parallel algorithms in JavaScript using a MPI-like syntax.

Running Rust in WebAssembly in a Pool of Concurrent Web Workers in JavaScript

Alessandro Genova — Mon, 18 Jan 2021 14:06:12 +0000

Your scientists were so preoccupied with whether or not they could, that they didn't stop to think whether they should.

I would like to share a little experiment I did for no other reason than to show I could.

In this proof of concept, the main application starts a pool of web workers that it later uses to offload a series of heavy tasks.

The task in question is to to render a single frame of a simple 3D scene using ray-tracing (path-tracing). The computationally intensive rendering is performed by a rust library compiled to WebAssembly.

These are the tools I used:

alesgenova / post-me

📩 Use web Workers and other Windows through a simple Promise API
alesgenova / ray-tracer

A simple ray tracing engine
rustwasm / wasm-bindgen

Facilitating high-level interactions between Wasm modules and JavaScript
Small in-house task queue to dispatch tasks to workers when available.
react for the skeleton of the app.

If you would like to run this madness, an instance of this application is deployed here.

If you would like to see the details of the implementation, you can find the source code of the app on Github

Bonus

Using a similar approach, I also created an app that can detect the pitch of sounds being captured by the device's microphone.

Try it out

alesgenova / post-me

📩 Use web Workers and other Windows through a simple Promise API
alesgenova / pitch-detection

A collection of algorithms to determine the pitch of a sound sample.

📩 Use web Workers and other Windows through a simple Promise API

Alessandro Genova — Fri, 08 Jan 2021 13:03:10 +0000

post-me is a typescript library that provides a simple promise-based API for bidirectional communication with web workers and other windows (iframes, popups, etc.).

0. TLDR

With post-me it is easy for a parent (for example the main app) and a child (for example a worker) to expose methods and custom events to each other.

Main features:

🔁 Parent and child can both expose methods and/or events.
🔎 Strong typing of method names, arguments, return values, as well as event names and payloads.
🤙 Seamlessly pass callbacks to the other context to get progress or partial results.
📨 Transfer arguments/return values/payloads when needed instead of cloning.
🔗 Establish multiple concurrent connections.
🌱 No dependencies: 2kb gzip bundle.
🧪 Excellent test coverage.
👐 Open source (MIT): https://github.com/alesgenova/post-me

Below is a minimal example of using post-me to communicate with a web worker. In this example, the worker exposes two methods (sum and mul) and a single event (ping) to the parent. The parent could expose methods and events as well.

Install:

npm install post-me

Parent code:

import { ParentHandshake, WorkerMessenger } from 'post-me';

const worker = new Worker('./worker.js');

const messenger = new WorkerMessenger({ worker });

ParentHandshake(messenger).then((connection) => {
  const remoteHandle = connection.remoteHandle();

  // Call methods on the worker and get the result as a promise
  remoteHandle.call('sum', 3, 4).then((result) => {
    console.log(result); // 7
  });

  // Listen for a specific custom event from the worker
  remoteHandle.addEventListener('ping', (payload) => {
    console.log(payload) // 'Oh, hi!'
  });
});

Worker code:

import { ChildHandshake, WorkerMessenger } from 'post-me';

// Methods exposed by the worker: each function can either return a value or a Promise.
const methods = {
  sum: (x, y) => x + y,
  mul: (x, y) => x * y
}

const messenger = WorkerMessenger({worker: self});
ChildHandshake(messenger, methods).then((connection) => {
  const localHandle = connection.localHandle();

  // Emit custom events to the app
  localHandle.emit('ping',  'Oh, hi!');
});

In this more complex interactive demo a parent application communicates with a web worker and a child iframe. You can play around with it on codesandbox.

1. History

A few months ago I was using the postmate library at work, to expose methods from my application (which was inside an iframe) to its parent app.

While postmate worked okay initially, I soon started running into some major limitations:

You can call a method with arguments, but you can't get its return value.
You can get the return value of a method, but only if the method takes no arguments.
No typescript support, makes it hard to enforce the correctness of API exposed by the parent/child across teams
If a method throws an error, it can't be caught by the other end.
Only the child can expose methods and events.
It works with iframes only.

I thought that it could be a fun weekend project to try and implement a new library that would overcome all of the shortcomings I had found, and that would provide first-class typescript support.

The first working version of post-me came together in a couple of days during the Thanksgiving break, and I was quite happy with it.

I soon realized that what I had wrote could be easily adapted to interface with web workers and beyond, making it more useful than the somewhat niche demand for communicating with iframes.

Now, after a few iterations, I believe post-me is ready to be introduced to a larger audience, and I hope it can be useful to some.

2. Typescript

Using typescript you can ensure that the parent and the child are using each other's methods and events correctly. Most coding mistakes will be caught during development by the typescript compiler.

Thanks to post-me extensive typescript support, the correctness of the following items can be statically checked during development:

Method names
Argument number and types
Return values type
Event names
Event payload type

Let's rewrite the small example above in typescript!

Types code:

// types.ts

export type WorkerMethods = {
  sum: (x: number, y: number) => number;
  mul: (x: number, y: number) => number;
}

export type WorkerEvents = {
  'ping': string;
}

Parent Code:

import {
 ParentHandshake, WorkerMessenger, RemoteHandle
} from 'post-me';

import { WorkerMethods, WorkerEvents } from './types';

const worker = new Worker('./worker.js');

const messenger = new WorkerMessenger({ worker });

ParentHandshake(messenger).then((connection) => {
  const remoteHandle: RemoteHandle<WorkerMethods, WorkerEvents>
    = connection.remoteHandle();

  // Call methods on the worker and get the result as a Promise
  remoteHandle.call('sum', 3, 4).then((result) => {
    console.log(result); // 7
  });

  // Listen for a specific custom event from the app
  remoteHandle.addEventListener('ping', (payload) => {
    console.log(payload) // 'Oh, hi!'
  });

  // The following lines have various mistakes that will be caught by the compiler
  remoteHandle.call('mul', 3, 'four'); // Wrong argument type
  remoteHandle.call('foo'); // 'foo' doesn't exist on WorkerMethods type
});

Worker code:

import { ChildHandshake, WorkerMessenger, LocalHandle } from 'post-me';

import { WorkerMethods, WorkerEvents } from './types';

const methods: WorkerMethods = {
  sum: (x: number, y: number) => x + y,
  mul: (x: number, y: number) => x * y,
}

const messenger = WorkerMessenger({worker: self});
ChildHandshake(messenger, methods).then((connection) => {
  const localHandle: LocalHandle<WorkerMethods, WorkerEvents>
    = connection.localHandle();

  // Emit custom events to the worker
  localHandle.emit('ping',  'Oh, hi!');
});

3. Other Windows

As mentioned earlier, post-me can establish the same level of bidirectional communications not only with workers but with other windows too (e.g. iframes).

Internally, the low level differences between communicating with a Worker or a Window have been abstracted, and the Handshake will accept any object that implements the Messenger interface defined by post-me.

This approach makes it easy for post-me to be extended by its users.

A Messenger implementation for communicating between window is already provided in the library (WindowMessenger).

Here is an example of using post-me to communicate with an iframe.

Parent code:

import { ParentHandshake, WindowMessenger } from 'post-me';

// For safety it is strongly adviced to pass the explicit child origin instead of '*'
const messenger = new WindowMessenger({
  localWindow: window,
  remoteWindow: childWindow,
  remoteOrigin: '*'
});

ParentHandshake(messenger).then((connection) => {/* ... */});

Child code:

import { ChildHandshake, WindowMessenger } from 'post-me';

// For safety it is strongly adviced to pass the explicit child origin instead of '*'
const messenger = new WindowMessenger({
  localWindow: window,
  remoteWindow: window.parent,
  remoteOrigin: '*'
});

ChildHandshake(messenger).then((connection) => {/* ... */});

4. Debugging

You can optionally output the internal low-level messages exchanged between the two ends.

To enable debugging, simply decorate any Messenger instance with the provided DebugMessenger decorator.

You can optionally pass to the decorator your own logging function (a glorified console.log by default), which can be useful to make the output more readable, or to inspect messages in automated tests.

import { ParentHandshake, WorkerMessenger, DebugMessenger } from 'post-me';

import debug from 'debug';          // Use the full feature logger from the 'debug' library
// import { debug } from 'post-me'; // Or the lightweight implementation provided

let messenger = new WorkerMessenger(/* ... */);
// To enable debugging of each message exchange, decorate the messenger with DebugMessenger
const log = debug('post-me:parent'); // optional
messenger = DebugMessenger(messenger, log);

ParentHandshake(messenger).then((connection) => {/* ... */});

Output:

5. Conclusion

Thank you for reading, I hope post-me can be useful to other people as well.
If you would like to try out or contribute to the library, the source code is available on GitHub.

DEV Community: Alessandro Genova

My First Arduino Project - Film Photography Memo Device and Light Meter

See it in action

Source Code

Parts List

Software

Minimizing Memory usage

"Manufacturing"

Conclusion

MPI-like Parallel Programming in JavaScript

Usage

MPI Operations

Typescript

Benchmark

Demo

Conclusion

Running Rust in WebAssembly in a Pool of Concurrent Web Workers in JavaScript

alesgenova / post-me

📩 Use web Workers and other Windows through a simple Promise API

alesgenova / ray-tracer

A simple ray tracing engine

rustwasm / wasm-bindgen

Facilitating high-level interactions between Wasm modules and JavaScript

Bonus

alesgenova / post-me

📩 Use web Workers and other Windows through a simple Promise API

alesgenova / pitch-detection

A collection of algorithms to determine the pitch of a sound sample.

📩 Use web Workers and other Windows through a simple Promise API

0. TLDR

1. History

2. Typescript

3. Other Windows

4. Debugging

5. Conclusion