Going Further

In all the experiments we have presented so far, only a SINGLE, simple operation or feature has been carried out.
That’s the idea of an experiment, to produce or concentrate on a single result. That’s the only way to fully understand the concept being investigated.
But that’s not the limit of the PIC LAB-1.
It is capable of quite considerable feats, such as a dialing alarm, robot control, counting and games, to name a few.
Some applications will require additional inputs or output devices but the main thing is the program can be generated on the PIC LAB-1 board and new PCB produced when everything is working perfectly.
As we have mentioned in previous pages of this article, all the development can be done at no cost, other than buying the PIC LAB-1 kit, as all the “tools for development” are provided on the site.
By following our alphabetical layout for programming you will be able to locate the sub-routines when the program becomes very long.
Keep all the sub-routines in alphabetical order (in the middle of the program). Start with SetUp, place Tables at the top and Main at the end.
Many of the programs can be developed by using the sub-routines we have presented in the experiments and you can start by taking one of the programs and using it as a “starting-point.”
As soon as you get something on the page, the pressure of starting will be over and you can change the instructions to reflect the new program.
As soon as you think of the next step, go to the experiments and see how it has been done. Or refer to the Library of Routines. It lists every feature you will need for each step of a program and by “cutting and pasting” you will be able to build up a program very quickly.
When you add a sub-routine to your program, make sure all the CALLs and RETURNs are operational.
As soon as possible, test it to make sure it works. Save the program with a new name so that if a mistake is created in the next phase, you can come back to the saved version and build-up again.
This is a very good policy as it saves a lot of frustration.
As you get better at programming, you will require this feature less often, but it is the only real way to solve some of the problems you will encounter.
If you get stuck during a stage of development, try using different instructions, as the instructions you are using may not be carrying out the operations you intend.
Gradually build up your program by using sub-routines from the experiments and Library of Routines.
These show you everything, such as how to toggle a line, compare two values, produce a tone, output a siren-sound, and many more.

One of the important features in a program is …

POLING

Poling is looking at an input line on a regular basis to see if a particular event has occurred - such as a button-press.
There are two ways to check an input line. One it to “look at it” on a regular basis and the other is to allow the input line to create an interrupt.
The simplest is to look at it on a regular basis, but this requires a little bit of thought as any long delay routines will keep the micro busy and the program will miss any button-presses during this time.
The answer is to include a “look” feature inside the delay.
You can have more than one “look” feature in a program and when a button is detected, a flag is SET.
This flag is checked in Main to see if it is SET, and the appropriate action taken.
The subroutine below shows a delay routine with a “look” feature.
The button flag must be CLEAR before entering Delay1.

Never leave a sub-routine (such as Delay1) on the action of a button-press and go directly to the push-button subroutine. Simply set a flag, complete the operation in the sub-routine and return to Main. If you want the operation in the sub-routine to cease, use the following instructions: