How to use the AVR Assembler (AVRASM2) for complex projects

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

I like to share how I use AVRASM2 for complex AVR projects.
This is about advanced features of AVRASM2, like macros.
The aim is well structured, easy to maintain, efficient and re-usable code.

 

http://web222.webclient5.de/doc/advavrasm2/AdvancedUseAVRASM2_en_20180120.pdf

(version 0.3 from 2018-01-20, PDF, 590 KB)

 

This is not about the AVR instruction set or how do do algorithms in assembler. For those there is plenty of good material available on the web.

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

If you want a more powerful assembler have you considered switching to GNU as?

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

Isn't the ultimate 'more powerful assembler' simply called C?

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

When I write in ASM I want to know that I'm in control so I (almost) never use macros.

 

I even hate to you the macros there are in the instructions set. (like clr I want to know how the flags are effected and will use the 3 different clr instructions depending of what is needed.)

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

sparrow2 wrote:
When I write in ASM I want to know that I'm in control so I (almost) never use macros.

Yes - it does rather seem to defeat the object!

 

If you find that writing in assembler is too cumbersome, and want to avoid all the minutiae and arcane details - then that is exactly the problem that 'C' solves!

 

In the (probably rare) cases where you really do need to have full control of & concern for all the minutiae and arcane details - then just do that part in assembler, with the rest in 'C'.

 

 

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

#5

with the rest in 'C'.

That is the real problem, then you have to use the structure your c-compiler use, which rare is optimal.

 

Like in OP's  paper, he use r1 for zero, because the C-compiler does! For AVR's with HW MUL that is a bad place, why not 

use the freedom when you have it!

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

sparrow2 wrote:
you have to use the structure your c-compiler use

only so far as the interface to the 'C' goes.

 

You just make sure that this is outside the part that needs optimising.

 

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

I mean things like you can't control Y and R1 (or spend time restore them)  

Use the RAM/flash layout the C compiler like etc. 

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

For about 40 years, I have wrote my MCU programs in assembly only.

 

When I shifted from C51 to AVR, I had the idea to let my AVR codes look much like of the C51 ones by using suitable macros.

In a way, this helped me enter the AVR world with less efforts. But, while being more familiar with the AVR spirit with time, I found myself disregarding one macro after another, to end up lately disregarding all my macros smiley

 

For instance and in my case in the least, macros are not suitable always during debugging since the only debugger tool I can use is the AS simulator.

 

Kerim

 

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

If you ever find yourself writing macros in 2 different assemblers to make the code look common/familiar you really HAVE reached the point where it's time to use C! ;-)

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

Sounds like the old joke:

 

A Real Programmer can write FORTRAN in any language!

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

Or the old joke

 

If you can't do it in C, then do it in assembler.

If you can't do it in assembler, it's not worth doing.

 

[Joked the alleged C++ man..]

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]

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

clawson wrote:

If you ever find yourself writing macros in 2 different assemblers to make the code look common/familiar you really HAVE reached the point where it's time to use C! ;-)

 

You are indeed totally right.

But, it happened that I 'had' to write hundreds of CPU programs in assembly, then thousands of MCU programs also in assembly before I got AS6 lately smiley (why I had to... is hard to explain in a forum devil ).

Soon I will be 70, and I am glad I still remember my name laugh

 

But, I also believe that if someone works in a team, writing in C or any other suitable high language becomes somehow a prerequisite for a complex application.

In my case and since I started a small private business after graduation (in the 70's, as a private designer, then producer) my programmer's team was and still is just me.

But, I used writing in C anytime I might need a specific function to be run on my user's PCs (I had to also write my PC applications for DOS only... till now).

 

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

Another very good reason for using C is it's portability.

If the orignal programmer has taken a bit of care to make a reasonable split between software algorithms and hardware abstraction then a C program is relatively easy to port from one uC family to another.

A C program written for oldies such as Z80 or 8051 can easily be ported to an AVR or PIC, ARM, MPS430 or whatever.

 

Once algorithms get a bit more complicated I also often write C functions and compile them on my big Linux Box. (10 year old Intel DualCore).

I can debug them there much more easieler :) than on an AVR.

After those functions are debugged I copy / paste them in the AVR sourcecode.

 

Try that with assembly.

 

--------

But OP seems tho have subsribed to AVRfreaks for sharing his knowledge of a 22 page pdf on using assembly for AVR's.

I wonder: In what way's is it still mandatory / efficient to use ASM in uC's.

Especially since C compilers are widely available and you can get an uC with 10x the horsepower (& complexity) of an AVR for the same price...

Some uses:

1). RTOS kernel. You will need ASM to handle the multiple stacks during task switching.

          ( Co Routines are coming in C / C++ ...).

2). Small routines where hand optimisation make's a significant difference. (avr/crc16.h).

3). Code where timing is of absolute importance (Software USB stack).

4). Being able to read LSS files to study C compiler output.

 

Did I forget something?

 

On the other side:

A lot of the ASM related posts seem to have the underlying reasons:

1). 70 year old guys who have been writing assembly for 40 years and are happy with it. (No disrespect. I understand).

2). Students of basic cpu architecture courses.

3). Reverse enginering.

4). People with a fetish for brain distorting code who derive some kind of fun out of it.

5). Fetish for "retro computing"

6). People who rolled into it (for example after "2)." ) and kind of got stuck there.

 

But this discussion has probably also been held many times on AVR freaks & else where.

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

Paulvdh wrote:

1). RTOS kernel. You will need ASM to handle the multiple stacks during task switching.

 

Being pedantic here but that should read...'Preemptive RTOS kernel.'

"This forum helps those that help themselves."

"If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

 

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

#14

 

Battery driven things (for long lasting) should never be written in C, the code should be written with optimal code.

 

 

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

Indeed, I have. Mostly to be able to mix assembly and C.

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

sparrow2 wrote:
Battery driven things (for long lasting) should never be written in C

Nonsense.

 

In most cases, it's the "idle" current that dominates battery life.

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

Define

 

Nonsense

and 

 most cases

 

For a 328PB the difference in power power is about a factor 4000 so if it run for 1 sec every hour it use more power running than not.

 

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

sparrow2 wrote:
For a 328PB the difference in power power is about a factor 4000 so if it run for 1 sec every hour it use more power running than not.

Compare that with an ESP8266

It has reasonable low power capability for a 160MHz chip which was never designed for low power applications, but it's WiFi radio is such a power hog that even turning it on once every hour wil drain your batteries significantly. Break even point where WiFi consumes as much Joules as deep sleep is in the days...

Especially if you consider that making a WiFi connection takes about 7 seconds. ( About 2 apparently if you turn DHCP off).

 

Power consumption is mostly hardware based, choose it wizely.

Second is using smart algorithms to use the hardware intelligently (turning individual peripherals off, power modes etc.)

C versus ASM is probably going to make a very minimal difference.

 

http://www.esp8266.com/wiki/doku...

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

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

But will you really run a ESP8266 from a battery ?