I'm making the move away from the PICAXE ecosystem and was ready to dive (reluctantly) into learning C when I happened across GCB. I liked what I saw and have managed to successfully write, compile and run a short program in GCB with just the info found here and in HELP. Now I seem to have run into a bit of a brick wall. How can I use MPLAB X IDE for debugging? I found the sticky FAQ#6 in this forum but the info there refers to 'Microchip MPASM toolsuite', which I am unable to find in MPLAB X IDE. How are all of you debugging your GCB programs? Your help is greatly appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have never been able to understand how to integrate my GCB programs with any useful emulator or debugger apart from one. I understand it should be easy, and I too have read the tutorials but I've never ever got my head around it.
This isn't a reflection on GCB, but my stupidity. I should add that I have a pathalogical hate for MpLAB (and all its variants) and have never got that installed and ever working to compile even a simple 'Hello World' type program so perhaps that is why I never got any debugging working?
The only simulator I had any luck with is from OshonSoft. It does work very well, if Vladimir was able to make the LCD section have 'moveable' pins, I would be using it daily.
My personal approach is the simplest. Most (if not all) of my projects include a display (LCD or LED) if something goes wrong, I simply place strategic sections of code to show either progress through the subroutines, or output 'relevant' variable values as they are encountered on the display. Where displays are not part of the design, I might write portions of the code on a different processor or PCB which does have a display and then port it over to the target device once I've smoothed out the major errors. I've also resorted to flashing LEDs in sequences to signal various operations have been started (or completed).
When a project I had (reportedly!) completed was found to fail under certain exacting circumstances, I wrote some code which very briefly pulsed a pin that was used for something else, to again show program flow, the pulses were able to be interpreted on an oscilloscope and showed that one of my subroutines didn't always exit and return to the calling procedure eventually resulting in the stack overflowing - resetting the device. I blamed the customer! I'd originally written the code with a few delays so that the buttons needed to be pressed for a few mS to reduce the likelihood of accidently starting a motor moving at the wrong time. Each button needed to be pressed, released, pressed, released to set the correct locks and latches in the correct sequence. The customer complained that it took too long and could I reduce the delays. I did that, without realising it was (just) possible to press the buttons fast enough that you could pass all the 'lock - latch - ready' tests quickly enough that an earlier delay had not expired - that delay expiring then called the 'lock - latch - ready' routine again, as all the tests had already been passed, the motor started and everything worked. But this left one extra subroutine call on the stack. After a few times of the motor being run eventually the stack overflowed. Of course in testing, it never played up as I would sedately press the 'lock - latch - ready' buttons...
I wrote an example demonstrating this approach which targeted the stack specifically, but using the 'ShowStack' subroutine it could be easily adjusted modified to output pulses of any value passed to it? The second example is shown here https://sourceforge.net/p/gcbasic/discussion/579125/thread/5a85c531e5/#541e but it might make more sense by reading my first example at the top of that thread. As it pulses for only 1uS an existing output pin could be used without it upsetting slower devices (LEDs, relays, buzzers and so on).
Last edit: mkstevo 2021-10-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I should mention Proteus. This has a full electronic circuit simulator, which allows simulation of many PICs including loading a .hex file into that PIC. At work I was allowed a demo version of the program to assess it. It was superb at simulating the circuit and running the code. I might have justified the cost had it been able to export the schematic files into Eagle (for me to create the PCB files). Drawing the schematic twice was almost as hard as simply building a prototype on Vero-Board and debugging it in 'hardware' rather than software. If you take the time to draw the schematic, Proteus is an excellent option, if a little expensive.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
I'm making the move away from the PICAXE ecosystem and was ready to dive (reluctantly) into learning C when I happened across GCB. I liked what I saw and have managed to successfully write, compile and run a short program in GCB with just the info found here and in HELP. Now I seem to have run into a bit of a brick wall. How can I use MPLAB X IDE for debugging? I found the sticky FAQ#6 in this forum but the info there refers to 'Microchip MPASM toolsuite', which I am unable to find in MPLAB X IDE. How are all of you debugging your GCB programs? Your help is greatly appreciated.
I have never been able to understand how to integrate my GCB programs with any useful emulator or debugger apart from one. I understand it should be easy, and I too have read the tutorials but I've never ever got my head around it.
This isn't a reflection on GCB, but my stupidity. I should add that I have a pathalogical hate for MpLAB (and all its variants) and have never got that installed and ever working to compile even a simple 'Hello World' type program so perhaps that is why I never got any debugging working?
The only simulator I had any luck with is from OshonSoft. It does work very well, if Vladimir was able to make the LCD section have 'moveable' pins, I would be using it daily.
My personal approach is the simplest. Most (if not all) of my projects include a display (LCD or LED) if something goes wrong, I simply place strategic sections of code to show either progress through the subroutines, or output 'relevant' variable values as they are encountered on the display. Where displays are not part of the design, I might write portions of the code on a different processor or PCB which does have a display and then port it over to the target device once I've smoothed out the major errors. I've also resorted to flashing LEDs in sequences to signal various operations have been started (or completed).
When a project I had (reportedly!) completed was found to fail under certain exacting circumstances, I wrote some code which very briefly pulsed a pin that was used for something else, to again show program flow, the pulses were able to be interpreted on an oscilloscope and showed that one of my subroutines didn't always exit and return to the calling procedure eventually resulting in the stack overflowing - resetting the device. I blamed the customer! I'd originally written the code with a few delays so that the buttons needed to be pressed for a few mS to reduce the likelihood of accidently starting a motor moving at the wrong time. Each button needed to be pressed, released, pressed, released to set the correct locks and latches in the correct sequence. The customer complained that it took too long and could I reduce the delays. I did that, without realising it was (just) possible to press the buttons fast enough that you could pass all the 'lock - latch - ready' tests quickly enough that an earlier delay had not expired - that delay expiring then called the 'lock - latch - ready' routine again, as all the tests had already been passed, the motor started and everything worked. But this left one extra subroutine call on the stack. After a few times of the motor being run eventually the stack overflowed. Of course in testing, it never played up as I would sedately press the 'lock - latch - ready' buttons...
I wrote an example demonstrating this approach which targeted the stack specifically, but using the 'ShowStack' subroutine it could be easily adjusted modified to output pulses of any value passed to it? The second example is shown here https://sourceforge.net/p/gcbasic/discussion/579125/thread/5a85c531e5/#541e but it might make more sense by reading my first example at the top of that thread. As it pulses for only 1uS an existing output pin could be used without it upsetting slower devices (LEDs, relays, buzzers and so on).
Last edit: mkstevo 2021-10-08
The debugging is relatively easy, please see https://sourceforge.net/p/gcbasic/discussion/579125/thread/3ec7fe0760/
I think you have explained it to me many times. Sadly I've never, ever, once got it to work. Nor come close to being able to get it to work.
I'm certain it is me, but sadly, I can't get it to work.
I should mention Proteus. This has a full electronic circuit simulator, which allows simulation of many PICs including loading a .hex file into that PIC. At work I was allowed a demo version of the program to assess it. It was superb at simulating the circuit and running the code. I might have justified the cost had it been able to export the schematic files into Eagle (for me to create the PCB files). Drawing the schematic twice was almost as hard as simply building a prototype on Vero-Board and debugging it in 'hardware' rather than software. If you take the time to draw the schematic, Proteus is an excellent option, if a little expensive.