Home | AVR | FPGA | M680x | Zilog Z8 | Zilog Z80 | Hitachi SH | Transputer | Linux | DOS

The SH (Super Cool) micro-controllers from Hitachi run cool and fast, use very little power, and include a lot of integration on a single chip. The SH family of processors include the SH1, SH2, SH-DSP, SH3, SH3-DSP and SH4.

The SH4 everyone will know as the CPU used inside the DreamCast Game console, while the SH3 CPU is used in most other PDA handheld computers. SH1, 2 and DSP are more for embedded controllers and dedicated applications.

All the source code provided here is designed to run on the concept hardware which has a master clock of 10MHz. The internal Phase Lock Loop circuits (PLL) step this frequency up according to this ratio: 8:4:2. That means the CPU will clock at 8 x 10MHz = 80MHz, the external memory bus clock will be 4 x 10MHz = 40MHz, and the Peripheral clock will be 2 x 10MHz = 20MHz.

Please note: All program source code presented here is written in SH3 assembler and 'C' original code where it is considered to be covered by the GNU General Public License (GPL) distribution agreement.

SHBIOS

SH3 BIOS (Kernel) for a generic system.
"SHBIOS"

Therefore this Basic I/O System provides that layer for standard Hitachi SH3 driven systems. The target hardware need only be made of CPU, SRAM or SDRAM, ROM and a RS232 interface. Click here for more details on a basic system SHBIOS has been designed for.

The features of SHBIOS includes:

There is a lot of code that makes the kernel of this system. It is stable and flexible. But not reprogramable. That is: new drivers can not be dynamically added or removed in a hot system.

SHBIOS has been designed to meet the big end dedicate embedded application, not the general purpose application that supports transient applications.

You would use this kernel in places like network routers, alarms, LED flasher, keyboards, tape drive controller etc. These are functions which have a single purpose and does it well fast.

Another neat feature of this kernel is its support of the Transputer's "C" library calls for timer and process management. That means most Transputer "C" programs  will port easily to this system

The program has been compiled assuming a master clock frequency of 10MHz - so all timers and dividers will be based on that. You can change this by changing the "CLK_10MHZ" definition in the kernel compiler options to: CLK_8MHz, CLK_12MHz or CLK_16MHz.

EYEPC

EYEPC (Debug) running over SHBIOS (Kernel)

In this project the kernel "SHBIOS" is used to host a simple program that allows a user to enter commands via the console. This will be known here as a Command Line Interface (CLI). Such commands provide a window into the internals of the system to see what it looks like and is doing.

For example it can show any memory space in the system then allow you to change that data.

"EYEPC" program code, which sounds like "Eye Piece", was first demonstrated in the Transputer Embedded controller of the same name. In that project, however, were five separate I/O consoles all working concurrently.

SHBIOS is also capable of running five separate consoles accept that there are not enough I/O devices to do it with. So there is no point to it, well not until the TCP/IP protocol stack is integrated anyway.

This version of EYEPC has been reduced to one console to provide a foundation building block that will be used in later programs to provide a more useful interface into the hardware, kernel and application.

The program has been compiled assuming a master clock frequency of 10MHz - so all timers and dividers will be based on that. You can change this by changing the "CLK_10MHZ" definition in the kernel compiler options to: CLK_8MHz, CLK_12MHz or CLK_16MHz.

NETAPP1

NETAPP1 TCP/IP Client-Server Application

So far the protocol stack employs: ARP, IP, ICMP and TCP. There is also a dummy Ethernet interface to provide a stub for any future expansion when a real Ethernet LAN controller is wired on. UDP is not far away.

"EYEPC" CLI has been extended to included the additional feature set given by the network stack and provides a number of additional commands to aid interrogation and modification of it. When SHBIOS is running type "help" at the console to view a brief list of the new network commands.

Since the concept hardware, SHBIOS has been written for, does not yet have an actual LAN connection then all TCP/IP communications routes through its dummy Ethernet and local interface. Therefore communications via TCP/IP will only be from one program to another.

In future expansion of this program, and kernel, a PPP and Radio based LAN will be added providing a means to communicate outside the host. So it will begin to take on more useful potential.

You should also notice that there are three process threads running to service the new network infra-structure. They are listed as:

To demonstrate the use of this  TCP/IP network protocol stack in this current context type a command at the CLI prompt to establish a connection to "Telnetd". That would look like:

telnet  192.168.0.1

The operation of this program and connection works like it does on a Linux computer's telnet program.

Note the IP address: The Ethernet dummy interface has been given the Class B unregistered subnet address 192.168.x.x  to use although this can be easily changed. Should any other IP address be given, at the command, then the router will throw the packets away because there is no where for them to go and  resulting in connection attempt failing.

SHBIOS's network protocol stack has been written from ground up with embedded controller applications as the goal. Therefore it is lean on memory and CPU time. It also watches its own performance and cleans up old idle connections regularly.

As yet there is no "sockets" API to the protocol stack so writing program code to control it will be a little more basic than would be expected otherwise. In my opinion though, it is pretty clean and easy to use.

And the program has been compiled assuming a master clock frequency of 10MHz - so all timers and dividers will be based on that. You can change this by changing the "CLK_10MHZ" definition in the kernel compiler options to: CLK_8MHz, CLK_12MHz or CLK_16MHz.