Slow Progress on the List

With the production prototype in hand and working, and plenty of program space available in the XMEGA, 2010 was spent methodically working through “the list” – the CellScript Language Reference. Hardware features came first, such as ADC, DAC, PWM, and input capture (measuring the pulse width or frequency of an incoming signal). This would allow testing circuitry on the DevKit whose job was to demonstrate these features.

But the list was very long, and sometimes got longer instead of shorter. Work items included getting multiple scripts to run at once, implement the DHCP network protocol, storing important data in the internal non-volatile memory (EEPROM), adding “MIME types” to web pages – and fixing lots and lots of bugs.

The WebCell has several ways to communicate with the outside world besides Ethernet, including three serial ports, an SPI (Serial Peripheral Interface) port, and an I2C (Inter-Integrated Circuit) port. “The list” has just a few functions and properties that CellScript needs to utilize these ports – things like read(), write(), and bitRate. Implementing these for the WebCell was a clearly understood task. However, what would these do on the simulator? This question applied to all the hardware features. I spent much of August creating ways for the user to interact with simulated hardware features, allowing entry of the stuff going in, and display of the stuff coming out.

In September I started creating web pages designed to demonstrate and test hardware features. In the process I looked into YUI, the Yahoo! User Interface. The first page I made was for testing PWM (pulse-width modulation), and it used a YUI “slider” to adjust the PWM width. YUI also made it easy to have the web page contact the server in the background (in this case, the WebCell or simulator) for instant updates – a common way to make web pages more interactive called AJAX (asynchronous JavaScript and XML).

The demo web pages were helpful in completing testing of the production prototype. Satisfied that I’d found all the wiring errors, I began revision of the PCB. On September 16, 2010 I sent in the order for new PCBs, and received them October 4. When assembled and put to the test, no problems were found in the hardware design. I now had two complete working units: the production prototype, with its cuts and jumpers; and the final production model.

Using the new hardware, I set out to give the WebCell the ability to have its firmware updated over the network. Part of that process included transmitting a somewhat large firmware file from the PC to the WebCell via FTP, which turned out to expose numerous problems in previously untested FAT file code. I had had a similar experience back in July, which had got me thinking about how to test the FAT file code better.

The CellScript simulator was a great way to test and debug CellScript itself, because the same source code was used for both the simulator and the real WebCell. However, the simulator just used Windows for file operations, so it didn’t help test the FAT file system. But I realized I could change that, using raw sector read/write calls through Windows. In just a few days I was able to create a special version of the simulator, just for testing, that used my FAT file code to read & write files on an SD card on the PC.

I did a lot of testing and fixed a lot of bugs in the FAT file system, now using nothing but the simulator. In December I ended up doing a major overhaul of the whole system. And now I had a large set of tests I could run anytime to make sure the FAT file system was working right. Program size when I was finished was 70K, out of the 128K available.