What and why is the HDT
=======================

HDT stand for Hardware Description Table and is a concept to
enable hardware drivers to easily detect and use hardware 
components like servos, motors or sensors attached to the 
Eyebot Platform.

HDT consists of two main parts.
1.) HDT access procedures
2.) HDT data structures

HDT access procedures
---------------------
These procedures are part of RoBiOS and are used by hardware
drivers to determine where and if a hardware component exists.
Currently there are four basic procedures that can be found
in /mc/robios/hdt.c.

int HDT_Validate(void);
is used by RoBiOS to check and initialize the HDT data structure.

void *HDT_FindEntry(TypeID typeid,DeviceSemantics semantics);
/* is used by device drivers to search for first entry that matches semantics and returns
a pointer to the corresponding datastructure. */

DeviceSemantics HDT_FindSemantics(TypeID typeid, int x);
/* look for xth entry of given Typ and return its semantics */

int HDT_TypeCount(TypeID typeid);
/* count entries of given Type */

char *HDT_GetString(TypeID typeid,DeviceSemantics semantics)
/* get semantic string */

These procedures can not be used by userprograms !

HDT data structure
------------------
The HDT data structure is a separate data file (/mc/hdtdata).
Each Eyebot or other hardware configuration needs its own
HDT data. These data files contain all the information about where
a hardware component is attached to the Eyebot and how to control it.

The HDT data structure itself consists of two main parts:
1.) the data structures of various hdt components
2.) the HDT list itself

1.) the data structure for a component, like a motor, contains
	all information a driver needs to know.
e.g.:
motor_type motor0 = {0,  0, TIMER1, 8196, (void*)(OutBase+2), 6, 7, (BYTE*)&motconv0};
0               : the maximum driver version for which this entry is sufficient
0               : the tpu channel the motor is attached to
TIMER2          : the tpu timer that has to be used
8196            : pwm period in Hz
OutBase+2       : the I/O Port address the driver has to use
6               : the portbit for forward drive
7               : the portbit for backward drive
motconv0        : the pointer to a conversion table to adjust different motors

These xxxx_type structures are defined in /mc/robios/include/hdt.h.

2.) the HDT list itself contains all the hardware components attached
	and their semantics.

e.g.:
HDT_entry_type HDT[] =
{
    MOTOR,MOTOR_RIGHT,"RIGHT",(void *)&motor0,
    MOTOR,MOTOR_LEFT,"LEFT",(void *)&motor1,

    PSD,PSD_FRONT,"FRONT",(void *)&psd1,

    INFO,INFO,"INFO",(void *)&roboinfo,

    END_OF_HDT,UNKNOWN_SEMANTICS,"END",(void *)0
};

e.g. first line:
MOTOR           : it is a motor
MOTOR_LEFT      : its semantics
"LEFT"          : a readable string for testroutines
&motor0         : a pointer to the motor0 data structure


The INFO and END_OF_HDT entries are mandatory!
The semantics and all other constants are defined in /mc/robios/include/hdt.h.


How it works
------------
This is demonstrated in the motor-demo (/mc/demos/motor).
At first you need a handle for your motor:

MotorHandle     leftmotor;

Then you have to initialize this handle, by calling MOTORInit with the
semantics of the motor you want to initialize. MOTORInit now searches
the HDT for a motor with the given semantics and if found calls the 
motor driver to initialize the motor.

leftmotor = MOTORInit(LEFTMOTOR);

Now you can use the motor by setting a speed value. This function
calls the motor driver and sets a previously initialized motor
to the given speed.

MOTORDrive (leftmotor,50);

After using the motor you have to release it again. This function
calls the motor drivers which than released the motor.

MOTORRelease (leftmotor);

Using all other hardware components works in a similar way.
Consult /mc/EXECLIB for further details about the functions.


Flashing/Downloading
--------------------

Flashing:

With the HDT-concept the flashing procedure has changed a little bit.
The HDT has to be flashed seperately behind the ROBIOS.

The procedure depends on the size of the used flashrom.

1 Mbit:
The 1 Mbit flash is physically divided into 8 blocks of 16KB each. It is possible
to erase and program each block seperately. The first 7 blocks are destined to
hold the RoBiOS. The last block is reserved for the HDT data structure that 
therefore can grow up to a maximum size of 16KB, which is fairly enough.
 
Flash RoBiOS with:
flash 11111110 robios.hex 0

and the hdt with:
flash 00000001 hdtdata.hex $1c000 


4 MBit:
The 4 Mbit flash is physically divided into 8 blocks of 64KB each. It is possible
to erase and program each block seperately. The first 2 blocks are destined to
hold the RoBiOS AND the HDT. The remaining 6 block are used to save up to three 
userprograms which is handled by the USR-menue of the RoBiOS. Obviously is there 
no way to store the HDT data structure seperately at the same position like in the 
1MBit case. To avoid the waste of a complete 64KB block (the third block) for holding 
the HDT a detour has to be taken. The HDT with a maximum size of 16KB is flashed at 
the beginning of the third block. Beware, a previously saved userprogram (slot 1) will 
be deleted by this action. After having restarted the Eyebot, the RoBiOS recognizes 
the new HDT and performs a reprogramming of the second block in the following way:
The first 48KB of the second block, containing the second part of the RoBiOS, is
copied into the RAM, now the first 16KB of the third block, containing the new HDT,
is copied directly behind it. This new 64KB block is now flashed back into the second
block and the third block is cleared, ready to hold a new userprogram. With this action
the first 128KB of the flashrom contain compared to the 1Mbit flash the same data at 
identical addresses.

Flash RoBiOS with:
flash 11000000 robios.hex 0

and the hdt with:
flash 00100000 hdtdata.hex $20000 


Downloading:

Since V.1.4 of RoBiOS exists the possibility of downloading the HDT or the RoBioS via 
a serial interface (1-3). There is no difference between the two flash chips with this
method. Enter 'USR' menue and initiate 'LD' just like downloading a USER program.
Initiate the transmission of a hdtxxx.hex or robios.hex file on your remote computer.
RoBiOS detects a new HDT/RoBiOS automatically and flashes it correctly. This is much
faster and easier than the 'flashing'-method above.


Description of all HDT entries
------------------------------

motor
-----
typedef struct
{
	int     driver_version;
	int     tpu_channel;
	int     tpu_timer;
	int     pwm_period;
	BYTE*   out_pin_address;
	short   out_pin_fbit;
	short   out_pin_bbit;
    BYTE*   conv_table;     /* NULL if no conversion needed */
}motor_type;

e.g. 
motor_type motor0 = {1,  0, TIMER1, 8196, (void*)(OutBase+2), 6, 7, (BYTE*)&motconv0)};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int tpu_channel:
The tpu channel the motor is attached to. Valid values are 0..15
Each motor needs a pwm (pulse width modulated) signal to drive with different speeds.
The internal TPU of the MC68332 is capable of generating this signal on up to 16 
channels. The value to be entered here is given through the actual hardwaredesign.

int tpu_timer:
The tpu timer that has to be used. Valid values are TIMER1, TIMER2
The tpu generates the pwm signal on an internal timer basis. There are two different
timers that can be used to determine the actual period for the pwm signal.
TIMER1 runs at a speed of 4MHz up to 8MHz depending on the actual CPU-clock
which allows periods between 128Hz and 4MHz (with 4MHz basefrq) up to 256Hz - 8MHz (with 8MHz)
TIMER2 runs at a speed of 512KHz up to 1MHz depending on the actual CPU-clock
which allows periods between 16Hz and 512KHz (512KHz base) up to 32Hz - 1MHz (1MHz base)
To determine the actual TIMERx speed use the following equation:
TIMER1[MHz] = 4MHZ * (16MHz + (CPUclock[MHz] % 16))/16
TIMER2[MHz] = 512KHZ * (16MHz + (CPUclock[MHz] % 16))/16

int pwm_period:
This value sets the length of one pwm period in Hz according to the selected timer.
The values are independent (in a certain interval) of the actual CPU-clock.
The maximal frequency is the actual TPU-frequency divided by 100 in order 
to guarantee 100 different energylevels for the motor. This implies a maximum period of 
40-80KHz with TIMER1 and 5-10KHz with TIMER2 (depending on the cpuclock). 
The minimal frequency is therefore the Timerclock divided by 32768 which implies
128-256Hz (Timer1) and 16-32Hz (Timer2) as longest periods (depending on CPUclock).
To be independent of the actual CPUclock a safe interval is given by 256Hz - 40KHz (Timer1)
and 32Hz - 5KHz (Timer2).
To avoid a 'stuttering' of the motor the period should not be set too slow but on the 
other hand decreases a too fast period the remaining calculationtime of the TPU.

BYTE* out_pin_address:
The I/O Port address the driver has to use. Valid value is a 32bit address.
To control the direction a motor is spinning a H-bridge is used. This type of hardware 
is normally connected via two pins to a latched output. The outlatches of the Eyebot-
plattform are for example located at OUTBASE and the succeeding addresses.
One of this two pins is set for forward movement and the other for backward movement.

short out_pin_fbit:
The portbit for forward drive. Valid values are 0..7
This is the bitnumber in the latch addressed by out_pin_addres.

short out_pin_bbit:
The portbit for backward drive. Valid values are 0..7
This is the bitnumber in the latch addressed by out_pin_addres.

BYTE* conv_table: 
The pointer to a conversion table to adjust different motors. 
Valid values are NULL or a pointer to a table containing 101 bytes.
Usually two motors behave slightly different when they get exactly the same amount of
energy. This will for example show up in a differential drive, when a vehicle should
drive in a straight line but moves in a curve. To adjust one motor to another a conversion
table is needed. For each possible speed (0..100%) an appropriate value has to be entered
in the table to obtain the same speed for both motors. It is wise to adapt the faster 
motor because at high speeds the slower one can't keep up, you would need speeds of more
than 100% ! 
Hint: The table can be generated by software using the connected encoders.


servo
-----
typedef struct
{
  int     driver_version;
  int     tpu_channel;
  int     tpu_timer;
  int     pwm_period;
  int     pwm_start;
  int     pwm_stop;
}servo_type;

e.g.
servo_type servo0 = {1,  0, TIMER2, 20000, 700, 1700};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int tpu_channel:
The tpu channel the servo is attached to. Valid values are 0..15
Each servo needs a pwm (pulse width modulated) signal to turn into different positions.
The internal TPU of the MC68332 is capable of generating this signal on up to 16 
channels. The value to be entered here is given through the actual hardwaredesign.

int tpu_timer:
The tpu timer that has to be used. Valid values are TIMER1, TIMER2
The tpu generates the pwm signal on an internal timer basis. There are two different
timers that can be used to determine the actual period for the pwm signal.
TIMER1 runs at a speed of 4MHz up to 8MHz depending on the actual CPU-clock
which allows periods between 128Hz and 4MHz (with 4MHz basefrq) up to 256Hz - 8MHz (with 8MHz)
TIMER2 runs at a speed of 512KHz up to 1MHz depending on the actual CPU-clock
which allows periods between 16Hz and 512KHz (512KHz base) up to 32Hz - 1MHz (1MHz base)
To determine the actual TIMERx speed use the following equation:
TIMER1[MHz] = 4MHZ * (16MHz + (CPUclock[MHz] % 16))/16
TIMER2[MHz] = 512KHZ * (16MHz + (CPUclock[MHz] % 16))/16

int pwm_period:
This value sets the length of one pwm period in microseconds (us).
A normal servo needs a pwm_period of 20ms which equals 20000us. For any
exotic servo this value can be changed accordingly. It is always preferable to take
TIMER2 because only here you have enough discrete steps to position the servo accurate.
The values are in a certain interval (see motor) independent of the CPUclock.

int pwm_start:
This is the minimal hightime of the pwm period in us. Valid values are 0..pwm_period
To position a servo the two extreme positions for it have to be defined. In the normal
case a servo needs to have a minimal hightime of 0.7ms (700us) at the beginning of each pwm
period. This is also one of the two extreme positions a servo can take.

int pwm_stop:
This is the maximum hightime of the pwm period. Valid values are 0..pwm_period.
Depending on the rotation direction of a servo, one may choose pwm_stop less than
or greater than pwm_start.
To position a servo the two extreme positions for it have to be defined. In the normal
case a servo needs to have a maximum hightime of 1.7ms (1700us) at the beginning of each
pwm period. This is also one of the two extreme positions a servo can take. 
All other positions of the servo are linear interpolated in 256 steps between this two 
extremes. 
Hint: If you don't need the full range the servo offers you can adjust the start and stop
parameters to a smaller 'window' like 1ms to 1.5ms and gain a higher resolution in this
bounds. Or the other way round, you can enlarge the 'window' to adjust the values to the
real degrees the servo changes it's position: 
Take for example a servo that covers a range of 210 degrees. Simply adjust the stop value
to 1.9ms. If you now set values between 0 and 210 you will reach the two extremes in steps
corresponding to the real angles. Values higher than 210 would not differ from the result 
gained by the value of 210!


Quadrature encoder
------------------
typedef struct
{
	int     driver_version;
	int     master_tpu_channel;
	int     slave_tpu_channel;
    DeviceSemantics motor;
    unsigned int clicksPerMeter;
    float   maxspeed;       /* (in m/s) only needed for VW-Interface */
}quad_type;

e.g.
quad_type decoder0 = {0, 3, 2, MOTOR_LEFT, 1234, 2.34};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int master_tpu_channel:
The first TPU channel used for quadrature decoding. Valid values are 0..15
To perform decoding of the motor encoder signals the TPU occupies two adjacent channels.
By changing the order of the two channels the direction of counting can be inverted.

int slave_tpu_channel:
The second TPU channel used for quadrature decoding. Valid values are master_tpu_channel +|- 1

DeviceSemantics motor:
The semantics of the attached motor.
To test a specific encoder via the internal RoBiOS function the semantics of the coupled 
motor is needed.

unsigned int clicksPerMeter:
This parameter is used only if the the connected motor powers a driving wheel.
It is the number of clicks that are delivered by the encoder covering the distance of 1 meter. 

float maxspeed:
This parameter is used only if the the connected motor powers a driving wheel.
It is the maximum speed of this wheel in m/s. 


Drive
-----
typedef struct
{
	int     version;
    int     drive_type;
    drvspec drive_spec; /* -> diff_data */
}vw_type;

    typedef struct
    {
        DeviceSemantics quad_left;
        DeviceSemantics quad_right;
        float           wheel_dist; /* meters */
    }diff_data;

e.g.
vw_type drive = {0, DIFFERENTIAL_DRIVE, {QUAD_LEFT, QUAD_RIGHT, 0.21}};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int drive_type:
Define the type of the actual used drive.
Valid values are DIFFERENTIAL_DRIVE (ACKERMAN_DRIVE, SYNCHRO_DRIVE, TRICYCLE_DRIVE)
The following parameters depend on the selected drive type.

DIFFERENTIAL_DRIVE:
The differential drive is made up of two parallel independent wheels with the kinematic 
center right between them. Obviously two encoders with the connected motors are needed.

    DeviceSemantics quad_left:
    The semantics of the encoder used for the left wheel. 

    DeviceSemantics quad_right:
    The semantics of the encoder used for the right wheel.
    
    float wheel_dist:
    The distance (meters) between this two wheels to determine the kinematic center.


Position Sensitive Device (PSD)
-------------------------------
typedef struct
{
	short   driver_version;
	short   tpu_channel;
	BYTE*   in_pin_address;
	short   in_pin_bit;
	short   in_logic;
	BYTE*   out_pin_address;
	short   out_pin_bit;
	short   out_logic;
	short*  dist_table;
}psd_type;

e.g.
psd_type psd0 = {0, 14, (BYTE*)(Ser1Base+6), 5, AL, (BYTE*)(Ser1Base+4), 0, AL, (short*)&dist0};
psd_type psd1 = {0, 14, (BYTE*)InBase, 2, AH, (BYTE*)OutBase, 0, AH, (short*)&dist1};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

short tpu_channel:
The master TPU channel for serial timing of the PSD communication. Valid values are 0..15
This TPU channel is not used as an in- or output. It is just used as a high resolution timer
needed to generate exact communication timing. If there are more than 1 PSD connected to
the hardware each PSD has to use the same TPU channel. The complete group or just a selected 
subset of PSDs can 'fire' simultaneously. Depending on the position of the PSDs it is 
preferable to avoid measure cycles of adjacent sensors to get correct distance values.

BYTE* in_pin_address:
Pointer to an 8Bit register/latch to receive the PSD measuring result.

short in_pin_bit:
The portbit for the receiver. Valid values are 0..7
This is the bitnumber in the register/latch addressed by in_pin_address.

short in_logic:
Type of the received data. Valid values are AH, AL
Some registers negate the incoming data. To compensate this, active low(AL) has to be selected.

BYTE* out_pin_address:
Pointer to an 8Bit register/latch to transmit the PSD control signal.
If two or more PSDs are allways intended to measure simulataneously the same outpin can be 
connected to all of this PSDs. This saves valuable register bits.  

short out_pin_bit:
The portbit for the transmitter. Valid values are 0..7
This is the bitnumber in the register/latch addressed by out_pin_address.

short out_logic:
Type of the transmitted data. Valid values are AH, AL
Some rgisters negate the outgoing data. To compensate this, active low(AL) has to be selected.

short* dist_table:
The pointer to a distance conversion table.
A PSD delivers an 8bit measure result which is just a number. Due to inaccuracey of the 
result only the upper 7 bits are used (div 2). To obtain the corresponding distance in mm
a lookup table with 128 entrys is needed. For every PSD slightly deviates in it's measured 
distance from each other, each PSD needs it's own conversion table to guarantee correct
distances. The tables have to be generated 'by hand'. The testprogram included in RoBiOS
shows the raw 8bit PSD value for the actual measured distance. By slowly moving a plane object
away from the sensor the raw values change accordingly. Now take every second raw value and
write down the corresponding distance in mm. That's it.  


Bumper
------
typedef struct
{
    int     driver_version;
    int     tpu_channel;
    int     tpu_timer;
    short   transition;
}bump_type;

e.g.
bump_type bumper0 = {0, 6, TIMER2, EITHER};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int tpu_channel:
The tpu channel the bumper is attached to. Valid values are 0..15
Each bumper needs a tpu channel to signal a 'bump'-occurance.

int tpu_timer:
The tpu timer that has to be used. Valid values are TIMER1, TIMER2
If a 'bump' is detected the cooresponding timer-value is stored for later calculations.
TIMER1 runs at a speed of 4MHz-8MHz (depending on CPUclock)
TIMER2 runs at a speed of 512Khz-1MHz (depending on CPUclock)

short transition:
React on a certain transition. Valid values are RISING, FALLING, EITHER
To alter the behaviour of the bumper, the type of transition the TPU reacts on can be choosen.

Infrared sensor
---------------
typedef struct
{
    int     driver_version;
    int     tpu_channel;
}ir_type;

e.g.
ir_type   ir0 = {0, 8};

int driver_version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int tpu_channel:
The tpu channel the ir-sensor is attached to. Valid values are 0..15
Each ir-sensor needs a tpu channel to signal the recognition of an obstacle.


Systeminformation
-----------------
typedef struct
{
	int     version;
	int     id;
	int     serspeed;
	int     handshake;
	int     interface;
	int     res;
	int     remote_control;
	int     cammode;
    int     battery_display;
    int     CPUclock;
    float   user_version;
    String10 name;
    unsigned char robi_id;    
}info_type;

e.g.
info_type roboinfo0  = {0,VEHICLE,SER57600,RTSCTS,SERIAL2,0,0,AUTOBRIGHTNESS,BATTERY_ON,16,VERSION,NAME};

int version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

int id:
The current envirnonment on which RoBiOS is running. Valid values are PLATFORM, VEHICLE, WALKER
It is accessible via OSMachineType().

int serspeed:
The default baudrate for the default serial interface. 
Valid values are SER9600, SER19200, SER38400, SER57600

int handshake:
The default handshake mode for the default serial interface. 
Valid values are NONE, RTSCTS

int interface:
The default serial interface for the transfer of userprograms. 
Valid values are SERIAL1, SERIAL2, SERIAL3

int res:
reserved for future extensions
allways set to zero

int remote_control:
The default control mode for the eyebot. Valid values are ON (the display is forwarded to
and the keys are send from a remote PC) and OFF (normal mode)

int cammode:
The default camera mode. Valid values are AUTOBRIGHTNESS, NOAUTOBRIGHTNESS

int battery_display:
Switch the battery status display on or off. Valid values are BATTERY_ON, BATTERY_OFF

int CPUclock:
The clock rate(MHz) the MC68332 microprocessor should run with.
It is accessible via OSMachineSpeed().

float user_version:
The user defined version number of the actual HDT. This nr is just for information and
will be displayed in the HRD-menue of the RoBiOS!

String10 name;
The user defined unique name for this Eyebot. This name is just for information and
will be displayed in the main-menue of the RoBiOS! It is accessible via OSMachineName().

unsigned char robi_id;
The user defined unique id for this Eyebot. This id is just for information and will
be displayed in the main-menu of the RoBiOS! Is is accessible via OSMachineID(). It can
temporarily be changed in Hrd/Set/Rmt



Waitstates
----------
typedef struct
{
	short     version;
	short     rom_ws;
	short     ram_ws;
	short     lcd_ws;
	short     io_ws;
	short     serpar_ws;
}waitstate_type;


e.g.
waitstate_type waitstates = {0,3,0,1,0,2};

int version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

short rom_ws:
Waitstates for the ROM access
Valid values (for all waitstates):
waitstates = 0..13, Fast Termination = 14, External = 15

short ram_ws:
Waitstates for the RAM access

short lcd_ws:
Waitstates for the LCD access

short io_ws:
Waitstates for the Input/Output latches access

short serpar_ws:
Waitstates for the 16c552 Serial/Parallel Port Interface access


Battery Info
------------
typedef struct
{
    int     version;
   	short   low_limit;
	short   high_limit;
}battery_type;


e.g.
battery_type battery = {0,550,850};

int version: 
The maximum driver version for which this entry is compatible.
Because newer drivers will surely need more information this tag prevents this drivers
from reading more information than actual available.

short low_limit: 
The value the AD-converter channel 1 measures shortly before the batteries are empty. 
This defines the lower limit of the tracked battery voltage.

short   high_limit:
The value the AD-converter channel 1 measures with fully loaded batteries. 
This defines the upper limit of the tracked battery voltage.

Melody 
------
Here you can enter your own melody, that will be played at startup. It is a list of pairs. 
The first value indicates the frq the second the duration in 1/100s. As last value there must be 
single 0.

Image
-----
Here you can enter your own startup image. It is a 128x64 Pixel B/W picture (1024Bytes).
