Difference between revisions of "PF EEPROM"
From DIDEAS Wiki
m (→keys.py) |
m |
||
Line 35: | Line 35: | ||
*SC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port | *SC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port | ||
*MC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port | *MC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port | ||
+ | |||
+ | = 16 bit keys = | ||
+ | |||
+ | ==RUN_LEVEL== | ||
+ | As the robot is tested and brought to full operational, the RUN LEVEL in increment to enable features and the use of tables. A run level of 0, -1, or non-existent RUN_LEVEL key (blank EEPROM) forces the use of NO features. | ||
+ | == KEY_REVISION_NUMBER == | ||
+ | |||
+ | ==FEATURE_BITS == | ||
+ | |||
+ | |||
+ | == KEY_SERIAL_NUMBER == | ||
+ | There are 3 keys in this set. These specifiy the serial numbers of the SC/MC, FET board, and IMU. Of course - on must be diligent to built the robot to be consistent with the serial numbers - as these KEYs do not reside on the other PCBs. Eg (the FET board has no EEPROM.) | ||
+ | |||
+ | |||
+ | == ENHANCED_FEATURE_BITS == | ||
+ | * USE_FF_K3 - enables the use of force field that protects from a K3 break | ||
+ | * USE_FF_TB - enables the use of force field that keeps ball nut from coliding with thrust bearing | ||
+ | * USE_OVERLOAD - enabled the use of the overload monitor | ||
+ | * USE_MILE - forces the use of the MILE encoder (backwards, encoder count of 2048), other wise the MR encoder is used (forwards, 2000 counts) | ||
+ | * DO_ENC_OFFSET_VERIFY - enables the test that verifies encoder offset (and checks for MILE encoder) | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | * DO_MODE2_CHECK - this is a necessary step to set the encoder offset for motor commutation. If MODE2 is not entered, then only motor modes 0 and 2 are available. MODE2 can be entered with various special commands. | ||
+ | |||
+ | == ABS_ENC_OFFSET == | ||
+ | For instant on (or for verification) this is the expected value of the absolute (motor) encoder when motor incremental is zeroed in MODE2. | ||
+ | |||
+ | == OVERLOAD PARAMETERS == | ||
+ | |||
+ | =32 bit keys= | ||
+ | == FUP_BAUD == | ||
+ | * Two keys, SC_FUP_BUAD, and MC_FUP_BAUD. | ||
+ | * Allows the baud rate of the FUP ports to be specified | ||
+ | * Note - the actual baud rate my differ from the one specified as only certain baud rates are available based on the clock frequency of the CPU. | ||
+ | * In general, assume that a baud rate must on of : 40,000,000 / 16 / n where n is an integer. | ||
+ | * Baud rate errors of +- a few percent are usually acceptable. | ||
+ | |||
+ | |||
+ | |||
+ | == FORCE FIELD PARAMETERS == | ||
+ | * Two key sets - FF_K3 and FF_TB | ||
+ | ** FF_K3 uses the hall angle sensor to limit motion when compressing K3 (or if K3 breaks.) | ||
+ | ** FF_TB uses the motor encoder to limit motion of the ball-nut that would result in contact with the thrust bearing | ||
+ | |||
+ | |||
+ | |||
=(tags SPLD3) EEPROM init table = | =(tags SPLD3) EEPROM init table = |
Revision as of 14:55, 3 November 2009
PF Users Navigation:
- PCB; Lifefix_users; Pf_users; benchtest_users; CalibFix Users; Hardware; Assembly ; iochan ;
- PCA : PCB ; AKENC SC/MC 218 ; FET 217 ; IMU219 ; Swifi ; Rev200_mods ; PCA Inventory
- Special Commands to the Ankle (PFCMD) : State Controller Commands; Motor Controller Commands; Python Examples; IMU Commands ;PFCMD_PY; Pf_calb_table_py; Virtual spring test; PF EEPROM
- DOC: Pf_users; Powerfoot Keyboard User Interface; Steps for Manual Tuning; "Dashboard" Program For Assisting with Tuning
- NEW (CEB) WIKI
- Torque Feedback Controller Guide
Contents
EEPROM init registry (SC SVN revision > 1611)
- During boot, the robot loads critical variables from its "init table registry"
- keys are define in : '../StateControl/eeprom_keys.h';
- the python program "keys.py" uses this file to permit keys to be referenced by name
- at present 16 and 32 bit unsigned int keys are support
- NOTE : python ignores the redundant part of a key name "KEY_"
keys.py
print ' -p COM port / or IP address port' print ' -b baudrate' print ' -i <name or IP address> : IP address of the SWIFI' print ' -r read keys by name that follow (multiple keys allowed)' print ' -w write key values by name, value that follow (multiple key values are allowed) (NOTE:after -w, only -r and -w options are processed)' print ' -f process script file' print ' -D generation keys.h wiki documentation file' print ' -l log file name ' print ' -V verify : after writing ALL values, will go back and verify them. (def=TRUE)' print print 'example: keys.py -p 26 -V -r serial_number run_level -w run_level 22 -r run_level' print
Documentation file
- filename = ../StateControl/eeprom_keys.h
- created @ 2009-10-31 12:04:46
EEPROM_KEYS_16_BIT
- SERIAL_NUMBER : serial number of the installed SC/MC board : eg 9
- RUN_LEVEL : a simpler way to specifying the progress of bringing and demoing a robot
- FEATURE_BITS : bits the enabled the use of specific features (currently conflicts w/run level)
- REVISION_NUMBER : serial number of the installed SC/MC board : eg 200
EEPROM_KEYS_32_BIT
- SC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port
- MC_FUP_BAUD : at present unused, but will be used to set the baudrate of the SC FUP port
16 bit keys
RUN_LEVEL
As the robot is tested and brought to full operational, the RUN LEVEL in increment to enable features and the use of tables. A run level of 0, -1, or non-existent RUN_LEVEL key (blank EEPROM) forces the use of NO features.
KEY_REVISION_NUMBER
FEATURE_BITS
KEY_SERIAL_NUMBER
There are 3 keys in this set. These specifiy the serial numbers of the SC/MC, FET board, and IMU. Of course - on must be diligent to built the robot to be consistent with the serial numbers - as these KEYs do not reside on the other PCBs. Eg (the FET board has no EEPROM.)
ENHANCED_FEATURE_BITS
- USE_FF_K3 - enables the use of force field that protects from a K3 break
- USE_FF_TB - enables the use of force field that keeps ball nut from coliding with thrust bearing
- USE_OVERLOAD - enabled the use of the overload monitor
- USE_MILE - forces the use of the MILE encoder (backwards, encoder count of 2048), other wise the MR encoder is used (forwards, 2000 counts)
- DO_ENC_OFFSET_VERIFY - enables the test that verifies encoder offset (and checks for MILE encoder)
- DO_MODE2_CHECK - this is a necessary step to set the encoder offset for motor commutation. If MODE2 is not entered, then only motor modes 0 and 2 are available. MODE2 can be entered with various special commands.
ABS_ENC_OFFSET
For instant on (or for verification) this is the expected value of the absolute (motor) encoder when motor incremental is zeroed in MODE2.
OVERLOAD PARAMETERS
32 bit keys
FUP_BAUD
- Two keys, SC_FUP_BUAD, and MC_FUP_BAUD.
- Allows the baud rate of the FUP ports to be specified
- Note - the actual baud rate my differ from the one specified as only certain baud rates are available based on the clock frequency of the CPU.
- In general, assume that a baud rate must on of : 40,000,000 / 16 / n where n is an integer.
- Baud rate errors of +- a few percent are usually acceptable.
FORCE FIELD PARAMETERS
- Two key sets - FF_K3 and FF_TB
- FF_K3 uses the hall angle sensor to limit motion when compressing K3 (or if K3 breaks.)
- FF_TB uses the motor encoder to limit motion of the ball-nut that would result in contact with the thrust bearing
(tags SPLD3) EEPROM init table
- The defaults 'feature bits' set in statemachine.h are basically ignored (6-28-09). Although loaded in sm_init.c, they're overwritten in demux_sm - where it reads the the EEPROM init table.
- if FEATURE_MC_CURRENT_UPDATES is NOT SET, then demux_sm skips the states that boot MC through mode 2
- if FEATURE_USE_IMU is set, then after MC is boot (immediately before RUN_TIME), the dataport_select is set to two, and the IMU communications is enabled.
(PRE SPLD 3) Problems / Goals
- need to be able to cleanly specify to boot too.
- great a global called 'run_level'. Each thing that gets turned on has a minimum level.
- what if a 'needed' table isn't loaded - eg calibration table.
- possibly this type of error should limit the maximum level of boot capability. eg no calb table, then at most we remain in a mode that will allow for calibration