Hello,
We've been using MPLab with ICD3 for debugging but also looking at other possibilities - like the Proteus simulator, an ICE adapter, and third-party simulators.
What are your favorite debug tools? I would love to have something that Motorola provided a while back for its HC series of microcontrollers, where you get a graphical 2D grid of RAM allocation with colours showing allocated RAM by variable and array name. You hover the mouse over the block to see the variable name. When RAM is written, it can show you if a fucntion wrote beyond it's bound as you step through the program.
Another nice feature would be to simulate serial data input from a file. It could be synchronized with an input by a simulator.
Best regards,
-Tom
What`s your favorite debug tool?
Moderators: David Barker, Jerry Messina
-
Jerry Messina
- Swordfish Developer
- Posts: 1473
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
I use MPLAB and a pickit/ICD3/RealIce depending on the chip and how big the program is.
For simple checkout/debug of software algorithms I often use the MPSIM simulator since it's quicker, doesn't require any hdw, and has more features than the hdw debuggers. MPSIM can so some simple UART IO simulations using files, but there's a lot of peripherals it can't deal with.
My problem with the simulators is just that... they're simulators so they bring in all their own limitations, quirks, and bugs. They're only as good as the models. I'm sure they have their place, but the last thing I need is to end up fighting a model that works differently than the real thing.
The only real complaint is the hardware debugging features of the PIC18 series are pretty limited. Couple that with the simplistic MPLAB software and things can be a challenge sometimes when things get complicated. With PIC24's things get a bit better, but you've still got to deal with MPLAB.
As far as watching ram usage there's nothing nearly as nice as what you described, that's for sure. About the closest thing would be to open a File Register window, execute the function, and see what's changed (the memory that's different shows up in RED). Mapping that back to variables would be a real trick, especially with the way SF re-uses ram. If you've got some function stomping on a variable it shouldn't be, it might be easier setting a breakpoint when the location's been accessed.
I'd be interested in what else you find out there.
For simple checkout/debug of software algorithms I often use the MPSIM simulator since it's quicker, doesn't require any hdw, and has more features than the hdw debuggers. MPSIM can so some simple UART IO simulations using files, but there's a lot of peripherals it can't deal with.
My problem with the simulators is just that... they're simulators so they bring in all their own limitations, quirks, and bugs. They're only as good as the models. I'm sure they have their place, but the last thing I need is to end up fighting a model that works differently than the real thing.
The only real complaint is the hardware debugging features of the PIC18 series are pretty limited. Couple that with the simplistic MPLAB software and things can be a challenge sometimes when things get complicated. With PIC24's things get a bit better, but you've still got to deal with MPLAB.
As far as watching ram usage there's nothing nearly as nice as what you described, that's for sure. About the closest thing would be to open a File Register window, execute the function, and see what's changed (the memory that's different shows up in RED). Mapping that back to variables would be a real trick, especially with the way SF re-uses ram. If you've got some function stomping on a variable it shouldn't be, it might be easier setting a breakpoint when the location's been accessed.
I'd be interested in what else you find out there.