Issue 145 August 2002
The Open-Source HCS Project

---

GOALS

The initial goal is to provide support for the existing user base. So far, we’ve managed to get all of the software for the HCS II SC (ROM images, host, and compile). The group is now working on getting the ROM images for the original COMM-Links. We have the source code for a few of them and need to compile them. Mike Baptiste (www.cc-concepts.com) was kind enough to turn his entire library of PIC-based COMM-Links into open source. We’re also working on posting the hex files to Mike’s COMM-Links and creating new PIC-based modules to use his code.

One of the major stumbling blocks is the host software. It was originally written to run under DOS. This works well for Linux using a DOS emulator (and 16,550 UART serial ports) and Windows (up to ’98). But for later releases of Windows, the host software fails because the OS will not give it direct access to the serial ports. I’ve got bits and pieces of Perl/TK code, which I’m hoping to put together into a program called tkhost. This program should be portable between Windows and Linux, which would allow a larger base of users to get involved.

In addition to the current support, we have plans for the future. Currently, there are plans for another Zilog-based controller that we’re calling the HCS II.V. It’s more advanced, faster, and much more expandable than the current HCS II. A few of the developers have started working on the HCS III, which was an idea that Mike Baptiste put forth last year. Mike’s idea is based on Rabbit Semiconductor’s development kits.

Both of these projects will support the current Express code and COMM-Link modules. The group is also putting together plans for an Ethernet and a second generation of faster COMM-Links.

CHOICES

I’m sure you have a lot of questions as to why we did what we did. Without going into minute detail (join the Local.cci.hcs2 newsgroup for the exact details), here are some of our decisions and the reasons why.

The first thing we needed was a license that would allow sharing of the code without abusing the code. We read through about 20 different licenses, and after some discussion (and watery eyes) concluded that the GPL was the appropriate license. Other licenses were too specific to their projects, too loose in their control, or just did not apply to what we were doing. We decided right away that writing our own license was not an option. After all, we’re engineers not lawyers.

We then proceeded to easier things such as deciding on future enhancements and a possible HCS SC module. The future SC processor has been brought up several times since then and I cringe each time, because each of us has our favorite processor or OS.

This is a discussion that verges on breaking into a religious war every time it’s brought up. Basically, there are two camps on this. One side wishes to work with a microcontroller-based SC, and the other wants a PC solution. You have to understand that we have limited resources (i.e., people, time, and money), so we must select work to be done in a frugal manner.

We chose a new Zilog chip because it allowed us to easily port over the RTOS of the SC with little work. It also has low power requirements, is quiet (no need for a fan), low-maintenance (no moving parts), and stand-alone. But when it was announced that Zilog was reorganizing, we decided to try to port the tasks over to the C language.

The decision made sense because several members of the group already had decided to use the Rabbit processor and had started to port the code over to that base. Instead of allowing that to splinter the group, I thought it wise to take advantage of their work. The side effect is that the code can then be ported over to other OSs, such as those available for PCs (and Macs) or another processor (e.g., ARM controller). The one minor drawback is that we’ll only be able to use the COMM-Links and not the stacked I/O boards.

The next issue to address is where we get the boards. We’ve been able to take advantage of the fact that Micromint still sells many of the boards that the original HCS was designed from. That means that we have support for the SC module (i.e., the RTC180 can be used).

The COMM-Link modules are another matter. Our first solution is to use the prototype boards available from ME Labs. These boards use the Microchip family of processors, which are easy to obtain. They require soldering and adding of parts to the prototyping area of the boards. Considering that our main customers are DIY types, this isn’t too much of a problem. But for those of you who are more software types, we’ve provided links on various electronics topics on our web site. We’re also looking at additional boards, so if your favorite processor isn’t listed, you should post a suggestion. As I said earlier, comments and suggestions are always welcome.

After the hardware, the question of software comes up. There are several solutions for the software. Most are commercial products, but we also have open-source solutions.

On the commercial side, we have the C compiler for PICs from CCS. At $99, the price isn’t bad. For those of you who don’t like C, we also have BASIC. ME Labs has two BASIC compilers, PIC BASIC ($100) and PIC BASIC Pro ($250).

On the open-source side, we have the SDCC C compiler. It supports the 8051, Z80, 14-bit Microchip PICs (e.g., the ’16F84, ’16F87x, and ’12CE6xx chips), and AVR. I’ve only had a chance to play with the 8051 and Z80, but all of them look promising. I’ll spend some time porting the PL-Link over to SDCC and see what I get. For the AVR, you can also use the GNU C compiler. In addition, there are a large number of freely available assemblers for almost every processor, so I won’t try and list them here. But I will talk about the ASL assembler we used to assemble the HCS II RTOS code.

Before Mike Baptiste provided his source code, we disassembled the 4.01 RTOS code (the SC ROM code). We had the 3.60 source but weren’t sure what assembler it was for. We did know, however, that it used macros and that those macros made the code extremely easy to read, so we had to save them. After a whole lot of searching, someone found ASL. It supports the macros and the 180 chip. A few tweaks to the assembly code were necessary to assemble the RTOS, and now we have one file for both the 3.6 and 4.0 RTOS.