79 posts / 0 new

## Pages

Author
Message

I have code I had written under atmel studio 4 a few years ago (but never debugged) and have created a new project under atmel studio 7 and copied all the files into the solution (they are added to the solution).  Problem is, these sources will not ever build using atmels assembler because its is lacking functionality that is absolutely required for this project.  I therefore need to switch to the GNU tool-chain.  When I go into my project properties and select the tool-chain tab the ONLY option is the avr assembler.  That is literally the only item in the list.

Why is the GNU assembler not an option here?  How do I enable it as an option?

If something can be read without effort then great effort has gone into its writing

Is this a project you have already created? Back when you first created it you should have got a choice between "C", "C++" and "Asm". But once you picked Asm that is the only toolchain you will see available. Or are you saying that even at the create project stateg there are no options for "C" and "C++ "?

I tried importing the old project but i had some problems with the way it did it so i just created a new project and dragged and dropped the source files into the solution but when i go into the project properties toolchain tabl the GNU assembler is not an option. the only thing in there is the atmel assembler

If something can be read without effort then great effort has gone into its writing

mark4th wrote:
so i just created a new project
mark4th wrote:
the only thing in there is the atmel assembler
Which takes me back to the question of how you went about creating the project.

From this page in the user manual...

http://www.atmel.com/webdoc/atme...

On this dialog....

which option did you select? Or, at the left there, where it says "Installed templates" was it the "Assembler" option that was selected?

If you want to use GNU as as your assembler you actually need to create a  C or C++ project. You then have the choice of whether you make the project from a mix of .c+.S (or .cpp+.S for C++) or whether you want to use just .S alone for a project that only uses GNU assembler (in which case you may/may not want to use -nostartfiles to remove the C/C++ startup code).

aha why is that?  its not very intuitive!

ty for the help :)

If something can be read without effort then great effort has gone into its writing

"GNU as" is only really there as a support tool for the GNU Compilers. Each of them converts C or C++ into AVR Asm for the GNU assembler to then convert into AVR opcodes. Sure you can use it to write standalone Asm but folks doing that would usually use the Atmel assembler for that as it's arguably easier to use and the majority of AVR Asm code and tutorials on the Internet are written for it.
.
But as soon as you want to mix C and Asm (or call existing C library code like printf() or sin() etc) from Asm you would switch to using Gas (GNU as) as the Atmel assembler won't support that.
.
As I say Gas is there for the compilers so the directives supported aren't always that obvious for us mere humans. OTOH it offers some very powerful facilities and, of course it's a linking assembler generating relocatable object.

there will be absolutely no C/C++ code in this project and it seems to be building now with the GNU toolchain except... i cant .include "foo.inc" i have to .include "c:\Users\me\foo\bar\bam\fud\project\foo.inc"   <-- have to escape the backslashes of course.

as for avrasm2 its one of the least functional assemblers ive ever seen. it does not seem to have the capabilities of a REAL assembler and I doubt very much if the GNU Asm macros I am using can be ported into the avrasm2 macro language.  Its just not able to do the things Im doing here.  For an example (actually an exact example :) of the macros im using for this project take a look at my GitHUB for some other projects...

The following file from my t4 (arm thumb 2) project is almost exactly the same as the one im using for this avr project.

https://github.com/mark4th/t4/bl...

(hopefully this forum allows external links)

If something can be read without effort then great effort has gone into its writing

Last Edited: Mon. Jun 5, 2017 - 06:03 PM

Oh if you already use GNU ARM as then avr-as will be the natural choice and you'll already know the "quirky" directives

im not exactly enamored of the GNU toolchain BECAUSE its quirky and also not as powerful as a "real" assembler (such as A386 for DoS, or DEVPAC for Amiga) but it has a macro facility that is much more capable than the one that comes with the avrasm2 assembler which i consider to be utter garbage.  Macros is what makes an assembler and avrasm2 cant do any kind of complex macros.

i also need to change the projects include path somehow, i cant edit the command line for the assembler because its grayed out so i cannot add switches for some reason.   right now i have to enter the full c:\... path to every file i include, i cant just .include "foo.inc" from within main.S because it gives path or file not found :/

If something can be read without effort then great effort has gone into its writing

If you like an assembler with an advanced macro language why not simply use C which is effectively just that.
.
As for #include the usual C preprocessor rules apply so just use -I's to tell it the paths to look into for the .h files.
.
EDIT now I reread your last post I wonder if you missed the fact that it's a linking assembler - you don't have to include all the code into a single compilation unit.

Last Edited: Mon. Jun 5, 2017 - 06:52 PM

I either need to include the files in a specific order or i need to edit the linker file.

personally I would prefer not to spend 3 days fighting a crippled development environment that seems to only function as expected when all your doing is drag and drop, cut and past coding and using the easy bake compiler that plays mommy and holds your hand and protects you from you.

This is seriously starting to become VERY annoying.  Why cant i .include "foo.inc" from my main asm source file... the include file is in the same damned directory as the file thats including it :(

and no C is NOT an option for this project.

Why cant i add -I "path to include files" ?  When i try do so the new include path just gets consigned to /dev/null.  NOTHING is added to the list of include paths!

If something can be read without effort then great effort has gone into its writing

update:  I now have a non relative include path added to the gnu assembler.  I have no idea why it was not accepting my previous attempts, it just silently ignored every path I tried to add.  however the include path is still not working.  .include "foo.inc" still gives me path or file not found.  whats going on?  why cant i include assembler files?

If something can be read without effort then great effort has gone into its writing

You need to be much more specific about exactly what you have done in order for us to help you with this. Screenshots of settings, verbatim copy of failing code.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

In your code, is it possible to use C preprocessor #include instead of the asm one? Maybe it works better. (I mean, by changing the .s extensions to .S so that it gets parsed by the C preprocessor)

as an experiment i changed all my .include directives to #include and now things are working.  I wasted 3+ hours fighting this which is VERY BAD.  The tools do not behave in an intuitive manner.   However I now have a new issue which I can see taking another 3+ hours to resolve followed by another, then another then another... ad infinitum.  This really is not acceptable, these sources built just fine using the GNU toolchain under avr studio 4!!!

My new issue is that I cannot seem to find a way to alias a register.  Some versions of the GNU Assembler have a .req directive allowing you do do .req r5, fud  after which you can then do a move of some value into fud.  this is not critical but being able to refer to a register with a descriptive name for dedicated registers makes the code more readable.

still looking for a way to do this but might just have to butcher the very readable existing sources to make them build under this butchered incantation of the GNU toolchain.

If you cant tell im getting very frustrated with these tools.  They should not be causing me this grief, what im doing here is not rocket surgery, its what ive been doing for over 20 years with the GNU toolchain without ANY problems what so ever.  Seems to me like Atmel removed functionality from these tools just to simplify their job and kitty corner everyone into the same box :(

If something can be read without effort then great effort has gone into its writing

mark4th wrote:

My new issue is that I cannot seem to find a way to alias a register.  Some versions of the GNU Assembler have a .req directive allowing you do do .req r5, fud  after which you can then do a move of some value into fud.  this is not critical but being able to refer to a register with a descriptive name for dedicated registers makes the code more readable.

Same suggestion, C preprocessor. #define fud r5

actually thats what I did and i also found out how to alias the registers with descriptive names using a #define too so that problem only took a few minutes.

My big problem here is "why did .include not work" ?  If something as mundane as an assembler include cannot find the specified file because of some obfuscated include path shenanigans there are going to be far more serious issues later on that will take much longer for me to resolve.

Right now, a macro that used to work is giving me an ')' required error.  there are no missing ')' in the macro so its somewhere else... the error is on the macro invocation which complicates things because it does not flag exactly where the problem is but this is not a 'tools' problem I dont think.

I had not thought of renaming my .s to .S - not sure its needed but ill give it a shot

This is the macro giving me the above error...

.macro _defer_ name, label
\label:
call dodefer
.int 0f
.section .eeprom
0:
.byte lo8(value)
.byte hi8(value)
.byte lo8(hlo8(value))
.previous
.endm

if i comment out the 3 lines following the 0: local lable the error goes away.  uncomment them one at a time shows its

.byte lo8(hlo8(value)) that is giving me the error... says its missing a ) character.... something else is afoot and its just manifesting itself here methinks because the above looks fine :/.

If something can be read without effort then great effort has gone into its writing

Last Edited: Mon. Jun 5, 2017 - 08:45 PM

> This really is not acceptable

Then go for the refund, perhaps ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

new problem.  I do not want ANY of the drivers for ANY of the peripherals incuded in my project but I still need the SFR #defines.  I cant seem to find a way to get these defined.. Usually its a simple .include (#include?) for the device being built for.  I do not want one signle byte of code or data space used by this include, i just need the register names for my device which is the atxmega256a3bu - is there an assembler include for that device?

If something can be read without effort then great effort has gone into its writing

There are asm includes. Problem is, they are made for avrasm2, they may or may not be compatible with GAS, I'm not sure.

Last Edited: Mon. Jun 5, 2017 - 09:08 PM

how do i get the register definitions for this project?

I very VERY specifically do not want any canned driver code compiled into this project.  I just need the complete SFR register definitions defined.

Again, this really looks like your jamming everyone into the same square hole here.  did it not occur to Atmel that there are applications that absolutely cannot afford to WASTE space including all the GOOP associated with the ASF libraries?  Some people need to write drivers for specific peripherals in a very minimalistic way.  Your canned drivers might be a good general purpose fit for 99% of the people out there but there are always corner cases... surely you have a simple include file that defines SFR's ?

If something can be read without effort then great effort has gone into its writing

Why do you think there are any drivers, involved?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

i looked in the ASF wizzard.  There is almost nothing in there that jumps out at me as giving SFR definitions for the selected device and most of it wants to compile some .c file or other if its included in the project.  If for example I wanted the register definitions for the UART/SPI/whatever it seems to me like I would also have the canned UART/SPI/whatever driver forced on me which would include all the the header files and other C sources that that driver depends on.

I dont want the any driver code compiled into my project, it would be very problematical if some random C file were to be compiled into the middle of this code and it would NEVER be called, I just want the register definitions for my selected device.  There should be a "atxmega256a3bu.def" (pick any other device) of some sort.

I cant even find where on my C drive all these supposed avrasm2 include files are kept.  I could translate them  if i knew where they were.

If something can be read without effort then great effort has gone into its writing

ASF should not even be part of what you are doing. All the register and bit defs are from <avr/io.h> based on the target you set when the project was created.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

where would that file be located?

I dont see any references to it in my solution explorer nor any instance of it in my project directory.. btw i was already including that file as it was included in the original avr studio 4 sources,

If something can be read without effort then great effort has gone into its writing

mark4th wrote:

how do i get the register definitions for this project?

I very VERY specifically do not want any canned driver code compiled into this project.  I just need the complete SFR register definitions defined.

Again, this really looks like your jamming everyone into the same square hole here.  did it not occur to Atmel that there are applications that absolutely cannot afford to WASTE space including all the GOOP associated with the ASF libraries?  Some people need to write drivers for specific peripherals in a very minimalistic way.  Your canned drivers might be a good general purpose fit for 99% of the people out there but there are always corner cases... surely you have a simple include file that defines SFR's ?

You are overreacting a bit, aren't you? Stress, I suppose.

Ok. I just remembered I had a similar problem to you, I wanted to create an ASM project for the SAMD10, an Atmel ARM MPU. Problem is, for this family you just have to use GAS if you are using Atmel Studio. Fortunately, forum member westfw figured out how to do it.

You can use the C include files, if __ASSEMBLY__ is defined. This will disable all C specific stuff and leave only GAS compatible defines. More details here:

https://community.atmel.com/forum/where-arm-assembly-language-project-file-template-atmel-studio in particular in post #5.

Obviously, it's not the same MPU, but the configuration of the project should be similar.

It located somewhere in the deep dark bowels of Atmel Studio. And, it really is MANY files, the ones used depending on the model and the architecture (there being a number of "architectures" that are shared by multiple devices - for example, Mega48x, Mega88x, Mega168x, Mega328x, and others all share one architecture and vary (mostly) by memory boundaries). If I am recalling correctly, the architecture files have names like Mega3, Mega4, and so forth, but I COULD be way off here.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Mon. Jun 5, 2017 - 09:47 PM

scatterbrained includes do nothing but obfuscated the entire problem.  those includes are a good reference for reminders on things you know but dont remember the finer details on.  such as whats the #define for the whatsit bit in the gizmo register.  Goto implementation does not work on the include of <avr/io.h> - where is that file exactly?  If i know where that file is i will be able to find the rest of the include files - that file is NOT in my project directory so I guess my projects defines a -Dthis_specific_processor which that include uses as a conditional.  i can  follow the rabbit trails if i knew where the entrance is.

If something can be read without effort then great effort has gone into its writing

On my computer (using Studio 6.2)  <avr/io.h> is located at:

C:\Program Files (x86)\Atmel\Atmel Toolchain\AVR8 GCC\Native\3.4.1061\avr8-gnu-toolchain\avr\include\avr

In my machine, the includes for specific chips are in:

C:\Program Files (x86)\Atmel\Studio\7.0\packs\atmel\{chip_type}\{version}\include\avr

Why do you need to know what that define is? I sure don't. It serves no useful knowledge.

Oh, yes, you want to be sure that it is correct, right? Do you check that your vehicle's tires are designed correctly and that the windshield is sufficiently shatterproof? And, that there is no e coli on your salad greens?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Last Edited: Tue. Jun 6, 2017 - 12:38 AM

wait.. what was that SFR called again "FOO_BAR_1" or "FOOBAR_1"

If something can be read without effort then great effort has gone into its writing

tyvm!

I searched for it but windows search isnt as good as locate or find . -name :)

If something can be read without effort then great effort has gone into its writing

So i have reduced it to a single error in the build now which is "undefined reference to r22"

This is generaged by....

#define wl r22              // working register lower 16 bits

#define wh r23

.. other register aliases define just fine.  I cant see anything wrong with the above.. therefore the problem is somewhere else?

If something can be read without effort then great effort has gone into its writing

What happens if you remove the commwnt part of the line for r22?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

There are a bunch of #define xxxx, rnn here and only r22 is not defined.  however, i removed all the comments from all the #defines and put them on lines of their own - also changed the // to ;.  think i needed // so the CPP wouldnt hickup on the ; character but not sure if that was needed.  anyway, with no comments on any of the register definitions i still get an undefined reference to r22.

If something can be read without effort then great effort has gone into its writing

As far as I have seen, register names and bit names are exactly as given in the spec sheets.

This caused no end of problems, for a while, when devices with one uart, for example, had them renamed from UART to UART0 to make them more consistent with multiple UART devices. It was in the spec sheet but many were used to the un-numbered names. There is also auto-complete.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Isn't it just

#include <avr/io.h>

Ok.  I was going to write a long message how I doubted that things were this broken.  I mean, gnu as hasn't changed significantly since the WINAVR/AS4 days, right?  But I tried to work through an example, an it's looking like somehow ".include" *is* that broken in the current avr-gcc; I can't seem to get it to pay attention to the provided include paths...

here's the simplified setup:

It was an AS7 project.  But I switched to the command line to eliminate what I thought were complications:

>>pwd
C:\Users\IEUser\Documents\Atmel Studio\ASMtest\ASMtest\Debug

Here's the trivial source code:

>>type ..\Assembler1.s

/*
* Assembler1.s
*/
.include "mydefs.inc"

.global main

main:  ldi r16, 0xFF
out ddrb,r16
rjmp .

.end

And the file to be .included...

>>type ..\mydefs.inc

/*
* mydefs.inc
*/
.macro _defer_ name, label
\label:
call dodefer
.int 0f
.section .eeprom
0:
.byte lo8(value)
.byte hi8(value)
.byte lo8(hlo8(value))
.previous
.endm

I have a quite recent AS7 install (on W7, in this case):

>>avr-gcc --version
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_1734) 5.4.0

And I run this stripped-down gcc command, but it doesn't find either include file!

>>avr-gcc -c -mmcu=atmega168pa -I.. -I "C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc" ..\Assembler1.s
..\Assembler1.s: Assembler messages:
..\Assembler1.s:5: Error: can't open m168padef.inc for reading: No such file or directory
..\Assembler1.s:6: Error: can't open mydefs.inc for reading: No such file or directory

>>

Switching to avr-as DOES find the include files, but of course the Atmel .inc files have never been compatible with the gcc assembler, anyway (and neither are the .h files, because they're C...)

>>avr-as -c -mmcu=atmega168pa -I.. -I "C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc" ..\Assembler1.s
C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc/m168padef.inc: Assembler messages:
C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc/m168padef.inc:47: Error: unknown pseudo-op: .device'
C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc/m168padef.inc:49: Error: expected comma after "SIGNATURE_000"
C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc/m168padef.inc:50: Error: expected comma after "SIGNATURE_001"

Can anyone get avr-gcc to ".include" a file from the project directory?  It looks like gcc is not passing the -I information on to as - I can get better behavior if I pass the paths explicitly with -Wa:

>>avr-gcc -c -mmcu=atmega168pa -Wa,-I.. -I "C:\Program Files\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.2.132\avrasm\inc" ..\Assembler1.s
..\Assembler1.s: Assembler messages:
..\Assembler1.s:5: Error: can't open m168padef.inc for reading: No such file or directory  (It found mydefs.inc !)

But AS doesn't do that except with manually-configured options, and  I'm having trouble passing any include paths with spaces in their name via that mechanism...

I wasted 3+ hours fighting this which is VERY BAD.

Meh.   Life is tough.  "Computer Science" may be all very formal and exact, but "Computer Engineering" all-too-often consists of banging your head against a mis-behaving toolchain until you get it to behave.  :-(

Are you sure this worked under AS4?   I'm not sure that I believe that ".include "avr/io.h"" would ever have worked - .include is an assembler directive, which means that it should happen WAY after C preprocessing, which is needed to process the contents of io.h...  In the AS4 days, you would have had to manually install the Gnu assembler; perhaps that involved much more customization than you're remembering?

AFAIK, there is no set of gcc-assembler syntax ioport definitions for AVR chips; you have the .inc files (off hidden somewhere) that have Atmel syntax, and the .h files that are for the C preprocessor (they pre-process into constants that work with avr-as, but you MUST run the source through the pre-procesor.)

I even tried moving the sources to a directory that didnt contain a space to see if that was why .include didnt work but it didnt help, i think .include is at the top of their "wont fix" list because meh we have the CPP solution which is probably why there are no gnu assembler include files for the register definitions.  Personally I would rather just have the assembler definitions and to hell with the CPP but that would mean them having to do some work like.. you know... fix bugs and create those include files?

Right now my problem is #define wl r22 giving an undefined reference to r22.  if i change it to r16 the undefined ref is the  r16 so im thinking maybe there is a definition for wl somewhere else and the pre processor is getting confused and giving a mixed up error message?

If something can be read without effort then great effort has gone into its writing

How are "assembler definitions" different from cpp ones?

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

Look up the .include, .equ and .set directives, they are built into the assembler, why should I have to depend on any part of a the C compiler for anything at all?  The only reason i have to use #include is because the people at Atmel cant fix .include.

The only reason I have to use GAS is because the people at Atmel wouldnt know a real assembler macro facility if it jumped up and bit me on the ass :P  If avrasm2 didn't have such a crippled macro facility I would stick with that simply because I would not have to use the pre-processor.... Though I cant say if its CPP thats causing me this grief it still makes my teeth itch to have to use it.

Im a minimalist, the best solution to any given problem is always (REPEAT ALWAYS) the absolute simplest solution to that problem and in an embedded application C is never the simplest solution, its just the easiest for the skript kiddies to use (even skript kiddies with real skills).

some inefficiencies off the top of my head....

You have no access to the processor status flags (carry, overflow).

you cant directly access bits using the BSET BCLR BTST and you know that FOO | = (1 << BAR_BIT) can never be as efficient as bset foo, bar_bit.

Ive been doing embedded control applications for close to 30 years and IMHO C and Embedded are absolutely mutually exclusive (c++ is orders of magnitude worse).  Embedded apps need to be space and time efficient, C will never be as efficient at doing things as raw assembler if the coder has skills, even when optimized to the umpteenth level.   The industry doesnt care about space or time efficiency on the target, they care about "get it to market today and fix it tomorrow".

C allows anyone to write code and "pretend" its portable and even with its quirks and flaws it CAN get the job done.

p.s. Portability is a MYTH, show me portable code and ill show you a bunch of #ifdef's interleaving 487256284 different versions of the same thing into the same scatter brained, unreadable source files:P

This little project of mine should not be giving the the grief it has been giving me, things should simply work in the most intuitive way and they dont so I spend a great deal of time trying to get the tools to do the things I need them to do.  Fighting development tools == wasted time.  Time that I could have used to develop went into working out the quirks and flaws of the tools I have no choice but to use.  Lucky for me, once this tool has been completed I can throw away GCC and GAS and avrasm2 AND the entire atmenl studio IDE.... at least for my ATXmega256a3bu :)

Meanwhile... back here in "reality" r22 is still undefined :/

If something can be read without effort then great effort has gone into its writing

How are "assembler definitions" different from cpp ones?

A C definition looks like:

#define PORTB 0x5

(after a bunch of intermediate steps, if you're using the assembler) and does a blind text substitution.

An assembler definition looks like one of:

 .equ PORTB = 5    ;; Atmel assembler
;; or
.equ PORTB, 5     ;; Gnu assembler

and actually defines a symbol with a numeric value.   There are places where the assembler version s MUCH more powerful.  Assembler macros also make C's "text substitution only" "macros" seem horribly primitive.  Even on relatively poor assemblers.

why should I have to depend on any part of a the C compiler for anything at all?  The only reason i have to use #include is because the people at Atmel cant fix .include.

Because the SFR definitions that you're looking for have never existed for the gnu assembler; it only has the C definitions; Atmel has always only really supported their own assembler; the gnu assembler is just a side effect of the compilers.     I don't see how you've been using the gnu assembler since AS4 days without knowing that.  And if you have such disdain for the Atmel tools, I'm not sure I understand why you're using AS at all, rather than CLI and a makefile (or even something more primitive.)  Especially since it's the AS-provided project structure and build commands that seem to be causing most of the problems.  There are also a couple of other Atmel-like assemblers that may or may not have some improvements: avra and tavrasm are two that I know of.

Fighting development tools == wasted time.

Yeah, yeah.  Whine, whine.  A good craftsman understands his tools.

r22 is still undefined

Tried R22?? (capital R) remember GAS is case sensitive.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

So, give us your opinion......
I'm working on a small embedded project at the moment and I'm using c++. If i were writing in asm i'd still not have half the features done by now. The majority of the code will be used on another project. I'll only resort to asm if i need to speed up the crypto. The rest of the code is inconsequential performance wise. Maybe i just havent been doing this stuff lobg enough......

Silly question- you wrote the code with studio4, why don't you use it now?
If someone is paying you to do this, don't you think you might want to stop bitching and actually get the job done?

mark4th wrote:

I have code I had written under atmel studio 4 a few years ago (but never debugged) and have created a new project under atmel studio 7 and copied all the files into the solution (they are added to the solution).  Problem is, these sources will not ever build using atmels assembler because its is lacking functionality that is absolutely required for this project.  I therefore need to switch to the GNU tool-chain.  When I go into my project properties and select the tool-chain tab the ONLY option is the avr assembler.  That is literally the only item in the list.

Why is the GNU assembler not an option here?  How do I enable it as an option?

As far as I know,  AvrAsm2 (Atmel's assembler) and gas (GNU assembler) are unchanged for the last 10 years.

If your project worked under AS4,  it will still work under AS4.    It should work under AS7 too.

Yes,  AvrAsm2 is a non-linking Assembler with less powerful macro features than avr-gas.

You have to choose which route you want to go down.

In practice,   you can achieve most common macro requirements for Avrasm2 with a combination of C Preprocessor #define and subsequent native assembler .define

Yes, it might be a little fiddly.   But like most macros,  you write once (very carefully) and use many.

Explain what you want to do.   Several members are experienced with AvrAsm2  (and with avr-gas)

You will probably get good advice.

If your project worked under AS4,  it will still work under AS4.

I had assumed that he needed support for newer chips and/or debug devices than are available under AS4.  He mentioned XMega (eventually.)

It should work under AS7 too.

Indeed.  Has anyone duplicated the apparent bug, yet?

Explain what you want to do.

Yes, please.  I'm guessing a Forth implementation that includes its own assembler, based on the macro shown, and the T4 repository.

Last Edited: Tue. Jun 6, 2017 - 07:54 AM

mark4th wrote:
Right now my problem is #define wl r22 giving an undefined reference to r22....
Have you tried trimming the fat and using

 #define wl 22

?

- John

westfw wrote:
But I tried to work through an example, an it's looking like somehow ".include" *is* that broken in the current avr-gcc; I can't seem to get it to pay attention to the provided include paths...

You folks do know about -Wl, and -Wa, I take it? Also about how avr-gcc (the "compiler driver") works?

The fact is that avr-gcc will pass files to target processes based on extensions (.c to the C compiler (cl), .cpp to the C++ compiler (avr-g++), .S to the assembler (avr-as) and so on). But because it is the front end for several tools it will try to pass on command line parameters to the "right tool". If an option is unique it will pass it to the right target but some options could be for several targets (such as -I). So if you have an option you know must go to the linker (for example) you use -Wl, before it and if you have an option for the assembler you use -Wa, as a prefix.

There is also -Wp,  to direct options to the preprocessor (and there could well be other -Wx, but I can't remember them right now)

So if you use "avr-gcc -I \some\path" that option will go to the preprocessor by default. If you want to use the assembler's own -I to give paths it should use for .include, as described here:

https://sourceware.org/binutils/...

then I would suggest you either use:

avr-as -I /path/to ...

or, because you probably want both preprocessing and asssembling, use the compiler driver:

avr-gcc -Wa,-I /path/to

EDIT: now I re-read this I see Bill already discovered this:

westfw wrote:
I can get better behavior if I pass the paths explicitly with -Wa

That should not come as a surprise, that is to be expected.

mark4th wrote:
why should I have to depend on any part of a the C compiler for anything at all?

Because you want to use avr-gcc, because (for .S) it will perform the two stage process of pre-processing and then assembling. If you think you can live without pre-processing then just invoke avr-as directly. HOWEVER I rather imagine you will want access to <avr/io.h> and you need that to be preprocessed.

By the way, don't forget __SFR_OFFSET. That is:

// my Asm .S file
#define __SFR_OFFSET 0
#include <avr/io.h>

main:
ldi r24, 0xFF
out DDRB, r24
etc.

If you don't do this you will need to use the hugely cumbersome:

// my Asm .S file
#include <avr/io.h>

main:
ldi r24, 0xFF
etc.

mark4th wrote:
Right now my problem is #define wl r22 giving an undefined reference to r22. if i change it to r16 the undefined ref is the r16 so im thinking maybe there is a definition for wl somewhere else and the pre processor is getting confused and giving a mixed up error message?
That persists if you precede the #define line with:

#undef wl

?

In this simple example I have no problem defining "wl" as R22:

C:\SysGCC\avr\bin>type asm.S
#define __SFR_OFFSET 0
#include <avr/io.h>

#define wl 22

.global main
main:
LDI wl, 123
RJMP main

C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 asm.S -o asm.elf
C:\SysGCC\avr\bin>`

No errors from the build. (and same whether I use just "22" or "r22").

Last Edited: Tue. Jun 6, 2017 - 09:30 AM

Is the OP still driving a taxi??

I posted a link to an example of the macros I'm using that are part of a ARM Forth for Linux that I wrote.  If I could accomplish the same macros under avrasm2 I would do so but I think avrasm2's macro engine is limited.

https://github.com/mark4th/t4/bl...

These macros are used to 'assemble' a forth kernel that is exactly the same as it would be if the forth compiler were to compile its own kernel (known as meta-compilation in forth speak).  The following macros are the most important ones.

hstring  : creates what is called a counted string in forth.  A count byte followed by the string which depending on the architecture is padded out with zeros to affect an alignment on architectures where that is required. the first byte of the string (the count byte) might also have certain bits set to mark this string.  I could explain the purpose of these marks but it would take an explanation as to how forth works internally :)

header :  this macro literally creates a singly linked list of forth word headers which you can think of as forths built in symbol table.  a word header as the following structure

.int back        ; pointer to previous word header in this chain

nfa:                 ; stands for "name field address"

.byte count    ; count byte with lex bits for the following word name

.ascii "name"

.int cfa           ; address (label) where this words executable code resides

the code field address pointed to above

.int nfa         ;  pointer to nfa at cell next to cfa

cfa:                ; this words "code field address"

asm code

goes here

nfa and cfa are not global labels as shown above but local labels of course.

alias:   used to create a second word header on an existing word.  does not modify the cfa's nfa pointer of the existing word

code: colon: variable: constant: defer: (or similar names) used to assemble various forth word types

vocab:  used to create a new forth vocabulary (name space).  A vocabulary is an array of usually 64 cells which are the head pointers for the above described linked lists of forth word headers.  when forth adds a new word to an existing vocabulary it calculates a hash for that word and links it to the correct bucket in the vocabulary array based on this hash value.  - when assembling i just chain everything onto the first chain of the voc and fix the links at run-time.  The only assembler I ever used that can calculate the hash values at compile time was the A386 DoS assembler By Eric Isaacson.

forth: compiler: root:  Used to select which of the three vocabularies that exist within the forth kernel any new words will be linked to.  these three vocabularies are the only ones that exist in any forth kernel I build, you can create new ones in your own forth sources which this kernel will compile.

It took me 2 months to learn enough of the GNU assemblers macro facility to get those macros working properly, it took me a week to learn A386's macro language to a level where I could create those macros.  I no longer have a copy of the A386 assembler which I am a registered user of but I do still have my dos forth sources.  Ive never published those sources.

The GitHUB link above links to the macros file for my t4 compiler.  This is a thumb2 Linux forth compiler that runs on the raspberry pi, the beagleboard and the cubieboard (the 3 ive tested it on).  There is another compiler on my github called x4 (t4 is thumb forth, x4 is x86 forth) which I believe is one of the fastest compilers of any non trivial programming language.  x4 can compile over 4 megabytes of source code per second.  The only other compiler I have seen that comes close was the oracle delphi compiler and it cheated :P

If something can be read without effort then great effort has gone into its writing