I've reached a critical coding point using a picaxe 28x1 - I've run out of variables.

Doing small programs on a picaxe is easy, thanks to a simple but powerful basic interpreter. Because of its structure, it has a limited number of byte and word variables available. Once these have all been used, coding gets increasingly difficult. I find that good coding strategies are needed to stop me going crazy.

Once you run out of variables, you need to find a way to re-use them without corrupting data from one routine to another. Data can be stored in random access memory (RAM) addresses or EEPROM addresses to free up variable for re-use. The problem comes in the detail, and carefully working out which variables are needed where in a program, and then making sure values are stored elsewhere before moving on.

I'm taking a break from coding to do this blog to prevent myself from going crazy at this point. I've realised that adopting some of the strategies outlined below might help me sleep tonight ;-)

Rule 1:

If a piece of code is repeated, always write a subroutine to do it.

Rule 2:

Try to minimise the depth of subroutine calls. It can be hard to keep track of which routine calls another, which makes it difficult to keep variables isolated.

One strategy is to set 'flags' to indicate a subroutine call if there needs to be a shift in call order.

Rule 3:

Make each procedure or subroutine a sealed unit - that is peek (get from RAM) all variable values at the start of the routine, and poke (store in RAM) them all at the end, freeing all variables up for other routines. If there needs to be any global variables, make sure there are good reasons for them.

Rule 4:

Start afresh with a clean slate and slowly re-build the complexity, rather than try to re-build an already complex piece of work.

The result:

After a couple of solid days of re-coding, I am still at a lesser-functioning piece of code. What I do have, though, is a much cleaner, and easily expandable piece of work. It is painful to go through the process, but if done properly will be worth it because the code will be much easier to maintain.

We had time to get the electronics gear out again last weekend, so we put together a test circuit for our level sensor.

Leah built our level test rig. The vertical is a hose with a funnel at the top to allow easy filling of water. To her left is the pressure connection to a motorola MPX5010GS sensor. This unit outputs around 5 volts at 50 cm of head pressure. For our purposes we will only need about 20 cm of this range, but the picaxe which will be doing the analog to digital conversion will still see around 100 mls of resolution. We figure there is no need to amplify the output (ie. keep it simple).

On the right hand side of the rig is a tap to let out water and therefore easily vary head pressure for testing purposes. (Thanks Garrett for the inspiration for this test rig ;-)

The circuit we put together has an LM3914 LED driver driving a LED bar display. This will give us a simple visual indicator of 10 LEDs to show a full tun. You can see our prototyping board above and the actual circuit diagram is shown below (sorry about the poor image here - this is a function of uploading to live spaces - please contact me if you want a copy you can read).

We marked out approximate volumes on the test rig, correlating head pressure (height) from the brewing tun onto the hose. The values shown are in litres.

 And the circuit worked beautifully. The indicator below shows the 'tun' is half full. Now that we have a proof of concept, we can design and build up a printed circuit board.

Every time I start up our dishwasher I am inspired by the simplicity of its control. I can select between a few cycle types such as normal or pots, and if I want I can add an economy feature which helps to save water.

It is this kind of simplicity that I am drawn to in designing a brewing machine control interface. Brewing machines are more complex, or at least if I am going to the trouble of making beer with grains, then I want to have greater control over temperatures and times than I would ever need in a dishwasher.

Designing a control interface that is both versatile and simple is a challenge, but I am happy with progress. For control, essentially the machine will have UP/DOWN, PREV/NEXT options and a start button. All information will be displayed on an LCD with 2 rows of 16 characters.

I made a template to help with designing screens. Above is an example of how I intend to deal with mash steps. The drawing shows a 3-step mash where both temperature and time settings can be adjusted simply. I found it a bit painful to do, but I made myself stick to temperature adjustments of 1 degree increments, and time in single minute increments. This will be more than enough accuracy for a machine like this, and 0.1 degree C resolution is really only "eye-candy".

With a screen like the one above, user-control is simple. The first number is displayed as >63<. The >< indicators show the user that this is the active variable. If I want to adjust this temperature setting, say to 67 degrees C, all I need to do is press the UP button four times. If I want to adjust the time duration associated with this temperature, I would press the NEXT button until the '30' below the original '63' is the active variable.

One of the features intended is that variable changes will be saved to memory. This means that if a brewer has a favourite step-mashing regime, this will become the default setting.

If the settings require no adjustment, the user can simply press the START button to select the next screen. This means that despite the complexities of a brewing machine, the machine can start brewing with only three START button presses (toggling through mash settings, boil settings and volume settings).

One of the design features of the machine is that settings screens like the one pictured above are easily accessible no matter where in the brew cycle the machine is. If, for example, the machine is mashing per the settings on the screen above, an information screen will be displayed showing actual system temperature, volume and system time (a count-down timer). A single button press will immediately return the user to the relevant settings screen, where parameters can be adjusted on the fly. After a short time of inactivity, the information screen will be displayed again.

At present, coding is complete to this stage. The next stages of coding will involve actual control of pump, heating element and taking the machine through a full brew cycle. Although that sounds complex, I think the coding is probably 2/3 complete.