This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C1294NCPDT: How to create and use a variable in TI Assembly?

Part Number: TM4C1294NCPDT

I'm not sure if this is the forum I should be asking this question, but it's the closer I found.

I want to create a variable in assembly and use it in two functions that are in the same assembly file. Reading the ARM Assembly Language Tools User's Guide I could make it work just like the example code below:

; create an uninitialized section named variable with 4 bytes
; is this how a variable is created is TI Assembly?
    .bss variable, 4
    
; I written this but I don't know how it works
; without this line code doesn't work
variable_addr    .field variable, 32
    
    .text
    .global foo
    .global bar

; the functions are just to show how I am trying to use the variable
    
foo:
    ldr   r1, variable_addr  ; load the address of the variable in R1
    ldr   r2, #0x01 
    str   r2, [r1]           ; save 0x01 in the variable
    bx    lr
    
bar:
    ldr   r1, variable_addr
    ; ....
    ; do something with the variable
    ; ....
    bx    lr

Am I creating and using variables the right way? I read the docs, I read a lot of forum questions, but I still don't know how to do that.

I know the variable is created in line 3, I just don't know how to use it without that .field thing.

  • I think I can have posted in the wrong forum. Can anyone move this question to the appropriate forum or direct me to the right one so I can make this question there?
  • rrd said:
    direct me to the right one  [Forum]

    Do note that this vendor provides an advanced, "C-based",  API - and has properly focused their efforts therein.      The use of (other) coding methods adds, "complexity - time expenditure - detail" - which reduces forum effectiveness.

    From atop the forum page - w/in vendor's "Red Style Bar" - click:  "Forums" > "Development Tools" > "Code Composer Studio."

    I've noted (some) ASM questions there - if not optimal - this (at least) gets you "closer."

    It remains unclear if your review of CCS has uncovered the presentation of (necessary) "ASM Usage."    (Firm/I employ "IAR" - thus I'm powerless to advise further.)     Note that there are MANY pages - filled w/ "high-detail" - devoted to ASM w/in the PRO IDEs (IAR, Keil).    (even w/in the "FREE" code-size limited versions - and such "ASM detail" may overlap your efforts - (even) w/the (limited) vendor offering, here.)

    While not "vendor specific" (that's a key consideration - is it not) Joseph Yiu's book,  "The Definitive Guide to the ARM Cortex M3/M4" - provides, "Guidance & Direction" re: ASM.     (although w/out the detail offered by IAR.)

  • What you are doing is correct. The .bss (block starting with symbol) reserves 4 bytes which the linker will put into RAM. Line 7, creates a place in the flash (.text section) near your assembly code that will contain the address of "variable". In line 16, the assembler translates this instruction to load into r1, the value stored at the location of the PC minus an offset. The offset cause the value stored at "variable_addr" to be loaded into r1.

    Your logical question might be, Why can't we just load the value stored at "variable" directly, why do we need to load an address first? The answer lies in the fact that the assembly language instructions are limited by the hardware. In this case, the size of the offset is limited. The RAM maybe (and in fact is) too far away for the offset to be represented in the number of bits allocated within the LDR opcode. For more information on Cortex M4 assembly language, please refer to: static.docs.arm.com/.../DDI0403E_B_armv7m_arm.pdf
  • Bob - again - my belief is you have gone, "Above/Beyond."

    That ARM doc IS 916 pages - and covers ARM v7-A and v7-R (more advanced MCUs) along w/  "v7-M"  (the MCU here).

    Poster must confine his "findings" to the v7-M manual sections.     (unless the data is specifically noted as "universal - for all variants.")    This has "tripped" others - thus my note...