## Keeping history alive with a 1959 FACOM 128B relay-based computer

August 4, 2019 2 comments

Back in the 1950s, the competition was between vacuum tube (valve) based computers and their relay-based brethren. Whereas the former type was theoretically faster, vacuum tubes suffer from reliability issues, which meant that relay-based computers would be used alongside tube-based ones. Not surprisingly, Fujitsu also designed a number of such electro-mechanical computers back then. More surprisingly, they are still keeping a FACOM 128B in tip-top shape.

Known in the 1950s as Fuji Tsushinki Manufacturing Corporation, Fujitsu’s Ikeda Toshio was involved in the design of first the FACOM 100, which was completed in 1954, followed by the FACOM 128A in 1956. The 128B was a 1958 upgrade of the 128A based on user experiences. Fujitsu installed a FACOM 128B at their own offices in 1959 to assist with projects ranging from the design of camera lenses to the NAMC YS-11 passenger plane, as well as calculation services.

As a successor in a long line of electro-mechanical computers (including the US’s 1944 Harvard Mark I) performance was pretty much as good as it was going to get with relays. Ratings of the FACOM 128B were listed as 0.1-0.2 seconds for addition/subtraction operations, 0.1-0.35 seconds for multiplication, with operations involving complex numbers and logarithmic operations taking in the order of seconds. Maybe not amazing by today’s (or 1970s) standards, but back then their point was to massively and consistently outperform human computers, with (ideally) unfailing accuracy.

Today, this same FACOM 128B can be found at the Toshio Ikeda Memorial Hall at Fujitsu’s Numazu Plant, where it’s lovingly maintained by the 49-year old engineer Tadao Hamada. Working as the leader of Fujitsu’s 2006 project to pass down technology that is still historically relevant, his job is basically to keep this relay-based computer working the way it has done since it was installed in 1959.

Categories: Retro

## Parsing command line arguments in C++

March 17, 2019 4 comments

One of the things which have frustrated me since I first started programming has been the difficulty in using command line arguments provided to one’s application. Everyone of us is aware of the standard formulation of the main function:

int main(int argc, char** argv);


Here argc is the number of arguments (separated by spaces), including the name of the application binary itself. Then argv is an array of C-style strings, each containing an argument. This leads to the most commonly used style of categorising the arguments:

app.exe -h --long argument_text


What annoyed me all these years is not having a built-in way to parse command line arguments in C++. Sure, there’s the getopt [2] way if one uses Linux or a similar OS. There are a range of argument parser libs or APIs in frameworks, such as gflags [3], Boost Program Options [4], POCO [5], Qt [6] and many others.

What these do not provide is a simple, zero-dependency way to add argument parsing to C++, while also being as uncomplicated as possible. This led me to put together a simple command line argument parsing class, which does exactly what I desire of such an API, without any complications.

Meet Sarge [1] and its integration test application:

#include "../src/sarge.h"

#include

int main(int argc, char** argv) {
Sarge sarge;

sarge.setArgument("h", "help", "Get help.", false);
sarge.setArgument("k", "kittens", "K is for kittens. Everyone needs kittens in their life.", true);
sarge.setDescription("Sarge command line argument parsing testing app. For demonstration purposes and testing.");
sarge.setUsage("sarge_test ");

if (!sarge.parseArguments(argc, argv)) {
std::cerr << "Couldn't parse arguments..." << std::endl;
return 1;
}

std::cout << "Number of flags found: " << sarge.flagCount() << std::endl;

if (sarge.exists("help")) {
sarge.printHelp();
}
else {
std::cout << "No help requested..." << std::endl;
}

std::string kittens;
if (sarge.getFlag("kittens", kittens)) {
std::cout << "Got kittens: " << kittens << std::endl;
}

return 0;
}


Here one can see most of the Sarge API, with the setting of arguments we are looking for, followed by the application description and usage, as it'll be printed if the user requests the help view or our code decides to print it in the case of missing options or similar.

The Sarge class implementation itself is very basic, using nothing but the STL features, specifically the vector, map, memory, iostream and string headers, in as of writing 136 lines of code.

When asked to parse the command line arguments, it will scan the argument list (argv) for known flags, flags which require a value, and unknown flags. It'll detect unknown flags and missing values, while allowing for short options (single-character) to be chained together.

I'll be using Sarge for my own projects from now on, making additions and tweaks as I see fit. Feel free to have a look and poke at the project as well, and let me know your thoughts.

Maya

Categories: C++, Projects Tags: , ,

## Designing an RC debounce circuit

June 26, 2018 2 comments

While working on a project earlier this year which involved the monitoring the state of a number of switches, I had to find a way to deal with the mechanical bouncing of these switches. I found that despite my initial assumption that this would be easy to find detailed information on, I failed to find any clear guides or tutorials. At least as far as hardware-based debouncing methods went.

Though I was aware of software-based switch debounce algorithms, I decided against using those, on account of them adding complexity to the code, taking away system timers from the pool and the extra burden this would put on testing and debugging the software design. Instead I opted to use an RC circuit-based solution. Without easy tutorials being available, in the end I simply copied the complete design from someone else, because it seemed to work for that purpose.

## The RC circuit

When debouncing switches in hardware, it matters which type of switch we are debouncing. The switches which I had to debounce for the project were SPST (Single-Pole, Single-Throw, with one output), meaning one has just a single signal wire to work with. This means that the delay created by an RC network charging or discharging is used to smooth out the erratic signal from a mechanical switch opening and closing.

With an SPDT (Single-Pole, Double-Throw) switch, one can use the same RC circuit, use an AND gate-based debounce circuit (not covered in this article), or use a hardware-based timer circuit.

The RC debounce circuit we’ll be looking at in this article is the following:

The way that this circuit works is that the capacitor (C1) is charged over R1 whenever the switch is in the open position, using the diode (D1) to bypass R2. This results in a logical ‘1’ being achieved after the delay created by the resistance value of R1.

When the switch closes, it discharges C1 over R2, with the latter’s value determining the delay, resulting in a logical ‘0’ being achieved. The output of the RC circuit is connected to U1, which is an inverse Schmitt trigger. This creates the expected logical ‘1’ when the switch is closed, and ‘0’ when it has been opened.

In addition to this, the Schmitt trigger (a CD40106 hex inverting Schmitt trigger IC) also adds hysteresis, essentially adding two trigger points to its output (which we connect to the input pin of our processor), which smooths out any remaining ripple by not switching to the opposite value immediately, but only after reaching the trigger point. This effectively creates a dead zone in between the logical values where any analogue noise has no effect.

## Understanding the circuit

When I decided to use this project as a practical example for my upcoming book on embedded C++ development [1], I realised that I needed to dive a bit deeper into the how and why of these circuits, especially on how to calculate the appropriate values for the RC circuit.

Fundamental to RC networks is the RC time constant, or τ (tau), which is defined as:

$\tau = { R C }$

This time constant is defined in seconds, with one τ being the time it takes for the capacitor to charge up to 63.2%, and 2τ to 86%. For discharging the capacitor, 1τ would discharge it to 37%, and 13.5% after 2τ. This shows that a capacitor is never fully charged or discharged, but has the process simply slow down. Of relevance for us here is that 1τ roughly corresponds to the charge level required to reach the opposite logical output level and thus the effective delay we get for a specific RC value.

In addition, we can calculate the voltage of the capacitor at any given time, when charging and discharging respectively:

$V(s) = { V_s (1 - e^{ -(t/RC) } ) }$

$V(s) = { V_s e^{-(t/RC) }}$

Here t is the elapsed time in seconds, $V_s$ the source voltage and e the mathematical constant (approximately 2.71828), also known as Euler’s number.

## Running the numbers

For the earlier given circuit diagram, we can take its values and use the RC time constant to calculate the delay we achieve and thus what length of switch bounce we can compensate for. We’ll first look at the charging time (51k Ohm, 1 uF), then the discharging time (22k Ohm, 1 uF):

$0.051 = { 51000 \cdot 0.000001 }$

$0.022 = { 22000 \cdot 0.000001 }$

With the used RC values we achieve 51 milliseconds for charging (switch opening) and 22 milliseconds for discharging (switch closing). As 20 ms is a common bounce time for mechanical switches, the used values seem therefore reasonable. For any practical applications we would need to use the actual bounce time of the used switches to pick the appropriate values, however.

## Conclusion

When it all comes down to it, designing an RC debounce circuit isn’t incredibly complex once one understands the principles and physics behind it. Using the RC time constant, it is a matter of picking an appropriate capacitor value, then sizing the resistors to reach the required charge and discharge times. The used Schmitt trigger IC isn’t terribly crucial, and can even be omitted in favour of an SoC’s built-in hysteresis.

The project which led me to research this topic resulted in me designing an entire debounce HAT [2] for the Raspberry Pi series of Single Board Computers (SBC):

This design uses all six Schmitt triggers in the CD40106 IC, allowing for up to six switches or equivalent to be connected. The integrated EEPROM allows the board to be automatically configured by the OS installed on the SBC by reading out the GPIO pins it is connected to, setting the appropriate direction and modes.

Naturally the RC values for this design can be altered at will to fit the requirements, so long as they fit the 0805 footprint.

Maya

## NymphRPC: my take on remote procedure call libraries

January 29, 2018 1 comment

Recently I open-sourced NymphRPC [1], which is a Remote Procedure Call (RPC) library I have been working on for the past months. In this article I would like to explain exactly why I felt it to be necessary to unleash yet another RPC library onto the world.

The past years I have had to deal quite a lot with a particular RPC library (Etch [2][3]) due to a commercial project. This is now a defunct project, but it spent some time languishing as an Apache project after Cisco open-sourced it in 2011 and got picked up by BMW as an internal protocol for their infotainment systems [4].

During the course of this aforementioned commercial project it quickly became clear to me that the Etch C library which I was using had lots of issues, including stability and general usability issues (like the calling of abort() without recovery option when any internal assert failed). As the project progressed, I found myself faced with the choice to either debug this existing library, or reimplement it.

At this point the C-based library was around 45,000 lines of code (LoC), with countless concurrency-related and other issues which made Valgrind spit out very long log files, and which proved to be virtually impossible to diagnose and fix. Many attempts resulted in the runtime becoming more unstable in other places.

Thus it was that I made the decision to reimplement the Etch protocol from scratch in C++. Even though there was already an official C++ runtime, it was still in Beta and it too suffered from stability issues. After dismissing it as an option, this led me to the next problem: the undocumented Etch protocol. Beyond a high-level overview of runtime concepts, there was virtually no documentation for Etch or its protocol.

Reimplementation

Fast-forward a few months and I had reverse-engineered the Etch protocol using countless Wireshark traces and implemented the protocol in a light-weight C++-based runtime of around 2,000 LoC. Foregoing the ‘official’ runtime architecture, I had elected to model a basic message serialisation/deserialisation flow architecture instead. Another big change was the foregoing of any domain specific language (DSL) as with Etch to define the available methods.

The latter choice was primarily to avoid the complexity that comes with having a DSL and compiler architecture which has to generate functioning code that then has to be compiled into the project in question. In the case of a medium-sized Etch-based project, this auto-generated code ended up adding another 15,000 LoC to the project. With my runtime functions were defined in code and added to the runtime on start-up.

In the end this new runtime I wrote performed much better (faster, lower RAM usage) than the original runtime, but it left me wondering whether there was a better RPC library out there. Projects I looked at included Apache Thrift [5] and Google Protocol Buffers [6].

Both sadly also are quite similar to Etch in that they follow the same DSL (ISL) and auto-generated code for clients/servers path. Using them is still fairly involved and cumbersome. Probably rpclib [7] comes closest, but it’s still very new and has made a lot of design choices which do not appeal to me, including the lack of any type of parameter validation for methods being called.

NymphRPC

Design choices I made in NymphRPC include such things as an extremely compact binary protocol (about 2x more compact than the Etch protocol) while allowing for a wide range of types. I also added dynamic callbacks (settable by the client). To save one the trouble of defining each RPC method in both the client and server, instead the client downloads the server’s API upon connecting to it.

At this point NymphRPC is being used for my file revision control project, FLR [8], as the communication fabric between clients and server.

Performance and future

Even though the network code in NymphRPC is pretty robust and essentially the same as what currently runs on thousands of customer systems around the world – as a result of this project that originally inspired the development of NymphRPC – it is still very much under development.

The primary focus during the development of NymphRPC has been on features and stability. The next steps will be to expand upon those features, especially more robust validation and ease of exception handling, and to optimise the existing code.

The coming time I’ll be benchmarking [9] NymphRPC to see how it compares other libraries and optimise any bottlenecks that show up. Until then I welcome anyone who wishes it to play around with NymphRPC (and FLR) and provide feedback 🙂

Maya

Categories: C++, Networking, NymphRPC, Protocols, RPC Tags: , ,

## MQTTCute: a new MQTT desktop client

January 2, 2018 Leave a comment

At the beginning of 2017 I was first introduced to the world of MQTT as part of a building monitoring and control project, and while this was generally a positive experience, I felt rather frustrated with one area of this ecosystem: the lack of proper MQTT clients, regardless of mobile or desktop. The custom binary protocol that was being used to communicate over MQTT with the sensor and control nodes also made those existing clients rather useless.

I would regularly have to resort to using Wireshark/tcpdump to check the MQTT traffic on TCP level, or dump the messages received into a file and open it with a hex editor, just so that I could inspect the payloads being sent by the nodes and services. This was annoying enough, and even more annoying was that the system was intended to be fully AES-encrypted, with only mosquitto_pub and mosquitto_sub actually supporting TLS certificates.

As a result I have had this urge to write my own MQTT client that would actually work in this scenario. Courtesy of getting laid off just before Christmas, I had some additional time to work on this new project. After about a week of work, I released the 0.1 Alpha version today on my GitHub account [1].

Called MQTTCute, it’s written in C++ and Qt 5, and using the Mosquitto client library for MQTT communication. Not surprisingly, it shares a fair bit of code with the Command & Control client for the BMaC system [2] which I also developed during the last year. I’ll be writing more on the BMaC project the coming time.

With this first version of the MQTTCute client all basic functionality is present: connecting to an MQTT broker, publishing on and subscribing to topics, along with being able to publish binary messages and see received messages both in their text and hexadecimal formats. Since an MDI interface is used, it should be possible to keep track of a large number of topics without too much trouble.

I’m hoping for feedback on this MQTT client, but regardless I’ll be implementing new features to improve the workflow and general options with the client. Hopefully someone beyond just myself will be finding it useful 🙂

Maya

Categories: C++, MQTT Tags: , , ,