nerd1951.com

Well, I’m flip-flopping on the Cannonball project but since I’m not a politician that’s ok.  I started looking around at open source requirements management packages and found one that seems very complete and has a web interface.  It’s called OSRMT (for Open Source Requirements Management Tool).  It is written in Java and uses the JDBC interface for database functions so I can run the package on Linux using MySQL.  I’d much rather spend some time installing and learning this package before I go any further with development.  If this package works out I’ll even suggest using it on my day job.

OSRMT is a complex software package and I’m not sure if I’m going to actually host it on my web server or not.  I may just install OSRMT locally and use it to generate requirements documents in HTML which I’ll post here.  Either way I want to do a local install and learn more about how it works so there may be yet another delay in posting the requirements.  Gee, this is starting to sound like a real project.

The other flip-flop is that I’ve decided for the Cannonball release that I’m going to use the ARM AME-51 Evaluation Kit that I had originally planned to use as a target.  I already have that system up and running and I’m anxious to get into design and coding.  I’ll deal with the complications of setting up another target and development environment for the second release.

Someone who calls himself zzyzxr left a comment for the post, TCP/IP Protocol Stack Project – Continued, suggesting that I explore implementing TCP/IP in an FPGA.  The point of the project is to show how to program a serious real-time application in object oriented C++ but zzyxxr is right about one thing.  If you are designing a networking product or any kind of embedded system you need to do a careful hardware/software trade-off analysis; a step that is often skipped in the design process.  It’s possible that a software application that requires a fast 32 bit RISC processor and gobs of Double Data Rate RAM could be implemented in a twenty dollar FPGA and an eight bit microcontroller.

That’s why I’m studying Verilog, a popular hardware description language.  I’ve done logic design in the past using a language called ABEL but that’s the equivelent of assembly language compared to a hardware description language like Verilog.  I don’t plan on becoming a logic designer though I wouldn’t mind pinch-hitting in this capacity once in a while.  My goal is to understand when programmable logic is a better solution to a problem than embedded software is.  This is my responsibility if I call myself a systems architect.  The only way for me to really be able to do these critical tradeoffs is for me to roll up my sleeves and dig into the tools that logic designers use.  This way I can understand the strengths and limitations of the logic design process and I’ll be equipped to make decisions about what should be done in programmable logic vs. what should be done in embedded software.

The first thing that I learned is that Verilog books are expensive but there are many tutorials on the web.  If you just Google Verilog, you’ll find a whole gaggle of tutorials.  One of my co-workers, a very bright and helpful hardware engineer pointed me to Icarus Verilog, a Verilog simulation and synthesis tool.  The simulation tool is more important than synthesis when learning logic design and debugging your code since you can see all the internal nodes of your design.  It’s hard to probe the inside of an FPGA to see what’s going on.

And thanks to zzyzxr for reminding me that there is more than one way to skin a cat.

With the Cable companies and the phone companies providing bundled broadband access and VOIP services it seems there should be a bundled device to take advantage of these services.  This device would be the next generation of Small Office/Home Office (SOHO) Integrated Access Device (IAD).  I’m thinking of a simple looking box like the LinkSys or D-Link wireless routers.  The device would integrate a WAN port, four or eight LAN ports, and four or eight phone ports.  The phone ports would be compatible with any old cheap phone.  The trick would be to build this box cheap enough so that it sells for less than the price of a couple of IP phones.

Digging deeper into the technical details, the product integrates a router, firewall, VOIP signaling and phone interfaces.  Integrating the router in the same device as the phone interfaces provides some important advantages.  First of all it solves the problem with running the Session Initiation Protocol (SIP) over Network Address Translation (NAT), a common firewall function.  Since the firewall, router, and VOIP functions are all integrated into the same device, the SIP protocol can just bypass the NAT function of the firewall.  Another advantage is that the router can throttle the Internet traffic down to give priority to the VOIP traffic when necessary.  Your Web surfing slows down but the phone doesn’t get garbled.

How would I implement this product?  First of all I would use one of Freescale’s PowerQUICC processors.  I’m a big fan of this product family and have used it in a number of products.  The advantage of this part is that you can get two fast Ethernet ports and a TDM interface all on one chip with a very powerful PowerPC processor.  The TDM interface is what you need to connect the phone interface circuits, known as CODECs.  For the CODECs, I like Infineon’s DuSLIC family.  These parts contain two phone ports that include ringing functions, DTMF transmitters and receivers and caller ID functions.

There are two business models I can think of for building and selling this product.  First there is the traditional venture-funded startup company.  You go out and convince some VCs to put up a couple of million dollars.  Sign non-disclosure agreements with the chip manufacturers to get access to their newest silicon before everyone else.  Then land a distribution agreement with a large phone company or cable company, work like hell for two or three years and get rich, maybe.  Many of us have been there, done that, and don’t have much to show for it except some company logo polo shirts.  Besides I think its a bit late to go up against companies like D-Link and LinkSys with something this obvious.

The other business model that I think is more interesting is to build a board like this with minimal investment and commonly available parts.  Completely embrace open source software; Linux and the Asterisk open source PBX.  You have several income streams.  You sell the hardware to OEMs and tech-savvy end users, provide training classes on customizing the software, and provide consulting services to OEMs, customizing both the hardware and the software.  You won’t make a fortune like this but it might be a fun way to make a good living.

I received my LinkSys WRT54GL router this week and took it apart to see how difficult it will be to add connectors for the serial interfaces and the JTAG debug port.  I plan to mount the router’s circuit board on a piece of Plexiglas or sheet metal along with connectors for the serial ports to make it more convenient to use as a development target.

I updated the Cannonball Specification a bit.  In the process I found that many of the IEEE standards for Local and Metropolitan Area Networks (LAN/MAN) are available for free download from the Get IEEE 802® Program.  The list of freely available standards includes the IEEE 802.3 series for Ethernet like LANs from 10 Mb/s up to 10 Gb/s and the IEEE 802.11 series for wireless LANs.

When developing networking products it’s easy to become so focused on getting the data path working that other important system features are ignored.  I discussed this in terms of element management in a previous rant: Network Product Specifications.

Now I want to talk about system state.  System state, especially in a redundant non-stop network core product, can become a complex design problem.  If the system state is not planned for and designed early, it can have repercussions in nearly every piece of software in the system.

In a redundant system, the redundant components have at least three states: Online, Standby, and Failed; pretty obvious.  But it can be much more complicated.  What about factory settings and calibration?  Often there are system parameters that are set only when a component is manufactured or repaired; settings such as MAC address, hardware and software version numbers, etc.  Then there is a maintenance state that allows an offline component to be looped back or send and receive data patterns to measure signal quality or Bit Error Rate.  Finally there may be an installation or provisioning state, used when equipment is first installed in a network.  The provisioning state might be needed to for configuring IP addresses or subnets, etc.

The important thing is to think about system state before writing any code.  You need to understand which software subsystems will be effected, how each subsystem will behave in each state, and what conditions will trigger the transition from one system state to another.

My list is not comprehensive but here is a list of states to consider that I mentioned in this discussion:

1. Factory or Manufactoring
2. Installation or Provisioning
3. Maintenance or Test
4. Standby
5. Failed
6. Online or Operational

Oh! and one more I often forget to mention Built-in-self-test or  diagnostic state for trouble shooting failed boards at a repair facility.

I’ve decided to use WordPress to capture the Cannonball release specification. WordPress provides many of the features that I want to capture requirements in a database. WordPress provides hierarchical list of categories that can be used to group related requirements. I’ll enter each requirement as a BLOG entry. Over time I plan to work on the PHP scripts that display the information to make it look more like a software specification.

A major change to the Cannonball TCP/IP release; I’ve decided to build it for a different hardware architecture..  It really is better to make these decisions while writing the specs rather than waiting until the code is almost done. ;-)  I’ve decided to use the Linksys WRT54GL wireless router as my development target.  The price is hard to beat at under $70.00 and since the WRT54GL has Ethernet interfaces I’ll skip the PPP development for now. The Linksys WRT54G made history as the first product where a manufacturer was forced to release the source code under the GPL.  The original embedded software was built on a Linux Kernel and the custom drivers for the router’s hardware were considered kernel modifications. 

The OpenWrt project has developed embedded software for the WRT54G directly from the Linux Kernel source. I don’t plan to use the Linux kernel or any of it’s source code in Cannonball but the Linux drivers from the OpenWrt project should provide enough guidance for me to understand the hardware interfaces.  I also plan to use the development tools from the OpenWrt project.

The WRT54GL is built around a Broadcom BCM5352EL which includes a MIPS processor, an IEEE 802.11b/g MAC and a five port Fast Ethernet switch.  There are two serial ports and a JTAG interface but the connectors for these are not populated.  The JTAG is supposed to work with a Wiggler probe for debugging. So developing software for the Linksys WRT54GL is much more of a do-it-yourself project than using an evaluation board but I’ll have much greater functionality when I’m done for much less money.  I can also set up these routers as traffic generators and I can afford to set up an entire test network.

I found myself twiddling with HTML and CSS far too much while starting the Cannonball Specification.  So, I’ve decided to take a little detour and develop a little web app to capture the specification in a MySQL database.  I will then use PHP to format the specification document.  This is the same approach that Wordpress, my BLOG software uses. This is one of the advantages of doing a software project just for fun.  I can change direction as I feel necessary in order to produce a quality product.

There are a number of advantages to capturing requirements in a database.  The software/system documents can be formatted in a number of ways; as a specification, a test plan document, or integrated into a software design document for requirements tracking.  It is also easier to re-use the requirements when developing specifications for new releases or upgrades to a software package.  I don’t intend to have a bunch of bells and whistles initially.  Like the TCP/IP stack itself, I’ll start out with the minimum functionality to meet my immediate needs then grow the package as I need to.  I’ll also post the source code in case anyone else might find it useful.

In keeping with the railroad theme I’m calling this package Siding.  A Siding is a length of track off of the main line.  One of the uses for sidings is for slower trains to pull off of the main track to let a faster or higher priority train pass; kind of like a little detour.

I’ve started writing the Specification for the Cannonball Release of my TCP/IP protocol stack. The only real meat in the specification so far is the license and the detailed specification for the PPP link layer.

The license that I chose is the Artistic License, Similar to the Perl Artistic License. This is an Open Source Initiative approved open source license. One important feature of this license is provision 8:

8.Aggregation of this Package with a commercial distribution is always permitted provided that the use of this Package is embedded; that is, when no overt attempt is made to make this Package’s interfaces visible to the end user of the commercial distribution. Such use shall not be construed as a distribution of this Package.

This essentially allows you to distribute this software as part of an embedded system without having to share any source code or even acknowledge that there is open source software in your product. This is the only type of open source license that makes sense for software that becomes part of an embedded system. Most people don’t really care or even understand if their IP phone or Web enabled audio gear uses open source software as a component.

As I was saying, the only real meat in the specification so far is the PPP link layer section. A couple of things to note about this; first, the specification is brief, complete and unambiguous because it relies heavily on existing standards documents and second, the specification for the management interfaces is twice as long as the specification for the data path.

It takes less time to write a specification that cites existing standards. The important goal of this exercise is that it forces the implementer to read and understand the standards that are cited. It’s best if the implementer is the same person who is writing the specification because they will have a thorough understanding of the standards before writing any code.

I was being a bit optimistic thinking that I’d have this completed in a couple of days. With my current work load from my day job, it may take me a week to have the complete specification done.

In his BLOG On Target: Embedded Systems, Chris Lanfear has a good overview of the vendors and products that were on view at the Embedded Systems Conference in September.

I was impressed by who was not there.  My impression of the conference based on the vendors that were there and those that were noticeably absent was that the vendors seemed to be aimed more at the systems integrator market than companies that develop commercial products from scratch.  Many of the vendors had board level products and systems specifically designed for military applications.

The largest chip makers’ booths were Intel and AMD who have overtly moved to get out of the embedded processor market and whose primary markets are desktop computers and servers.  Noticeably absent was Freescale Semiconductor whose MCORE and PowerPC processors and Codewarrior development tools are widely used in the embedded systems market and whose  PopwerPC based microprocessors dominate the datacom and telecom markets.

I was also surprised that Windriver did not have a booth.  For many years they have been one of the largest RTOS and development tool vendors in embedded systems.

I’m don’t know if the absence of these major players says more about the embedded systems community on the east coast or about the financial state of the companies that support the embedded systems community.

On the other hand Freescale and Windriver are jointly presenting a Seminar to announce Windriver’s support for Frescale’s new multicore Power PC, the MPC8572.  The seminar is being presented in Austin, TX on October 10 and in San Jose, CA on November 7.  No East Coast venue.  Hmm, I wonder what that’s all about?