OK. But how I do that?
If I use MPLAB-X, I write the program in c. But I wrote the program in GCB.
Which files do I have to load in MPLAB-X and how do I do that?
I do not understand how GCB and MPLAB-X work together
Is there perhaps a step by step guide for it?
As hardware I have an ICD3 and a PICkit3 available.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I got a mention, Thanks :) I should point out that Real PIC Simulator, whilst a useful piece of code, is a commercial product requiring the purchase of a licence. And, as it has not been updated in the past few years, it is effectively no longer supported by the developer.
PICSimLab on the other hand is Open Source and in active development, to the extent that the core simulator has received several tweeks already this year alone to address simulation errors uncovered by CGBASIC.
RealPICSim emulates more devices but one of the benefits of GCBASIC is that you can do most debugging on any available device, because the code is portable, so you do not have to emulate the physical target device to debug your code.
So as GCBASIC is a Free Open Source Compiler I prefer to recommend Free Open Source tools, especially when the developer willing and actively working with us.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If, like me, you were intrigued by Evan's videos but are allergic to MPLABx and reluctant to install several Gigabytes of Bloatware, there is an alternative.
MPLAB Xpress is browser based so there is no need to install anything, however, it looks in early testing like you will need to create an account with Microchip. If you are working with PIC chips and don't have a Microchip account there is no harm in creating one, I have had mine for years and it is not abused with spam etc.
The Process is remarkably similar to what Evan posted earlier, if anything it is easier as it is mostly drag and drop (I have 3 screens). But you do need to make sure your ASM file is all UPPERCASE before importing it.
Evan has been commissioned to make a new video to show how to do it but as a teaser here is the standard Blink.gcb code being tested in MPLAB Xpress.
The Screen Shot shows the code stopped on a Breakpoint for the LED = !LED statement.
The lower window shows that it is watching the content of PortC as LED is defined as PortC.0
Here is the GCBASIC Code for the sake of comparison.
'
' MPLAB Xpress debug test
'
#chip PIC16F18855
#Option Explicit
#define LED PortC.0
Dir LED Out
Do
LED = !LED
wait 500 ms
Loop
End
Cheers
Chris
Last edit: Chris Roper 2019-05-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
And, a video explicitly for Great Cow BASIC debugging using PICKitPlus software with a PICKit2 Programmer. Using this configuration to send debug information via the MCU serial port via the PICKitPlus software to the PC.
Last edit: Anobium 2019-05-14
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Give MPLab Xpress a try, but later, I think we have crashed it as it is currently timing out for both of us at the moment when making a new project. Even was building a new video and I was testing the PICkit3 Hardware debugger and the web site died :>(
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
Just looking at this now having had a few minutes at work to watch the video about debugging programs using MPLabXpress. I've run into a problem already!
On compiling the program I'm getting an error message with regards to my frequency tables.
The error returned is:
Error[151] D:\TEMP\MICROCHIP\F42A2B1DDE1E460298E39D8891C33AAD\9D5221725EE04A7893CA4B32A10DC57F\12F1840_FREQUENCY\AD9833_CONTROLLER_12F1840_TABLE.ASM 196 : Operand contains unresolvable labels or is too complex
On the assumption that this points to line 196 of the .asm, the command is:
MOVLW (HIGH TABLEFREQTABLEHIGH) & 127
I have a two tables containing word values, each of which seem to be split by the GCB compiler into two tables containg the byte values, making four tables in total. All four tables are returning the same error message.
The code compiles in GCB perfectly, and I've downloaded it to an actual 12F1840 device where it runs perfectly well. I'm sure I've missed something obvious, but can't see what.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I opened another (even simpler) project for outputting some bit-banged serial data to a 4x7 segment LED display using four 74HC595 to drive the displays that I have used in a number of hardware designs. That won't run either. It builds correctly this time but fails to 'Run' giving the very helpful message:
Although as it states 'No code generated' I'm wondering if it compiled anything.
This is precisely what stopped me from using PIC microprocessors in the first case and why I started out using PicAXE processors. I never could get anything to compile/build/program using MPLab. It drove me bananas then, and it seems like nothing has changed. I could not believe how beautifully easy it was to program PIC devices with GCB. Any errors (and I do get plenty!) I get are simple to understand, simple to find and simple to correct. Once I've cleared my silly spelling errors and the like the program compiles/builds/programs everytime.
Oh well. I thought that it would be lovely to be able to put the debugger to use. Sometimes it isn't always possible to hook up an LCD and have the code print out the values of pins and variables at various points in the code in order to try and see what stupidity I've created this time so thought this could be very useful. It's looking far less useful if I can't get it to run two simple programs. I'll never get it to simulate the large programs I have that give me concern over the stack level down to me overusing subroutines - which is what I'd really like to be able to do.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I said in my previous post, if it is going to drive me into a furious swearing match with the computer each time I try to use it, I won't bother to use MPLabXpress.
I'd be happy to pay a reasonable sum for something that actually worked, and worked with a range of devices that I actually use. As of yet, I have not found anything that does one of the two criteria never mind both.
Code attached. As with many of my programs, it is split into the main program, a header containing the definitions and a header with the tables.
As a result of the original debugging Question and the subsequent discussion, I have been putting together some debugging code for GCBASIC. It should overcome your issue of not always having an LCD display available and, if you use a PICKit 2 programmer it should be a plug and play solution for you.
My main issue is, however, has been getting its footprint down and if you are already running into capacity issues with RAM or Call Depth it is probably not going to work for you, but it can still help to test individual sections of code or even your hardware, before you combine them into the target app.
As for the stack level the data sheet for your device will give you the stack depth (GCBASIC does not maintain its own stack) but as a rule of thumb this table, paraphrased from the GCBASIC Help File, is a good guide:
I have been trying to fully document the debugger and test on all of the PIC families and AVR, but for expediency I am considering releasing it in stages for testing with a view to submitting a debug Library for the next GCBASIC release.
I will add you to the beta test list if you are interested.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Firstly, yes, I would like to be added to your beta list for the debugger.
I was aware of the seven nested levels stack limit, but have not yet managed to come up with a way of determining the maximum level of nested subroutines in my code! I did bang together a script that determined all the calls to subroutines within the source code, then listing each external call within each subroutine, but couldn't then think how I could follow each call into each subroutine, showing any subsequent calls.
Giving me the worst case scenario of a stack level of four.
MainLoop_Sub > SetFreq > SendSPI > PulseCLK
But I have not had any clever ideas yet on how to do this using AppleScript, and in honesty 'real' work has got in the way of doing much thinking about it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How I can debugging software written in GCB? Is there a circuit debugger?
You can use MPLAB-X. Or, any of the simulators.
OK. But how I do that?
If I use MPLAB-X, I write the program in c. But I wrote the program in GCB.
Which files do I have to load in MPLAB-X and how do I do that?
I do not understand how GCB and MPLAB-X work together
Is there perhaps a step by step guide for it?
As hardware I have an ICD3 and a PICkit3 available.
I will have to create a video to show you. I cannot explain via just a post.
Has anyone created or seen a video that shows this?
I just created a video.... 38 minutes.
There are a number of options to debug code, shown below.
Hey! I would also like to watch this video. Thanks!
@Anobium
Great! But where can I find this video?
A comment on Evan’s excellent Video:
As I got a mention, Thanks :) I should point out that Real PIC Simulator, whilst a useful piece of code, is a commercial product requiring the purchase of a licence. And, as it has not been updated in the past few years, it is effectively no longer supported by the developer.
PICSimLab on the other hand is Open Source and in active development, to the extent that the core simulator has received several tweeks already this year alone to address simulation errors uncovered by CGBASIC.
RealPICSim emulates more devices but one of the benefits of GCBASIC is that you can do most debugging on any available device, because the code is portable, so you do not have to emulate the physical target device to debug your code.
So as GCBASIC is a Free Open Source Compiler I prefer to recommend Free Open Source tools, especially when the developer willing and actively working with us.
Cheers
Chris
And, a video explicitly for Great Cow BASIC debugging using MPLAB X IDE. I was not happy with my previous video.
Last edit: Anobium 2019-05-14
If, like me, you were intrigued by Evan's videos but are allergic to MPLABx and reluctant to install several Gigabytes of Bloatware, there is an alternative.
MPLAB Xpress now has simulation capability.
MPLAB Xpress is browser based so there is no need to install anything, however, it looks in early testing like you will need to create an account with Microchip. If you are working with PIC chips and don't have a Microchip account there is no harm in creating one, I have had mine for years and it is not abused with spam etc.
The Process is remarkably similar to what Evan posted earlier, if anything it is easier as it is mostly drag and drop (I have 3 screens). But you do need to make sure your ASM file is all UPPERCASE before importing it.
Evan has been commissioned to make a new video to show how to do it but as a teaser here is the standard Blink.gcb code being tested in MPLAB Xpress.
The Screen Shot shows the code stopped on a Breakpoint for the LED = !LED statement.
The lower window shows that it is watching the content of PortC as LED is defined as PortC.0
Here is the GCBASIC Code for the sake of comparison.
Cheers
Chris
Last edit: Chris Roper 2019-05-14
And, a video explicitly for Great Cow BASIC debugging using MPLAB Xpress, the online version of MPLAB X IDE.
WATCH THE VIDEO HERE... https://sourceforge.net/p/gcbasic/discussion/579125/thread/3ec7fe0760/#bf85 IT IS A LOT BETTER!
Last edit: Anobium 2019-05-15
And, a video explicitly for Great Cow BASIC debugging using PICKitPlus software with a PICKit2 Programmer. Using this configuration to send debug information via the MCU serial port via the PICKitPlus software to the PC.
Last edit: Anobium 2019-05-14
Excellent work by Evan....I haven't a clue how to use mplab.
Give MPLab Xpress a try, but later, I think we have crashed it as it is currently timing out for both of us at the moment when making a new project. Even was building a new video and I was testing the PICkit3 Hardware debugger and the web site died :>(
And, an updated video explicitly for Great Cow BASIC debugging using MPLAB Xpress, the online version of MPLAB X IDE.
Great post! I am working on this as well...
@Randall. It was you that gave me the inspiration to figure out MPLAB-
Hello.
Just looking at this now having had a few minutes at work to watch the video about debugging programs using MPLabXpress. I've run into a problem already!
On compiling the program I'm getting an error message with regards to my frequency tables.
The error returned is:
Error[151] D:\TEMP\MICROCHIP\F42A2B1DDE1E460298E39D8891C33AAD\9D5221725EE04A7893CA4B32A10DC57F\12F1840_FREQUENCY\AD9833_CONTROLLER_12F1840_TABLE.ASM 196 : Operand contains unresolvable labels or is too complex
On the assumption that this points to line 196 of the .asm, the command is:
MOVLW (HIGH TABLEFREQTABLEHIGH) & 127
The code for this table being:
I have a two tables containing word values, each of which seem to be split by the GCB compiler into two tables containg the byte values, making four tables in total. All four tables are returning the same error message.
The code compiles in GCB perfectly, and I've downloaded it to an actual 12F1840 device where it runs perfectly well. I'm sure I've missed something obvious, but can't see what.
Well spotted.
There are a large of number of issues with MPLAB Xpress. Chris and I are working with Microchip to resolve.
I have created this GitHub with a number of the issues. https://github.com/Anobium/Microchip_Xpress_Projects/tree/master/bugs%2Bissues/asm
Your issue is reported at issue #3. No resolution as yet.
Thanks for that. I thought I'd lost the plot.
I opened another (even simpler) project for outputting some bit-banged serial data to a 4x7 segment LED display using four 74HC595 to drive the displays that I have used in a number of hardware designs. That won't run either. It builds correctly this time but fails to 'Run' giving the very helpful message:
Although as it states 'No code generated' I'm wondering if it compiled anything.
This is precisely what stopped me from using PIC microprocessors in the first case and why I started out using PicAXE processors. I never could get anything to compile/build/program using MPLab. It drove me bananas then, and it seems like nothing has changed. I could not believe how beautifully easy it was to program PIC devices with GCB. Any errors (and I do get plenty!) I get are simple to understand, simple to find and simple to correct. Once I've cleared my silly spelling errors and the like the program compiles/builds/programs everytime.
Oh well. I thought that it would be lovely to be able to put the debugger to use. Sometimes it isn't always possible to hook up an LCD and have the code print out the values of pins and variables at various points in the code in order to try and see what stupidity I've created this time so thought this could be very useful. It's looking far less useful if I can't get it to run two simple programs. I'll never get it to simulate the large programs I have that give me concern over the stack level down to me overusing subroutines - which is what I'd really like to be able to do.
if you send me you GCB file. I can test.
Tomorrow, I will post all the issues, but, yours could be a new one.
Thanks for looking, I really appreciate it.
As I said in my previous post, if it is going to drive me into a furious swearing match with the computer each time I try to use it, I won't bother to use MPLabXpress.
I'd be happy to pay a reasonable sum for something that actually worked, and worked with a range of devices that I actually use. As of yet, I have not found anything that does one of the two criteria never mind both.
Code attached. As with many of my programs, it is split into the main program, a header containing the definitions and a header with the tables.
As a result of the original debugging Question and the subsequent discussion, I have been putting together some debugging code for GCBASIC. It should overcome your issue of not always having an LCD display available and, if you use a PICKit 2 programmer it should be a plug and play solution for you.
My main issue is, however, has been getting its footprint down and if you are already running into capacity issues with RAM or Call Depth it is probably not going to work for you, but it can still help to test individual sections of code or even your hardware, before you combine them into the target app.
As for the stack level the data sheet for your device will give you the stack depth (GCBASIC does not maintain its own stack) but as a rule of thumb this table, paraphrased from the GCBASIC Help File, is a good guide:
I have been trying to fully document the debugger and test on all of the PIC families and AVR, but for expediency I am considering releasing it in stages for testing with a view to submitting a debug Library for the next GCBASIC release.
I will add you to the beta test list if you are interested.
Cheers
Chris
Hello. Thanks for your response.
Firstly, yes, I would like to be added to your beta list for the debugger.
I was aware of the seven nested levels stack limit, but have not yet managed to come up with a way of determining the maximum level of nested subroutines in my code! I did bang together a script that determined all the calls to subroutines within the source code, then listing each external call within each subroutine, but couldn't then think how I could follow each call into each subroutine, showing any subsequent calls.
I get something like this from my script:
Which I'd like to be able to drill down into something more like this:
Giving me the worst case scenario of a stack level of four.
MainLoop_Sub > SetFreq > SendSPI > PulseCLK
But I have not had any clever ideas yet on how to do this using AppleScript, and in honesty 'real' work has got in the way of doing much thinking about it.