When the pandemic hit, I scrambled to determine a way to work from home with my embedded system. The system was portable. I squeezed everything I needed into a large box. I already had extra monitors and other accessories in my home office. Hence working from home was viable.

Developing embedded software is a cycle of building the code, flashing the binary into the embedded target hardware, and testing it. And repeating this cycle until the team has all the features developed and bugs fixed.

Here are some valuable lessons I learned during this process.

Read more…

After switching to WSL2 as explained in a previous post, while terminator and code were working fine, something broke with my blogging workflow.

When nikola serve -b is executed from bash, it should launch a web browser and serve the blog locally for review. But this does not work under WSL2 without some adjustments.

Read more…

I've had these notes regarding git setup in Linux for a while and decided it would be good to add it to the blog for future reference. Setting up git and SSH is a little tricky. For example, if you don't have all the file permissions just right for your SSH setup, things will just not work. Setup involves piecing together information from multiple web searches, so collecting it all here is useful.

Some of the notes also explain how you can copy git and SSH configurations from Windows to a Linux VM (e.g. WSL2 or VirtualBox-based).

Read more…

Here's a view of my favorite terminal emulator, terminator, running under WSL2 with X11 forwarding, side-by-side with VSCode running in Windows. (The screenshot is from a 49" widescreen monitor.) In this note, I've outlined my setup to get to this.

Read more…

Please see an adapted version of this article published on Opensource.com here.

In the previous post in this series on evolving your use of git, I outlined how git can be used in a one-person project.

In this post, I'll outline additional things you may need to learn about git to work effectively as part of a team.

Read more…

I started using git several years ago. The sophisticated way in which git swaps files back and forth "under the hood" (inside the mysterious .git folder) when changing branches still amazes me to this day. In my first job years ago where I worked on signal processing research, none of the researchers used any formal version control systems. Every day, I would make a "just-in-case" backup of my code that was in a good working state before making further changes. Even after I started using git, there was an initial period of anxiety when I made such backups because I didn't really know all the ways of undoing changes with git and feared a mishap.

I wish I had known about the approaches and opportunities for code management that git provides beyond the high level explanations about its importance. While there is a staggering amount of documentation and tutorials on git, it is a sophisticated tool that is impossible to learn all at once while also trying to focus on the application you're developing.

This is not a complete tutorial on git but a sequence of stages to gently evolve your knowledge and use of git. Had I known these stages beforehand, I would have stumbled less along my journey with git. In this first article, I'm going to outline how to evolve your usage of git in a one-person project.

Read more…

With the advent of the disastrous COVID-19, I decided to write this down as a sort of COVID-19 survival tip.

I've had to take a work project home and set it up in my home office. The work project is an embedded system with a physical Ethernet interface for networking (i.e. no WiFi), and requires internet access. I used an old Raspberry Pi 3 that I had laying around and set it up as a router to get the embedded system onto the internet.

Here are the steps.

Read more…

It's amazing how a trivial search for something that should obviously exist spirals out of control...

It all started with this. I was tinkering with some Python machine learning scripts which took a while to run, and wanted to know how long they took to run. Unfortunately, I was running my scripts on a Windows command prompt so that Tensorflow could access my PC's NVIDIA GPU. Under Linux via VirtualBox, GPU access doesn't work. Hence my need to use Windows (or get another native Linux machine...)

Under Linux, there's the well known time utility that can tell you how long a command took to run. However, I was surprised to find no equivalent utility available in the Windows 10 command prompt. Yes, there are a myriad of solutions for this: use PowerShell, or install Cygwin, or install Bash for Linux, or install one of several old binaries that provide the solution that used to exist on some long-forgotten Windows version. I'm wary of installing anything, especially old binaries of dubious origin. Of course, there's also the more cumbersome approach of simply adding the timing functionality into the Python scripts themselves. It'd be just a few lines of code.

Hey, why not just create a Python console script that does something like what the Linux time utility does? It'd only be a few lines of code, right? And so, that's how this little detour started...

Read more…

Here are some notes on how to set up Unity ML Agents under Windows 10. The instructions are consolidated from multiple locations. They've been cleaned up or updated to make sense for the current Unity 2019.30f3 version, the current ml-agents and Windows 10.

Read more…

Docker-in-Docker is explained by its author here. In a nutshell, the recommendation is to not use "true" Docker-in-Docker. Instead, use:

docker container run --volume /var/run/docker.sock:/var/run/docker.sock ...

The above volume mapping provides the container with access to the Docker socket with which it can start more "sibling" containers. But the approach is not a "true" Docker-in-Docker (which is not recommended) and avoids its corresponding issues. The nice thing about this approach is it can work with any Docker image (with some additional items installed as explained in this post).

Here's a compilation of useful proxy settings that may be required if you work in an organization using proxies and require Docker-in-Docker for your work. In addition, I also outline how to update your Dockerfile so that the corresponding image can support this Docker-in-Docker approach.

Read more…