As devices are increasingly more networked, an embedded web server is becoming a standard way for users to interact with and configure an embedded device using a standard web browser. As an example, most pieces of networking equipment (such as routers and wireless access points) are configured this way. There are many ways to implement a web server. One way is to just write a monolithic program that handles the requests and outputs HTML using print statements. Without a lot of planning, you usually end up with something where logic is intermixed with presentation. The disadvantage of such an approach is that it quickly becomes very difficult to maintain your web application as it grows and changes. The current best practice with web application frameworks (such as Ruby on Rails) splits a web application into 3 distinct components (Model, View, Controller -- MVC) so that changes to one component can be made with minimal impact to others. This article details a solution used in a recent project to implement such an architecture using the following open source components: SQLite, Clearsilver, and Python. The challenge was to find a solution that performed acceptably on a resource constrained 130MHz ARM-Linux system.

Interfacing with a RS232 serial device is a common task when using Python in embedded applications. The easiest way to get python talking to serial ports is use the pyserial project found at http://pyserial.sourceforge.net/. This module works on most platforms and is straightforward to use (see examples on project web site). However, getting the read function in this module to operate in an optimal way takes a little study and thought. This article investigates how the pyserial module works, possible issues you might encounter, and how to optimize serial reads.

Some time ago, eWeek published in interesting article by Scott McNealy named "Technology's Barriers to Exit" (http://www.eweek.com/article2/0,1895,1907211,00.asp). In this article, Scott makes an interesting point about considering the cost of technology. There are three costs to consider:

• cost of acquisition
• ongoing cost
• cost to exit
  

Scott states that most people analyze the first two costs fairly well. What is not thought about as much is the the cost to exit -- how do I move on to the next thing. I think these basic questions apply very much to embedded technology decisions.

Over the past month, we have been working on implementing Asterisk in our office. Asterisk (http://www.asterisk.org/ ) is a complete software PBX (Private Branch Exchange) that runs on top of Linux. Asterisk supports a number of features commonly found in a PBX including voicemail, hosted conferencing, call queuing, and many other features. Having a real PBX provides many benefits for a business and has the potential to improve our service and lower our costs. Over the next couple months we will be writing about our experiences implementing Asterisk, tips for setting it up etc.

In our quest to implement an Asterisk PBX in our office, we are evaluating several VOIP (Voice Over IP) providers. VOIP provides several benefits over traditional phone lines including:

• low cost (typically around $0.02 per minute)
• available in pre-paid plans
• can support concurrent concurrent calls on the same number
  

However, implementing VOIP successfully is not trivial. You must have a reliable internet connection and we have found you must implement some type of Quality of Service (QoS) in the router. The first problem I ran into was calls sounded great to me, but people I called mentioned the calls sometimes sounded garbled to them. This article discusses the diagnosis of this problem and how to implement QoS in a Linksys router to fix this issue.