if 0x37 should point to the DDRB then its wrong on the first sight. But shouldn’t we also count with the 32 general purpose working registers? According to the data sheet of the Attiny85 the address of DDRB is 0x17 (see page 200 “Register Summary”) but they are not including the 32 working registers in that calculation. Because deducting these 0d32 from the 0x37 we end up at 0x17 (point is, I think it should be 31 because “0” is one register as well … too bad we don’t see what address has R16 … was reading today a couple of hours through the structure of the memory and addressing of the Atmega chips, esp. attiny85 and atmega328)
Think i found a solution and it has indeed to do with the hex address and the 32 registers. In the Atmega328 (i know, addresses of the commands are different compared to the Attiny85) datasheet on page 624 ("Register Summary), there is written at the address 0x17 the other address in brackets (0x37) and then i looked at note 4 that points out to use the ST commands that adds these 0x20 addresses (think my terminology is not sharp enough yet). So I replaced in the assembler program the command “OUT” with the command “STS”, then i uploaded, and everything worked fine.
I have to dig deeper in these differences of addressing or writing directly to the SRAM and what difference all these commands make.
… or as stated here: https://www.avrfreaks.net/forum/assembler-compiler-and-linker-questions
just integrating #define __SFR_OFFSET 0 on top of `#include avr/io.h
That works!
PS: It says in that link, that is has something to do with the fact that its expecting still some C code? How can I get the environment to accept that I just want pure AVR assembler??
1 Like
That seems to be the valid explanation and the correct fix.
Programs which use <avr/io.h> and friends are expected to be C code, but noone prevents these headers and their definitions to be used in assembler, so it’s just up to the programmer’s usage of them.
I would prefer my assembly codes being completely free of C commands or structures. So, I would like to use e.g. the .equ command instead of others and so on.
I slowly start to believe that I should leave PlatformIO aside until I start with C programming. I thought I could just use this project environment of PlatformIO in order to have my assembly code file, the additional chip specific files (e.g. tn85def.inc) as well as an implemented pdf reader, the Terminal and of course the assembling and programming functions (initiating and using the USBasp for example) together with Debugging (which is not supported for Atmel chips yet) in one place and not to worry about connecting the right files with each other, but just to focus on learning AVR assembler. Any suggestion where I could find such a platform? Because if I have to think sometimes in C terms in order to get my assembler programs running, this is not really target leading for me now. Especially, if I want to apply some assembly coding examples from the web or tutorials, I have the impression that I have to rewrite the code so that it works with my PlatformIO enviroment.