ISIS

[CharlieM]

Hello All,

I am looking at ISIS for 18F pics to debug code. I have to demo version of ISIS and the ISIS plugin. I have played with it some,but I feel it does more then I am doing with it.Does anyone here use it with SF and how is it liked? Thanks.

[PhilJ2]

I use it a lot, no problems - great combination.
Note I'm still using XP though

[Jerry Messina]

Charlie,

I don't use ISIS, so I can't really comment on it except to say that it's a serious chunk of change.

Personally, I've been doing all my debugging using MPLAB and a Pickit2. For $35, it's hard to beat. It's usefulness depends on which pic you want to use, though. Some of the larger 18F's (like the 18F4685 and 46J50) provide three hardware breakpoints, while others may only give you one, which can be pretty limiting. All of them give you source level debugging, single stepping, etc.

I've also used the ICD's, but I've been real surprised at what I can do with the Pickit2. I've got well over 100 source modules with canbus, network stacks, serial, usb and a bunch of other hardware running.

[CharlieM]

Thanks Jerry,

I am reluctant to use MPLAB because its so complicated. I have a pickit2 so I may have to just dive in and see what I can learn. I really need a way to debug code.

[richardb]

For me my pics use 40 or 48MHz clk's so 99% of the time i can use a spare pin on the pic for debugging.

I always program the pic in circuit so i always have a connector with 2 I/o pins on it, if possible i try to make sure that these are the last pins that i use up, so they are mostly free to use for rs232 op's.

I have a standard lead that can plug from the programming connector to the rs232 input on the pc, i've never used voltage translation chips for this and it always works, i just set the suart to non inverted.

I use real terminal to display the debug info. you can also capture to a file if the display info is too fast to be read.

As this method is using suart it can be affected by interrupts, but you can get round this most of the time by writing a simple debug routine that disables the isr while you’re sending each byte. i can post this if anyone’s interested.

I know this method won't work all the time but its saved my bacon many times.

Richard

[Jerry Messina]

Charlie,

There IS a lot to MPLAB, but if all you want to do is use it for debugging (which is what I do), getting it
setup isn't too bad. I use the SF ide to do all my editing and compiling, and just open MPLAB for debugging.
I've tried using MPLAB to do everything, but I've never been able to get it setup properly without jumping
through all sorts of hoops, and it's just not worth it. Besides, when you're compiling, the SF ide does a
better job at identifying what and where the errors are. There are a few extra steps required when you do it
this way, but after a while you get used to it, and there's hot key combinations for most of the steps.
You can keep both programs running, so swapping windows back and forth isn't that big of a deal.

If you'd like to try it, I'd suggest you try using the simulator built into MPLAB (MPLAB SIM) first before
you try using the pickit2. It saves a few steps, and will give you a feel for how the process works. Besides,
this is actually a good method to use when you have a software algorithm you want to checkout or debug since
you don't even need any hardware. You can use the simulator for hardware too, but personally, anything much
past "toggling an led" isn't worth it in my book. The trouble with software simulations (and this applies to
ISIS as well) is that the result is only as good as the information you feed the simulator. It can get pretty
complicated trying to describe all the hardware interactions accurately. If you don't completely understand
the hardware to begin with, it's real easy to make some bad assumptions, so you end up with something that
works in the simulator and then fails when you run it on your hardware.

The simulator built into MPLAB has another advantage...it doesn't have any of the restrictions that the
hardware debuggers do, and it's easier to setup. The pickit2 (or ICD's for that matter) require the use of
certain hardware resources on the pic you're debugging, and that can vary depending on the device you're using.
You need to reserve these when you compile so that SF doesn't use them. It's usually a few ram locations and
some program memory space for the debug executive. In addition, the number of hardware breakpoints you can
use is limited to whatever the device supports, typically only one or three for most PIC18's. You can get more
info on this from the MPLAB 'Help | Topics... Debuggers MPLAB ICD2' topic, and select 'Reserved Resources'.
Note: The info here applies to both the ICD2 and pickit2... they don't specifically talk much about using the
pickit2 for debugging. MPLAB SIM can set an "unlimited" number of breakpoints since they're all done in software,
and doesn't require any special reserved resources. You can just compile your program as you would normally.

Make a simple .BAS file to check things out at first... a couple of variables, maybe some loops, etc. I'll use
the name "main.bas" as an example.

First, you need to setup SF to output a .COF file, which is a file that has all of the code and symbolic
debugging information. To do this, in the SF ide, select the 'View | Compile and Program Options...' menu.
On the 'Compiler' tab, check 'Generate debugger *.cof file', and 'OK'. Now, when you compile your main.bas
program, SF will produce a main.cof file in addition to the others that it normally does. This is the file
you'll need to import into MPLAB.

Fire up MPLAB. First, you'll need to set it up for the pic device you're using. From the main MPLAB window,
select 'Configure | Select device...' Use the 'Device' listbox, and scroll down to the pic you want, then
select 'OK'.

Second, setup the debugger you want to use. Again, from the main window, select 'Debugger | Select Tool' and
check 'MPLAB SIM'

Now you're ready to begin debugging. From the 'File' menu, select 'Import...'. Browse to your project directory,
and select the "main.cof" file. This should load, and open up a window with "main.bas" in it. From here, you
can use the 'Debugger' menu to run, set breakpoints, single step, etc. You'll want to use the various windows
available from the 'View' menu (such as 'Watch') to aid in observing the contents of memory and variables.
If you want to make changes, switch back to the SF ide, change and compile, and then re-import the .cof file
to begin a new debugging session. Note: You can make your changes directly to the .bas file in the MPLAB editor
window and do a 'File | Save', and when you switch back to SF you should see the updated file. Personally, I
don't like doing it this way as it's real easy to get confused over whether you've changed something and
re-compiled it or not.

You can save all the MPLAB settings in a workspace file so that you don't have to redo all the settings the next
time you want to debug. I save an individual workspace file in the project directory. That way, the next time
all you have to do is double-click the workspace file (.mcw) to get started. To do this, select 'File |
Save Workspace As...', browse to the project directory, and give the .mcw file a name, such as 'main_mpsim.mcw'.
This way, you can have different workspaces set up for the simulator and pickit2 if you like.

Give this a shot, and see if you like it or not. If you do, there's threads here on the forum on how to setup
things for the pickit2, or just drop a note here and I'll walk you through the steps.

Happy debugging.

Jerry

[CharlieM]

Hi Jerry,

Thanks for the info. I will give it a try.