March, 2012

BUILD A

SOFTWARE MACHINE
A Language for Super programmers

MasoodAlam
Electronic Engineer with Programming experience maswd@yahoo.com

Category:
Electronics C language Programming Microcontrollers Software Automation

SMG Release version 0.1 March, 2012

INTRODUCTION
An IDEA to flourish Why keep doing same job all the time Learning, Learning, Learning, why not teach you something different Keep it open SMG is a State Machine Generator for microcontroller based projects.

STORY
Being a programmer and electronic engineer at the same time put ultimate responsibility to design a system from scratch. Writing Hello world is a neat example when a future programmer is introduced to a language especially C. Later on, the programmer learns to write complicated program using Logic testing, loops and his main function expands until he/she learns the code segmentation by making subroutines or distributed functions. Whatever language you use, your application grows in every dimension, and programmer feels it more difficult to understand or keep in mind as whole. Sometimes programmer uses a better technique on applied problem that was experienced before. These are programming rules/expertise the programmer has developed. If you happen to be a software administrator or you keep tracks of dozen of software in your organization from different programmers, you can recognize the coding by a number of ways: Syntax of code i.e. function or subroutine names Commenting style, description given in the code. Usage styles of loops, conditions

Once basic application is ready, it is made complicated by oncoming client requirements. It sometimes tries to change the basic architecture, and often results in birth of one or more bugs. Testing the application each time after adding a feature becomes more difficult. So changes in the environment of an application are constant phenomena. The behavior of application should be ideally followed by the client requirements. I call it specifications or the culture of program. In a traditional development environment, specifications are not present or not understood. Requirements are just the foundations of building or creating a new application.

MOTHER OF INVENTION
Yea, you will put NEED in the phrase. Jami and I were good colleagues for quite some time in an organization. He was technician and a kind of intelligent guy. He left abroad for job and passed about a decade there. Now he is back, and often visits me with a storm of miniature electronic requirements such as Temperature sensor, controller, light flasher etc. etc. I guided him the way of Microcontroller (8051), but C language was quite hard for him and I was continued being bombarded by his ideas and requirements. Unpleasantly, there was zero or quite insufficient M-factor. . . . M for Money. Many times Jami called me to build a simple microcontroller based application which fulfills the requirements of a Full-time watchman to start and stop the water pump installed for overhead water tank and a basement water tank in certain premises.

The application had serious clients including my father too. So I begin to start over his idea, so that one circuit could be used by me myself. Generally speaking it is not difficult for any programmer lets put the Jami requirement in these words here: Water pump is connected through an electric motor (One Output) Empty and Overflow signals are sensed via dipped wire (Two Inputs) Start motor when it goes empty Stop motor when it reaches water at full level i.e. overflow Think you have made the application, you are pretty smart. But now my JAMI comes again and tells that there is a condition of water supply into the overhead tank. Sometimes water is not available to pump into overhead tank. It is quite normal, now the application will add a waiting function until water supply is resumed. I will put the specifications of my client now in these words. Start Motor when tank goes Empty Check water for 1 minute. If there is no water supply for 1 minute, turn off the motor and restart after one hour. If water supply is normal, keep the motor on until over head tanks goes full, and stop motor then. Now specification still seems to be easy because human language used in above lines are quite explanatory. However many of the programmers will not be convinced with my idea. In fact programmers will begin to state that these specifications are confusing. Often client uses simple words to declare the requirements, and often the requirements cover it prime objective. In other words, client does not address the conditions that occur during the operation of its application e.g. What to do when water supply is broken from normal condition What to do when motor is turned off after acquiring full conditions What to do when power fails. What to do when 1 minute / 1 hour time values need to be changed. Since programmers implement the fundamental requirements in the heart of application, most of the parameters are hard coded. Sometimes the main application rejects such changes at all. As a result programmer begins a complete re-write. My client (JAMI) is very annoying, now the requirements include blinking of a Light, so that operation of the application is visible. Mercifully a add up following line into the specifications of the application Blink the Light every second.

Truly speaking, this requirement is not the primary objective; anyway application has to support it. It implies that there can be one or more requirements need to be implanted into the application that rarely related to its prime objective I believe that my client is right in his requirements whenever it comes there. It is something wrong with my application architecture that does not seamlessly accommodate the oncoming requirements. There is also a factor of Human mind. Human brain starts to focus on a new object (My application) when it is presented for the first time. At this initial level, the requirements are well understood. So the implementation was easy and fast. When the brain is given second time requirements by the client, it tries to fit those in the existing structure of the application. You remember Timer functionality that was added in the second-time requirements, is entirely a different sort of service. Any how our programmers put it working. Congratulations. Now the third-time my brain was hit by Light blinking requirements. You know this is the dumbest requirements that one can put in an XYZ application built over electronic components. Most of the programmers will do it in the easiest style. Now Application seems to be complete as far as my client and your client does not come back with a new demand. Hey!, JAMI t comes again, now he wanted to build similar kind of application for basement tank, i.e. now another set of Motor pump and control signals, and another Light too. I, boringly, asked him to build two of electronic circuits and use them. JAMI was surprised, and told me there are still many pins left unused, plenty of code and data memory free. You cannot deny, I had taught him how to burn the hex file into controller. He was using AT89C2051 controller, and he was right all the times. Now the Human brain has to re-write the application so that application has to use: Empty input signal for over head tank Empty input signal for basement tank. Overflow input signal for overhead tank. Over flow input signal for basement tank. Water supply input signal for over head tank. Water supply input signal for basement tank. Over head motor output signal. Basement motor output signal. Common Light signal for blinking the Eye. 1minute timer for over head tank water supply 1 hour timer for over head tank restart condition.

10 minute timer for basement tank supply 1 hour timer for basement tank restart condition. 1 second light flashing timer. Now the programmers might find application difficult high enough especially running without bugs. I would have to need a multitasking system which prevents any blocking conditions while waiting for one timer and so. I was not convinced with this idea, that how a simple state machine could go to a complicated level which is difficult to implement. I searched for state machine description so as to get the hot shot tips for building state driven machine for my application. Anyway, I could not find much helping material other than to build a jump table for all possible states for one output. Maintaining state variables, and generating events according to input signals.

BIRTH OF SMG
This was the starting point of what I call StateMachine Generator (SMG). Obviously, I had to tell SMG that what inputs and outputs I am going to use, and what are the values of various timers that provide an internal event. Recall, I had overhead waterpump application, here is its requirements (I call it Specifications UTankPump_specs.txt):

You can simple invoke smg by following command: smg sUtankPump_specs.txt, here is the output

You will see SMG generates a number of files, but believe me the code is quite simple and small in size. All you need is to put them in single project of your favorite compiler (Like KEILs microvision) Currently, SMG 0.1 is released, in order that Jami can get its fruits and I will not expect any Mfactor. It can generate similar files for basement tank when specs file for basement tank is provided. Look at the specs I had written for BottomTank.

Remember timer.c, timer.h, delay.h, delay.c remain the same for both specifications, since the state machines will run within same microcontroller. Life became easier, now I wrote simple specs for Light flashing.

Now I have to make single project in Microvision compiler containing following files: Timer.c, timer.h Delay.c, delay.h Led_statemachine.h, led_statemachine.c UTank_statemachine.h, UTank_statemachine.c BTank_statemachine.h, BTank_statemachine.c Main.c

Following is the architecture of final application:

MAKE A BLINKER USING SMG

Write a simple Specification led_specs.txt file as following

Now you will simply have to run this command:

Now open KEILs Microvision compiler IDE and make blinker project with these files.

TEST BLINKER WHITHIN SMG

I put stress on TESTing. Developers put their 98% of mind concentration on Developing an Idea, While giving 2% on Testing their invention causes them to put another 98% of Mind stress on finding the Bugs in their application.

SMG is built on keeping the idea behind. You will be invited to test your application before you actually deploy. To test something, you will have to give a test paper. I am giving LedTest.txt for testing my newborn blinker application.

You can give Blinker test command at the same time when it is created.

Understanding of inputs and outputs is left for our super programmers.

TO BE CONTINUED . . .