Writing Software for the Microprocessor
The word 'Programming' means different things to different people. Schools might refer to preparing a Power-Point presentation, or arranging the graphics on a web site as 'Programming'. What happens to microprocessors within control modules is programming in the true sense of the word.
A virtual structure is created in just a few kilobytes of memory space. Software reads inputs, compares and measures these readings, makes decisions, then drives a network of outputs accordingly. Using code like the sample above, a program for a motor controller or pumping system could have four thousand lines of manually written code. In this environment a simple comma or space in the wrong place will stop the program from working. To create what may seem like a simple system could take fifty or one hundred hours of computer screen time to get a first working version. It is not something that can be done in a crowded room or next to a busy telephone. Programming in the machine language of a microprocessor is a delicate form of art in its own right.
What does the program do?
The programmer examines the specifications of the job, the details of the hardware structure, then sets about writing code that will make the device behave exactly as it should. The program will have a lot of contingencies of what to do when things go wrong or happen unexpectedly. When the user of some equipment throws a switch and expects something to happen, they don't realise that the program has been constantly checking that switch one hundred times a second, just waiting for a change. Even then, it may wait for another twenty or so checks to ensure that the change was real and not just a passing spike or glitch. It is the job of the programmer to ensure that the product is friendly to the user and will guard against the odd and unwanted events ever present in the real world.
How does the program get into the circuit board?
The program is written in a special editor program on a PC as a long series of instructions. This is a long-form that can contain hundreds of comments that help the programmer for where additions and changes become necessary at some time in the future. This is called the Source Code of the program.
If there are no compilation or typographical errors present, this bulky text form of the program gets compiled into a very compact hexadecimal program file ready to be transferred to the prepared circuit board.
Each circuit board with a microprocessor has a small connection socket where a special adapter can connect the new module to a PC. This hexadecimal file (hex file) is then transferred to the microprocessor that has been soldered into the prototype controller module. With some circuit boards, the microprocessor can be made to be an unpluggable module that can be quickly replaced in the field with another, updated microprocessor module. (This way software can be upgraded without disturbing the rest of a working system.) If the transfer was successful, the module should 'wake up' when power is applied and begin to carry out the instructions of the user.
How do we know it transferred ok?
Part of the transfer process is the Verify process. Once transferred, the PC will read the program back from the chip and compare it with the one still in the PC. If the two files match then the transfer was successful and the programmer unit will signal that all is ok. If it fails to verify, then the PC will tell the programmer of a problem. Usually it only takes 2-3 seconds to transfer a program. Modern microprocessors allow their memory to be programmed over and over again without degradation.
How are different versions of a program managed?
When the first release of a program is used in a field trial it will be called Version 1. Every time a change of any kind is made to that program, its version number is incremented by 1. Many software houses creating programs for industry follow a protocol of decimal points to delineate the differences between major and minor changes. As most microprocessor based projects will meet their objective within 2 or 3 revisions, a simple version number after the project code suffices.
Alian Electronics allocates a code to every new project starting with the letters 'SM' for System Module. A number such as SM246 would appear on a circuit diagram, a circuit board and the software for a project, followed by a small 'v' then a version number. Each of these three areas could have different version numbers. It is possible for the most current circuit diagram to be labeled SM246v2, the circuit board could be up to three revisions, (perhaps mounting hole sizes or positions have changed) where it would be called SM246v3. The most current software for the same project could be up to version seven (and be identified as SM246v7. All previous versions of diagrams, boards and code are all preserved and backed up. Earlier versions of machines and module will still need to be serviced at some point in the future.
Who owns the code?
The short answer is that the code belongs to the person or enterprise that paid for its creation. If a business finds a product on the Alian Elect. web site that it wishes to purchase, that's fine they may buy the product, but they have no control or interest in the software that makes it go. This is no different to buying a car, but not owning the software that makes the engine management work.
Conversely, if that same company ordered a new product to be built from scratch with matching software, then pays for that project in full, then they own the circuit, circuit board and software elements as well. Source code and artwork files would always be made available upon request. This information would then allow a third-party to recreate the same product.
Sometimes the situation may be split. For example, a company may use a generic control module (like the SM171) but have their own special program applied to it. They would own the program but not the module design, which may be re-used with different programs for different customers.
How do we stop others from reading and copying that program?
There are a number of protection options available to the programmer to ensure this does not happen. Once programmed, a chip can be told that it cannot be read or re-programmed again. It may permit the program to be erased, but not copied from the chip. This is a really useful feature that gives the owner of the new design a sense that they still control the product and that the competition cannot simply steal their valuable work.
Summary
The software within a project is its most valued aspect. It will determine the look, feel and behavior of a product. When a product is being sold and its features are being highlighted to prospective customers, all too often it will be the software features that are being described. Rather than being considered as the easy bit at the end of a project, it is in reality the heart which will determine the product success of failure in the real world.
Click here to return to CREATING A NEW PRODUCT
The word 'Programming' means different things to different people. Schools might refer to preparing a Power-Point presentation, or arranging the graphics on a web site as 'Programming'. What happens to microprocessors within control modules is programming in the true sense of the word.
A virtual structure is created in just a few kilobytes of memory space. Software reads inputs, compares and measures these readings, makes decisions, then drives a network of outputs accordingly. Using code like the sample above, a program for a motor controller or pumping system could have four thousand lines of manually written code. In this environment a simple comma or space in the wrong place will stop the program from working. To create what may seem like a simple system could take fifty or one hundred hours of computer screen time to get a first working version. It is not something that can be done in a crowded room or next to a busy telephone. Programming in the machine language of a microprocessor is a delicate form of art in its own right.
What does the program do?
The programmer examines the specifications of the job, the details of the hardware structure, then sets about writing code that will make the device behave exactly as it should. The program will have a lot of contingencies of what to do when things go wrong or happen unexpectedly. When the user of some equipment throws a switch and expects something to happen, they don't realise that the program has been constantly checking that switch one hundred times a second, just waiting for a change. Even then, it may wait for another twenty or so checks to ensure that the change was real and not just a passing spike or glitch. It is the job of the programmer to ensure that the product is friendly to the user and will guard against the odd and unwanted events ever present in the real world.
How does the program get into the circuit board?
The program is written in a special editor program on a PC as a long series of instructions. This is a long-form that can contain hundreds of comments that help the programmer for where additions and changes become necessary at some time in the future. This is called the Source Code of the program.
If there are no compilation or typographical errors present, this bulky text form of the program gets compiled into a very compact hexadecimal program file ready to be transferred to the prepared circuit board.
Each circuit board with a microprocessor has a small connection socket where a special adapter can connect the new module to a PC. This hexadecimal file (hex file) is then transferred to the microprocessor that has been soldered into the prototype controller module. With some circuit boards, the microprocessor can be made to be an unpluggable module that can be quickly replaced in the field with another, updated microprocessor module. (This way software can be upgraded without disturbing the rest of a working system.) If the transfer was successful, the module should 'wake up' when power is applied and begin to carry out the instructions of the user.
How do we know it transferred ok?
Part of the transfer process is the Verify process. Once transferred, the PC will read the program back from the chip and compare it with the one still in the PC. If the two files match then the transfer was successful and the programmer unit will signal that all is ok. If it fails to verify, then the PC will tell the programmer of a problem. Usually it only takes 2-3 seconds to transfer a program. Modern microprocessors allow their memory to be programmed over and over again without degradation.
How are different versions of a program managed?
When the first release of a program is used in a field trial it will be called Version 1. Every time a change of any kind is made to that program, its version number is incremented by 1. Many software houses creating programs for industry follow a protocol of decimal points to delineate the differences between major and minor changes. As most microprocessor based projects will meet their objective within 2 or 3 revisions, a simple version number after the project code suffices.
Alian Electronics allocates a code to every new project starting with the letters 'SM' for System Module. A number such as SM246 would appear on a circuit diagram, a circuit board and the software for a project, followed by a small 'v' then a version number. Each of these three areas could have different version numbers. It is possible for the most current circuit diagram to be labeled SM246v2, the circuit board could be up to three revisions, (perhaps mounting hole sizes or positions have changed) where it would be called SM246v3. The most current software for the same project could be up to version seven (and be identified as SM246v7. All previous versions of diagrams, boards and code are all preserved and backed up. Earlier versions of machines and module will still need to be serviced at some point in the future.
Who owns the code?
The short answer is that the code belongs to the person or enterprise that paid for its creation. If a business finds a product on the Alian Elect. web site that it wishes to purchase, that's fine they may buy the product, but they have no control or interest in the software that makes it go. This is no different to buying a car, but not owning the software that makes the engine management work.
Conversely, if that same company ordered a new product to be built from scratch with matching software, then pays for that project in full, then they own the circuit, circuit board and software elements as well. Source code and artwork files would always be made available upon request. This information would then allow a third-party to recreate the same product.
Sometimes the situation may be split. For example, a company may use a generic control module (like the SM171) but have their own special program applied to it. They would own the program but not the module design, which may be re-used with different programs for different customers.
How do we stop others from reading and copying that program?
There are a number of protection options available to the programmer to ensure this does not happen. Once programmed, a chip can be told that it cannot be read or re-programmed again. It may permit the program to be erased, but not copied from the chip. This is a really useful feature that gives the owner of the new design a sense that they still control the product and that the competition cannot simply steal their valuable work.
Summary
The software within a project is its most valued aspect. It will determine the look, feel and behavior of a product. When a product is being sold and its features are being highlighted to prospective customers, all too often it will be the software features that are being described. Rather than being considered as the easy bit at the end of a project, it is in reality the heart which will determine the product success of failure in the real world.
Click here to return to CREATING A NEW PRODUCT
