staging: comedi: jr3_pci.h: Fix checkpatch warning
Fix checkpatch.pl warning: Block comments use * on subsequent lines Block comments use a trailing */ on a separate line Block comments starts with /* followed by comments on the next line Signed-off-by: Anson Jacob <ansonjacob.aj@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This commit is contained in:
Родитель
12f992adeb
Коммит
f8d791f2ab
|
@ -1,4 +1,5 @@
|
|||
/* Helper types to take care of the fact that the DSP card memory
|
||||
/*
|
||||
* Helper types to take care of the fact that the DSP card memory
|
||||
* is 16 bits, but aligned on a 32 bit PCI boundary
|
||||
*/
|
||||
|
||||
|
@ -22,7 +23,8 @@ static inline void set_s16(s32 __iomem *p, s16 val)
|
|||
writel(val, p);
|
||||
}
|
||||
|
||||
/* The raw data is stored in a format which facilitates rapid
|
||||
/*
|
||||
* The raw data is stored in a format which facilitates rapid
|
||||
* processing by the JR3 DSP chip. The raw_channel structure shows the
|
||||
* format for a single channel of data. Each channel takes four,
|
||||
* two-byte words.
|
||||
|
@ -47,7 +49,8 @@ struct raw_channel {
|
|||
s32 reserved[2];
|
||||
};
|
||||
|
||||
/* The force_array structure shows the layout for the decoupled and
|
||||
/*
|
||||
* The force_array structure shows the layout for the decoupled and
|
||||
* filtered force data.
|
||||
*/
|
||||
struct force_array {
|
||||
|
@ -61,7 +64,8 @@ struct force_array {
|
|||
s32 v2;
|
||||
};
|
||||
|
||||
/* The six_axis_array structure shows the layout for the offsets and
|
||||
/*
|
||||
* The six_axis_array structure shows the layout for the offsets and
|
||||
* the full scales.
|
||||
*/
|
||||
struct six_axis_array {
|
||||
|
@ -74,7 +78,8 @@ struct six_axis_array {
|
|||
};
|
||||
|
||||
/* VECT_BITS */
|
||||
/* The vect_bits structure shows the layout for indicating
|
||||
/*
|
||||
* The vect_bits structure shows the layout for indicating
|
||||
* which axes to use in computing the vectors. Each bit signifies
|
||||
* selection of a single axis. The V1x axis bit corresponds to a hex
|
||||
* value of 0x0001 and the V2z bit corresponds to a hex value of
|
||||
|
@ -100,12 +105,14 @@ enum {
|
|||
};
|
||||
|
||||
/* WARNING_BITS */
|
||||
/* The warning_bits structure shows the bit pattern for the warning
|
||||
/*
|
||||
* The warning_bits structure shows the bit pattern for the warning
|
||||
* word. The bit fields are shown from bit 0 (lsb) to bit 15 (msb).
|
||||
*/
|
||||
|
||||
/* XX_NEAR_SET */
|
||||
/* The xx_near_sat bits signify that the indicated axis has reached or
|
||||
/* XX_NEAR_SET */
|
||||
/*
|
||||
* The xx_near_sat bits signify that the indicated axis has reached or
|
||||
* exceeded the near saturation value.
|
||||
*/
|
||||
|
||||
|
@ -118,12 +125,13 @@ enum {
|
|||
mz_near_sat = 0x0020
|
||||
};
|
||||
|
||||
/* ERROR_BITS */
|
||||
/* XX_SAT */
|
||||
/* MEMORY_ERROR */
|
||||
/* SENSOR_CHANGE */
|
||||
/* ERROR_BITS */
|
||||
/* XX_SAT */
|
||||
/* MEMORY_ERROR */
|
||||
/* SENSOR_CHANGE */
|
||||
|
||||
/* The error_bits structure shows the bit pattern for the error word.
|
||||
/*
|
||||
* The error_bits structure shows the bit pattern for the error word.
|
||||
* The bit fields are shown from bit 0 (lsb) to bit 15 (msb). The
|
||||
* xx_sat bits signify that the indicated axis has reached or exceeded
|
||||
* the saturation value. The memory_error bit indicates that a problem
|
||||
|
@ -134,9 +142,10 @@ enum {
|
|||
*
|
||||
*/
|
||||
|
||||
/* SYSTEM_BUSY */
|
||||
/* SYSTEM_BUSY */
|
||||
|
||||
/* The system_busy bit indicates that the JR3 DSP is currently busy
|
||||
/*
|
||||
* The system_busy bit indicates that the JR3 DSP is currently busy
|
||||
* and is not calculating force data. This occurs when a new
|
||||
* coordinate transformation, or new sensor full scale is set by the
|
||||
* user. A very fast system using the force data for feedback might
|
||||
|
@ -146,9 +155,10 @@ enum {
|
|||
* calibration CRC.
|
||||
*/
|
||||
|
||||
/* CAL_CRC_BAD */
|
||||
/* CAL_CRC_BAD */
|
||||
|
||||
/* The cal_crc_bad bit indicates that the calibration CRC has not
|
||||
/*
|
||||
* The cal_crc_bad bit indicates that the calibration CRC has not
|
||||
* calculated to zero. CRC is short for cyclic redundancy code. It is
|
||||
* a method for determining the integrity of messages in data
|
||||
* communication. The calibration data stored inside the sensor is
|
||||
|
@ -168,7 +178,8 @@ enum {
|
|||
/* WATCH_DOG */
|
||||
/* WATCH_DOG2 */
|
||||
|
||||
/* The watch_dog and watch_dog2 bits are sensor, not processor, watch
|
||||
/*
|
||||
* The watch_dog and watch_dog2 bits are sensor, not processor, watch
|
||||
* dog bits. Watch_dog indicates that the sensor data line seems to be
|
||||
* acting correctly, while watch_dog2 indicates that sensor data and
|
||||
* clock are being received. It is possible for watch_dog2 to go off
|
||||
|
@ -192,9 +203,10 @@ enum error_bits_t {
|
|||
watch_dog = 0x8000
|
||||
};
|
||||
|
||||
/* THRESH_STRUCT */
|
||||
/* THRESH_STRUCT */
|
||||
|
||||
/* This structure shows the layout for a single threshold packet inside of a
|
||||
/*
|
||||
* This structure shows the layout for a single threshold packet inside of a
|
||||
* load envelope. Each load envelope can contain several threshold structures.
|
||||
* 1. data_address contains the address of the data for that threshold. This
|
||||
* includes filtered, unfiltered, raw, rate, counters, error and warning data
|
||||
|
@ -210,9 +222,10 @@ struct thresh_struct {
|
|||
s32 bit_pattern;
|
||||
};
|
||||
|
||||
/* LE_STRUCT */
|
||||
/* LE_STRUCT */
|
||||
|
||||
/* Layout of a load enveloped packet. Four thresholds are showed ... for more
|
||||
/*
|
||||
* Layout of a load enveloped packet. Four thresholds are showed ... for more
|
||||
* see manual (pag.25)
|
||||
* 1. latch_bits is a bit pattern that show which bits the user wants to latch.
|
||||
* The latched bits will not be reset once the threshold which set them is
|
||||
|
@ -228,8 +241,9 @@ struct le_struct {
|
|||
s32 reserved;
|
||||
};
|
||||
|
||||
/* LINK_TYPES */
|
||||
/* Link types is an enumerated value showing the different possible transform
|
||||
/* LINK_TYPES */
|
||||
/*
|
||||
* Link types is an enumerated value showing the different possible transform
|
||||
* link types.
|
||||
* 0 - end transform packet
|
||||
* 1 - translate along X axis (TX)
|
||||
|
@ -252,8 +266,8 @@ enum link_types {
|
|||
neg
|
||||
};
|
||||
|
||||
/* TRANSFORM */
|
||||
/* Structure used to describe a transform. */
|
||||
/* TRANSFORM */
|
||||
/* Structure used to describe a transform. */
|
||||
struct intern_transform {
|
||||
struct {
|
||||
u32 link_type;
|
||||
|
@ -261,23 +275,29 @@ struct intern_transform {
|
|||
} link[8];
|
||||
};
|
||||
|
||||
/* JR3 force/torque sensor data definition. For more information see sensor
|
||||
* and hardware manuals.
|
||||
/*
|
||||
* JR3 force/torque sensor data definition. For more information see sensor
|
||||
* and hardware manuals.
|
||||
*/
|
||||
|
||||
struct jr3_channel {
|
||||
/* Raw_channels is the area used to store the raw data coming from */
|
||||
/* the sensor. */
|
||||
/*
|
||||
* Raw_channels is the area used to store the raw data coming from
|
||||
* the sensor.
|
||||
*/
|
||||
|
||||
struct raw_channel raw_channels[16]; /* offset 0x0000 */
|
||||
|
||||
/* Copyright is a null terminated ASCII string containing the JR3 */
|
||||
/* copyright notice. */
|
||||
/*
|
||||
* Copyright is a null terminated ASCII string containing the JR3
|
||||
* copyright notice.
|
||||
*/
|
||||
|
||||
u32 copyright[0x0018]; /* offset 0x0040 */
|
||||
s32 reserved1[0x0008]; /* offset 0x0058 */
|
||||
|
||||
/* Shunts contains the sensor shunt readings. Some JR3 sensors have
|
||||
/*
|
||||
* Shunts contains the sensor shunt readings. Some JR3 sensors have
|
||||
* the ability to have their gains adjusted. This allows the
|
||||
* hardware full scales to be adjusted to potentially allow
|
||||
* better resolution or dynamic range. For sensors that have
|
||||
|
@ -298,25 +318,29 @@ struct jr3_channel {
|
|||
* command (10) set new full scales (pg. 38).
|
||||
*/
|
||||
|
||||
struct six_axis_array shunts; /* offset 0x0060 */
|
||||
s32 reserved2[2]; /* offset 0x0066 */
|
||||
struct six_axis_array shunts; /* offset 0x0060 */
|
||||
s32 reserved2[2]; /* offset 0x0066 */
|
||||
|
||||
/* Default_FS contains the full scale that is used if the user does */
|
||||
/* not set a full scale. */
|
||||
/*
|
||||
* Default_FS contains the full scale that is used if the user does
|
||||
* not set a full scale.
|
||||
*/
|
||||
|
||||
struct six_axis_array default_FS; /* offset 0x0068 */
|
||||
s32 reserved3; /* offset 0x006e */
|
||||
s32 reserved3; /* offset 0x006e */
|
||||
|
||||
/* Load_envelope_num is the load envelope number that is currently
|
||||
/*
|
||||
* Load_envelope_num is the load envelope number that is currently
|
||||
* in use. This value is set by the user after one of the load
|
||||
* envelopes has been initialized.
|
||||
*/
|
||||
|
||||
s32 load_envelope_num; /* offset 0x006f */
|
||||
s32 load_envelope_num; /* offset 0x006f */
|
||||
|
||||
/* Min_full_scale is the recommend minimum full scale. */
|
||||
|
||||
/* These values in conjunction with max_full_scale (pg. 9) helps
|
||||
/*
|
||||
* These values in conjunction with max_full_scale (pg. 9) helps
|
||||
* determine the appropriate value for setting the full scales. The
|
||||
* software allows the user to set the sensor full scale to an
|
||||
* arbitrary value. But setting the full scales has some hazards. If
|
||||
|
@ -342,30 +366,35 @@ struct jr3_channel {
|
|||
*/
|
||||
|
||||
struct six_axis_array min_full_scale; /* offset 0x0070 */
|
||||
s32 reserved4; /* offset 0x0076 */
|
||||
s32 reserved4; /* offset 0x0076 */
|
||||
|
||||
/* Transform_num is the transform number that is currently in use.
|
||||
/*
|
||||
* Transform_num is the transform number that is currently in use.
|
||||
* This value is set by the JR3 DSP after the user has used command
|
||||
* (5) use transform # (pg. 33).
|
||||
*/
|
||||
|
||||
s32 transform_num; /* offset 0x0077 */
|
||||
s32 transform_num; /* offset 0x0077 */
|
||||
|
||||
/* Max_full_scale is the recommended maximum full scale. See */
|
||||
/* min_full_scale (pg. 9) for more details. */
|
||||
/*
|
||||
* Max_full_scale is the recommended maximum full scale.
|
||||
* See min_full_scale (pg. 9) for more details.
|
||||
*/
|
||||
|
||||
struct six_axis_array max_full_scale; /* offset 0x0078 */
|
||||
s32 reserved5; /* offset 0x007e */
|
||||
s32 reserved5; /* offset 0x007e */
|
||||
|
||||
/* Peak_address is the address of the data which will be monitored
|
||||
/*
|
||||
* Peak_address is the address of the data which will be monitored
|
||||
* by the peak routine. This value is set by the user. The peak
|
||||
* routine will monitor any 8 contiguous addresses for peak values.
|
||||
* (ex. to watch filter3 data for peaks, set this value to 0x00a8).
|
||||
*/
|
||||
|
||||
s32 peak_address; /* offset 0x007f */
|
||||
s32 peak_address; /* offset 0x007f */
|
||||
|
||||
/* Full_scale is the sensor full scales which are currently in use.
|
||||
/*
|
||||
* Full_scale is the sensor full scales which are currently in use.
|
||||
* Decoupled and filtered data is scaled so that +/- 16384 is equal
|
||||
* to the full scales. The engineering units used are indicated by
|
||||
* the units value discussed on page 16. The full scales for Fx, Fy,
|
||||
|
@ -377,9 +406,10 @@ struct jr3_channel {
|
|||
* axes used for each vector respectively.
|
||||
*/
|
||||
|
||||
struct force_array full_scale; /* offset 0x0080 */
|
||||
struct force_array full_scale; /* offset 0x0080 */
|
||||
|
||||
/* Offsets contains the sensor offsets. These values are subtracted from
|
||||
/*
|
||||
* Offsets contains the sensor offsets. These values are subtracted from
|
||||
* the sensor data to obtain the decoupled data. The offsets are set a
|
||||
* few seconds (< 10) after the calibration data has been received.
|
||||
* They are set so that the output data will be zero. These values
|
||||
|
@ -392,23 +422,26 @@ struct jr3_channel {
|
|||
* about Z by 90 degrees, FY would be 5 and all others would be zero.
|
||||
*/
|
||||
|
||||
struct six_axis_array offsets; /* offset 0x0088 */
|
||||
struct six_axis_array offsets; /* offset 0x0088 */
|
||||
|
||||
/* Offset_num is the number of the offset currently in use. This
|
||||
/*
|
||||
* Offset_num is the number of the offset currently in use. This
|
||||
* value is set by the JR3 DSP after the user has executed the use
|
||||
* offset # command (pg. 34). It can vary between 0 and 15.
|
||||
*/
|
||||
|
||||
s32 offset_num; /* offset 0x008e */
|
||||
s32 offset_num; /* offset 0x008e */
|
||||
|
||||
/* Vect_axes is a bit map showing which of the axes are being used
|
||||
/*
|
||||
* Vect_axes is a bit map showing which of the axes are being used
|
||||
* in the vector calculations. This value is set by the JR3 DSP
|
||||
* after the user has executed the set vector axes command (pg. 37).
|
||||
*/
|
||||
|
||||
u32 vect_axes; /* offset 0x008f */
|
||||
u32 vect_axes; /* offset 0x008f */
|
||||
|
||||
/* Filter0 is the decoupled, unfiltered data from the JR3 sensor.
|
||||
/*
|
||||
* Filter0 is the decoupled, unfiltered data from the JR3 sensor.
|
||||
* This data has had the offsets removed.
|
||||
*
|
||||
* These force_arrays hold the filtered data. The decoupled data is
|
||||
|
@ -420,23 +453,27 @@ struct jr3_channel {
|
|||
* cutoff at 125 Hz, 31.25 Hz, 7.813 Hz, 1.953 Hz and 0.4883 Hz.
|
||||
*/
|
||||
|
||||
struct force_array filter[7]; /* offset 0x0090,
|
||||
offset 0x0098,
|
||||
offset 0x00a0,
|
||||
offset 0x00a8,
|
||||
offset 0x00b0,
|
||||
offset 0x00b8 ,
|
||||
offset 0x00c0 */
|
||||
struct force_array filter[7]; /*
|
||||
* offset 0x0090,
|
||||
* offset 0x0098,
|
||||
* offset 0x00a0,
|
||||
* offset 0x00a8,
|
||||
* offset 0x00b0,
|
||||
* offset 0x00b8,
|
||||
* offset 0x00c0
|
||||
*/
|
||||
|
||||
/* Rate_data is the calculated rate data. It is a first derivative
|
||||
/*
|
||||
* Rate_data is the calculated rate data. It is a first derivative
|
||||
* calculation. It is calculated at a frequency specified by the
|
||||
* variable rate_divisor (pg. 12). The data on which the rate is
|
||||
* calculated is specified by the variable rate_address (pg. 12).
|
||||
*/
|
||||
|
||||
struct force_array rate_data; /* offset 0x00c8 */
|
||||
struct force_array rate_data; /* offset 0x00c8 */
|
||||
|
||||
/* Minimum_data & maximum_data are the minimum and maximum (peak)
|
||||
/*
|
||||
* Minimum_data & maximum_data are the minimum and maximum (peak)
|
||||
* data values. The JR3 DSP can monitor any 8 contiguous data items
|
||||
* for minimums and maximums at full sensor bandwidth. This area is
|
||||
* only updated at user request. This is done so that the user does
|
||||
|
@ -451,7 +488,8 @@ struct jr3_channel {
|
|||
struct force_array minimum_data; /* offset 0x00d0 */
|
||||
struct force_array maximum_data; /* offset 0x00d8 */
|
||||
|
||||
/* Near_sat_value & sat_value contain the value used to determine if
|
||||
/*
|
||||
* Near_sat_value & sat_value contain the value used to determine if
|
||||
* the raw sensor is saturated. Because of decoupling and offset
|
||||
* removal, it is difficult to tell from the processed data if the
|
||||
* sensor is saturated. These values, in conjunction with the error
|
||||
|
@ -465,10 +503,11 @@ struct jr3_channel {
|
|||
* sat_value = 32768 - 2^(16 - ADC bits)
|
||||
*/
|
||||
|
||||
s32 near_sat_value; /* offset 0x00e0 */
|
||||
s32 sat_value; /* offset 0x00e1 */
|
||||
s32 near_sat_value; /* offset 0x00e0 */
|
||||
s32 sat_value; /* offset 0x00e1 */
|
||||
|
||||
/* Rate_address, rate_divisor & rate_count contain the data used to
|
||||
/*
|
||||
* Rate_address, rate_divisor & rate_count contain the data used to
|
||||
* control the calculations of the rates. Rate_address is the
|
||||
* address of the data used for the rate calculation. The JR3 DSP
|
||||
* will calculate rates for any 8 contiguous values (ex. to
|
||||
|
@ -485,11 +524,12 @@ struct jr3_channel {
|
|||
* will minimize the time necessary to start the rate calculations.
|
||||
*/
|
||||
|
||||
s32 rate_address; /* offset 0x00e2 */
|
||||
u32 rate_divisor; /* offset 0x00e3 */
|
||||
u32 rate_count; /* offset 0x00e4 */
|
||||
s32 rate_address; /* offset 0x00e2 */
|
||||
u32 rate_divisor; /* offset 0x00e3 */
|
||||
u32 rate_count; /* offset 0x00e4 */
|
||||
|
||||
/* Command_word2 through command_word0 are the locations used to
|
||||
/*
|
||||
* Command_word2 through command_word0 are the locations used to
|
||||
* send commands to the JR3 DSP. Their usage varies with the command
|
||||
* and is detailed later in the Command Definitions section (pg.
|
||||
* 29). In general the user places values into various memory
|
||||
|
@ -502,11 +542,12 @@ struct jr3_channel {
|
|||
* command_word1).
|
||||
*/
|
||||
|
||||
s32 command_word2; /* offset 0x00e5 */
|
||||
s32 command_word1; /* offset 0x00e6 */
|
||||
s32 command_word0; /* offset 0x00e7 */
|
||||
s32 command_word2; /* offset 0x00e5 */
|
||||
s32 command_word1; /* offset 0x00e6 */
|
||||
s32 command_word0; /* offset 0x00e7 */
|
||||
|
||||
/* Count1 through count6 are unsigned counters which are incremented
|
||||
/*
|
||||
* Count1 through count6 are unsigned counters which are incremented
|
||||
* every time the matching filters are calculated. Filter1 is
|
||||
* calculated at the sensor data bandwidth. So this counter would
|
||||
* increment at 8 kHz for a typical sensor. The rest of the counters
|
||||
|
@ -518,14 +559,15 @@ struct jr3_channel {
|
|||
* once.
|
||||
*/
|
||||
|
||||
u32 count1; /* offset 0x00e8 */
|
||||
u32 count2; /* offset 0x00e9 */
|
||||
u32 count3; /* offset 0x00ea */
|
||||
u32 count4; /* offset 0x00eb */
|
||||
u32 count5; /* offset 0x00ec */
|
||||
u32 count6; /* offset 0x00ed */
|
||||
u32 count1; /* offset 0x00e8 */
|
||||
u32 count2; /* offset 0x00e9 */
|
||||
u32 count3; /* offset 0x00ea */
|
||||
u32 count4; /* offset 0x00eb */
|
||||
u32 count5; /* offset 0x00ec */
|
||||
u32 count6; /* offset 0x00ed */
|
||||
|
||||
/* Error_count is a running count of data reception errors. If this
|
||||
/*
|
||||
* Error_count is a running count of data reception errors. If this
|
||||
* counter is changing rapidly, it probably indicates a bad sensor
|
||||
* cable connection or other hardware problem. In most installations
|
||||
* error_count should not change at all. But it is possible in an
|
||||
|
@ -535,75 +577,84 @@ struct jr3_channel {
|
|||
* where this counter counts a bad sample, that sample is ignored.
|
||||
*/
|
||||
|
||||
u32 error_count; /* offset 0x00ee */
|
||||
u32 error_count; /* offset 0x00ee */
|
||||
|
||||
/* Count_x is a counter which is incremented every time the JR3 DSP
|
||||
/*
|
||||
* Count_x is a counter which is incremented every time the JR3 DSP
|
||||
* searches its job queues and finds nothing to do. It indicates the
|
||||
* amount of idle time the JR3 DSP has available. It can also be
|
||||
* used to determine if the JR3 DSP is alive. See the Performance
|
||||
* Issues section on pg. 49 for more details.
|
||||
*/
|
||||
|
||||
u32 count_x; /* offset 0x00ef */
|
||||
u32 count_x; /* offset 0x00ef */
|
||||
|
||||
/* Warnings & errors contain the warning and error bits
|
||||
/*
|
||||
* Warnings & errors contain the warning and error bits
|
||||
* respectively. The format of these two words is discussed on page
|
||||
* 21 under the headings warnings_bits and error_bits.
|
||||
*/
|
||||
|
||||
u32 warnings; /* offset 0x00f0 */
|
||||
u32 errors; /* offset 0x00f1 */
|
||||
u32 warnings; /* offset 0x00f0 */
|
||||
u32 errors; /* offset 0x00f1 */
|
||||
|
||||
/* Threshold_bits is a word containing the bits that are set by the
|
||||
/*
|
||||
* Threshold_bits is a word containing the bits that are set by the
|
||||
* load envelopes. See load_envelopes (pg. 17) and thresh_struct
|
||||
* (pg. 23) for more details.
|
||||
*/
|
||||
|
||||
s32 threshold_bits; /* offset 0x00f2 */
|
||||
s32 threshold_bits; /* offset 0x00f2 */
|
||||
|
||||
/* Last_crc is the value that shows the actual calculated CRC. CRC
|
||||
/*
|
||||
* Last_crc is the value that shows the actual calculated CRC. CRC
|
||||
* is short for cyclic redundancy code. It should be zero. See the
|
||||
* description for cal_crc_bad (pg. 21) for more information.
|
||||
*/
|
||||
|
||||
s32 last_CRC; /* offset 0x00f3 */
|
||||
s32 last_CRC; /* offset 0x00f3 */
|
||||
|
||||
/* EEProm_ver_no contains the version number of the sensor EEProm.
|
||||
/*
|
||||
* EEProm_ver_no contains the version number of the sensor EEProm.
|
||||
* EEProm version numbers can vary between 0 and 255.
|
||||
* Software_ver_no contains the software version number. Version
|
||||
* 3.02 would be stored as 302.
|
||||
*/
|
||||
|
||||
s32 eeprom_ver_no; /* offset 0x00f4 */
|
||||
s32 software_ver_no; /* offset 0x00f5 */
|
||||
s32 eeprom_ver_no; /* offset 0x00f4 */
|
||||
s32 software_ver_no; /* offset 0x00f5 */
|
||||
|
||||
/* Software_day & software_year are the release date of the software
|
||||
/*
|
||||
* Software_day & software_year are the release date of the software
|
||||
* the JR3 DSP is currently running. Day is the day of the year,
|
||||
* with January 1 being 1, and December 31, being 365 for non leap
|
||||
* years.
|
||||
*/
|
||||
|
||||
s32 software_day; /* offset 0x00f6 */
|
||||
s32 software_year; /* offset 0x00f7 */
|
||||
s32 software_day; /* offset 0x00f6 */
|
||||
s32 software_year; /* offset 0x00f7 */
|
||||
|
||||
/* Serial_no & model_no are the two values which uniquely identify a
|
||||
/*
|
||||
* Serial_no & model_no are the two values which uniquely identify a
|
||||
* sensor. This model number does not directly correspond to the JR3
|
||||
* model number, but it will provide a unique identifier for
|
||||
* different sensor configurations.
|
||||
*/
|
||||
|
||||
u32 serial_no; /* offset 0x00f8 */
|
||||
u32 model_no; /* offset 0x00f9 */
|
||||
u32 serial_no; /* offset 0x00f8 */
|
||||
u32 model_no; /* offset 0x00f9 */
|
||||
|
||||
/* Cal_day & cal_year are the sensor calibration date. Day is the
|
||||
/*
|
||||
* Cal_day & cal_year are the sensor calibration date. Day is the
|
||||
* day of the year, with January 1 being 1, and December 31, being
|
||||
* 366 for leap years.
|
||||
*/
|
||||
|
||||
s32 cal_day; /* offset 0x00fa */
|
||||
s32 cal_year; /* offset 0x00fb */
|
||||
s32 cal_day; /* offset 0x00fa */
|
||||
s32 cal_year; /* offset 0x00fb */
|
||||
|
||||
/* Units is an enumerated read only value defining the engineering
|
||||
/*
|
||||
* Units is an enumerated read only value defining the engineering
|
||||
* units used in the sensor full scale. The meanings of particular
|
||||
* values are discussed in the section detailing the force_units
|
||||
* structure on page 22. The engineering units are setto customer
|
||||
|
@ -626,20 +677,22 @@ struct jr3_channel {
|
|||
* received.
|
||||
*/
|
||||
|
||||
u32 units; /* offset 0x00fc */
|
||||
s32 bits; /* offset 0x00fd */
|
||||
s32 channels; /* offset 0x00fe */
|
||||
u32 units; /* offset 0x00fc */
|
||||
s32 bits; /* offset 0x00fd */
|
||||
s32 channels; /* offset 0x00fe */
|
||||
|
||||
/* Thickness specifies the overall thickness of the sensor from
|
||||
/*
|
||||
* Thickness specifies the overall thickness of the sensor from
|
||||
* flange to flange. The engineering units for this value are
|
||||
* contained in units (pg. 16). The sensor calibration is relative
|
||||
* to the center of the sensor. This value allows easy coordinate
|
||||
* transformation from the center of the sensor to either flange.
|
||||
*/
|
||||
|
||||
s32 thickness; /* offset 0x00ff */
|
||||
s32 thickness; /* offset 0x00ff */
|
||||
|
||||
/* Load_envelopes is a table containing the load envelope
|
||||
/*
|
||||
* Load_envelopes is a table containing the load envelope
|
||||
* descriptions. There are 16 possible load envelope slots in the
|
||||
* table. The slots are on 16 word boundaries and are numbered 0-15.
|
||||
* Each load envelope needs to start at the beginning of a slot but
|
||||
|
@ -655,7 +708,8 @@ struct jr3_channel {
|
|||
|
||||
struct le_struct load_envelopes[0x10]; /* offset 0x0100 */
|
||||
|
||||
/* Transforms is a table containing the transform descriptions.
|
||||
/*
|
||||
* Transforms is a table containing the transform descriptions.
|
||||
* There are 16 possible transform slots in the table. The slots are
|
||||
* on 16 word boundaries and are numbered 0-15. Each transform needs
|
||||
* to start at the beginning of a slot but need not be fully
|
||||
|
|
Загрузка…
Ссылка в новой задаче