SHBIOS

(SuperH  Basic Input Output System)

INTRODUCTION

This page is designed to provide further detailed information about SHBIOS. You can read this information and use it to make decisions about the suitability of SHBIOS for your application.

SHBIOS is not cripple ware. There are no traps or time limited features to prevent it from working for too long, or absent features - what you see is what you get. Rather it is all provided in source and binary forms to allow easy use anywhere by anyone who wants to make their new or existing SH3 system go.

SHBIOS has been compiled using Hitachi's Integrated Development Environment (IDE) named by Hitachi as Hitachi Embedded Workshop - Revision level 5.1 (HEW.) The source code archive supplied here has included into it all control files for the project that belong to this IDE.

The system is multiprocess based so it will allow a lot of programs to be run simultaneously. In fact there can be up to 32768 processes run at any one time, however, a limitation of memory will restrict actual numbers of started, or  running threads. 

Managing processes is similar to the Transputer's "C" library. Functions such as ProcAlloc() and ProcRun() exist to match the Transputer's process library. The intended end result is a library that resembles the existing Transputer "C" process library, and therefore most programs written for the Transputer will compile and run on this system.

Since this kernel can execute multiple processes dictates that a lot of attention be given to program "race" conditions. A program "race" condition is a moment in time where two or more programs attempt to access a single resource which results in a conflict. Effectively corrupting any results received from the resource.

SHBIOS guards against "race" conditions in many ways which are defined by their application. For example: the SemWait() function forms a method to lock down, otherwise known as "blocking", processes that are being accessed by another, while all FIFO's are designed to work in a very asynchronous way. One side of the FIFO will not effect the other and still retain proper data transfer through it.

Memory is managed through the "heap" memory in combination with the standard function set supplied with the HEW compiler. This library provides all the usual functions like: malloc(), calloc(), free() and so on.

All peripherals located on the CPU silicon have a driver function, or library, associated to them and in some cases interrupt handlers will be activated at startup. This allows all peripherals to be used straight away without too much trouble.

The SH3 provides very good power management strategies and these have been integrated into the kernel to allow full use of them. All or none of the functional blocks in the system can be turned on, off or down.

There is no doubt that more can be added to this kernel, and so it should, however, it all must start here. The very basics of the system have to be built and used to make a foundation for further work.

SHBIOS has been designed to be run on a minimal system for two reasons:

1. Target hardware can be any off-the-shelf product so long as it has a SH3 CPU. Only internal peripherals will be used guaranteeing that no special hardware configuration is needed.
2. Simple to design and get going. When this kernel is running you have instant control of the system.

Copyright Message

The source code and binaries to SHBIOS  have been distributed under the GPL. So you will see a message like this through out the source tree at the head of each file:

Authors and other copyright holders:
1991-2001 by Kevin Bertram (alias: -Kev), This source code module. kevin@cate.com.au

This software may be used and distributed according to the terms of the GNU General Public License (GPL), incorporated herein by reference. Drivers based on or derived from this code fall under the GPL and must retain the authorship, copyright and license otice. This file is not a complete program and may only be used when the entire operating system is licensed under the GPL.

The author may be reached as: kevin@cate.com.au

So the entire source tree for SBIOS can be copied and distributed as per the GPL agreement.

SYSTEM HARDWARE BLOCK DIAGRAM

SHBIOS has been designed to run on a minimum SH3 based system. That means there is an SH3 CPU with all its internal peripherals, some RAM and ROM, a system clock, a reset, a status LED and an RS232 interface.

As the diagrams shows the basic functional blocks needed that can be constructed from six chips. However, since integration of functional blocks is on the increase this can be reduced to four chips at the time of writing. Not shown here is the power supply - A 3v3 and 1v8 supply rail needs to be provided and assumes all parts are 3v3 types.

A lot of the internal peripherals housed on the SH3 chip are used by the kernel to provide it with the appropriate support. SHBIOS does not expect anything other than memory and a simple RS232 interface to be connected outside the chip.

The RS232 interface is used as standard input and output where all messages will be sent to and commands expected from the user.

Should you want to add more components then that  can be done too. The kernel will not know about it, however, there is no reason why driver code cannot be added to suit. But in its plain vanilla form the kernel will be running and waiting for commands via the RS232 I/O.

Schematic diagrams have not been supplied because of their perceived complexity, and they may not add to completing this system anyway. Chances are that if you are reading this web page then you already have the hardware and are looking for a good software solution.

There are a lot of prototype systems on the market that can be acquired from Hitachi or 3rd party producers these days, so I would recommend this approach because SMD printed circuits require a lot of effort to get right and cost a lot more than most people want to payout for prototypes. Its easier to get a ready built board and the software adjusted to fit it.

Depending on the hardware available will determine where the status LED(s), if any, are wired to and how they are driven. The given kernel assumes a certain connection which can be changed to suit the new target system. 

Status LED's, as every Engineer knows, form the only line of communication between program and programmer in a newly designed computer. I have to say, "computers don't work unless they have a flashing LED.

Sound Generation Data Pump

Generating sound using the SH3 microprocessor is very easy. Well, the initial setup may be a but daunting but once that has been done the effort becomes easier. 

To aid audio generation the SH3 allows any of its DMA's to be driven from a programmable time base. This means that feeding a data stream to one or more DAC's becomes a memory move operation that reduces the load on the CPU significantly.

And to add icing to this cake the audio data stream can be made to loop indefinitely with almost no overhead. This would satisfy sound instrument synthesis from single wave tables and repetitive looping sounds.

Once a DMA is set going it will load the system by about 0.001% overhead. These figures include memory access and interrupt handling times. The DMAC load figure was calculated using the standard memory interface timings, a data block of 256 bytes, sample rate of 22KHz and the currently supplied DMAC interrupt handler.

If software were used entirely to transfer data from memory to DAC then this figure changes dramatically. In fact calculated figures for this type of solution working out to about 40% overhead. SHBIOS will not move the data under program control. All is done through a DMAC.

SHBIOS provides the means to "pump" the DAC with an uninterrupted data stream at the back-end but what about the front end? 

Front-end Sound Generation

Sound data can be generated in many ways before being feed to a DAC. However, for the purposes of this explanation MP3 music encoded files will be used to demonstrate two features of SHBIOS and its Sound Generation system:

1. How the sound data pump is integrated to an application.
2. Using the multiprocessing ability of the kernel to manage MP3 sound file playback.

Sound is generated by pumping the sound DAC with a constant uninterrupted stream of data. The data has to be relevant to the sound that is being produced. 

So, where should the source sound data come from? It can be obtained from a number of sources such as pre-capture digitized sound data streams, MP3 sound files, wave tables, or software generated methods.

For this application  MP3 sound files will be used to illustrate the data chain. As the drawing here suggests the original MP3 sound file resides in memory somewhere.

The MP3 decoder engine will use that file to decode and extract the relevant sound information, reassemble it then pump it out, in blocks, to a memory buffer somewhere. On an IBM-PC output data from the MP3 engine would be delivered straight to the DAC's at this point since they have their own PCM decoders built into hardware.

However, an SH3 system needs to be further refine the data by converting the PCM data to 8-bit raw samples. That is handled by the "PCM to RAM converter" functional block and is fairly easy to do. The data output would then be placed into memory somewhere ready for the Sound data pump to become free to pump it out to the DAC.

Since SHBIOS supports multiprocessing then the MP3 player application can be run as an asynchronous process (thread) where it spends all its time just decoding the original MP3 file to raw sound samples. The Sound data pump would also operate independently from the MP3 application and would dictate the speed of data delivery rate to the DAC that would ensure minimization of clicks and bumps in the final generated sound.

Since the MP3 engine is an asynchronous process then it would spend a lot of its time sleeping or waiting for the data pump to release. The data pump would be working at its programmed rate of about 44Ksps but compared to program execution speed of software that can be considered a "snails pace" by comparison.

Process Scheduling and Management

SHBIOS supports the ability to run many programs at once. In this context it is considered a multiprocess operating system.

Each process will occupy a small portion on the CPU's total time to execute. The duration is defined by a 1000Hz time base free running oscillator. It is used to time the access a program has to the CPU and when expired another program gets access to the CPU. If all programs have had their chance to run for one millisecond then it all starts again. This type of context switching is called "Round Robin". It is efficient and reduces context switch management overhead to a bare minimum.

Other types of context switching, such as "Pre-emptive" forces more to be managed inside the context switching software but gives better load distribution across all processes that need it at the expense of predictability of execution time.

"Pre-emptive" context switching is not supported by this kernel. Even so, it can be added should the need arise.

Each processes details are stored in a single control structure where the process manager can be used to start, stop or suspend it at any time. Since there will be more than one process running on the system many of these control structures are linked together in a "linked list". The Process scheduler will walk the list every time a reschedule  interrupt occurs one step at a time. 

If the list has four control structures in it, that is: four processes are running, then it will take four milliseconds to walk from start to end. Once the end has been reached the list wraps back to the first entry and begins again.

New processes can be started at anytime by any of those currently running or they can be stopped at any time. There are no priorities or access controls so there is not concept of ownership beyond the Parent and child. 

The concept of memory sharing between process falls into two categories:

1. Global memory. All process running on the system can see and access this memory. It includes all programs running including interrupt handlers and internal resources. This memory takes the form of Static (BSS) or Heap (DSS) memory.

2. Workspace memory. A process will be allocated an area of memory out of heap for use by its stack. This memory is reserved for the owner process, but since the memory manager is not operating then it is also accessible by other programs on the system.

Memory Management

The SH3 can employ full memory controls through its Memory Management Unit (MMU) and user/kernel level protection bit. However, SHBIOS does not employ the use of these devices so full controls cannot be implemented.

SHBIOS is designed for a self contained embedded application where transient programs do not exist so the requirement for protected memory does not need to exist.

Memory is managed by the compiler and the heap. Static data will be loaded and initialized at startup and left for the program to use. Heap is a little more dynamic and controlled by requests from the program to reserve off areas for functions to use. These reserved areas can be freed back to the system so that other functions can use that memory.

The memory manager library belongs to the HEW IDE library set, however there are two places where the size and placement of this memory is defined and controlled.

1. Compiler Linker Directive. Look into the menu item "Tools-Optilinker options-[Section]" to view the memory map of how the linker should place components of the program in memory. NB: [Section] is a Tab selection input device within a GUI dialogue box.

2. Heap Size. This is a number stored in the file "sbrk.h" which defines the actual total size of memory to be used for heap. The compiler uses this figure also and communicates it back to the standard memory manager functions, like malloc() and free(), so they know their limits. The actual start location of heap is defined by the Linker memory map in combination with the end of Static memory space allocated by the compiler.

Minimum required Hardware Resources

The system will need a minimum of memory and support to actually run. In this system that is fairly minimal and can be easily satisfied using off the shelf components.

The minimum system will need to have:

1. Hitachi SH3 (HD6417707), or SH3-DSP (HD6417709, HD6417729) CPU. These are packed into a 208 pin QFP. That will mean the system has to be surface mounted and fixed to a printed circuit board.
2. 1MB SRAM - Static RAM (16-bits wide).
3. 8MB SDRAM - Synchronous Dynamic RAM (16-bits wide).
4. 256KB ROM which can take the form ROM, PROM, EPROM, or Flash ROM (16-bits wide).

The stated memory size can be larger, however, these figures are given as a minimum guideline. If you want to attach 32MB of SDRAM then go for it just make sure the CPU's memory interface is correctly configured to suit.

The memory map of the system will be very basic. Most of its complexity lays in on the CPU's chip and is adequately documented by the parts data sheet. For the rest of the system the memory map will look like this:

At startup all these memory areas will be configured to suit to device attached. Since most memory devices follow a close relationship between manufacturers, even though small differences exist, the general settings should hit close to the mark.

This table gives the rough details each memory device should comply to or exceed. Most timings of the system have been backed off to a liberal setting to cover a larger range of suitable devices.

KERNEL SERVICES

The kernel - SHBIOS will be running and supporting a minimum set of services that can be used to maintain and manage the system. It will offer methods for further additions and hardware drivers to be integrated in the future.

When the kernel properly starts these resources will be active and in operation:

SYSTEM UPGRADES

Upgrading SHBIOS is easy enough to do - just add. Most of the vital components to the software's structure has been detailed here. You would need to consider these areas and effects changes would make to them.

However, adjusting the system will be very simple once the location of keys features is known. Most directives, such as base addresses for logical functions are housed in standard 'C' included files. Moving a functional block from one address to another may be as easy as changing the base address definition.

However, this will not be an issue for a minimal system all contained on the SH3 chip.

SHBIOS is composed of many source files. These will all have a source code module ("C" file) and an associated included file ("H" file). 

All source files will be linked into a single library - "shbios.lib" while all included files will be read in by a top level included file - "system.h".

Each functional block will have all its drivers contained in a single file which has been named to reflect its purpose. For example the process manager will be named "process.c" and its include file will be named "process.h".

The programs entry point will be "main()" and the existence of this function will be expected by the Reset handler and setup functions. On entry to main() the system can be assumed to be initialized, all I/O setup and all interrupts running. There is no further setup needed to be done by main() accept for additional setup needed by the application.