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