Commit | Line | Data |
---|---|---|
f8d791f2 AJ |
1 | /* |
2 | * Helper types to take care of the fact that the DSP card memory | |
b2be969b BP |
3 | * is 16 bits, but aligned on a 32 bit PCI boundary |
4 | */ | |
5 | ||
95b24682 | 6 | static inline u16 get_u16(const u32 __iomem *p) |
07b509e6 | 7 | { |
95b24682 | 8 | return (u16)readl(p); |
07b509e6 AB |
9 | } |
10 | ||
95b24682 | 11 | static inline void set_u16(u32 __iomem *p, u16 val) |
07b509e6 AB |
12 | { |
13 | writel(val, p); | |
14 | } | |
15 | ||
95b24682 | 16 | static inline s16 get_s16(const s32 __iomem *p) |
07b509e6 | 17 | { |
95b24682 | 18 | return (s16)readl(p); |
07b509e6 AB |
19 | } |
20 | ||
95b24682 | 21 | static inline void set_s16(s32 __iomem *p, s16 val) |
07b509e6 AB |
22 | { |
23 | writel(val, p); | |
24 | } | |
25 | ||
f8d791f2 AJ |
26 | /* |
27 | * The raw data is stored in a format which facilitates rapid | |
b2be969b BP |
28 | * processing by the JR3 DSP chip. The raw_channel structure shows the |
29 | * format for a single channel of data. Each channel takes four, | |
30 | * two-byte words. | |
31 | * | |
32 | * Raw_time is an unsigned integer which shows the value of the JR3 | |
33 | * DSP's internal clock at the time the sample was received. The clock | |
34 | * runs at 1/10 the JR3 DSP cycle time. JR3's slowest DSP runs at 10 | |
35 | * Mhz. At 10 Mhz raw_time would therefore clock at 1 Mhz. | |
36 | * | |
37 | * Raw_data is the raw data received directly from the sensor. The | |
38 | * sensor data stream is capable of representing 16 different | |
39 | * channels. Channel 0 shows the excitation voltage at the sensor. It | |
40 | * is used to regulate the voltage over various cable lengths. | |
41 | * Channels 1-6 contain the coupled force data Fx through Mz. Channel | |
42 | * 7 contains the sensor's calibration data. The use of channels 8-15 | |
43 | * varies with different sensors. | |
44 | */ | |
45 | ||
2deee55e | 46 | struct raw_channel { |
54298a8d | 47 | u32 raw_time; |
0642feb3 BP |
48 | s32 raw_data; |
49 | s32 reserved[2]; | |
2deee55e | 50 | }; |
07b509e6 | 51 | |
f8d791f2 AJ |
52 | /* |
53 | * The force_array structure shows the layout for the decoupled and | |
b2be969b BP |
54 | * filtered force data. |
55 | */ | |
cdc14cd0 | 56 | struct force_array { |
0642feb3 BP |
57 | s32 fx; |
58 | s32 fy; | |
59 | s32 fz; | |
60 | s32 mx; | |
61 | s32 my; | |
62 | s32 mz; | |
63 | s32 v1; | |
64 | s32 v2; | |
cdc14cd0 | 65 | }; |
07b509e6 | 66 | |
f8d791f2 AJ |
67 | /* |
68 | * The six_axis_array structure shows the layout for the offsets and | |
b2be969b BP |
69 | * the full scales. |
70 | */ | |
5671c0c2 | 71 | struct six_axis_array { |
0642feb3 BP |
72 | s32 fx; |
73 | s32 fy; | |
74 | s32 fz; | |
75 | s32 mx; | |
76 | s32 my; | |
77 | s32 mz; | |
5671c0c2 | 78 | }; |
07b509e6 | 79 | |
b2be969b | 80 | /* VECT_BITS */ |
f8d791f2 AJ |
81 | /* |
82 | * The vect_bits structure shows the layout for indicating | |
b2be969b BP |
83 | * which axes to use in computing the vectors. Each bit signifies |
84 | * selection of a single axis. The V1x axis bit corresponds to a hex | |
85 | * value of 0x0001 and the V2z bit corresponds to a hex value of | |
86 | * 0x0020. Example: to specify the axes V1x, V1y, V2x, and V2z the | |
87 | * pattern would be 0x002b. Vector 1 defaults to a force vector and | |
88 | * vector 2 defaults to a moment vector. It is possible to change one | |
89 | * or the other so that two force vectors or two moment vectors are | |
90 | * calculated. Setting the changeV1 bit or the changeV2 bit will | |
91 | * change that vector to be the opposite of its default. Therefore to | |
92 | * have two force vectors, set changeV1 to 1. | |
93 | */ | |
07b509e6 | 94 | |
f3fd0937 BP |
95 | /* vect_bits appears to be unused at this time */ |
96 | enum { | |
07b509e6 AB |
97 | fx = 0x0001, |
98 | fy = 0x0002, | |
99 | fz = 0x0004, | |
100 | mx = 0x0008, | |
101 | my = 0x0010, | |
102 | mz = 0x0020, | |
103 | changeV2 = 0x0040, | |
104 | changeV1 = 0x0080 | |
135f8a5e | 105 | }; |
07b509e6 | 106 | |
b2be969b | 107 | /* WARNING_BITS */ |
f8d791f2 AJ |
108 | /* |
109 | * The warning_bits structure shows the bit pattern for the warning | |
b2be969b BP |
110 | * word. The bit fields are shown from bit 0 (lsb) to bit 15 (msb). |
111 | */ | |
112 | ||
f8d791f2 AJ |
113 | /* XX_NEAR_SET */ |
114 | /* | |
115 | * The xx_near_sat bits signify that the indicated axis has reached or | |
b2be969b BP |
116 | * exceeded the near saturation value. |
117 | */ | |
07b509e6 | 118 | |
f3fd0937 | 119 | enum { |
07b509e6 AB |
120 | fx_near_sat = 0x0001, |
121 | fy_near_sat = 0x0002, | |
122 | fz_near_sat = 0x0004, | |
123 | mx_near_sat = 0x0008, | |
124 | my_near_sat = 0x0010, | |
125 | mz_near_sat = 0x0020 | |
135f8a5e | 126 | }; |
07b509e6 | 127 | |
f8d791f2 AJ |
128 | /* ERROR_BITS */ |
129 | /* XX_SAT */ | |
130 | /* MEMORY_ERROR */ | |
131 | /* SENSOR_CHANGE */ | |
b2be969b | 132 | |
f8d791f2 AJ |
133 | /* |
134 | * The error_bits structure shows the bit pattern for the error word. | |
b2be969b BP |
135 | * The bit fields are shown from bit 0 (lsb) to bit 15 (msb). The |
136 | * xx_sat bits signify that the indicated axis has reached or exceeded | |
137 | * the saturation value. The memory_error bit indicates that a problem | |
138 | * was detected in the on-board RAM during the power-up | |
139 | * initialization. The sensor_change bit indicates that a sensor other | |
140 | * than the one originally plugged in has passed its CRC check. This | |
141 | * bit latches, and must be reset by the user. | |
142 | * | |
143 | */ | |
144 | ||
f8d791f2 | 145 | /* SYSTEM_BUSY */ |
b2be969b | 146 | |
f8d791f2 AJ |
147 | /* |
148 | * The system_busy bit indicates that the JR3 DSP is currently busy | |
b2be969b BP |
149 | * and is not calculating force data. This occurs when a new |
150 | * coordinate transformation, or new sensor full scale is set by the | |
151 | * user. A very fast system using the force data for feedback might | |
152 | * become unstable during the approximately 4 ms needed to accomplish | |
153 | * these calculations. This bit will also become active when a new | |
154 | * sensor is plugged in and the system needs to recalculate the | |
155 | * calibration CRC. | |
156 | */ | |
157 | ||
f8d791f2 | 158 | /* CAL_CRC_BAD */ |
b2be969b | 159 | |
f8d791f2 AJ |
160 | /* |
161 | * The cal_crc_bad bit indicates that the calibration CRC has not | |
b2be969b BP |
162 | * calculated to zero. CRC is short for cyclic redundancy code. It is |
163 | * a method for determining the integrity of messages in data | |
164 | * communication. The calibration data stored inside the sensor is | |
165 | * transmitted to the JR3 DSP along with the sensor data. The | |
166 | * calibration data has a CRC attached to the end of it, to assist in | |
167 | * determining the completeness and integrity of the calibration data | |
168 | * received from the sensor. There are two reasons the CRC may not | |
169 | * have calculated to zero. The first is that all the calibration data | |
170 | * has not yet been received, the second is that the calibration data | |
171 | * has been corrupted. A typical sensor transmits the entire contents | |
172 | * of its calibration matrix over 30 times a second. Therefore, if | |
173 | * this bit is not zero within a couple of seconds after the sensor | |
174 | * has been plugged in, there is a problem with the sensor's | |
175 | * calibration data. | |
176 | */ | |
177 | ||
178 | /* WATCH_DOG */ | |
179 | /* WATCH_DOG2 */ | |
180 | ||
f8d791f2 AJ |
181 | /* |
182 | * The watch_dog and watch_dog2 bits are sensor, not processor, watch | |
b2be969b BP |
183 | * dog bits. Watch_dog indicates that the sensor data line seems to be |
184 | * acting correctly, while watch_dog2 indicates that sensor data and | |
185 | * clock are being received. It is possible for watch_dog2 to go off | |
186 | * while watch_dog does not. This would indicate an improper clock | |
187 | * signal, while data is acting correctly. If either watch dog barks, | |
188 | * the sensor data is not being received correctly. | |
189 | */ | |
07b509e6 | 190 | |
f3fd0937 | 191 | enum error_bits_t { |
07b509e6 AB |
192 | fx_sat = 0x0001, |
193 | fy_sat = 0x0002, | |
194 | fz_sat = 0x0004, | |
195 | mx_sat = 0x0008, | |
196 | my_sat = 0x0010, | |
197 | mz_sat = 0x0020, | |
198 | memory_error = 0x0400, | |
199 | sensor_change = 0x0800, | |
200 | system_busy = 0x1000, | |
201 | cal_crc_bad = 0x2000, | |
202 | watch_dog2 = 0x4000, | |
203 | watch_dog = 0x8000 | |
f3fd0937 | 204 | }; |
07b509e6 | 205 | |
f8d791f2 | 206 | /* THRESH_STRUCT */ |
b2be969b | 207 | |
f8d791f2 AJ |
208 | /* |
209 | * This structure shows the layout for a single threshold packet inside of a | |
b2be969b BP |
210 | * load envelope. Each load envelope can contain several threshold structures. |
211 | * 1. data_address contains the address of the data for that threshold. This | |
212 | * includes filtered, unfiltered, raw, rate, counters, error and warning data | |
213 | * 2. threshold is the is the value at which, if data is above or below, the | |
214 | * bits will be set ... (pag.24). | |
215 | * 3. bit_pattern contains the bits that will be set if the threshold value is | |
216 | * met or exceeded. | |
217 | */ | |
218 | ||
38443673 | 219 | struct thresh_struct { |
07b509e6 AB |
220 | s32 data_address; |
221 | s32 threshold; | |
222 | s32 bit_pattern; | |
38443673 | 223 | }; |
07b509e6 | 224 | |
f8d791f2 | 225 | /* LE_STRUCT */ |
b2be969b | 226 | |
f8d791f2 AJ |
227 | /* |
228 | * Layout of a load enveloped packet. Four thresholds are showed ... for more | |
b2be969b BP |
229 | * see manual (pag.25) |
230 | * 1. latch_bits is a bit pattern that show which bits the user wants to latch. | |
231 | * The latched bits will not be reset once the threshold which set them is | |
232 | * no longer true. In that case the user must reset them using the reset_bit | |
233 | * command. | |
234 | * 2. number_of_xx_thresholds specify how many GE/LE threshold there are. | |
235 | */ | |
0306b0cb | 236 | struct le_struct { |
07b509e6 AB |
237 | s32 latch_bits; |
238 | s32 number_of_ge_thresholds; | |
239 | s32 number_of_le_thresholds; | |
240 | struct thresh_struct thresholds[4]; | |
241 | s32 reserved; | |
0306b0cb | 242 | }; |
07b509e6 | 243 | |
f8d791f2 AJ |
244 | /* LINK_TYPES */ |
245 | /* | |
246 | * Link types is an enumerated value showing the different possible transform | |
b2be969b BP |
247 | * link types. |
248 | * 0 - end transform packet | |
249 | * 1 - translate along X axis (TX) | |
250 | * 2 - translate along Y axis (TY) | |
251 | * 3 - translate along Z axis (TZ) | |
252 | * 4 - rotate about X axis (RX) | |
253 | * 5 - rotate about Y axis (RY) | |
254 | * 6 - rotate about Z axis (RZ) | |
255 | * 7 - negate all axes (NEG) | |
256 | */ | |
257 | ||
4e1ccd97 | 258 | enum link_types { |
07b509e6 AB |
259 | end_x_form, |
260 | tx, | |
261 | ty, | |
262 | tz, | |
263 | rx, | |
264 | ry, | |
265 | rz, | |
266 | neg | |
4e1ccd97 | 267 | }; |
07b509e6 | 268 | |
f8d791f2 AJ |
269 | /* TRANSFORM */ |
270 | /* Structure used to describe a transform. */ | |
1c31ddaf | 271 | struct intern_transform { |
07b509e6 | 272 | struct { |
54298a8d | 273 | u32 link_type; |
0642feb3 | 274 | s32 link_amount; |
07b509e6 | 275 | } link[8]; |
1c31ddaf | 276 | }; |
07b509e6 | 277 | |
f8d791f2 AJ |
278 | /* |
279 | * JR3 force/torque sensor data definition. For more information see sensor | |
280 | * and hardware manuals. | |
9ef6a833 | 281 | */ |
07b509e6 | 282 | |
67080790 | 283 | struct jr3_channel { |
f8d791f2 AJ |
284 | /* |
285 | * Raw_channels is the area used to store the raw data coming from | |
286 | * the sensor. | |
287 | */ | |
07b509e6 | 288 | |
2deee55e | 289 | struct raw_channel raw_channels[16]; /* offset 0x0000 */ |
07b509e6 | 290 | |
f8d791f2 AJ |
291 | /* |
292 | * Copyright is a null terminated ASCII string containing the JR3 | |
293 | * copyright notice. | |
294 | */ | |
07b509e6 | 295 | |
54298a8d | 296 | u32 copyright[0x0018]; /* offset 0x0040 */ |
0642feb3 | 297 | s32 reserved1[0x0008]; /* offset 0x0058 */ |
07b509e6 | 298 | |
f8d791f2 AJ |
299 | /* |
300 | * Shunts contains the sensor shunt readings. Some JR3 sensors have | |
b2be969b BP |
301 | * the ability to have their gains adjusted. This allows the |
302 | * hardware full scales to be adjusted to potentially allow | |
303 | * better resolution or dynamic range. For sensors that have | |
304 | * this ability, the gain of each sensor channel is measured at | |
305 | * the time of calibration using a shunt resistor. The shunt | |
306 | * resistor is placed across one arm of the resistor bridge, and | |
307 | * the resulting change in the output of that channel is | |
308 | * measured. This measurement is called the shunt reading, and | |
309 | * is recorded here. If the user has changed the gain of the // | |
310 | * sensor, and made new shunt measurements, those shunt | |
311 | * measurements can be placed here. The JR3 DSP will then scale | |
312 | * the calibration matrix such so that the gains are again | |
313 | * proper for the indicated shunt readings. If shunts is 0, then | |
314 | * the sensor cannot have its gain changed. For details on | |
315 | * changing the sensor gain, and making shunts readings, please | |
316 | * see the sensor manual. To make these values take effect the | |
317 | * user must call either command (5) use transform # (pg. 33) or | |
318 | * command (10) set new full scales (pg. 38). | |
319 | */ | |
07b509e6 | 320 | |
f8d791f2 AJ |
321 | struct six_axis_array shunts; /* offset 0x0060 */ |
322 | s32 reserved2[2]; /* offset 0x0066 */ | |
07b509e6 | 323 | |
f8d791f2 AJ |
324 | /* |
325 | * Default_FS contains the full scale that is used if the user does | |
326 | * not set a full scale. | |
327 | */ | |
07b509e6 | 328 | |
5671c0c2 | 329 | struct six_axis_array default_FS; /* offset 0x0068 */ |
f8d791f2 | 330 | s32 reserved3; /* offset 0x006e */ |
07b509e6 | 331 | |
f8d791f2 AJ |
332 | /* |
333 | * Load_envelope_num is the load envelope number that is currently | |
b2be969b BP |
334 | * in use. This value is set by the user after one of the load |
335 | * envelopes has been initialized. | |
336 | */ | |
07b509e6 | 337 | |
f8d791f2 | 338 | s32 load_envelope_num; /* offset 0x006f */ |
07b509e6 | 339 | |
b2be969b BP |
340 | /* Min_full_scale is the recommend minimum full scale. */ |
341 | ||
f8d791f2 AJ |
342 | /* |
343 | * These values in conjunction with max_full_scale (pg. 9) helps | |
b2be969b BP |
344 | * determine the appropriate value for setting the full scales. The |
345 | * software allows the user to set the sensor full scale to an | |
346 | * arbitrary value. But setting the full scales has some hazards. If | |
347 | * the full scale is set too low, the data will saturate | |
348 | * prematurely, and dynamic range will be lost. If the full scale is | |
349 | * set too high, then resolution is lost as the data is shifted to | |
350 | * the right and the least significant bits are lost. Therefore the | |
351 | * maximum full scale is the maximum value at which no resolution is | |
352 | * lost, and the minimum full scale is the value at which the data | |
353 | * will not saturate prematurely. These values are calculated | |
354 | * whenever a new coordinate transformation is calculated. It is | |
355 | * possible for the recommended maximum to be less than the | |
356 | * recommended minimum. This comes about primarily when using | |
357 | * coordinate translations. If this is the case, it means that any | |
358 | * full scale selection will be a compromise between dynamic range | |
359 | * and resolution. It is usually recommended to compromise in favor | |
360 | * of resolution which means that the recommend maximum full scale | |
361 | * should be chosen. | |
362 | * | |
363 | * WARNING: Be sure that the full scale is no less than 0.4% of the | |
364 | * recommended minimum full scale. Full scales below this value will | |
365 | * cause erroneous results. | |
366 | */ | |
07b509e6 | 367 | |
5671c0c2 | 368 | struct six_axis_array min_full_scale; /* offset 0x0070 */ |
f8d791f2 | 369 | s32 reserved4; /* offset 0x0076 */ |
07b509e6 | 370 | |
f8d791f2 AJ |
371 | /* |
372 | * Transform_num is the transform number that is currently in use. | |
b2be969b BP |
373 | * This value is set by the JR3 DSP after the user has used command |
374 | * (5) use transform # (pg. 33). | |
375 | */ | |
07b509e6 | 376 | |
f8d791f2 | 377 | s32 transform_num; /* offset 0x0077 */ |
07b509e6 | 378 | |
f8d791f2 AJ |
379 | /* |
380 | * Max_full_scale is the recommended maximum full scale. | |
381 | * See min_full_scale (pg. 9) for more details. | |
382 | */ | |
07b509e6 | 383 | |
5671c0c2 | 384 | struct six_axis_array max_full_scale; /* offset 0x0078 */ |
f8d791f2 | 385 | s32 reserved5; /* offset 0x007e */ |
07b509e6 | 386 | |
f8d791f2 AJ |
387 | /* |
388 | * Peak_address is the address of the data which will be monitored | |
b2be969b BP |
389 | * by the peak routine. This value is set by the user. The peak |
390 | * routine will monitor any 8 contiguous addresses for peak values. | |
391 | * (ex. to watch filter3 data for peaks, set this value to 0x00a8). | |
392 | */ | |
07b509e6 | 393 | |
f8d791f2 | 394 | s32 peak_address; /* offset 0x007f */ |
07b509e6 | 395 | |
f8d791f2 AJ |
396 | /* |
397 | * Full_scale is the sensor full scales which are currently in use. | |
b2be969b BP |
398 | * Decoupled and filtered data is scaled so that +/- 16384 is equal |
399 | * to the full scales. The engineering units used are indicated by | |
400 | * the units value discussed on page 16. The full scales for Fx, Fy, | |
401 | * Fz, Mx, My and Mz can be written by the user prior to calling | |
402 | * command (10) set new full scales (pg. 38). The full scales for V1 | |
403 | * and V2 are set whenever the full scales are changed or when the | |
404 | * axes used to calculate the vectors are changed. The full scale of | |
405 | * V1 and V2 will always be equal to the largest full scale of the | |
406 | * axes used for each vector respectively. | |
407 | */ | |
07b509e6 | 408 | |
f8d791f2 | 409 | struct force_array full_scale; /* offset 0x0080 */ |
07b509e6 | 410 | |
f8d791f2 AJ |
411 | /* |
412 | * Offsets contains the sensor offsets. These values are subtracted from | |
b2be969b BP |
413 | * the sensor data to obtain the decoupled data. The offsets are set a |
414 | * few seconds (< 10) after the calibration data has been received. | |
415 | * They are set so that the output data will be zero. These values | |
416 | * can be written as well as read. The JR3 DSP will use the values | |
417 | * written here within 2 ms of being written. To set future | |
418 | * decoupled data to zero, add these values to the current decoupled | |
419 | * data values and place the sum here. The JR3 DSP will change these | |
420 | * values when a new transform is applied. So if the offsets are | |
421 | * such that FX is 5 and all other values are zero, after rotating | |
422 | * about Z by 90 degrees, FY would be 5 and all others would be zero. | |
423 | */ | |
07b509e6 | 424 | |
f8d791f2 | 425 | struct six_axis_array offsets; /* offset 0x0088 */ |
07b509e6 | 426 | |
f8d791f2 AJ |
427 | /* |
428 | * Offset_num is the number of the offset currently in use. This | |
b2be969b BP |
429 | * value is set by the JR3 DSP after the user has executed the use |
430 | * offset # command (pg. 34). It can vary between 0 and 15. | |
431 | */ | |
07b509e6 | 432 | |
f8d791f2 | 433 | s32 offset_num; /* offset 0x008e */ |
07b509e6 | 434 | |
f8d791f2 AJ |
435 | /* |
436 | * Vect_axes is a bit map showing which of the axes are being used | |
b2be969b BP |
437 | * in the vector calculations. This value is set by the JR3 DSP |
438 | * after the user has executed the set vector axes command (pg. 37). | |
439 | */ | |
07b509e6 | 440 | |
f8d791f2 | 441 | u32 vect_axes; /* offset 0x008f */ |
07b509e6 | 442 | |
f8d791f2 AJ |
443 | /* |
444 | * Filter0 is the decoupled, unfiltered data from the JR3 sensor. | |
b2be969b BP |
445 | * This data has had the offsets removed. |
446 | * | |
447 | * These force_arrays hold the filtered data. The decoupled data is | |
448 | * passed through cascaded low pass filters. Each succeeding filter | |
449 | * has a cutoff frequency of 1/4 of the preceding filter. The cutoff | |
450 | * frequency of filter1 is 1/16 of the sample rate from the sensor. | |
451 | * For a typical sensor with a sample rate of 8 kHz, the cutoff | |
452 | * frequency of filter1 would be 500 Hz. The following filters would | |
453 | * cutoff at 125 Hz, 31.25 Hz, 7.813 Hz, 1.953 Hz and 0.4883 Hz. | |
454 | */ | |
07b509e6 | 455 | |
f8d791f2 AJ |
456 | struct force_array filter[7]; /* |
457 | * offset 0x0090, | |
458 | * offset 0x0098, | |
459 | * offset 0x00a0, | |
460 | * offset 0x00a8, | |
461 | * offset 0x00b0, | |
462 | * offset 0x00b8, | |
463 | * offset 0x00c0 | |
464 | */ | |
465 | ||
466 | /* | |
467 | * Rate_data is the calculated rate data. It is a first derivative | |
b2be969b BP |
468 | * calculation. It is calculated at a frequency specified by the |
469 | * variable rate_divisor (pg. 12). The data on which the rate is | |
470 | * calculated is specified by the variable rate_address (pg. 12). | |
471 | */ | |
07b509e6 | 472 | |
f8d791f2 | 473 | struct force_array rate_data; /* offset 0x00c8 */ |
07b509e6 | 474 | |
f8d791f2 AJ |
475 | /* |
476 | * Minimum_data & maximum_data are the minimum and maximum (peak) | |
b2be969b BP |
477 | * data values. The JR3 DSP can monitor any 8 contiguous data items |
478 | * for minimums and maximums at full sensor bandwidth. This area is | |
479 | * only updated at user request. This is done so that the user does | |
480 | * not miss any peaks. To read the data, use either the read peaks | |
481 | * command (pg. 40), or the read and reset peaks command (pg. 39). | |
482 | * The address of the data to watch for peaks is stored in the | |
483 | * variable peak_address (pg. 10). Peak data is lost when executing | |
484 | * a coordinate transformation or a full scale change. Peak data is | |
485 | * also lost when plugging in a new sensor. | |
486 | */ | |
07b509e6 | 487 | |
cdc14cd0 BP |
488 | struct force_array minimum_data; /* offset 0x00d0 */ |
489 | struct force_array maximum_data; /* offset 0x00d8 */ | |
07b509e6 | 490 | |
f8d791f2 AJ |
491 | /* |
492 | * Near_sat_value & sat_value contain the value used to determine if | |
b2be969b BP |
493 | * the raw sensor is saturated. Because of decoupling and offset |
494 | * removal, it is difficult to tell from the processed data if the | |
495 | * sensor is saturated. These values, in conjunction with the error | |
496 | * and warning words (pg. 14), provide this critical information. | |
497 | * These two values may be set by the host processor. These values | |
498 | * are positive signed values, since the saturation logic uses the | |
499 | * absolute values of the raw data. The near_sat_value defaults to | |
500 | * approximately 80% of the ADC's full scale, which is 26214, while | |
501 | * sat_value defaults to the ADC's full scale: | |
502 | * | |
503 | * sat_value = 32768 - 2^(16 - ADC bits) | |
504 | */ | |
07b509e6 | 505 | |
f8d791f2 AJ |
506 | s32 near_sat_value; /* offset 0x00e0 */ |
507 | s32 sat_value; /* offset 0x00e1 */ | |
07b509e6 | 508 | |
f8d791f2 AJ |
509 | /* |
510 | * Rate_address, rate_divisor & rate_count contain the data used to | |
b2be969b BP |
511 | * control the calculations of the rates. Rate_address is the |
512 | * address of the data used for the rate calculation. The JR3 DSP | |
513 | * will calculate rates for any 8 contiguous values (ex. to | |
514 | * calculate rates for filter3 data set rate_address to 0x00a8). | |
515 | * Rate_divisor is how often the rate is calculated. If rate_divisor | |
516 | * is 1, the rates are calculated at full sensor bandwidth. If | |
517 | * rate_divisor is 200, rates are calculated every 200 samples. | |
518 | * Rate_divisor can be any value between 1 and 65536. Set | |
519 | * rate_divisor to 0 to calculate rates every 65536 samples. | |
520 | * Rate_count starts at zero and counts until it equals | |
521 | * rate_divisor, at which point the rates are calculated, and | |
522 | * rate_count is reset to 0. When setting a new rate divisor, it is | |
523 | * a good idea to set rate_count to one less than rate divisor. This | |
524 | * will minimize the time necessary to start the rate calculations. | |
525 | */ | |
07b509e6 | 526 | |
f8d791f2 AJ |
527 | s32 rate_address; /* offset 0x00e2 */ |
528 | u32 rate_divisor; /* offset 0x00e3 */ | |
529 | u32 rate_count; /* offset 0x00e4 */ | |
07b509e6 | 530 | |
f8d791f2 AJ |
531 | /* |
532 | * Command_word2 through command_word0 are the locations used to | |
b2be969b BP |
533 | * send commands to the JR3 DSP. Their usage varies with the command |
534 | * and is detailed later in the Command Definitions section (pg. | |
535 | * 29). In general the user places values into various memory | |
536 | * locations, and then places the command word into command_word0. | |
537 | * The JR3 DSP will process the command and place a 0 into | |
538 | * command_word0 to indicate successful completion. Alternatively | |
539 | * the JR3 DSP will place a negative number into command_word0 to | |
540 | * indicate an error condition. Please note the command locations | |
541 | * are numbered backwards. (I.E. command_word2 comes before | |
542 | * command_word1). | |
543 | */ | |
07b509e6 | 544 | |
f8d791f2 AJ |
545 | s32 command_word2; /* offset 0x00e5 */ |
546 | s32 command_word1; /* offset 0x00e6 */ | |
547 | s32 command_word0; /* offset 0x00e7 */ | |
07b509e6 | 548 | |
f8d791f2 AJ |
549 | /* |
550 | * Count1 through count6 are unsigned counters which are incremented | |
b2be969b BP |
551 | * every time the matching filters are calculated. Filter1 is |
552 | * calculated at the sensor data bandwidth. So this counter would | |
553 | * increment at 8 kHz for a typical sensor. The rest of the counters | |
554 | * are incremented at 1/4 the interval of the counter immediately | |
555 | * preceding it, so they would count at 2 kHz, 500 Hz, 125 Hz etc. | |
556 | * These counters can be used to wait for data. Each time the | |
557 | * counter changes, the corresponding data set can be sampled, and | |
558 | * this will insure that the user gets each sample, once, and only | |
559 | * once. | |
560 | */ | |
07b509e6 | 561 | |
f8d791f2 AJ |
562 | u32 count1; /* offset 0x00e8 */ |
563 | u32 count2; /* offset 0x00e9 */ | |
564 | u32 count3; /* offset 0x00ea */ | |
565 | u32 count4; /* offset 0x00eb */ | |
566 | u32 count5; /* offset 0x00ec */ | |
567 | u32 count6; /* offset 0x00ed */ | |
07b509e6 | 568 | |
f8d791f2 AJ |
569 | /* |
570 | * Error_count is a running count of data reception errors. If this | |
b2be969b BP |
571 | * counter is changing rapidly, it probably indicates a bad sensor |
572 | * cable connection or other hardware problem. In most installations | |
573 | * error_count should not change at all. But it is possible in an | |
574 | * extremely noisy environment to experience occasional errors even | |
575 | * without a hardware problem. If the sensor is well grounded, this | |
576 | * is probably unavoidable in these environments. On the occasions | |
577 | * where this counter counts a bad sample, that sample is ignored. | |
578 | */ | |
07b509e6 | 579 | |
f8d791f2 | 580 | u32 error_count; /* offset 0x00ee */ |
07b509e6 | 581 | |
f8d791f2 AJ |
582 | /* |
583 | * Count_x is a counter which is incremented every time the JR3 DSP | |
b2be969b BP |
584 | * searches its job queues and finds nothing to do. It indicates the |
585 | * amount of idle time the JR3 DSP has available. It can also be | |
586 | * used to determine if the JR3 DSP is alive. See the Performance | |
587 | * Issues section on pg. 49 for more details. | |
588 | */ | |
07b509e6 | 589 | |
f8d791f2 | 590 | u32 count_x; /* offset 0x00ef */ |
07b509e6 | 591 | |
f8d791f2 AJ |
592 | /* |
593 | * Warnings & errors contain the warning and error bits | |
b2be969b BP |
594 | * respectively. The format of these two words is discussed on page |
595 | * 21 under the headings warnings_bits and error_bits. | |
596 | */ | |
07b509e6 | 597 | |
f8d791f2 AJ |
598 | u32 warnings; /* offset 0x00f0 */ |
599 | u32 errors; /* offset 0x00f1 */ | |
07b509e6 | 600 | |
f8d791f2 AJ |
601 | /* |
602 | * Threshold_bits is a word containing the bits that are set by the | |
b2be969b BP |
603 | * load envelopes. See load_envelopes (pg. 17) and thresh_struct |
604 | * (pg. 23) for more details. | |
605 | */ | |
07b509e6 | 606 | |
f8d791f2 | 607 | s32 threshold_bits; /* offset 0x00f2 */ |
07b509e6 | 608 | |
f8d791f2 AJ |
609 | /* |
610 | * Last_crc is the value that shows the actual calculated CRC. CRC | |
b2be969b BP |
611 | * is short for cyclic redundancy code. It should be zero. See the |
612 | * description for cal_crc_bad (pg. 21) for more information. | |
613 | */ | |
07b509e6 | 614 | |
f8d791f2 | 615 | s32 last_CRC; /* offset 0x00f3 */ |
07b509e6 | 616 | |
f8d791f2 AJ |
617 | /* |
618 | * EEProm_ver_no contains the version number of the sensor EEProm. | |
b2be969b BP |
619 | * EEProm version numbers can vary between 0 and 255. |
620 | * Software_ver_no contains the software version number. Version | |
621 | * 3.02 would be stored as 302. | |
622 | */ | |
07b509e6 | 623 | |
f8d791f2 AJ |
624 | s32 eeprom_ver_no; /* offset 0x00f4 */ |
625 | s32 software_ver_no; /* offset 0x00f5 */ | |
07b509e6 | 626 | |
f8d791f2 AJ |
627 | /* |
628 | * Software_day & software_year are the release date of the software | |
b2be969b BP |
629 | * the JR3 DSP is currently running. Day is the day of the year, |
630 | * with January 1 being 1, and December 31, being 365 for non leap | |
631 | * years. | |
632 | */ | |
07b509e6 | 633 | |
f8d791f2 AJ |
634 | s32 software_day; /* offset 0x00f6 */ |
635 | s32 software_year; /* offset 0x00f7 */ | |
07b509e6 | 636 | |
f8d791f2 AJ |
637 | /* |
638 | * Serial_no & model_no are the two values which uniquely identify a | |
b2be969b BP |
639 | * sensor. This model number does not directly correspond to the JR3 |
640 | * model number, but it will provide a unique identifier for | |
641 | * different sensor configurations. | |
642 | */ | |
07b509e6 | 643 | |
f8d791f2 AJ |
644 | u32 serial_no; /* offset 0x00f8 */ |
645 | u32 model_no; /* offset 0x00f9 */ | |
07b509e6 | 646 | |
f8d791f2 AJ |
647 | /* |
648 | * Cal_day & cal_year are the sensor calibration date. Day is the | |
b2be969b BP |
649 | * day of the year, with January 1 being 1, and December 31, being |
650 | * 366 for leap years. | |
651 | */ | |
07b509e6 | 652 | |
f8d791f2 AJ |
653 | s32 cal_day; /* offset 0x00fa */ |
654 | s32 cal_year; /* offset 0x00fb */ | |
07b509e6 | 655 | |
f8d791f2 AJ |
656 | /* |
657 | * Units is an enumerated read only value defining the engineering | |
b2be969b BP |
658 | * units used in the sensor full scale. The meanings of particular |
659 | * values are discussed in the section detailing the force_units | |
660 | * structure on page 22. The engineering units are setto customer | |
661 | * specifications during sensor manufacture and cannot be changed by | |
662 | * writing to Units. | |
663 | * | |
664 | * Bits contains the number of bits of resolution of the ADC | |
665 | * currently in use. | |
666 | * | |
667 | * Channels is a bit field showing which channels the current sensor | |
668 | * is capable of sending. If bit 0 is active, this sensor can send | |
669 | * channel 0, if bit 13 is active, this sensor can send channel 13, | |
670 | * etc. This bit can be active, even if the sensor is not currently | |
671 | * sending this channel. Some sensors are configurable as to which | |
672 | * channels to send, and this field only contains information on the | |
673 | * channels available to send, not on the current configuration. To | |
674 | * find which channels are currently being sent, monitor the | |
675 | * Raw_time fields (pg. 19) in the raw_channels array (pg. 7). If | |
676 | * the time is changing periodically, then that channel is being | |
677 | * received. | |
678 | */ | |
07b509e6 | 679 | |
f8d791f2 AJ |
680 | u32 units; /* offset 0x00fc */ |
681 | s32 bits; /* offset 0x00fd */ | |
682 | s32 channels; /* offset 0x00fe */ | |
07b509e6 | 683 | |
f8d791f2 AJ |
684 | /* |
685 | * Thickness specifies the overall thickness of the sensor from | |
b2be969b BP |
686 | * flange to flange. The engineering units for this value are |
687 | * contained in units (pg. 16). The sensor calibration is relative | |
688 | * to the center of the sensor. This value allows easy coordinate | |
689 | * transformation from the center of the sensor to either flange. | |
690 | */ | |
07b509e6 | 691 | |
f8d791f2 | 692 | s32 thickness; /* offset 0x00ff */ |
07b509e6 | 693 | |
f8d791f2 AJ |
694 | /* |
695 | * Load_envelopes is a table containing the load envelope | |
b2be969b BP |
696 | * descriptions. There are 16 possible load envelope slots in the |
697 | * table. The slots are on 16 word boundaries and are numbered 0-15. | |
698 | * Each load envelope needs to start at the beginning of a slot but | |
699 | * need not be fully contained in that slot. That is to say that a | |
700 | * single load envelope can be larger than a single slot. The | |
701 | * software has been tested and ran satisfactorily with 50 | |
702 | * thresholds active. A single load envelope this large would take | |
703 | * up 5 of the 16 slots. The load envelope data is laid out in an | |
704 | * order that is most efficient for the JR3 DSP. The structure is | |
705 | * detailed later in the section showing the definition of the | |
706 | * le_struct structure (pg. 23). | |
707 | */ | |
07b509e6 | 708 | |
0306b0cb | 709 | struct le_struct load_envelopes[0x10]; /* offset 0x0100 */ |
07b509e6 | 710 | |
f8d791f2 AJ |
711 | /* |
712 | * Transforms is a table containing the transform descriptions. | |
b2be969b BP |
713 | * There are 16 possible transform slots in the table. The slots are |
714 | * on 16 word boundaries and are numbered 0-15. Each transform needs | |
715 | * to start at the beginning of a slot but need not be fully | |
716 | * contained in that slot. That is to say that a single transform | |
717 | * can be larger than a single slot. A transform is 2 * no of links | |
718 | * + 1 words in length. So a single slot can contain a transform | |
719 | * with 7 links. Two slots can contain a transform that is 15 links. | |
720 | * The layout is detailed later in the section showing the | |
721 | * definition of the transform structure (pg. 26). | |
722 | */ | |
07b509e6 | 723 | |
1c31ddaf | 724 | struct intern_transform transforms[0x10]; /* offset 0x0200 */ |
67080790 | 725 | }; |
07b509e6 | 726 | |
b2e1b3c2 | 727 | struct jr3_t { |
07b509e6 | 728 | struct { |
127301cb | 729 | u32 program_lo[0x4000]; /* 0x00000 - 0x10000 */ |
67080790 | 730 | struct jr3_channel data; /* 0x10000 - 0x10c00 */ |
b2be969b | 731 | char pad2[0x30000 - 0x00c00]; /* 0x10c00 - 0x40000 */ |
127301cb HS |
732 | u32 program_hi[0x8000]; /* 0x40000 - 0x60000 */ |
733 | u32 reset; /* 0x60000 - 0x60004 */ | |
b2be969b | 734 | char pad3[0x20000 - 0x00004]; /* 0x60004 - 0x80000 */ |
07b509e6 | 735 | } channel[4]; |
b2e1b3c2 | 736 | }; |