AVR-Chat

Hi All,

I have been working furiously on a program to help with debugging and
analysis of AVR assembler programs, and an evaluation 
version is now ready.

The program is called "AVRavel". It takes the listing and map files
from AVRASM as input, and analyzes them for presentation, and to 
check for some types of errors. 
The display shows the structure of the target program, lists the
symbols used, and allows each section (subroutine) to be viewed in 
detail. Each path through the section can selected, and the use of
variables by that path is displayed. 
Details of any symbol are shown by clicking on it, and another small
window can show all references to a given symbol. Clicking on 
many displayed items allows navigation to other relevant display
areas. 
Errors detected include incorrect use of PUSH,POP,RET and RETI
instructions, and identification of unreachable and badly 
terminated code areas. 
Detection of failure to preserve registers inside interrupt handlers
is almost operational, and other facilities are planned.

The link below contains further information, screen shots and the
evaluation version download (limited in size of input program it 
accepts). The download contains sample listings ready to look at, so
trying it out is simple: Download-Unzip-Run

http://members.optushome.com.au/intaavr/AVRavel.htm

All forms of feedback are invited.

Regards,
Rob Storey

>
>Detection of failure to preserve registers inside interrupt handlers
>is almost operational, and other facilities are planned.

That's a very nice feature, it will save a lot of head-scratching.


Usage of ram, and register variables would be interesting.
IE who mucks with Thingy_pointer or  Other_thingy appears unused..

Possibly spotting variables in the upper register bank that could be moved 
to lower, or moved to ram with minimal impact..
Code segs that could be profitably made into subroutines.

I wrote one application where I deliberately overlapped my input buffer, 
output buffer, and stack space in SRAM, but with careful design, it was fine.

> >Detection of failure to preserve registers inside interrupt handlers
> >is almost operational, and other facilities are planned.
> 
> That's a very nice feature, it will save a lot of head-scratching.
Not far off, but not foolproof either. To be done properly, full
variable analysis is required (tracking the contents of variables), eg.
to detect that the sreg has been saved and restored, since this requires
I/O as well as just simple push/pop (which is easier to track).
 
> Usage of ram, and register variables would be interesting.
> IE who mucks with Thingy_pointer or  Other_thingy appears unused..
Not sure exactly what you mean here, all refs to a variable can be
displayed, and the symbol table display shows unreferenced symbols.
 
> Possibly spotting variables in the upper register bank that could be moved
> to lower, or moved to ram with minimal impact..
> Code segs that could be profitably made into subroutines.
These are more in the optimization/hints category, rather than
debug/error detection.
I plan on these a bit further down the track, though some could be done
soon.
Other possibilities include:-
* Detection of unused operation results (eg. alter a variable, then
without using the new value, alter it again). 
* Calculation of maximum stack depth to detect collision with variable
storage.
* Identification of code that is executed on many flow paths, but only
needed on some (eg. push a var, then branch around stuff, and pop again.
The push/pop could be moved inside the "stuff" so that it's done only
when needed).
* Calculation of path lengths to come up with maximum execution and
interrupt service times.
and probably many more...

> I wrote one application where I deliberately overlapped my input buffer,
> output buffer, and stack space in SRAM, but with careful design, it was fine.
*Very* careful I imagine. I'd just use the next chip up, with more RAM
;-)

Rob

>
> > Usage of ram, and register variables would be interesting.
> > IE who mucks with Thingy_pointer or  Other_thingy appears unused..
>Not sure exactly what you mean here, all refs to a variable can be
>displayed, and the symbol table display shows unreferenced symbols.

A very common problem is where one routine messes with another's variables.
Either by direct reference, or indexed as My_Ram+5 accidentally stepping on 
Your_Ram


>* Detection of unused operation results (eg. alter a variable, then
>without using the new value, alter it again).

Good

>* Calculation of maximum stack depth to detect collision with variable 
>storage.

Maybe thorny, but good idea.


>* Calculation of path lengths to come up with maximum execution and
>interrupt service times.
>and probably many more...

This is not brilliant, only tedoius, but it's still quite a useful thing.
Many times the tedious steps are the ones that don't get done, and 
computers are good at tedious.

> > I wrote one application where I deliberately overlapped my input buffer,
> > output buffer, and stack space in SRAM, but with careful design, it was 
> fine.
>*Very* careful I imagine. I'd just use the next chip up, with more RAM

What 8 pin chip, has more ram than the 2343?

> A very common problem is where one routine messes with another's variables.
> Either by direct reference, or indexed as My_Ram+5 accidentally stepping on
> Your_Ram
The trouble here is the concept of "ownership" of the variables (This is
clearly defined and controlled in high level OOP languages, but not in
assembler). The same problem arises in detecting corruption of variables
by interrupt handlers - it alters a register, but should the ISR have
preserved the register, or does it "own" the register and therefore the
action is legitimate?

> > > I wrote one application where I deliberately overlapped my input buffer,
> > > output buffer, and stack space in SRAM, but with careful design, it was
> > fine.
> >*Very* careful I imagine. I'd just use the next chip up, with more RAM
> 
> What 8 pin chip, has more ram than the 2343?
Don't know, but I'd be looking for one! 'twas a general comment that
comtemplating techniques like that is a dead giveaway that you've
outgrown your hardware capacity.

Rob