All the physical parts of the system are now built. Various software routines were written to test the different aspects of the system, but not everything has been together on the same circuit boards. The display, for arguments sake, had never been proved. I've used LCD displays in past projects though, so that was not a big deal.
While I was laying the processor board out, it occurred to me that a cool facility would be some sort of visual interface for programming. I'm really glad I did, because it came in very handy for debugging, by telling me what the system was doing at any time. This can be a time-saver, as you can see if the software is caught up in an endless loop, and the system appears broken!
The display was included as part of the final system as a user interface.
I was a bit dubious of the system operating in the real world, as that can be a pretty hostile environment for a sensitive micro-processor. This is certainly true in some pipe organs, because there are numerous electro-magnets, causing potential spikes through the power supply when operated (although the magnets are supposed to be suppressed). There's also an electric motor for raising the wind. If the motor is turned on and off with any electronic systems connected, that might cause issues. In short, you can prepare for a lot of eventualities, but you're never sure about anything until the system is up and running in these hostile surroundings.
Another thing is, it's one thing testing single inputs to the system to get it to perform a single task, but if you press a piston (button) that makes several things happen together, the result can be quite unpredictable. When you're programming for a system like this, you have to be something of a pessimist, and think "what's the worst thing that can happen at any time?". If you program with this in mind, there shouldn't be too many surprises when the system is "doing it for real".
There are certain times when you actually have to slow the program down, or wait until an entire sequence of events has finished. With an organ control system you normally don't notice anything untoward, as the bits of organ you're controlling wont really be quick enough to respond to most things at a transient level. On the other hand, this is a system that once it starts to speak, it's committed to finishing the phrase!
As a valedictory to these pages, I'm going to include a few lines of the system glue (called software) that keeps everything together! This is a straightforward routine to get all the inputs.
if(test_bit(portc,5)) bt = 1; else bt = 0;//Preserve mute state
portc = chip_l;
w_store[chip_l + (bd_l * 8)] = 0;
for(bit_l = 0; bit_l < 8; bit_l++) //Inputs for current chip interrogation
porte = bit_l;
bt = test_bit(porta,4); //Output bit corresponding to current address/data/board enable combo.
if (bt) set_bit(w_store[chip_l + (bd_l * 8)], bit_l);
The few lines above is just a snippet of the whole project software. It's being constantly called, with a differential-checking routine in between. Any differences are then acted upon - that's where the fun-and-games start!
The processor device I ended up using was a PIC18F4685. Along the way, I evaluated a PIC16F874, a PIC18F452 and a PIC18F4520.
Thanks to all the people I know, who put up with my enthusiasm while I worked on the project. I must have been pretty boring! Yeah yeah, I know - I still am!