Intermittent bugs are amongst the most frustrating ones to track down to the root. Why? They don't crash your program consistently — they just occasionally make things stop working, and restarting usually fixes them... for a while though. And this is exactly the kind of ghost that was haunting the JNI-for-NI-Drivers library, an open-source Java wrapper for National Instruments (NI) hardware drivers, also used in a train cab simulator at the Birmingham Centre for Railway Research and Education (BCRRE), University of Birmingham . — 8 min read This post walks through the root cause of a bug, how it was diagnosed, and its fix contributed via Pull Request #2 . What is JNI-for-NI-Drivers? National Instruments, officially, does not provide Java language bindings for its hardware drivers. There, JNI-for-NI-Drivers library fills that gap. In essence, it is a wrapper around the officially provided drivers, built itself with the Java Native Interface (JNI) ...
Six keywords appearing in almost every embedded project, cited commonly in code reviews, and understood correctly by almost a negligible number of new developers. And this isn't a report from a random academic survey — it is a field report from development teams of systems where getting these wrong costs weeks and months. — 18 min read Particular kind of bug keeps haunting embedded systems: it is the kind where the code is correct, logic looks sound, unit tests pass, but the system still fails in hardware. You revisit the algorithm. Verify the peripherals. Add printf s for debugging — which, in turn, changes the timing enough for the fault to disappear. Then you remove it. And the problem returns. In a significant proportion of such cases, the root cause can be traced to misunderstood keywords. It is not about a missing keyword — it is about a keyword that is present, used with confidence, but doing something entirely different from what the developer beli...