MPLAB / MPSIM - How do I log/trace a registers contents to file?

It might be a "simple" thing. But Microchip is not too good at presenting needed info, starting with what pin numbers are used for programming their PICs: missing on various "adta sheets", inconsistent labels / terminology of those pins; the info is scattered over a number of documents with no guide or clue as wher to look. Programming via one of their kits is as bad; no guide as to what / where the progammer is, no clue that the "demo board" is a demo and not a programmer. Hell, the so-called data sheets that i have seen have zero DC specs almost zero AC specs (set-up times, hold times, rise times, fall times, etc). It seems that the ASS-u-ME-uption is that one inherently knows the answers to PIC questions before one learns to read. And it is extremely helpful that these "data sheets" are multi-megabytes in size - therby cutting out everyone on dial-up (will NOT spend umpteen hours to download !one! file). If you have high speed internet, then take days to download the terrorbytes of documentation and write a program to traverse them all, looking for *your* keywords.

Thanks for the response Robert - I tend to agree with much of what you say. I've got the MPLAB/MPSIM manuals which seem to contain a lot about stuff I found by playing but not much on tacking register contents.

Have you tried posting and searching in microchips forums?

In the help for MPLAB SIM I found the following under register trace:

The value of a specified register may be saved to a file (traced) during a run for certain conditions (see Table: Definitions of Register Trace). Specify register trace information here.

I have not actually done it, but it sounds like it should be possible. The best place to ask is

Paul

Thanks mook, yeah I've been there.

...and doing *that* will fix Microchip documentation problems?

I did a little experimenting and I was able to get a file with a trace of the value of a user-defined file register upon each entry into a procedure.

I used Stimulus-Register Trace, and I set the Reg/SFR to "ledcount", and the PC value to "BlinkUSBStatus". I created a text file for the results, and chose "Dec" format. I set the width as 2 since the variable is an integer. I am using my USB project, which is modified from the USB FS Demo, and the "ledcount" simply runs from 0 to 9999 as a delay for blinking status LEDs. When I click on "Apply" it tells me that the synchronous stimulus was applied successfully, and it also clears the content of the text file. When I run the simulation and stop after a second or so, or upon a breakpoint, the file shows a succession of integer values from 0 to 9999.

I was unable to get a trace on the WREG register or LATB, but I was able to see the PORTB register.

If you want to update the trace on a PC that is not named in the drop-down list, you can use the disassemby listing to find the hex value of the PC you want, and enter that.

It seems that it is best to set up separate files if you want to trace more than one register, but a single file does work. It just adds the second trace at the end of the first.

HTH,

Paul

Hi Paul thanks, that is encouraging. I'll try it and see how I go.

Terrorbytes? Are they that scary? :-)

I dunno, but the other day I misread a posting titled Multisim as Muslim

PS - it's rumoured that Al Qaeda are placing explosives in tins of Alphagetti Spaghetti, there are fears that it could spell disaster.

Yes, they really are scary and an obvious threat to national security.

Dubya should send in the Marines. Trouble is that with all the "hup hup hup" the Terrorbytes would hear them coming and be long gone.

If they're

"Robert Baer" skrev i meddelelsen news:MOidnQEDQsEck6zUnZ2dnUVZ snipped-for-privacy@posted.localnet...

HeHe - why not cut the bottomfeeding and go straight to ARM7?

The CPU performance is vast, vast overkill if a PIC will do the job BUT the ARM's are nevertheless relatively cheap, multi-sourced and the tools are good and plentiful.

The forums are there to try to fill the gaps/gaping holes in documentation.