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