AS7 variables bug

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 2 bytes variable is displayed as a 4 bytes (double word) variable.

 

ADC_ch5:                    .byte    2          ; ADC previous ch5 readings

 

Also hovering the pointer over the variable name shows it a as a dword.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see what's happening. The "value" is NOT the data in the variable but the address of it, I checked it by watching a couple more variables and it's their address rather that the data they contain

 

ie completely stuffed like a capsicum.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way this has been stuffed in various ways for at least 2.5 years! https://www.avrfreaks.net/forum/w...

 

And since it has been such a long time it is likely that the kids working on programming Studio have never seen what the widow should look like so here it is.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We have at least two tickets in the bug tracking system, and they are both closed with the following working procedure:

 

For AVR8 , nonGDB, Assembly Projects :

 

To view the content of the variable use "BY " , "WO " , or "DW " before the location in the watch view. This will treat it as a pointer that can be dereferenced to byte, word, or dword respectively.
E.g. instead of watching "VariableName", watch "BY VariableName".

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To view the content of the variable use "BY " , "WO " , or "DW " before the location in the watch view.

For heaven's sake that was 2.5 years ago, I don't want a "workaround" I want a fix! PLEASE!

 

Also the value is WRONG, it is showing the address of the variable not it's contents. And why is everything 32 bits when I'm working with an 8 bits processor?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I re-opened TSD-464, but need some help in defining desired behaviour.

 

The rules are a bit confusing, and the kiddies coding this have not used assembly for the last 30-40 years.

Could you perhaps make a list of what is expected from watching an EQU, a .byte , dd dw etc ?

Some of these directives take a repeat argument. Does that turn the label into a pointer ?

I.e:

 

scalarvalue:  .byte 1

vectorvalue: .byte 2

 

In the OP, you are declaring an array of two bytes, so in a way it does makes sense to evaluate to a pointer (type=DWORD being just wrong)

If you wanted to declare a 2 byte variable you might have said  "Variable: .word 1" (Update: I've learned the assembler does not have .word or .dword )

 

What do you think ? Should all "BYTE n" be treated as an n-byte scalar ?

 

 

Last Edited: Tue. Oct 13, 2015 - 12:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I should be in bed sleeping but anyway....

 

Tried to open the assembly Help file in AS7 and it doesn't seem to exist so I went back to AS4.18.

 

The only valid syntax for data in RAM seems to be .byte

The BYTE directive reserves memory resources in the SRAM or EEPROM

There is also DW (incorrect for RAM, tried but no difference in result) DD and DQ however they are for EEPROM or flash.

DW - Define constant word(s) in program memory and EEPROM

DD - Define constant doubleword(s) in program memory and EEPROM
DQ - Define constant quadword(s) in program memory and EEPROM

so .byte is/can be used for anything in RAM, in the above case as a 2 bytes "variable" to hold the results of the ADC5. But it can also be a pointer or just consecutive data.

 

I see where the confusion results for the poor "kiddies".

 

Perhaps the definitions for DW, DD and DQ could be extended to RAM as well and then there should not be any confusion as to the size of the variable for display purposes. The user would just need to change the definitions in the code accordingly.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the OP, you are declaring an array of two bytes, so in a way it does makes sense to evaluate to a pointer

I tend to agree. If it was me I'd treat it pretty much the same as "unsigned char *" in C. If you could then dereference it like putting a watch on "ADC_ch5[1]" that would be great. Even better if you could "cast" it so something like "(unsigned int *)data[5]" which would show five 2 byte entries interpreted as unsigned words etc.

 

I'm not near Studio right now. What happens in C if you just use:

unsigned char data[4];

then watch "data". Does it show the address the pointer is pointing to or does it dereference it and show the 4 bytes at the target?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Even with the work around to tell Studio what the data is the value is still wrong, need sleep now.

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it need a '*' ?

WO * ADC_ch5

to dereference the pointer perhaps?

 

BTW, just out of interest why use .byte for a 2 byte array rather than .dw to say it is a "word"?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No * needed, the BY, WO and DW operators interpret their operand as a pointer and dereference it. The syntax is something we picked from the standard Microsoft Visual Studio.

If WO doesnt dereference its' operand I will file it as a separate bug. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

why use .byte for a 2 byte array rather than .dw to say it is a "word"?

See post #7 above. .byte is the only thing usable for RAM according to the assembler help but it doesn't seem to care if one uses DW or other outside their respective memory segments. I'll do a bit more testing if I get some time today.

 

It seems illogical to be able to use DW, DD and DQ for data in EEPROM but not allowed for RAM??

 

Anyway if the above definitions works for RAM and it will fix the watch bug I'm happy to modify my code with DW for 2 bytes variables.

 

I guess it could work this way:

 

.byte 1 or DB 1 single byte variable or constant

.byte 2, .byte x data array with + same as in C

 

.DW word variable or constant

.DD double word variable or constant

.DQ quad word variable or constant

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It seems illogical to be able to use DW, DD and DQ for data in EEPROM but not allowed for RAM??

I can kind of see the point - because Asm has no equivalent of C's _do_copy_data() you couldn't do something like:

.dseg

somevar: .dw 12345

and expect the 12345 to be there when your code starts. Yet if you use:

.eseg

somevar: .dw 12345

then, because of the .eep file you program the 12345 will be there. In RAM all you can do is reserve some space for something you are going to put there later (at run time) so I now understand why you'd use .byte and not the others in .dseg

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So really we need a couple of additional keywords in the avrasm? (avrasm3.exe??)  angel

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, i just installed atmel studio 7, and they still show byte variables as dword. How to add BYTE variables to the watch view, then?

I still have avr studio 4 installed. In that version, it showed all variables as 1 byte variables. Not really true, but at least better than showing it as dword and with the memory address instead of the value.

 

There is no need for additional variable definitions to fix that. For example, take a look at this variable definition:

 

DecTics:    .BYTE 2

 

Unsurprisingly, it's a 2 byte variable.

 

Can also be used to define some memory buffer:

 

UsartTxBuff:    .BYTE 32

 

For this kind of assembler variables, i think a "correct" solution would be at least to show the number of bytes defined, as if it was a limited size memory dump. An option to view it as an n-byte signed or unsigned number wouldn't be crazy, either.

 

For example:

 

Variable Size Value
Dectics 2 (FF 6A | Unsigned 65386 | Signed -150)
UsartTxBuff 32 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20

 

That would do.