LMX2820EVM: TICS Pro Control Names

Nevermind, just found that mouse-over on the TICS Pro software reveals the Control Names

I'll add a couple of quick remarks:

• Mousing over controls in TICS Pro can reveal their control names. There's also the profile INI files (C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\...\<name>.ini) which have a listing of all defined fields and controls. But it's currently a little complicated to parse this.
  • In the main profile INI (either has the same name as the directory, or is defined explicitly by a key in device.ini), the [BITS] section has every field listed. The name used should correspond to the NAME key. 
    • If the NAME isn't a valid python identifier, invalid characters are replaced with "_". Mousing over the control if uncertain is usually the best way to confirm what TICS Pro thinks the control is named.
    • If the field NAME value is also the value of any LINKEDBITS Key, it is "linked" and this name isn't technically used anywhere. The name to use when accessing this field is the name of the first field which starts the LINKEDBITS chain.
      • For instance, if we have PLL_N, PLL_N[15:8], and PLL_N[23:16], there's a good chance the last two fields are the LINKEDBITS of the previous two fields. PLL_N would be used as the name to access all of these fields, as it's the only "real" field.
    • If the DISPLAY key is false, and the field is not located on a subsequent page, the field is not accessible through APIs at the moment. This will change in subsequent versions of TICS Pro, but for now it's a known limitation.
  • In the main profile INI, under the [FLEXES] section, there are several DEFINITION_FILES keys which correspond to the names of several other INI files. These other INI files define the controls that are displayed on other pages.
    • Any control defined in these other INI files should be available to APIs by the section name.
    • If the section name also matches an existing name in the main profile INI [BITS] section NAME keys, i.e. if it's a field that exists, that control will be linked to register map actions and will be accessible to APIs even if the DISPLAY key is false (or the "hidden" key is true, in the other INIs).
• SetIndex, SetText, and SetFieldValue all behave slightly differently.
  • SetFieldValue directly sets a field to a value. It only works on controls that have defined fields.
  • SetIndex sets an indexable control to an index. For fields this is usually just the field value, but might be different if the field is defined as a SmartList in the main profile INI, as SmartLists can rearrange their indices. SetIndex works on both fields and non-field controls.
  • SetText sets the text of a control to a value as long as the control has some text indication. 
  • Problematically, we have some instances of controls where the representation differs between pages or from the UserControls page representation. It's not clear to me how the APIs resolve in this case, but I know that it picks one of the control representations and only one of them. I think it's deterministic.

99% of the time the APIs work fine, but there's some edge cases that aren't thought through. I don't think you'll encounter any of them in LMX2820. We are steadily working on making the TCP API less clunky to use, so if you have any specific feedback after some usage or if you suspect something doesn't work right, please let us know.