Hmm...  It appears as though my attachment didn't go through...

Go to www.ubasics.com/adam/pic/doc to see the files
asmfile.htm    The html formatted assembly file
TLMCHIP.INI    The modified language suite file for mchip
               (use it to replace tlmchip.ini)
MPASMhtm.MTC   The modified MPASM.MTC file
               (use it in addition with mpasm.mtc)

After copying the language files to your mplab directory, choose 'install
language tools' from the project menu.  Under the microchip lanuage tools, there
will ba an additional language, "MPASM(*.htm)".  Select that, and put in the
path to your mpasmwin.exe file.

-Adam

"M. Adam Davis" wrote:
>
> Along those lines, here is an assembly file marked up with enough HTML to
> display properly in a browser...  (Small attachment!  Don't shoot me!)
>
> It is an htm file so that I can simply click on it and see the document.  MPLAB
> does care what extension a file has so I provided an extra language tool file
> and modified microchip's language tool suite file to accept htm files.
> (mpasm.mtc --> mpasmhtm.mtc with some modification and modified TLMCHIP.INI).  I
> then installed my new language tool "MPASM(*.htm)" and now I can include htm
> files as nodes in a project and assemble them under mplab.
>
> -Adam
>
> "Get the facts first, you can distort them later" - Mark Twain
>
> Mark Willis wrote:
> >
> > (Fixed the subject line, needed a colon after [OT].)
> >
> > One thing I've seen that I mostly liked, in past, was in aviation safety
> > systems - the documentation was installed inside the source (.asm)
> > files.
> >
> > IMO this is a good idea - This way the programmers could actually get at
> > & see the docs, and were in fact in charge of the documentation's upkeep
> > and maintenance (gasp!) - SO often, it's marketing or someone who knows
> > nothing about the code, who writes the manual etc., months later, with
> > no clue - And it ends up resembling the code's behavior SO little, that
> > it's rather pathetic.
> >
> > They had a tool that'd extract the docs into a file that the
> > documentation people were allowed to get at, then had a nice tool that
> > re-formatted that text file into a properly formatted document.
> > Nowadays, HTML comes to mind <G>  Probably could treat it as a separate
> > "source code" file, and not include it directly into the code.  And the
> > extract document "compiled" (checked syntax) as a matter of course so
> > you couldn't "oops" without noticing, well, not too badly anyways.
> >
> > And of course you could verify that you didn't mess up the code when the
> > docs were changed (compare the previous .obj files with current freshly
> > compiled version, should be identical) - twas on a Z80/80186 dual
> > processor machine.
> >
> > You already know about concepts like bug report filing, bug
> > verification, change control boards, regression testing, and so on, I'll
> > assume, if you've seen what NASA has to offer.  (IMO some co's go way
> > overboard on paranoia on "If we fix a bug it'll just make 15 new bugs.",
> > I always feel my competence is being insulted, frankly.  Now, "If we let
> > management make decisions, it'll just encourage them", that definitely
> > has truth to it, for some values of management <G>)  Treat it like any
> > other system, look for gaping holes, and design something that's able to
> > cope with your organizations needs.
> >
> >   Mark
> >
> > D Lloyd wrote:
> > > Hi PICsters,
> > >
> > > As we all know that documentation of code is very important and that we all
> > > *religiously* follow our procedures <cough, cough>, does anyone know of any good
> > > templates regarding maintenance as opposed to development?
> > >
> > > Such templates would ideally relate to change control procedures, bug
> > > maintenance etc. I went through the same exercise of obtaining such information
> > > for development but procedures used by the likes of NASA are a bit overkill for
> > > general embedded systems, so cut down information would be more beneficial.
> > >
> > > Any help/useful pointers would be appreciated.
> > >
> > > Kind Regards,
> > > Dan Lloyd
> > >
> > > Firmware Engineer, Electronic Operations
> > > ABB Metering. England.
> >
> > --
> > I re-ship for small US & overseas businesses, world-wide.
> > (For private individuals at cost; ask.)