I've hidden away and burned the midnight oil to finish off a Nixie Tube Driver Library of which I am satisfied. As previously mentioned in Testing the Nixie Tube Library, I've ended up with three classes that make up the Library Model. These are named 'NixieTube', 'NixieDriver' and 'NixieDisplay'. I've hopefully written this well enough to be worthy of the 'Model-View-Control' concept.

I've written enough in each class [for now] to make it usable in this specific application, but there are so many more functions I could write to make the Library more complete and flexible. the NixieTube and NixieDriver classes both have 'runBlock()' functions and 'callback()' function pointers.

runBlock()

The reason for the name of this function is that it must be called as often as possible during the lifetime of the program, and when it is called it will 'block' [sleep] the thread one or more times, for timing of various actions. It updates the state of the object(s), so in the case of the NixieTube it will set the tube state to 'on', wait a while and then set the tube state 'off'. I had originally planned to avoid using a 'blocking' [sleep-calling] in favour of 'non-blocking' [without sleeping] where I would have stored an offset to the next time a particular action needed to happen, and used if-statements to keep track of the schedule. This turned out to be CPU-hogging (100% on a CPU core), power-hungry and does not play nice on a threaded OS like Linux. I'm too used to Micro-controllers, it seems! The alternative 'blocking' method, on the other hand, typically uses 3.5% of a CPU core. Far more efficient and friendly.

callback() function pointers

This Drivier Library is specifically a 'Model' and does not care about the 'View' or 'Control' detail. All the Model does is indicate that an action has taken place, and that is partly where the 'callback()' function pointers come into play. The 'callback()' function pattern in my implementation is Asynchronous, so it also serves as an Event Handler. For my tests (and possibly my final version in this project), I'm assigning only one function via the NixieDriver's setOnCallback() and setOffCallback() setter functions. This is more than enough for what I need to do right now, and could be optimised slightly by calling a separate function for 'on' and 'off' to save unnecessarily polling certain GPIO pins. We'll see.

driverThread()

Since I have taken the 'blocking' route for timing actions, the Library may cause timing problems for other aspects of my application. To solve this issue, I've designed the Library so that the NixieDriver's 'runBlock()' function runs on a separate thread to the main application. The thread creation and operation is handled in the NixieDisplay class via driverThread() and startThread().