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