| /* SPDX-License-Identifier: GPL-2.0 */ |
| /* |
| * Helper types to take care of the fact that the DSP card memory |
| * is 16 bits, but aligned on a 32 bit PCI boundary |
| */ |
| |
| static inline u16 get_u16(const u32 __iomem *p) |
| { |
| return (u16)readl(p); |
| } |
| |
| static inline void set_u16(u32 __iomem *p, u16 val) |
| { |
| writel(val, p); |
| } |
| |
| static inline s16 get_s16(const s32 __iomem *p) |
| { |
| return (s16)readl(p); |
| } |
| |
| static inline void set_s16(s32 __iomem *p, s16 val) |
| { |
| writel(val, p); |
| } |
| |
| /* |
| * 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. |
| * |
| * Raw_time is an unsigned integer which shows the value of the JR3 |
| * DSP's internal clock at the time the sample was received. The clock |
| * runs at 1/10 the JR3 DSP cycle time. JR3's slowest DSP runs at 10 |
| * Mhz. At 10 Mhz raw_time would therefore clock at 1 Mhz. |
| * |
| * Raw_data is the raw data received directly from the sensor. The |
| * sensor data stream is capable of representing 16 different |
| * channels. Channel 0 shows the excitation voltage at the sensor. It |
| * is used to regulate the voltage over various cable lengths. |
| * Channels 1-6 contain the coupled force data Fx through Mz. Channel |
| * 7 contains the sensor's calibration data. The use of channels 8-15 |
| * varies with different sensors. |
| */ |
| |
| struct raw_channel { |
| u32 raw_time; |
| s32 raw_data; |
| s32 reserved[2]; |
| }; |
| |
| /* |
| * The force_array structure shows the layout for the decoupled and |
| * filtered force data. |
| */ |
| struct force_array { |
| s32 fx; |
| s32 fy; |
| s32 fz; |
| s32 mx; |
| s32 my; |
| s32 mz; |
| s32 v1; |
| s32 v2; |
| }; |
| |
| /* |
| * The six_axis_array structure shows the layout for the offsets and |
| * the full scales. |
| */ |
| struct six_axis_array { |
| s32 fx; |
| s32 fy; |
| s32 fz; |
| s32 mx; |
| s32 my; |
| s32 mz; |
| }; |
| |
| /* VECT_BITS */ |
| /* |
| * 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 |
| * 0x0020. Example: to specify the axes V1x, V1y, V2x, and V2z the |
| * pattern would be 0x002b. Vector 1 defaults to a force vector and |
| * vector 2 defaults to a moment vector. It is possible to change one |
| * or the other so that two force vectors or two moment vectors are |
| * calculated. Setting the changeV1 bit or the changeV2 bit will |
| * change that vector to be the opposite of its default. Therefore to |
| * have two force vectors, set changeV1 to 1. |
| */ |
| |
| /* vect_bits appears to be unused at this time */ |
| enum { |
| fx = 0x0001, |
| fy = 0x0002, |
| fz = 0x0004, |
| mx = 0x0008, |
| my = 0x0010, |
| mz = 0x0020, |
| changeV2 = 0x0040, |
| changeV1 = 0x0080 |
| }; |
| |
| /* WARNING_BITS */ |
| /* |
| * 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 |
| * exceeded the near saturation value. |
| */ |
| |
| enum { |
| fx_near_sat = 0x0001, |
| fy_near_sat = 0x0002, |
| fz_near_sat = 0x0004, |
| mx_near_sat = 0x0008, |
| my_near_sat = 0x0010, |
| mz_near_sat = 0x0020 |
| }; |
| |
| /* ERROR_BITS */ |
| /* XX_SAT */ |
| /* MEMORY_ERROR */ |
| /* SENSOR_CHANGE */ |
| |
| /* |
| * 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 |
| * was detected in the on-board RAM during the power-up |
| * initialization. The sensor_change bit indicates that a sensor other |
| * than the one originally plugged in has passed its CRC check. This |
| * bit latches, and must be reset by the user. |
| * |
| */ |
| |
| /* SYSTEM_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 |
| * become unstable during the approximately 4 ms needed to accomplish |
| * these calculations. This bit will also become active when a new |
| * sensor is plugged in and the system needs to recalculate the |
| * calibration CRC. |
| */ |
| |
| /* CAL_CRC_BAD */ |
| |
| /* |
| * 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 |
| * transmitted to the JR3 DSP along with the sensor data. The |
| * calibration data has a CRC attached to the end of it, to assist in |
| * determining the completeness and integrity of the calibration data |
| * received from the sensor. There are two reasons the CRC may not |
| * have calculated to zero. The first is that all the calibration data |
| * has not yet been received, the second is that the calibration data |
| * has been corrupted. A typical sensor transmits the entire contents |
| * of its calibration matrix over 30 times a second. Therefore, if |
| * this bit is not zero within a couple of seconds after the sensor |
| * has been plugged in, there is a problem with the sensor's |
| * calibration data. |
| */ |
| |
| /* WATCH_DOG */ |
| /* WATCH_DOG2 */ |
| |
| /* |
| * 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 |
| * while watch_dog does not. This would indicate an improper clock |
| * signal, while data is acting correctly. If either watch dog barks, |
| * the sensor data is not being received correctly. |
| */ |
| |
| enum error_bits_t { |
| fx_sat = 0x0001, |
| fy_sat = 0x0002, |
| fz_sat = 0x0004, |
| mx_sat = 0x0008, |
| my_sat = 0x0010, |
| mz_sat = 0x0020, |
| memory_error = 0x0400, |
| sensor_change = 0x0800, |
| system_busy = 0x1000, |
| cal_crc_bad = 0x2000, |
| watch_dog2 = 0x4000, |
| watch_dog = 0x8000 |
| }; |
| |
| /* THRESH_STRUCT */ |
| |
| /* |
| * 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 |
| * 2. threshold is the is the value at which, if data is above or below, the |
| * bits will be set ... (pag.24). |
| * 3. bit_pattern contains the bits that will be set if the threshold value is |
| * met or exceeded. |
| */ |
| |
| struct thresh_struct { |
| s32 data_address; |
| s32 threshold; |
| s32 bit_pattern; |
| }; |
| |
| /* LE_STRUCT */ |
| |
| /* |
| * 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 |
| * no longer true. In that case the user must reset them using the reset_bit |
| * command. |
| * 2. number_of_xx_thresholds specify how many GE/LE threshold there are. |
| */ |
| struct le_struct { |
| s32 latch_bits; |
| s32 number_of_ge_thresholds; |
| s32 number_of_le_thresholds; |
| struct thresh_struct thresholds[4]; |
| s32 reserved; |
| }; |
| |
| /* 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) |
| * 2 - translate along Y axis (TY) |
| * 3 - translate along Z axis (TZ) |
| * 4 - rotate about X axis (RX) |
| * 5 - rotate about Y axis (RY) |
| * 6 - rotate about Z axis (RZ) |
| * 7 - negate all axes (NEG) |
| */ |
| |
| enum link_types { |
| end_x_form, |
| tx, |
| ty, |
| tz, |
| rx, |
| ry, |
| rz, |
| neg |
| }; |
| |
| /* TRANSFORM */ |
| /* Structure used to describe a transform. */ |
| struct intern_transform { |
| struct { |
| u32 link_type; |
| s32 link_amount; |
| } link[8]; |
| }; |
| |
| /* |
| * JR3 force/torque sensor data definition. For more information see sensor |
| * and hardware manuals. |
| */ |
| |
| struct jr3_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. |
| */ |
| |
| u32 copyright[0x0018]; /* offset 0x0040 */ |
| s32 reserved1[0x0008]; /* offset 0x0058 */ |
| |
| /* |
| * 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 |
| * this ability, the gain of each sensor channel is measured at |
| * the time of calibration using a shunt resistor. The shunt |
| * resistor is placed across one arm of the resistor bridge, and |
| * the resulting change in the output of that channel is |
| * measured. This measurement is called the shunt reading, and |
| * is recorded here. If the user has changed the gain of the // |
| * sensor, and made new shunt measurements, those shunt |
| * measurements can be placed here. The JR3 DSP will then scale |
| * the calibration matrix such so that the gains are again |
| * proper for the indicated shunt readings. If shunts is 0, then |
| * the sensor cannot have its gain changed. For details on |
| * changing the sensor gain, and making shunts readings, please |
| * see the sensor manual. To make these values take effect the |
| * user must call either command (5) use transform # (pg. 33) or |
| * command (10) set new full scales (pg. 38). |
| */ |
| |
| 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. |
| */ |
| |
| struct six_axis_array default_FS; /* offset 0x0068 */ |
| s32 reserved3; /* offset 0x006e */ |
| |
| /* |
| * 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 */ |
| |
| /* Min_full_scale is the recommend minimum full scale. */ |
| |
| /* |
| * 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 |
| * the full scale is set too low, the data will saturate |
| * prematurely, and dynamic range will be lost. If the full scale is |
| * set too high, then resolution is lost as the data is shifted to |
| * the right and the least significant bits are lost. Therefore the |
| * maximum full scale is the maximum value at which no resolution is |
| * lost, and the minimum full scale is the value at which the data |
| * will not saturate prematurely. These values are calculated |
| * whenever a new coordinate transformation is calculated. It is |
| * possible for the recommended maximum to be less than the |
| * recommended minimum. This comes about primarily when using |
| * coordinate translations. If this is the case, it means that any |
| * full scale selection will be a compromise between dynamic range |
| * and resolution. It is usually recommended to compromise in favor |
| * of resolution which means that the recommend maximum full scale |
| * should be chosen. |
| * |
| * WARNING: Be sure that the full scale is no less than 0.4% of the |
| * recommended minimum full scale. Full scales below this value will |
| * cause erroneous results. |
| */ |
| |
| struct six_axis_array min_full_scale; /* offset 0x0070 */ |
| s32 reserved4; /* offset 0x0076 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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, |
| * Fz, Mx, My and Mz can be written by the user prior to calling |
| * command (10) set new full scales (pg. 38). The full scales for V1 |
| * and V2 are set whenever the full scales are changed or when the |
| * axes used to calculate the vectors are changed. The full scale of |
| * V1 and V2 will always be equal to the largest full scale of the |
| * axes used for each vector respectively. |
| */ |
| |
| struct force_array full_scale; /* offset 0x0080 */ |
| |
| /* |
| * 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 |
| * can be written as well as read. The JR3 DSP will use the values |
| * written here within 2 ms of being written. To set future |
| * decoupled data to zero, add these values to the current decoupled |
| * data values and place the sum here. The JR3 DSP will change these |
| * values when a new transform is applied. So if the offsets are |
| * such that FX is 5 and all other values are zero, after rotating |
| * about Z by 90 degrees, FY would be 5 and all others would be zero. |
| */ |
| |
| struct six_axis_array offsets; /* offset 0x0088 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 |
| * passed through cascaded low pass filters. Each succeeding filter |
| * has a cutoff frequency of 1/4 of the preceding filter. The cutoff |
| * frequency of filter1 is 1/16 of the sample rate from the sensor. |
| * For a typical sensor with a sample rate of 8 kHz, the cutoff |
| * frequency of filter1 would be 500 Hz. The following filters would |
| * 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 |
| */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 |
| * not miss any peaks. To read the data, use either the read peaks |
| * command (pg. 40), or the read and reset peaks command (pg. 39). |
| * The address of the data to watch for peaks is stored in the |
| * variable peak_address (pg. 10). Peak data is lost when executing |
| * a coordinate transformation or a full scale change. Peak data is |
| * also lost when plugging in a new sensor. |
| */ |
| |
| 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 |
| * 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 |
| * and warning words (pg. 14), provide this critical information. |
| * These two values may be set by the host processor. These values |
| * are positive signed values, since the saturation logic uses the |
| * absolute values of the raw data. The near_sat_value defaults to |
| * approximately 80% of the ADC's full scale, which is 26214, while |
| * sat_value defaults to the ADC's full scale: |
| * |
| * sat_value = 32768 - 2^(16 - ADC bits) |
| */ |
| |
| s32 near_sat_value; /* offset 0x00e0 */ |
| s32 sat_value; /* offset 0x00e1 */ |
| |
| /* |
| * 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 |
| * calculate rates for filter3 data set rate_address to 0x00a8). |
| * Rate_divisor is how often the rate is calculated. If rate_divisor |
| * is 1, the rates are calculated at full sensor bandwidth. If |
| * rate_divisor is 200, rates are calculated every 200 samples. |
| * Rate_divisor can be any value between 1 and 65536. Set |
| * rate_divisor to 0 to calculate rates every 65536 samples. |
| * Rate_count starts at zero and counts until it equals |
| * rate_divisor, at which point the rates are calculated, and |
| * rate_count is reset to 0. When setting a new rate divisor, it is |
| * a good idea to set rate_count to one less than rate divisor. This |
| * 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 */ |
| |
| /* |
| * 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 |
| * locations, and then places the command word into command_word0. |
| * The JR3 DSP will process the command and place a 0 into |
| * command_word0 to indicate successful completion. Alternatively |
| * the JR3 DSP will place a negative number into command_word0 to |
| * indicate an error condition. Please note the command locations |
| * are numbered backwards. (I.E. command_word2 comes before |
| * command_word1). |
| */ |
| |
| s32 command_word2; /* offset 0x00e5 */ |
| s32 command_word1; /* offset 0x00e6 */ |
| s32 command_word0; /* offset 0x00e7 */ |
| |
| /* |
| * 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 |
| * are incremented at 1/4 the interval of the counter immediately |
| * preceding it, so they would count at 2 kHz, 500 Hz, 125 Hz etc. |
| * These counters can be used to wait for data. Each time the |
| * counter changes, the corresponding data set can be sampled, and |
| * this will insure that the user gets each sample, once, and only |
| * 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 */ |
| |
| /* |
| * 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 |
| * extremely noisy environment to experience occasional errors even |
| * without a hardware problem. If the sensor is well grounded, this |
| * is probably unavoidable in these environments. On the occasions |
| * where this counter counts a bad sample, that sample is ignored. |
| */ |
| |
| u32 error_count; /* offset 0x00ee */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 |
| * specifications during sensor manufacture and cannot be changed by |
| * writing to Units. |
| * |
| * Bits contains the number of bits of resolution of the ADC |
| * currently in use. |
| * |
| * Channels is a bit field showing which channels the current sensor |
| * is capable of sending. If bit 0 is active, this sensor can send |
| * channel 0, if bit 13 is active, this sensor can send channel 13, |
| * etc. This bit can be active, even if the sensor is not currently |
| * sending this channel. Some sensors are configurable as to which |
| * channels to send, and this field only contains information on the |
| * channels available to send, not on the current configuration. To |
| * find which channels are currently being sent, monitor the |
| * Raw_time fields (pg. 19) in the raw_channels array (pg. 7). If |
| * the time is changing periodically, then that channel is being |
| * received. |
| */ |
| |
| u32 units; /* offset 0x00fc */ |
| s32 bits; /* offset 0x00fd */ |
| s32 channels; /* offset 0x00fe */ |
| |
| /* |
| * 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 */ |
| |
| /* |
| * 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 |
| * need not be fully contained in that slot. That is to say that a |
| * single load envelope can be larger than a single slot. The |
| * software has been tested and ran satisfactorily with 50 |
| * thresholds active. A single load envelope this large would take |
| * up 5 of the 16 slots. The load envelope data is laid out in an |
| * order that is most efficient for the JR3 DSP. The structure is |
| * detailed later in the section showing the definition of the |
| * le_struct structure (pg. 23). |
| */ |
| |
| struct le_struct load_envelopes[0x10]; /* offset 0x0100 */ |
| |
| /* |
| * 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 |
| * contained in that slot. That is to say that a single transform |
| * can be larger than a single slot. A transform is 2 * no of links |
| * + 1 words in length. So a single slot can contain a transform |
| * with 7 links. Two slots can contain a transform that is 15 links. |
| * The layout is detailed later in the section showing the |
| * definition of the transform structure (pg. 26). |
| */ |
| |
| struct intern_transform transforms[0x10]; /* offset 0x0200 */ |
| }; |
| |
| struct jr3_block { |
| u32 program_lo[0x4000]; /* 0x00000 - 0x10000 */ |
| struct jr3_sensor sensor; /* 0x10000 - 0x10c00 */ |
| char pad2[0x30000 - 0x00c00]; /* 0x10c00 - 0x40000 */ |
| u32 program_hi[0x8000]; /* 0x40000 - 0x60000 */ |
| u32 reset; /* 0x60000 - 0x60004 */ |
| char pad3[0x20000 - 0x00004]; /* 0x60004 - 0x80000 */ |
| }; |
