CellScript and the Simulator

While serving up a static web page is an important milestone, it isn’t useful. The goal of my project is to have it present web pages as the user interface for home automation functions like thermostat settings, irrigation times, and lighting schedules. That means it needs to collect information from the user, and then do something with it. The server must be programmable.

I settled on an approach very similar to Microsoft Active Server Pages (ASP). A programming script would be embedded in each web page that would tell the server what to do; this script would be stripped out before the web page was sent on to the user’s browser. Since web pages are themselves often programmed using JavaScript, I decided to also use JavaScript to program the server. Or rather a small subset of JavaScript, which I call CellScript.

But then came the question: If the AVR is running a script, how do you debug it when it isn’t working? The answer was to create a simulator on the PC. The simulator would serve up web pages and behave just like the WebCell, but allow full debugging of the embedded CellScript with single stepping, breakpoints, and viewing variable values. On September 24, 2008, I started work on the simulator, before ever starting to implement CellScript itself.

A fundamental tenet of the simulator was that it would be built from the same C++ source code files used to implement CellScript on the WebCell. That was the only way to ensure they would work the same, and of course I didn’t want to write the code twice. For the past few years I’d used the programming language C# for all my programming on a PC. But since CellScript would be written in C++, I figured the simulator would need to be in C++ as well.

I started programming the simulator using Microsoft Foundation Classes (MFC) – a standard library for creating a Windows program (nearly obsolete now) that I’d used before. But I missed features that I had gotten used to with C#, some of which were actually part of Microsoft .NET, which is really the ultimate environment for Windows programming. Before long I switched to “managed C++”, a variation of C++ for the .NET environment.

So as I implemented CellScript, I found I did all the testing and debugging in the simulator. In late November I got a script to run for the first time on the prototype hardware. This sequence became the norm: implement new features, test and debug on the simulator, then check it out on the prototype hardware. Quite often things simply worked when transferred to the prototype, a satisfying testament to the effectiveness of the simulator. The reason for creating the simulator had not been to make development easier, but that turned out to be a huge benefit.

The prototype hardware used the ATmega324P MCU, which has 32K of program space. Of that, 18K of program space was being used when the basic web server functionality was first working (before starting on CellScript). At the start of 2009, my work on CellScript had filled the entire 32K, and I still had a long way to go. I switched over to a newly built-up prototype with the ATmega644P, giving me 64K of program space. This also increased RAM size to a whopping 4K (from 2K).