AVRFreaks.net

warning: .cseg .db misalignment - padding zero byte

This is what is happening. The AVR flash application program memory is 16 bits wide. Each byte is 8 bits wide, so you can also say the application program memory is 2 bytes wide (16 divided by 8 ). Two bytes together is also known as a 16 bit word.

When you use .db to place bytes in the flash application program memory, it takes two bytes to fill each word (each word has its own unique address). If you only specify an odd number of .db bytes, the assembler will pad your odd count with an extra zero byte (the assembler just happened to use zero for the value, it has nothing to do with strings). When you get the assembler warning message it pads your 21 bytes to 22 bytes to make it fit evenly into the 16 bit application flash memory words. If you do not want to see the warning message, you can add your own extra zero byte. In either case, you can go ahead and use the zero byte to terminate your string.

The newer versions of the assembler should pad the extra even byte correctly, without causing any problems.

DB - Define constant byte(s) in program memory and EEPROM
The DB directive reserves memory resources in the program memory or the EEPROM memory. In order to be able to refer to the reserved locations, the DB directive should be preceded by a label. The DB directive takes a list of expressions, and must contain at least one expression. The DB directive must be placed in a Code Segment or an EEPROM Segment.

The expression list is a sequence of expressions, delimited by commas. Each expression must evaluate to a number between -128 and 255. If the expression evaluates to a negative number, the 8 bits twos complement of the number will be placed in the program memory or EEPROM memory location.

If the DB directive is given in a Code Segment and the expressionlist contains more than one expression, the expressions are packed so that two bytes are placed in each program memory word. If the expressionlist contains an odd number of expressions, the last expression will be placed in a program memory word of its own, even if the next line in the assemby code contains a DB directive. The unused half of the program word is set to zero. A warning is given, in order to notify the user that an extra zero byte is added to the .DB statement

How to switch off into the AVRASM2 the automatic padding by $00?

You cannot - opcodes must be word aligned so if the byte length of the data is odd then it must be padded so that it regains even alignment. If you have lots of data with "holes" then consider re-arranging the data storage.

No padding

(and in general just put an even number of bytes in each .db).

In single line.

What about it?

If you really want to arrange your code textually with odd number of bytes per line I believe that you can use the "line continuation symbol":



The important thing is that each DB has an even number of bytes. Not each line.

This work with the values, but not working with the text datas

That's very bad, that imposible to turn off the padding.

I think perhaps you are under the mistaken notion that this is a limitation of the assembler (or the linker). It is not. In AVR, instructions are 16-bit words, and all references to flash (in the context of instructions) are with word addresses. It is impossible to cause an AVR to execute code from an odd byte address, as that would be in the middle of an instruction word. The assembler knows this and is simply enforcing the restrictions imposed by the hardware.

JJ

LPM adressing as 8-bits bytes (not by 16-bits words).
I wont to know how to bypass limitation of AVRASM2 to control padding/no padding.

to control padding/no padding.

I wont to know how to bypass limitation of AVRASM2 to control padding/no padding.

LPM adressing as 8-bits bytes (not by 16-bits words).