SLAU132V User guide | 德州仪器 TI.com.cn

SLAU132V October 2004 – February 2020

1
1. 2
2. 3
3. 4
4. 5
5. 6
7
1. 8
2. 9
3. 10
4. 11
5. 12
13
1. 14
2. 15
3. 16
  1. 17
  2. 18
  3. 19
  4. 20
  5. 21
  6. 22
  7. 23
  8. 24
  9. 25
  10. 26
  11. 27
  12. 28
4. 29
  1. 30
  2. 31
5. 32
  1. 33
  2. 34
    1. 35
  3. 36
  4. 37
  5. 38
  6. 39
  7. 40
  8. 41
  9. 42
  10. 43
6. 44
7. 45
  1. 46
  2. 47
8. 48
9. 49
10. 50
11. 51
  1. 52
  2. 53
12. 54
  1. 55
13. 56
14. 57
58
1. 59
2. 60
3. 61
  1. 62
4. 63
  1. 64
  2. 65
5. 66
6. 67
  1. 68
  2. 69
7. 70
  1. 71
    1. 72
    2. 73
    3. 74
    4. 75
    5. 76
    6. 77
    7. 78
    8. 79
  2. 80
  3. 81
  4. 82
8. 83
  1. 84
    1. 85
    2. 86
  2. 87
    1. 88
    2. 89
    3. 90
9. 91
10. 92
11. 93
  1. 94
  2. 95
12. 96
13. 97
  1. 98
  2. 99
  3. 100
  4. 101
  5. 102
  6. 103
  7. 104
  8. 105
  9. 106
  10. 107
  11. 108
  12. 109
  13. 110
111
1. 112
  1. 113
  2. 114
  3. 115
2. 116
  1. 117
  2. 118
3. 119
  1. 120
    1. 121
      1. 122
    2. 123
    3. 124
  2. 125
  3. 126
  4. 127
  5. 128
  6. 129
  7. 130
  8. 131
  9. 132
    1. 133
134
1. 135
  1. 136
2. 137
3. 138
4. 139
5. 140
6. 141
  1. 142
7. 143
8. 144
  1. 145
  2. 146
  3. 147
    1. 148
    2. 149
  4. 150
    1. 151
9. 152
10. 153
11. 154
12. 155
  1. 156
  2. 157
  3. 158
  4. 159
  5. 160
  6. 161
    1. 162
    2. 163
    3. 164
    4. 165
  7. 166
  8. 167
    1. 168
    2. 169
    3. 170
  9. 171
  10. 172
  11. 173
  12. 174
  13. 175
  14. 176
  15. 177
  16. 178
  17. 179
  18. 180
  19. 181
  20. 182
  21. 183
  22. 184
  23. 185
  24. 186
  25. 187
  26. 188
  27. 189
  28. 190
  29. 191
  30. 192
    1. 193
    2. 194
    3. 195
  31. 196
  32. 197
13. 198
14. 199
15. 200
16. 201
  1. 202
  2. 203
  3. 204
17. 205
  1. 206
  2. 207
  3. 208
  4. 209
  5. 210
18. 211
212
1. 213
  1. 214
  2. 215
  3. 216
  4. 217
  5. 218
  6. 219
2. 220
  1. 221
    1. 222
    2. 223
    3. 224
    4. 225
  2. 226
3. 227
4. 228
  1. 229
  2. 230
  3. 231
5. 232
6. 233
  1. 234
  2. 235
    1. 236
    2. 237
  3. 238
    1. 239
      1. 240
      2. 241
    2. 242
      1. 243
      2. 244
  4. 245
  5. 246
7. 247
  1. 248
  2. 249
  3. 250
  4. 251
  5. 252
8. 253
  1. 254
  2. 255
  3. 256
  4. 257
    1. 258
      1. 259
    2. 260
      1. 261
9. 262
  1. 263
  2. 264
  3. 265
    1. 266
    2. 267
    3. 268
    4. 269
      1. 270
      2. 271
      3. 272
      4. 273
    5. 274
    6. 275
  4. 276
    1. 277
    2. 278
10. 279
280
1. 281
  1. 282
  2. 283
  3. 284
  4. 285
  5. 286
  6. 287
  7. 288
  8. 289
2. 290
  1. 291
    1. 292
  2. 293
  3. 294
  4. 295
    1. 296
  5. 297
    1. 298
3. 299
4. 300
  1. 301
  2. 302
    1. 303
    2. 304
      1. 305
      2. 306
      3. 307
      4. 308
  3. 309
    1. 310
    2. 311
312
1. 313
2. 314
  1. 315
  2. 316
  3. 317
318
1. 319
320
1. 321

5.17.2 Function Attributes

The following GCC function attributes are supported:

alias
aligned
always_inline
call_conv
calls
const
constructor
deprecated
format
format_arg
interrupt
malloc
naked
noinline
noreturn
pure
ramfunc
section
unused
used
warn_unused_result
weak

The following additional TI-specific function attribute is supported:

retain

For example, this function declaration uses the alias attribute to make "my_alias" a function alias for the "myFunc" function:

void my_alias() __attribute__((alias("myFunc")));

The aligned function attribute has the same effect as the CODE_ALIGN pragma. See Section 5.12.5

The always_inline function attribute has the same effect as the FUNC_ALWAYS_INLINE pragma. See Section 5.12.12

The call_conv attribute can be used to modify the calling conventions to allow both the IAR and TI compilers to link against the same ROM image. This function attribute allows functions compiled with the TI compiler to be linked with a ROM image generated by the IAR compiler. Note that the TI compiler does not generate ROM images.

The call_conv attribute can be specified with "cc_rom" (for IAR/TI compatibility) or "cc_norm" (the default calling convention). Use "cc_rom" if you want to share a ROM image compiled with IAR. The following example uses the call_conv attribute in several ways:

#define __cc_rom __attribute__((call_conv("cc_rom"))) 
 
__cc_rom void rom_func(void)
{
   ...
}

typedef __cc_rom void (rom_func_t)(void);
 
int main()
{
   rom_func();
 
   rom_func_t *fp = (rom_func_t*)0x1234; 
   fp();
 
   ((void (__cc_rom *)(void))0x2468)();
 
   void (__cc_rom *rom_func_ptr)(void); 
   rom_func_ptr = &rom_func;
   rom_func_ptr();
}

If you want IAR/TI compatibility with your calling conventions, be aware of the following restrictions on parameter passing.

All parameters combined must fit in registers. Registers may not be passed on the stack.
Only scalar parameters are allowed. Do not pass structs.
Do not pass function pointers, enums, or doubles.
For single registers, use R12,13,14,15 in that order.
For register pairs, use R12:R13 or R14:R15 in that order.
For register quads, use R12:R13:R14:R15.
For MSP430, always use CALL/RET.
For MSP430x always uses CALLA/RETA.
For save-on-call registers, use R11-R15.
For save-on-entry registers, use R4-R10.

The calls attribute has the same effect as the CALLS pragma, which is described in Section 5.12.2.

The format attribute is applied to the declarations of printf, fprintf, sprintf, snprintf, vprintf, vfprintf, vsprintf, vsnprintf, scanf, fscanf, vfscanf, vscanf, vsscanf, and sscanf in stdio.h. Thus when GCC extensions are enabled, the data arguments of these functions are type checked against the format specifiers in the format string argument and warnings are issued when there is a mismatch. These warnings can be suppressed in the usual ways if they are not desired.

See Section 5.12.20 for more about using the interrupt function attribute.

The malloc attribute is applied to the declarations of malloc, calloc, realloc and memalign in stdlib.h.

The naked attribute identifies functions that are written as embedded assembly functions using __asm statements. The compiler does not generate prologue and epilog sequences for such functions. See Section 5.11.

The noinline function attribute has the same effect as the FUNC_CANNOT_INLINE pragma. See Section 5.12.13

The ramfunc attribute specifies that a function will be placed in and executed from RAM. The ramfunc attribute allows the compiler to optimize functions for RAM execution, as well as to automatically copy functions to RAM on flash-based devices. For example:

__attribute__((ramfunc))
void f(void) {
   ... 
}

The --ramfunc=on option specifies that all functions compiled with this option are placed in and executed from RAM, even if this function attribute is not used.

Newer TI linker command files support the ramfunc attribute automatically by placing functions with this attribute in the .TI.ramfunc section. If you have a linker command file that does not include a section specification for the .TI.ramfunc section, you can modify the linker command file to place this section in RAM. See the Placing functions in RAM wiki page for more about the ramfunc attribute and option. See the MSP430 Assembly Language Tools User's Guide for details on section placement.

The retain attribute has the same effect as the RETAIN pragma (Section 5.12.29). That is, the section that contains the function will not be omitted from conditionally linked output even if it is not referenced elsewhere in the application.

The section attribute when used on a function has the same effect as the CODE_SECTION pragma. See Section 5.12.6

The weak attribute has the same effect as the WEAK pragma (Section 5.12.32).