> There is nothing that would prevent you from using Doxygen for this. You
> have to write the assembly calling sequence for each target CPU anyway,
> and if you write it in the function's header comment, it can be
> extracted by Doxygen.

OK, but could it generate *both* C and asm calling documentation from 
one source? Currently I write something like

          #interface mkt_pin_direction
             #parameter N unsigned int
                number of the IO pin
             #parameter D unsigned int
                direction for the pin

 From this is generated:

//  (C, C++)
void mkt_pin_direction(
    unsigned int N  //  number of the IO pin
    unsigned int D  //  direction for the pin
);

//  (ARM assembler)
subroutine mkt_pin_direction
    R0 : N          (unsigned int)       //  number of the IO pin
    R1 : D          (unsigned int)       //  direction for the pin

> It really boils down to whether you want it to be
> with the source and extracted (meaning Doxygen can be useful) or whether
> you want to write it somewhere separately (meaning Doxygen can't be
> useful). 

In my case it's a bit complex: everything (C code, assembler code, 
documentation, and more) is in one Python source.

> The advantage, of course, of writing it in the function header comment
> is that the chances are higher that if you change the function
> prototype, you also change the associated comment -- and this is then
> automatically extracted into the documentation. Changing the function
> prototype in the user manual, in a far-away manual source, is more
> likely to be forgotten.

I agree with that. I try to keep the generating source for the code and 
the documentation close.

-- 

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist