## Major ASM concern/confusion

31 posts / 0 new
Author
Message

Hello All:

I've been checking out the AVR Assembler manual (or part of one) and I have some real concerns about its capabilities.

The assembler manual says it produces "fixed code allocations" and states no linking is required. I don't understand this.

I became even more nervous when I did not see an EXTRN directive. If I write a reusable subroutine in ASM, how do I reference another routine (or data) from an ASM code library and how do I integrate ASM routines into a larger project? Do I need to generate a C subroutine and then inline code ASM?

Please keep in mind, I'm an old fart and I am used to having a linker and locator.

I have to assume that AVR studio and/or the compiler manages various code sections written in C via Include directives etc, but nothing is obvious for ASM. Does a build handle ASM code sections as well?

My searches for an AVR studio manual or more ASM detail don't come up with much, so I feel a bit stuck.

The whole name of the game is reusable code, so I can only assume that I'm missing something really obvious.

At least I sure hope so :-(

Can someone help me see the error of my ways and/or point me to documentation that covers this? , or is there a third party dev suite that offers more extensive tools/capabilities?

Cheers,

Atmel's assembler is non-linking. Use Winavr's assembler for such code work. But it has some syntax differences compared to Atmel's ( See the bottom of this page for some of those ).

http://www.nongnu.org/avr-libc/u...

Winavr will integrate with Studio, so its assembler can be used too.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Last Edited: Thu. Mar 31, 2011 - 04:39 AM

Quote:
The assembler manual says it produces "fixed code allocations" and states no linking is required. I don't understand this.
I have used this kind of assembler for more than 20 years with different types of processors.

NO linking is required. GREAT. :) One less step to worry about.

Quote:
If I write a reusable subroutine in ASM, how do I reference another routine (or data) from an ASM code library
You simply .include your source LIBRARY file into the project and it all happens.

Linker were OK 30 years ago when computer took forever to do anything and needed preassembled object code to speed things up. Nowadays you can assemble a full 64K project in a few seconds and every bit of code is absolutely fresh, not canned.

And yes, I have a senior's card too. :wink:

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

John beat me to it, I was going to say pretty much the same thing. Just include you library files (which are text source files). Since the assembler is a 2-pass assembler it doesn't matter the order of things. You can call a subroutine at the beginning of the file and actually declare/write the routine at the bottom of the file. No headers files either.

indianajones11 wrote:
Atmel's assembler is non-linking. Use Winavr's assembler for such code work.
Winavr will integrate with Studio, so its assembler can be used too.

It looks like I'm going to have to make a leap of faith into the new millennium.

I still don't quite get it, but I am going to assume I'm covered, between the two assemblers.

js wrote:
I have used this kind of assembler for more than 20 years with different types of processors.

NO linking is required. GREAT. :) One less step to worry about.

js wrote:
You simply .include your source LIBRARY file into the project and it all happens.

I am assuming that the assembly/compiling/build all happens at once, using all source code as the input.

I am also assuming that unresolved references in an assembler source file are just ignored until the build, but this implies that the coder has to ignore certain errors when the ASM results are shown, while you are writing the code and syntax checking, yes?

There is probably some clever switch to set to avoid this or other such thing.

I think it's about time to shut up and commit to some hardware and just dive in, (and have faith in the majick).

BTW, I will probably get a programmer/debugger/ICE at the same time. The AVRONE! seems a little spendy, which leaves me the choice of a MK II, a MK III or a third party (if any).

Any ideas/recommendations?

Thanks!

dksmall wrote:
Just include you library files (which are text source files).

I was typing while you were posting, but that confirms my assumptions.

dksmall wrote:
Since the assembler is a 2-pass assembler it doesn't matter the order of things. You can call a subroutine at the beginning of the file and actually declare/write the routine at the bottom of the file. No headers files either.

Does this also apply to subroutine calls that reside in other source files? I didn't see any PUBLIC or PRIVATE directives, so this magic flags duplicate references?

Get a Dragon for about 50 bucks !! It programs / debugs almost every MCU they have ( inc. some of their at32 32 BITTERS ).

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

I saw the Dragon, but IIRC, it wasn't clear about its ICE capabilities. I do like the proto area though.

If the Dragon has what I need, why buy one of the three bigger boys? (Unless you have a government cost-plus contract. :-) )

I don't like to throw away money, but I get frustrated when I go cheap, er, I mean frugal and then find some limitation and come down with a bad case of buyers remorse.

WHICH ICE capabilities are you lookin' for ?

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

Quote:
I am also assuming that unresolved references in an assembler source file are just ignored until the build,
There are NO unresolved references, the included files are simply added up as one giant file so if you you refer to anything in some other file (say a "library" file) it will be seen by the assembler.

If you can afford the JTAG Mk 2 and can still get the original at half price ($150.00) it's a more robust unit than the Dragon but you will need to have your own boards as there is no prototype area. The STK500 is a favoured tool of the "old timers", youngins go for the STK600. These will let you play with pretty much any AVR 8 bit chip. (Programmers only, no debug but a debugger can be plugged into the STKs for debugging) John Samperi Ampertronics Pty. Ltd. https://www.ampertronics.com.au * Electronic Design * Custom Products * Contract Assembly Total votes: 0 indianajones11 wrote: WHICH ICE capabilities are you lookin' for ? OK, you got me! LOL I don't know enough about the whole AVR family to answer that intelligently, but in the past I have found that the lesser debuggers have limitations like clock speed or run length. This can make it tough to debug things like race conditions. So, I guess I'll turn it around and ask: Where would the Dragon fall down, compared to the MKII MKIII and AVR One? IOW, what would be the justification for spending between$250 and $550 more? I am assuming it is more than just memory depth, but we all know about assumptions :-) Total votes: 0 My turn to lol, since I only have a lowly Dragon ! :lol: Personally, I wouldn't get such expensive tools UNLESS I was doing serious contract work, where getting the answers to headaches needs to be ASAPpy. OP wrote: Do I need to generate a C subroutine and then inline code ASM? Generally, the easiest way to add an asm file to a larger C pjt. is shown here: http://www.nongnu.org/avr-libc/u... 1) Studio 4.18 build 716 (SP3) 2) WinAvr 20100110 3) PN, all on Doze XP... For Now A) Avr Dragon ver. 1 B) Avr MKII ISP, 2009 model C) MKII JTAGICE ver. 1 Total votes: 0 js wrote: There are NO unresolved references, the included files are simply added up as one giant file so if you you refer to anything in some other file (say a "library" file) it will be seen by the assembler. OK, I get that bit, but, as I'm coding individual routines (as in good ol' text editing), I will want to assemble or compile it to check for typing errors, syntax etc. For example, if I call Fubar and there is is no other reference to Fubar, it should generate an error because: A) My subroutine may be in the same module, but it's labeled Foobar, or B) It may really be Fubar, but located in another source file not included (or perhaps not even written yet). I assume good practices would mean that the system would flag this, and would also flag an error if two files contained a subroutine with a label of Fubar, either as a code address or a data reference. Total votes: 0 indianajones11 wrote: My turn to lol, since I only have a lowly Dragon ! :lol: Personally, I wouldn't get such expensive tools UNLESS I was doing serious contract work, where getting the answers to headaches needs to be ASAPpy. I will read the link after some shut eye, but besides from suffering from toy withdrawal :-), I do actually have some potential serious apps on the horizon that weren't cost effective with older ucontroller offerings. I suppose if they take root I can spend the extra money then. Total votes: 0 Please can you say what experience you have had with which processors, toolchains, o-s etc. By the sound of it, you want to use a regular linking assembler such as avr-gcc (WinAvr). If this is the case, learn the avr-gcc syntax. Read the documentation. Study example code. The Atmel assembler is non-linking, and is considerably simpler to use. It is up to you. Yes. You can .include 'library' functions in source code form. Remember that every label is going to be 'global' and hence you can run into naming conflicts quite easily. David. Total votes: 0 Quote: I will want to assemble or compile it to check for typing errors, syntax etc. Simply include that file to the project and assemble it. If it finds a multiple reference it will flag an error and you can click on the error and the cursor will jump at the offending line. If something doesn't exist an error will also be generated as above. For test purposes where you have a routine not yet written you can simply add a dummy routine ie. rcall USART0_INIT ;code not written yet . . ;dummy routine USART0_INIT: ret you can even have a file with dummy routines for stuff that you will write later. Sample project: ;Mega168 start up code .nolist .include "m88def.inc" .include "c:\avr\lib\ASCII_table.asm" .include "c:\avr\lib\utility_macros.inc" .list .include "DISA-5S07_equ.asm" .include "DISA-5S07_ram.asm" .include "c:\avr\lib\int_v_m48_m88.asm" .cseg ;main code starts here I usually add all my support routines that are forward referenced at the end of the main file . . ;Include files area .include "DISA-5S07_init.asm" .include "c:\avr\lib\rs485com_mega88.asm" .include "c:\avr\lib\h2d_d2h8.asm" .include "c:\avr\lib\6x6_5x8_dis25100.asm" ;.include "DISA-5S07_mon.asm" .include "c:\avr\lib\cgn5x7_1252_ex1.asm" .include "c:\avr\lib\sw_timers.asm" .include "int_s_DISA-5S07.asm"  John Samperi Ampertronics Pty. Ltd. https://www.ampertronics.com.au * Electronic Design * Custom Products * Contract Assembly Total votes: 0 david.prentice wrote: Please can you say what experience you have had with which processors, toolchains, o-s etc. Well, my first major foray was an Intel Intellec II, coding 8080, 8085 and 8088/86. This was a serious machine for the day (pre PC and verrry spendy, esp. if you had the hard drive option). Also, dedicated ICE & stand-alone programmer. No ISP then, no sir! No wheelchair jokes please :D A 2708 UV EEPROM ran about$70!!

The Assemble, Link, Locate sequence is permanently burned into my wetware.

Then, after a hiatus, I moved on to 8051 and variants (Intel, Phillips and Dallas) using EEPROM for dev, and then OTP for production.

david.prentice wrote:
By the sound of it, you want to use a regular linking assembler such as avr-gcc (WinAvr).

It's not so much what I want, but I am running on old, and probably outdated, methods. I was just confused as to how everything hangs together. Now that I am starting to understand the differences, I can pick and choose as I learn more.

david.prentice wrote:
Yes. You can .include 'library' functions in source code form. Remember that every label is going to be 'global' and hence you can run into naming conflicts quite easily.

David.

This strikes me as an unnecessary pain and a bit of a regression. I have always used Global and Local directives so I can maintain consistent structures and labels within subroutines, like error handling, exception handling, and register cleanup on RETs and RETIs, but I can adapt.

I'm still on the steep part of the learning curve, so I'm just figuring how it's done now.

js wrote:
Simply include that file to the project and assemble it. If it finds a multiple reference it will flag an error and you can click on the error and the cursor will jump at the offending line.

If something doesn't exist an error will also be generated as above. For test purposes where you have a routine not yet written you can simply add a dummy routine.

Makes sense John.

Define all routines at the top of the design and then include stubs before any real coding is done.

This similar to how I roll, but the idea of compiling the entire project just to check for typos in one routine seems counter intuitive.

That said, we're not running at 4 MHz anymore, are we?

Old habits die hard. :wink:

I suggest that you go straight into avr-as, avr-ld, avr-ar etc. You keep your mindset, and just have to learn the directives and any syntax quirks.

I have always concluded that most people who say "I want to do ASM and not C" is because they think ASM has less things to learn.

Yes. It has a simpler syntax but you require far better design and organisational skills from the programmer.

Presumably you are happy with structuring projects, so stick with your existing design methods.

All the same, there are many tips that you can get from reading other people's code. For example, your previous thread about symbolic expressions.

David.

Defining the structure and maintaining discipline is critical IMHO, regardless of the language. It's just that with ASM, you can get into trouble faster and deeper, so you learn or you sink.

If one is not methodical, you end up bouncing around like a water drop on a hot skillet, like that poor lad from Sweden recently trying to get a display to work.

As for symbolics and such, I try to put as much into my formatting and naming conventions as possible, but it probably wouldn't mean much to others.

Discussions here are helping me refine that.

I'm with David. If you want to use an industrial strength toolchain then use the GNU binutils.

The easy way to invoke them is via avr-gcc but if you do that it has a habit of bolting a vector table and C runtime onto the start of your program. As what this contains is what you were probably going to do anyway you might choose to simply accept it in which case the entry to your own code will be at a label called "main:" (that the C runtime expects to exist). This will not be at location 0 so you don't have a "clean machine". If you do want that and will code everything including the restart JMP and a (possibly limited) vector table of your own then explore the use of -nostartfiles which tells avr-gcc to not bind in the CRT.

Cliff

Never understood the advantage of splitting a project into separate files.

Keeping all code in one large file makes it much easier to search for labels or variables using Ctrl+F / F3 or setting bookmarks at the different parts of code you're working with at that moment.

I'm facing the downside of 15 separate .asm files at my workplace at the moment.
Need to do some some serious changes to a project where someone else written the original code.
When I need to follow a call to a subroutine not included in the current file I need to run Ctrl+F in 4-5 files before I find the subroutine. That routine might have calls in it to other subroutines in other files.
This gets very tiresome and rather inproductive.

When several persons are involved in same project there might be a need for splitting in several files of course.

If the large single file is written in "modules" with headers it's easy to replace the content of that module if needed.
Just my two cents...

Lennart,

You seriously need to use a source browsing editor. The ultimate example, perhaps is editing the Linux kernel code that is split over about 50000 files. In a decent editor if you simply hover the cursor over a variable or function name a sub window will show you its definition or offer to take you to it and will work as well for asm as C. Such an editor would find a 15 file Asm project trivial.

clawson wrote:
Lennart,

You seriously need to use a source browsing editor. The ultimate example, perhaps is editing the Linux kernel code that is split over about 50000 files. In a decent editor if you simply hover the cursor over a variable or function name a sub window will show you its definition or offer to take you to it and will work as well for asm as C. Such an editor would find a 15 file Asm project trivial.

Sounds valuable. Can you recommend one or two, preferably cheap?

Thx

Quote:
You seriously need to use a source browsing editor

Suggestions for a nice one that can handle 68HC08 code?
But I'd prefer a good one over a cheap one.

Lennart wrote:

No worries, I'm getting back in the game after a long hiatus, so all pertinent info is welcome, slightly OT or not.

Cheers

I've used UltraEdit for a very long time now, both for asm and winavr projects. Toolbar is configured to run the compilers, assemblers, and programmers with a single keystroke. For me this is much faster then studio with a better editor. It's not free, but it's not that costly either.

Quote:
Never understood the advantage of splitting a project into separate files.
Not having to wade through pages upon pages of code? :) If at all possible all my stuff is one or a couple of pages long.

Also I have stock standard routines like USART handling, chip driver etc. which I don't even have to look at in the main code. And if I call CHIN I know I will get a char from a UART/USART/SCI regardless if I'm using AVR, HC11, HC05-08 or even P.. :shock:

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

js wrote:
Quote:
Never understood the advantage of splitting a project into separate files.
Not having to wade through pages upon pages of code? :) If at all possible all my stuff is one or a couple of pages long.

Also I have stock standard routines like USART handling, chip driver etc. which I don't even have to look at in the main code. And if I call CHIN I know I will get a char from a UART/USART/SCI regardless if I'm using AVR, HC11, HC05-08 or even P.. :shock:

Absolutely! Modularity and re-usability is what it's all about. Trusted routines are a coders stock in trade.

Having these utilities on tap is almost like making the language, any language, extensible.

I always try to make a routine parameter driven, even if it starts out as a single function. For example, CHIN might be passed CHARS to return x chars from a buffer (loaded by event or DMA) or PORT, which specifies the hardware source.

It doesn't matter if the routine acts on the input parms or not, the point is to establish a framework from the get go.

A strict framework allows things like error-in & error-out combined with a call chain to track down run time glitches.

If you want to get fancy, just pass a pointer to a variable length data block, so you don't need to decide what parameters might be needed in the future.

Parms can also allow the functionality of a routine to expand at a later date WITHOUT AFFECTING any code that has used the original version. Think of input parms like switches in a command line.

John, I'm sure you know all this, I'm just expounding (or pontificating :) :oops:)