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