The RJ Journal - Programming

2007-05-13

On these pages I will share some of my knowledge in this area and give tips on programming in general and tips for different type of platforms in specific. But first, for the ones that are interested and have the energy to read about it, my biography regarding computer and microcontroller programming. As you will see, I am self taught in most of the programming areas, as are many of us programmers, driven by a passionate and genuine interest.

I was first introduced to programming in upper secondary technical school on an ABC80 computer using the BASIC computer language. It didn't take long until I found out that this was something for me. I then learnt assembler programming and CP/M, also in school, on the 8080/85 microcontroller.
After that came the Casio Fx-702P, programmable calculator, where I improved my BASIC skills in a very restricted environment, both regarding memory and display capabilities.

Then it happened, in the early 1980s Commodore made the VIC 20 computer, which, at the time, was in my price range. It had a BASIC interpreter as the standard operating system with the READY> prompt flashing at you on the 22 column * 23 row text monitor on power up. The start screen also revealed that it had a stunning 3583 bytes free, just waiting for you to do something useful with it. Most people used it for games but that wasn't enough for me. Since the BASIC language had so many limitations, mostly in speed and program size, I learnt the 6502 instruction set and started to program in assembly language. At first I had no assembler so I hand coded the programs directly into machine code. Later I bought the VICMON cartridge which would let me write code with mnemonics instead of machine code, but no symbols for constants or addresses. It had single step and trace abilities, though, which made debugging a lot easier. The VIC20 BASIC interpreter was made smart enough to be easily extended with pointers to important functions in RAM that could be replaced or wedged with your own. I did a set of BASIC commands to handle graphics, like simple sprites and line and polygon drawing, that all could be used together with the original BASIC interpreter, which didn't have any built in commands at all for graphics. This program was sold by a Swedish software vendor and went under the name of "Rubens BASIC" and it was the first piece of software that I made any money on. Not very much though.

I then bought the Commodore 64 which was the successor for the VIC 20. It had the same breadbox look as the VIC 20 but it was hardware wise improved in several ways. It had a lot more RAM, a whole 64k, and much better graphics capabilities through hardware circuits that handled sprites and smooth scrolling, perfect for games. I got myself a machine code monitor cartridge for the C64 too, but I could still not use labels which was a real pain when doing forward jumps in the code since the destination address had to be corrected when I knew where it would be located. Luckily, most jump instructions could be done with relative branches which made it pretty easy to move the code blocks around. After a while, programming in this way became a bit tedious so I wrote an assembler that could work with text and labels instead of code directly in memory. It could handle several source files by the use of symbol tables and simple linking. At some point in this development I actually could use the assembler to write improved versions of itself. I did a couple of games for the C64 and I ported the code for the graphics commands from the VIC 20 and also added 3D wire frame capabilities and double buffering.

Next on my programming experience was embedded controllers using the Z80 and it's peripheral components. The CPU was programmed with assembly language and the applications where different kinds of industrial controllers doing everything from measuring and positioning to converting protocols between industrial robots and peripheral equipment.

Then it was time for the Amiga 500, a wonderful machine with a very nice preemptive multitasking operating system for its time. The vast majority of the Amiga 500 owners used it for gaming because of its good graphics and sound capabilities. For me it was the starting point for more serious application programming and of course the introduction to modem communication and BBSes, which in many ways can be seen as the predecessor to the internet. I bought the reference manuals to all of the Amiga libraries (Exec, Intuition, Libraries and Devices and Hardware) and a C-compiler (Lattice C) since C was the native programming language for the Amiga. After that, C became my programming language of preference.

At my work I came in contact with the Psion HC 100 range hand held computers which I developed some applications for. It had a nice multitasking operating system and remote debugging capabilities.
Around this time, early 1990s, the PC became more and more popular even in the industrial field so I started to do DOS applications, for industrial control and data acquisition, using bar code scanners, RFID readers and optical sensors of all sorts. Most of the devices communicated with RS232 or RS485. Some of them also used embedded devices to relieve the PC from time critical code.

I also did some applications for the MEMOR 2000 hand held computer with built in RFID reader and/or barcode scanner. Its programming environment was very much like the PC DOS but a lot more limited.

I built a rather comprehensive library for character based menus, screen presentation and data input in C for DOS, some of which are still used today. This made it rather easy to quickly build small applications that was, and still is, used for production testing equipment, for example. It could also easily be used as a simple shell for other applications since the menu structure was built up with a text file which, besides the internal commands, could take external commands such as programs or batch files and submenus could also come from another text file.

In the mid 90s I started to use the PIC embedded controllers and programmed these in assembly language. Among other things, I made a 2 processor safety system, a light beam safety controller, where the 2 processors continuously supervised each other and the safety output couldn't be engaged if the light beam was broken, if one of the 2 processors or any other critical component didn't work in a potentially dangerous way or the external output contactors failed. The PIC circuits became very popular and developed into several new families and more and more products that I developed included one and sometimes more. I also used the SCENIX micro controller in some applications. This is based on the PIC 16C5X family but is 4 times faster with the same clock and can be clocked with up to 75MHz. It also has a programming/debugging interface via the clock pins which lets you trace, singlestep, set breakpoints and view/edit memory and register values with a cheap hardware dongle.

At the beginning of this millennium it became apparent that DOS applications on PC's will be more and more limited. It did work for simple industrial control systems that needs minimal visual appearance and input or non at all but for applications that lives in the borderland between office desktop and industrial control/measurement, DOS was a dying environment. Especially if the PC was running Windows together with other programs. So it was time to learn Windows programming and C++. I figured this would be closer to my experience with C than to go the Visual BASIC route. I also wanted the better performance that C++ could give. Even if it only is less than 10 years ago, PC's were a lot slower then. Since I was going to use C++ it was also natural to learn MFC, which is the C++ object oriented programming interface to the Windows API. It was quite a big step to go from C and DOS to C++ and Windows with MFC. Not only with the object oriented programming but also the way the applications had to work. Instead of linear programming where one application more or less owns the hardware and software resources, applications had to be event driven and ask nicely for any resource it needed. Luckily, this was very much how programs worked on the Amiga and the Psion HC100, with their multitasking environments, so I had the basics from the beginning.

Another major difference was how software was written. I was used to simple text editors with little or no help with the actual programming. With Windows programming this was very different since I used Visual Studio for C++ (VC98) which was like a programmers heaven, coming from the simpler text editors. There is IntelliSence, which saves a lot of typing (when it is working), Class Wizzard for messages and control variables, Workspace with its ClassView and ResourceView and if course the graphical interface for placing controls and text on dialogs. I found myself very frustrated when I had to go back to the old style text editors to maintain older programs.

In the embedded segment I found that I sometimes needed a microcontroller with more resources and speed than the PIC could deliver. This was before the PIC 18 family had come out. I choose the Frescale (still Motorola at that time) HCS12 family since it was fairly scalable regarding memory and peripheral blocks using much the same pinout. This  means that a smaller device could be replaced by a bigger without the need to change the layout if there, for example, was need for more memory. It also means that the initial development could be done on a device with more resources and the production device could be chosen optimized for the final code size. Besides the standard A/D, D/A and timer blocks, the HCS12  comes with various peripheral blocks. Depending on type, there is asynchronous and synchronous serial, IIC, USB, CAN, Ethernet and even a free running little RISC processor. The HCS12 family also has a nice, low cost, programming/debugging interface that could be directly integrated in the development environment. It's architecture makes it optimal for C, and even C++, compilers. I use the CodeWarrior IDE and write in C. I have not yet needed to do any assembler coding with this processor.

Next on the agenda was Microsoft's .Net Framework and C# (pronounced C sharp). I initially looked at this when we were going to do an application with a Pocket PC using the compact .Net Framework and Visual Studio 2003. I still haven't done so many things with C# and the .Net Framework but I have tried to keep up with the technology and also updated to Visual Studio 2005. I have ported some of my classes and programming methods to the C# and .Net environment, for example a subsystem class with a visual interface that is a base class for functions normally more or less free running quietly in the background that can be opened and inspected for troubleshooting or configuration purposes. These free running background functions could be serial communication interfaces for sensors, TCP/IP communication, watching for files and folders to import data from, for example. I have also ported classes for handling persistent data between sessions such as properties selected by the user or variables maintained by the application, which could be window positions and states. Data is stored as XML files and have initial default values the first time the application is run or when the XML file doesn't exist.

Microsoft has now also released a very nice platform for the embedded market, called the .Net Micro Framework, which is programmed in C# using the standard Visual Studio programming and debugging environment that also can use a simulator on the PC instead of the real hardware. This is mainly targeted at larger embedded devices such as the ARM7 and ARM9. Mark my word, this will be a very interesting platform in the near future for embedded applications such as set top boxes and internet connected appliances, much because of a lot of code that already has been written, for both desktop and the compact framework, can be reused in smaller embedded applications. More processor families will most likely be added to this environment in the near future. Especially considering how embedded devices have developed over the last 10 years. In the next 10 years, even processors targeted for smaller devices will have much more resources and horsepower than they have today. It will also be more important to be able to develop the firmware for these devices more quickly. A very smart move for Microsoft. The question now is not if we will se the windows logo in our cars but when we will se it. I got a little sidetracked here since this isn't part of my programming biography yet, except from running a few samples, but I expect that it soon will.

Recently, I also have studied Flash and Action Script 3.0 in order to make some interesting and nice looking web graphics, controls and interfaces and of course Flash games. The result of the game programming can be seen here and here.