tag:blogger.com,1999:blog-24526010101737355592024-02-07T01:36:48.395-08:00WebCell Development BlogCreating a miniature full-featured web serverTim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-2452601010173735559.post-3060832875569235052015-04-13T12:49:00.001-07:002015-04-13T12:49:23.500-07:00Expanding Home Automation<p>I’ve recently taken steps to expand the range of home automation devices supported by the WebCell web pages. The first new device is the <a href="http://smartenit.com/product/rainbee16/">RainBee16 irrigation controller</a> from Smartenit. This is a 16-zone controller commanded wirelessly over ZigBee. At the head end, Smartenit’s <a href="http://smartenit.com/product/zbplm/">ZBPLM</a> (RJ-45 serial version) connects to the WebCell to provide the ZigBee interface. The ZBPLM also provides INSTEON control, so only one interface device is needed for both ZigBee and INSTEON.</p> <p>I just installed this system, replacing a traditional irrigation controller. It was a real pleasure to be able to walk around the yard, iPhone in hand selecting an irrigation zone to check out. Even out of Wi-Fi range, the iPhone connected via cellular data and kept me in control. (I had to set up remote access with user name and password, as mentioned in my last post, for this to work.)</p> <p>To get this going there was a fair amount of restructuring of the underlying web services used to communicate between the browser (on the iPhone or whatever) and the WebCell. Now that this is independent of control system, I hope to add more types of devices.</p> <p>These new abilities have not yet been rolled out as update for WebCell. A little more testing and tweaking is needed.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-67218452019556404162015-04-13T11:23:00.001-07:002015-04-13T12:15:35.015-07:00Update to Self-Sufficiency<p>As presented on my <a href="http://www.patersontech.com/">company web site</a>, the WebCell product line is sold as a programmable module that allows you to add a web interface to some existing project. Much is said about the CellScript Simulator for developing your own interface, while the included home automation interface is mentioned little more than in passing.</p> <p>Since I myself use this device for home automation, I’ve decided to start shifting the emphasis in that direction. Toward that end, I’ve issued a major update to the WebCell firmware and home automation web pages. Once installed, this update allows the WebCell to be fully managed without the CellScript Simulator. This mainly means that the WebCell is now capable of checking for and installing updates for it’s own firmware and for the web pages. (If you already had a WebCell, installing this update would require the CellScript Simulator.) The bottom line is that from now on, an average end-user of the home automation pages will have no reason to ever use or even install the CellScript Simulator.</p> <p>Another important feature of this update is that it now supports password-protected remote access. It allows you to create users that can access the WebCell from anywhere on the Internet. It also handles the nitty-gritty steps of opening a connection through your router to the Internet, using Universal Plug and Play (UPnP).</p> <p>Finally, some of the home automation web pages have been spruced up. Managing and switching between multiple schedules has been greatly simplified. But the major overhaul I’d hoped for has not happened. My last post, over a year ago, talked about having a contractor lined up. That contractor was unable to deliver much, and the next one accomplished even less, so a year has been wasted on that front.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-88131096843781451302013-11-14T17:42:00.001-08:002013-11-14T17:42:50.374-08:00On Sale<p>Today the <a href="http://www.patersontech.com/">Paterson Technology</a> web site was updated to take orders for the WebCell and Cell Development Kit. I’ve spent most of my time on the production process, from ordering parts to developing production programming software. (The actual assembly is handled by a nearby factory, <a href="http://pcacorporation.com/" target="_blank">Printed Circuits Assembly</a>.) We now have both products in stock.</p> <p>There has been some progress on the documentation, but there is still a long way to go. This will be a continuing emphasis for me.</p> <p>The standard web pages for the WebCell are still as rough as ever. But I now have a contractor lined up to give them a beautiful new design.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-49426368791435117612013-08-02T17:45:00.001-07:002013-08-02T17:45:27.404-07:00The Unveiling<p>Today I rolled out a completely new <a href="http://www.patersontech.com/">Paterson Technology</a> web site featuring the WebCell as a product “coming soon”. The WebCell documentation is skeletal at best and the pre-built web pages provided with it are pretty rough, so I don’t know when it will actually go on sale. But I felt I needed to get the obsolete products removed from the site and start talking about what’s coming up.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-83702682413404330432013-07-04T00:02:00.001-07:002013-07-04T00:02:07.321-07:00A Change of Schedule<p>Wow, it’s been a long time since my last update. I have continued to work on developing the WebCell into a product. I’ve used a few contractors from <a href="http://www.elance.com/">Elance.com</a> to help with specific things, like make icons for the CellScript Simulator. But I’ve spent the most time on a total rewrite of the web pages for home automation.</p> <p>The home automation web pages are no longer generated by running CellScript code on the WebCell. They create their content themselves with JavaScript by using a web service written in CellScript on the WebCell as the source of data. The web service provides an interface to the WebCell scheduler, which tracks things like thermostat settings and irrigation times.</p> <p>With this rewrite I also recently completed a web page that for the first time provides access to a feature that the scheduler has had from the beginning – the ability to schedule a change of schedule. Here’s how I put it to use: </p> <p>I have thermostat schedules called “Home” and “Away”. The Home schedule changes the temperature setting each morning and evening; the Away schedule is basically set to turn the system off, with the heat set to 55° and the cooling set to 85°. I was leaving town for a week, but my son-in-law was staying at my house for an additional night, so I set the Away schedule to start at 8AM the next day. I also set the Home schedule to start in the morning on the day I get back. So now I get to save energy when nobody is in the house, but it will be a comfortable temperature when I return.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-25519107661756194102012-08-16T10:28:00.001-07:002012-08-16T10:28:47.917-07:00Is It a Product?<p>I recently made a revision to to the Development Kit PCB, and I’ve been testing out the revised prototypes. Everything is looking good so far. I didn’t need the circuit changes for my own use -– at worst, I could cut-and-jumper any of the PC boards I would want. This is the latest in a string of actions that only make sense if I turn the WebCell into a product.</p> <p>Earlier in the summer I spent a fair amount of time creating simple web pages to demonstrate the I/O capabilities of the WebCell. Then I started writing a manual (a scary big project!). None of these things are stuff I would need to do just to keep using it around the house, but I could chalk it up to keeping myself occupied.</p> <p>That changed when I decided to spend money on product development. Paying to have a new PCB fabricated and assembled is one example. I also upgraded my version of <a href="http://www.helpandmanual.com/" target="_blank">Help & Manual</a> to make writing the documentation easier.</p> <p>Yes, I would like to make the WebCell into a product if I can tackle all the hurdles. At this point I don’t know that I can, because what needs to be done isn’t what I’m good at. Writing documentation. Creating more web pages. Making the web pages I have look professional. Maybe I will find a contractor to help out (spending money again!).</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-35531546832315160512012-03-19T12:39:00.001-07:002012-03-19T12:40:29.306-07:00It’s About Time<p>I happened to check the time on the WebCell the other day and noticed it was running about 4 minutes fast. Currently the WebCell clock only sets itself (using a network time server) when it powers on, so that error would have accumulated over the few months since the last winter power outage. I guess it’s time to change that.</p> <p>Timekeeping on the WebCell originates with a 25 MHz crystal on the Ethernet chip. The Ethernet chip divides it by 4 to 6.25 MHz before sending it over to the AVR microcontroller. The AVR multiplies it by 5 to 31.25 MHz, very close to its max clock speed of 32 MHz. A counter in the AVR divides this by 62,500 resulting in 500 Hz, which is then used for all internal timekeeping.</p> <p>The crystal is supposed to be accurate to 50 parts per million, which can also viewed as one part per 20,000. Since there are 60 * 60 * 24 = 86,400 seconds per day, the crystal could have a max error of 86,400 / 20,000 = 4.32 seconds per day. Even resetting the time every day, that’s a little more error than I’d like to see.</p> <p>The number 2^16 = 65536 is a bit special in programming, and I chose it as the interval in seconds between resetting the clock. This works out to about 18 hours. Not only that, but if the clock is off by one second or more when it gets reset, the counter that puts out the 500 Hz gets its divisor adjusted by one tick. So if the clock was running fast, the counter will be adjusted to divide by 62,501. If the clock continues to show an error at subsequent resets, the divisor will continue to be adjusted, one tick at a time. Given the accuracy of the crystal, this adjustment shouldn’t get larger than 3 or 4 ticks off the nominal 62,500, and I’ve set a limit of 20. This adjustment is maintained in the (non-volatile) EEPROM so it won’t be lost on power failure.</p> <p>With that done, I decided to tackle another time issue that’s been bugging me. When I copy new web pages to the WebCell, the date/time stamp on the file is not copied with it. Instead, the new files are stamped with the current time. This can get pretty confusing when you look back and have to realize that a file time stamp on the WebCell that is <em>after</em> the file time stamp on the PC <em>probably</em> means they’re the same file.</p> <p>Fixing this required hitting work items at several different levels. First, my implementation of the FAT file system did not yet support setting a file time stamp to an arbitrary date/time. Next, because these files are transferred using FTP, I had to implement the FTP extension MFMT, which sets the time stamp on a file. Finally, I had to have the FTP client in the CellScript simulator use that FTP extension when it copied files.</p> <p>Fixing these time issues resolved all my immediate concerns for the WebCell itself, giving me some sense of completion.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-19667262084745324972011-11-23T22:13:00.001-08:002011-11-23T22:13:05.228-08:00Ready for Christmas<p>One of the jobs I want to hand over to the WebCell is turning the Christmas lights & decorations on and off. I’ve been using mechanical timers, which is fine until there’s a power outage and they fall behind.</p> <p>I spent three days last week creating the web pages needed to enter the Insteon control devices and the times to turn them on and off. It was very similar to the thermostat pages and I used them as a starting point. All the underlying scheduling features of the WebCell were supposed to ready, but one of the days was spent debugging new bugs the pages exposed.</p> <p>I wasn’t satisfied when I was done, because I was still skipping over one of the last unimplemented features in the CellScript specification: the ability to schedule relative to sunrise and sunset. It made a lot of sense to do this now, since I would want the lights to go on about sunset. So I attacked that problem this week.</p> <p>I did a web search to find the equations, and used a spreadsheet to enter test values and see all the intermediate values. The equations use a lot of trig functions, but they’re all in the C runtime library for the AVR. It took two days to get “sun-based” scheduling fully implemented, and one more day to rework the scheduling web page to accept entries. I put one set of decorations on a sunset-to-midnight schedule so I can watch and make sure it seems to be working right.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-39746942052623572422011-11-04T14:59:00.001-07:002011-11-04T14:59:22.187-07:00Time to Fix the DST Bug<p>I haven’t done any work on the WebCell since August when it took over my thermostat schedule. But Daylight Savings Time ends in a few days, so I thought I should fix a bug in the code that handles it.</p> <p>I didn’t test it, but I’m pretty sure the simple way the WebCell was figuring the end of Daylight Time would behave badly. I suspect it would have spent an hour ping-ponging back and forth between Daylight and Standard Time. You can see how it would happen: at 2:00 AM it sets the clock back to 1:00 AM; then it decides Daylight Time isn’t over for another hour and sets it back to 2:00 AM, etc.</p> <p>The fix wasn’t hard – just do everything in Standard Time. Instead of Daylight Time ending at 2:00 AM Daylight Time, it ends at 1:00 AM Standard Time. All fixed. (Internally, time is kept in UTC [GMT] with time zone adjustment added to get Standard Time.)</p> <p>All the parameters of Daylight Time can be changed in CellScript code, but up till now I hadn’t created a user interface to do it. I spent more time on the web page to view and edit Daylight Time settings than I did fixing the bug.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-34715941103675411762011-09-22T18:48:00.001-07:002011-09-22T18:48:59.965-07:00The Scheduler<p>When I started this project, I envisioned the WebCell as the user interface, via web pages, for otherwise self-contained home automation devices. For example, the WebCell might pass on to a thermostat a list of temperatures and times that the user had entered, and the thermostat would handle it, even if the WebCell was subsequently disconnected. In practice, however, the devices I’ve encountered need more supervision – they need a controller to maintain the schedule.</p> <p>In January 2011, I started the design of the CellScript scheduler. I wanted total flexibility, and used the calendar feature of Microsoft Outlook as a guide for creating recurring schedules. The plan made its way into the CellScript Language Reference, and from there the coding began. By the end of February, the scheduler successfully “fired an event” on time – simulated, of course.</p> <p>In March I felt the scheduler was in pretty good shape. It was time to write the web pages that would collect the settings and feed them into the scheduler. To help with this I took a class at the nearby community college in cascading style sheets (CSS), which is all about making web pages look the way you want them to. </p> <p>Still I found writing the web pages to be a major challenge. The pages all use <a href="http://en.wikipedia.org/wiki/Ajax_(programming)" target="_blank">AJAX</a> techniques and <a href="https://developer.yahoo.com/yui/3/" target="_blank">YUI 3</a> to make them as easy to use as possible. I was creating these pages to work with an <a href="http://www.smarthome.com/31270/INSTEON-8-Zone-Sprinkler-Controller-Lawn-Irrigation-System/p.aspx" target="_blank">Insteon irrigation controller</a> and a pair of <a href="http://www.smarthome.com/2491T1/Venstar-Thermostat-INSTEON-Remote-Control-Thermostat-1-Day-Programmable/p.aspx" target="_blank">Insteon thermostats</a> (for two separate furnaces in my house). For each system I had a setup page (irrigation zones, for example), and then a settings page (such as watering time for each zone and watering schedule).</p> <p>My priority was the irrigation system, because I’d already wired in the Insteon controller. Fortunately we had a very cool and wet spring in Western Washington, giving me more time to get the irrigation pages ready. In late May the WebCell succeeded in starting an irrigation cycle on schedule, which turned out to be about two weeks to spare.</p> <p>The push to get irrigation running on the WebCell gave me my first real experience with CellScript (as opposed to writing test cases). I did some tweaking and bug fixing before returning to the next set of web pages, for the thermostats. On August 13, 2011, the WebCell took control of the thermostat schedule. Program size is now at 83,464 bytes. And I will be taking a break from WebCell development for a while!</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-79551840897741883582011-09-22T18:41:00.001-07:002011-09-22T18:41:17.532-07:00Slow Progress on the List<p>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 <a href="http://en.wikipedia.org/wiki/Analog-to-digital_converter" target="_blank">ADC</a>, <a href="http://en.wikipedia.org/wiki/Digital-to-analog_converter" target="_blank">DAC</a>, <a href="http://en.wikipedia.org/wiki/Pulse-width_modulation" target="_blank">PWM</a>, 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.</p> <p>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 <a href="http://en.wikipedia.org/wiki/Dhcp" target="_blank">DHCP network protocol</a>, storing important data in the internal non-volatile memory (EEPROM), adding “<a href="http://en.wikipedia.org/wiki/MIME_types" target="_blank">MIME types</a>” to web pages – and fixing lots and lots of bugs.</p> <p>The WebCell has several ways to communicate with the outside world besides Ethernet, including three serial ports, an <a href="http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus" target="_blank">SPI (Serial Peripheral Interface) port</a>, and an <a href="http://en.wikipedia.org/wiki/I2c" target="_blank">I2C (Inter-Integrated Circuit) port</a>. “The list” has just a few functions and properties that CellScript needs to utilize these ports – things like <strong>read(), write()</strong>, and <strong>bitRate</strong>. 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.</p> <p>In September I started creating web pages designed to demonstrate and test hardware features. In the process I looked into <a href="https://developer.yahoo.com/yui/3/" target="_blank">YUI, the Yahoo! User Interface</a>. 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 <a href="http://en.wikipedia.org/wiki/Ajax_(programming)" target="_blank">AJAX</a> (asynchronous JavaScript and XML).</p> <p>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.</p> <p>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. </p> <p>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.</p> <p>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.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-18409862333985246152011-09-01T15:17:00.001-07:002011-09-22T14:15:47.448-07:00Final Hardware Design<p>In early 2008 Atmel announced a whole new line of microcontrollers called XMEGA that sounded pretty interesting. Compared to the existing ATmega line, they offer much higher performance and much more capability, all at around the same price or less.</p> <p>As a new product, availability is an issue. I originally placed an order when they first showed up in my distributor’s catalog in September 2008, and just let it ride on backorder. The order was eventually cancelled because that specific part (ATxmega64A4) was never produced. A year later I did get my hands on one of the top-of-the-line XMEGA chips, the ATxmega256A3. This was not the chip I would use for my final hardware design, but it did give me a chance to test it out.</p> <p>The XMEGA family is only available in surface mount (SMD) packages, so I mounted mine onto a DIP adapter. Then I put it on my solderless breadboard in place of the ATmega324P, wired up to an SD memory card socket and serial port. By the end of September 2009 I had my “mini-DOS” FAT/SD test program working on it.</p> <p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEihPWOWnQYB5skDb1pm29q0uFQHhwFTK28kbYNS1aLbDacF4vo8Ggk7t8AdX_Q7tYBu8Y3JIYw1MWatpDHDFzZacwt_LQJeyLfjtijOHB2vNkaoTC9Fo6P92UrDZewrwkrR6lqcMwsFH755/s1600-h/SdBreadboard%25255B1%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="SdBreadboard" border="0" alt="SdBreadboard" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgdBEYCl2opinbsWRygqOhyI1M1ZibNcKxLdil0UvQwMNG3mnmVV9xrYUN32Qg3vTj9JDPzCdMxEUFh8iVhCG9NcI1sZ0G1tMgJTmTxrjtAQz-wWraJy8mMgTVOaGkRFrtOSJC2fsrje8Na/?imgmax=800" width="500" height="744"></a><em><br><strong>SD Card Breadboard with XMEGA.</strong> Parts include a small 3.3V regulator, reset button, and simple RS-232 serial interface just using a 74AC04 inverter.</em></p> <p>Also in September I started work on the hardware design for the “production” WebCell, using the ATxmega128A3. I had never used either of the radio circuits on the engineering prototype, so I decided to leave them out. In the home automation application I envisioned, the WebCell would have to connect to some other device. I had experimented with Insteon products so I knew the WebCell could be hooked up to control their devices, for example.</p> <p>In November I finished the layout of the WebCell PCB. Next I started design of the “Development Kit”. This is another PCB that the WebCell can plug into that makes it easy to try out. For example, it powers the WebCell from USB, provides a serial connector, and includes a reset button.</p> <p>I also designed a variation of the WebCell that I call the FileCell. This variation removes the network interface and replaces it with a USB port and battery backup. So instead of being a web server, it is more of a general-purpose controller module. It could be particularly useful for data logging because of the high storage capacity available on the microSD card. I wasn’t sure if I would ever build this variation, but I wanted to explore how it would be different from the WebCell so I could make sure the Development Kit would work with both. Because of the battery backup, I did end up changing some of the interface connector pins on the WebCell.</p> <p>I had to order samples of various parts to decide which ones I wanted to use and how they would fit. I finally placed orders for production prototype PCBs on January 21, 2010. I had been planning to get PCBs for all three designs, but in the end I saw no reason to build the FileCell variation yet.</p> <p>The PCBs arrived on February 8. I took them and a kit of parts to my local electronics assembly company, <a href="http://www.pcacorporation.com/" target="_blank">Printed Circuits Assembly</a>. Both boards use chips in leadless (QFN) packages, which are really hard to solder by hand. I got the assembled units back about a week later.</p> <p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnAnsDGDhsiW3So31qY83Uxb-OvuSJ-70pAz_vrnXn1AYt5lDju9g2hK0ryipOhCEd71rmqMJEnUWoYvXCAmIRGI_V_3suEfbs7iMaghaKo4-dd-DXPS-cinfi4ihs-VbYMOouJVY9RPvy/s1600-h/WebCellOnDevKit%25255B7%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="WebCellOnDevKit" border="0" alt="WebCellOnDevKit" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj-z-oU8frpOaU457FoC_nEhzicvmqr5oMD0lROLEs6TVMcoYnuKu1a6gTh_x-QGKPzm4en6OeeHyyQOyocaeadnf73gfn66I0Qtcvh6xSqtkEYEH3C-0uEnzX-yHX676ec1EXhj3zARsrq/?imgmax=800" width="500" height="317"></a><br><em><strong>WebCell on DevKit.</strong> Blue jumper wires correct some PCB layout errors, and provide test points to internal circuitry. Long tails on board-to-board connector were useful as additional test points. Micro USB connector for power is in lower right corner.</em></p> <p>It took a few weeks to get the software ready for the production prototype and to get the prototype working. The final hitch was an error in the wiring of the Ethernet jack, requiring cuts and jumpers of the PCB traces. Once that was fixed, on February 28, 2010, the prototype began serving up web pages.</p> <p>During the wait for assembly, my work on the WebCell software started bumping up against the 64K program limit of the engineering prototype. The production prototype with its 128K program size came just in time to keep me working.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-55148074230888814332011-08-31T10:00:00.001-07:002011-08-31T10:08:03.542-07:00WebCell Script File Updates<p>I spent the spring of 2009 working on my implementation of the FAT file system. A year earlier I had it reading files from an SD card, but now I wanted it to write to the SD card. Before the start of summer I had the essentials working – creating folders, creating files, and writing data to files.</p> <p>This gave me the opportunity to relieve a long-standing annoyance. Up to now, when I wanted to test a new or updated script on the WebCell, it took a few steps:</p> <ul> <li>Remove the microSD card from the WebCell. <li>Put the microSD card in an SD adapter. <li>Plug the SD adapter into an SD slot on my monitor. <li>Copy the test script from the PC to the microSD card. <li>“Eject” the microSD card. <li>Remove the SD adapter from the monitor. <li>Move the microSD card from the adapter back to the WebCell.</li></ul> <p>Now that the WebCell could write files itself, this process could be eliminated by sending the file to the WebCell over the network connection. And the way to do that was with FTP – File Transfer Protocol. I set to work on the implementation.</p> <p>On July 9, 2009, I used FTP on Windows Explorer to copy a test script from the PC to the WebCell. This was a satisfying if not momentous milestone. Program size on the WebCell with FTP completed was at 55,510 bytes out of the 65,536 bytes available.</p> <p>With the WebCell receiving files by FTP, I felt obligated to add an FTP client to the CellScript simulator. The simulator allowed me to edit scripts, so it just seemed wrong if it couldn’t send those updated scripts on to the WebCell. </p> <p>Unfortunately, this would mean a lot work to do on the simulator. The simulator was written in C++ so it could share the code for CellScript with the WebCell. But I really missed the very elegant and refined environment that came with programming in Microsoft’s C# programming language. I decided I wasn’t going to take it anymore. </p> <p>I split the simulator in two: a module in C++ that carried the shared CellScript code, and a module in C# that handled the user interface through Windows. Once I found out how easy it was to get the two modules to talk to each other, I was kicking myself for not doing it this way in the first place. The split and translation of the UI from C++ to C# took about a week. </p> <p>Once the new simulator was working the same as before the split, I started the job of adding FTP. I created a “File Manager” similar to a stripped-down Windows Explorer. But it tracked both script files on the PC used for the simulator, and files on the WebCell using FTP. It then presented them in an integrated list showing what files were different between the two. The finishing touch was that it would monitor when changes were made to simulator script files, and could automatically copy them to the WebCell immediately.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-31597941952909079972011-08-26T11:49:00.001-07:002011-08-31T09:54:33.831-07:00Just What is CellScript?<p>I had jumped in and started implementing CellScript using a book on JavaScript I’d bought and the ECMAScript Language Specification Edition 3 as my guides. But after I had some of the basic language features working, I needed to give myself more concrete direction – it was time to define just what would be in CellScript.</p> <p>First of all, CellScript is only a small subset of JavaScript. All I wanted were the basic features that any programming language has: evaluating expressions, conditional (“if”) statements, looping constructs, etc. I didn’t want to try to implement any of the special features of JavaScript. I needed to draw the line at what was in and what was out.</p> <p>Second, CellScript needs to extend JavaScript so it can access and control features of the WebCell. This is done by adding “host objects”, such as the Net object for dealing with the network interface or the File object for managing files on the SD card.</p> <p>In late February 2009 I created the CellScript Language Reference. My productivity had started to lag as I paused each time I finished a feature to figure out what was next – or worse, spun my wheels. Once the spec was written, I was able to charge ahead.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-13531163284941526292011-08-18T23:42:00.001-07:002011-08-18T23:42:57.605-07:00CellScript and the Simulator<p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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).</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-30712582087434476222011-08-14T17:25:00.001-07:002011-08-14T17:25:50.173-07:00Interface to an SD Card<p>In February 2008 I started a related project: interfacing an AVR to an SD memory card. I was using an ATmega324P MCU on a solderless breadboard. It was wired to an SD card “breakout board” from <a href="http://www.sparkfun.com/" target="_blank">SparkFun Electronics</a>, and a serial port for connecting to a PC running HyperTerminal.</p> <p>It didn’t take long to get basic communication with the SD card working, but to make sense of the card contents I had to implement the FAT file system. The idea of doing this was an interesting flashback, since I wrote the original FAT12 file system in 8086 assembly language almost 30 years ago. Now I was using the published Microsoft specification to implement FAT12, FAT16, FAT32, and long file names, thankfully in C++ rather than assembly language.</p> <p>In March I was working (at least some) on the FAT file system almost every day. By the end of the month I had sort of a mini DOS command prompt working, with commands like DIR, CD, and TYPE. I hadn’t attempted to write to the SD card yet.</p> <p>I didn’t get much more done until June, when I started pushing harder on the AVR network software. I hadn’t worked on this since last August, so some reviewing was necessary to get back into the swing of things. But by the end of the month I had the “Easy Ethernet AVR” module successfully serving up a minimal web page to my PC. The module does not have an SD card (or any other storage), so there was no real content, but it demonstrated success with IP, TCP, and HTTP network protocols.</p> <p>I needed hardware that combined Ethernet and SD Card, and I set about designing it in July. This design included sockets for both a standard SD Card and a microSD card. My vision for this project was that it would be a home automation controller, communicating by <a href="http://www.zigbee.org/" target="_blank">ZigBee</a> radio to other devices around the house. To that end, my engineering prototype included two radio systems: a socket for a MaxStream (now <a href="http://www.digi.com/" target="_blank">Digi</a>) XBee radio module, and a radio circuit built around the Atmel AT86RF231 ZigBee-compatible transceiver chip. I also switched to a smaller and simpler Ethernet controller chip, the Microchip ENC28J60.</p> <p>With the design complete and printed circuit board (PCB) laid out, I ordered boards from <a href="http://pcbfabexpress.com/" target="_blank">PCB Fab Express</a> on August 1st. While they were in process I improved my SD card & FAT file system software so it could write to the card as well as read it, which didn’t take long. I also revised the software so it will work with new hardware, including drivers for the alternate Ethernet chip I was using. And of course I ordered the parts I’d need, from my favorite distributor, <a href="http://www.digikey.com/" target="_blank">Digi-Key</a>.</p> <p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhN5QIRLoTfhxoKdVi3FMot2ybSAScl46HHzhz7bbHDqy_XvWnc6MASPlTGYR7eA0NlXrhXzrQ2NBC9dn44Ezww7BeAntR5VAA7dXHROh8mHB3ZhDV9uvzuu5YlboBGilU2DiFr511Zi-_N/s1600-h/EngProto%25255B4%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="EngProto" border="0" alt="EngProto" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi9g0eQBOYRLK5sK4yI-cJNoKMhAW6ywLf5uAEfmEAoj5nwrLNDHp_Bcir4HVM-tz2tgOGdZ8b9Q0t0ziEOtzPqvFEYFoCy0Rcs9u6rqCtR52C3PoAM6MUBAMU0Kf76kBl-tvu6py16y3CY/?imgmax=800" width="500" height="654"></a><br><em><strong>Engineering Prototype.</strong> At upper left is the discrete radio circuit, without the antenna jack installed. Below that is the socket for the XBee radio module. At right middle is an ATmega644P MCU. The first unit was built with the pin-compatible ATmega324P, but the program grew beyond its 32K program size limit.</em></p> <p>The prototype boards arrived in about three weeks, and I assembled one right away. Within a few days I had it serving up a fake web page (not yet reading it from the SD card). The network protocol analyzer <a href="http://www.wireshark.org/" target="_blank">WireShark</a> proved invaluable in getting this working. A few weeks later, on September 11, 2008, the prototype was serving up web pages from the SD card on request – a major milestone.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0tag:blogger.com,1999:blog-2452601010173735559.post-79814229778734077322011-08-13T10:49:00.000-07:002011-08-13T16:29:19.311-07:00Development of the WebCell Begins<p>On April 20, 2007 I started my project to make a web server based on an Atmel AVR microcontroller. Let me start catching up on this story.</p> <p>The idea that it was possible to build a web server around a microcontroller unit (MCU) came from a series of articles written by Peter Best that appeared in <em>Nuts and Volts</em> magazine in 2006. These articles discussed network protocols, and also led me to <a href="http://www.edtp.com/" target="_blank">EDTP Electronics</a> and their “Easy Ethernet” modules for experimenters.</p> <p>The “Easy Ethernet” line was available with either a Microchip PIC or Atmel AVR MCU. I had used the PIC in the distant past, but switched to the AVR once I heard about it – I consider it vastly superior. So my module has the Atmel ATmega16 MCU, which has 16K of program space and 1K of RAM. The Ethernet chip on the module is the Realtek RTL8019AS.</p> <p align="center"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgECsAPBQXl3xt4g_ptzQZD1lqYazC_6DhYZz7QNNmGApnfxcqVQE3QQvYXgYmM5xxryhmBF7IuTn9UjYTHXAtrCqEazSDxNTDef5GSW6qyOOYMDKQ25h4AOrFtH_q_TKsG0FD6xbXSJ-P4/s1600-h/EDTP16.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="EDTP" border="0" alt="EDTP" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdWqMM7Xn_5dgJIXQmep4yJJM1NVuqFo2sFl0aA188byuiKB4s-R_YIau_zBMe-nol6tXFWiKNWuNivocbpXitP_XL7mYCQxtagGgim57anx7-LF-9ckfpNpjsrnF3klxlYN_8302i3fn8/?imgmax=800" width="500" height="529"></a><br><em><strong>Easy Ethernet AVR module from EDTP Electronics.</strong> The shiny block at the upper left is the Ethernet jack. Strangely, the module did not come with a connector for Atmel’s standard debugging interface (JTAG), so I had to patch into the correct pins using the “squid”.</em></p> <p>I spent about seven days working on the project over the next six weeks. I was writing basic drivers for the Ethernet chip and implementing the Address Resolution Protocol (ARP) as my first test. On June 3rd I hit my first milestone, verifying for the first time the module could send and receive Ethernet frames: it successfully made an ARP request and read the response.</p> <p>I continued to work on the project a little on and off until later that summer, when I dropped it to do other things.</p> Tim Patersonhttp://www.blogger.com/profile/10420105718052222890noreply@blogger.com0