Hello All-
I have been asked to share some of my coding philosophy in code versions.
Over the past few weeks I have been exploring and learning GCB. In my code I have documented as I learn at the beginning in my Version Notes what I have accomplished and what is in flux.
We all save versions of code while we are getting the target to perform as we want but just looking at the REV or VER number in a file does not help much.
If you add notes at the top of your code and along with that add version history with your version numbering scheme it will prove useful.
Trying to find what version you are using works if you look at the code, but I also use any display device such as 7 segment LEDs, or an LCD. I also use a serial line to a serial terminal program - I use the one in GCB which has been helpful.
All of these tell me what version of code is running on the proc and it is also noted in the comment section I put at the beginning thus making it easy to determine where I am - especially if I walk away for a few days.
All you have to do is put up a brief initial screen indicating the software version. You can reference what you see with what you read at the top of your code.
There are many ways to do this, I use 3 sets of digits;
XX.YY.ZZ where XX is the main body of code or the design philosophy and YY may be any hardware changes you may have made and ZZ is the version of code to make YY work like you wish. You may use whatever makes sense to you and that is precisely the point - it must make sense to you.
If your design does not use 8 digits of 7 Segment LEDs or a LCD, you can flash and LED a number of times and use a long in between shorter flashes to get to a numerical sequence. Also, I have used an I2C LCD display that I just plug in and boot the target to get my version as well as any diagnostic info I may need.
It sounds dull, a pain, boring to do all of this but it helps organize your project and when you come back to a piece of code in 6 months or longer, you will be happy you took the time for this important bit of documentation.
I hope some of you find this useful - it has helped me learn this compiler much faster and now I have a record of what I did, both good and stupid.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot this it is little used:
#include "GCBVersionNumber.cnt"
'Include the GCBVersionNumber.cnt to increment versionString and create the build time string called GCBBuildTimeStr.
' versionString a string is created automatically.
' GCBBuildTimeStr is a string that is also created automatically.
' use "GCBVersionNumber.cnt" as this will create a local copy of the versionString tracker.
' if you use <gcbversionnumber.cnt> this is a system wide versionString tracker.</gcbversionnumber.cnt>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello All-
I have been asked to share some of my coding philosophy in code versions.
Over the past few weeks I have been exploring and learning GCB. In my code I have documented as I learn at the beginning in my Version Notes what I have accomplished and what is in flux.
We all save versions of code while we are getting the target to perform as we want but just looking at the REV or VER number in a file does not help much.
If you add notes at the top of your code and along with that add version history with your version numbering scheme it will prove useful.
Trying to find what version you are using works if you look at the code, but I also use any display device such as 7 segment LEDs, or an LCD. I also use a serial line to a serial terminal program - I use the one in GCB which has been helpful.
All of these tell me what version of code is running on the proc and it is also noted in the comment section I put at the beginning thus making it easy to determine where I am - especially if I walk away for a few days.
All you have to do is put up a brief initial screen indicating the software version. You can reference what you see with what you read at the top of your code.
There are many ways to do this, I use 3 sets of digits;
XX.YY.ZZ where XX is the main body of code or the design philosophy and YY may be any hardware changes you may have made and ZZ is the version of code to make YY work like you wish. You may use whatever makes sense to you and that is precisely the point - it must make sense to you.
If your design does not use 8 digits of 7 Segment LEDs or a LCD, you can flash and LED a number of times and use a long in between shorter flashes to get to a numerical sequence. Also, I have used an I2C LCD display that I just plug in and boot the target to get my version as well as any diagnostic info I may need.
It sounds dull, a pain, boring to do all of this but it helps organize your project and when you come back to a piece of code in 6 months or longer, you will be happy you took the time for this important bit of documentation.
I hope some of you find this useful - it has helped me learn this compiler much faster and now I have a record of what I did, both good and stupid.
I forgot this it is little used:
#include "GCBVersionNumber.cnt"
'Include the GCBVersionNumber.cnt to increment versionString and create the build time string called GCBBuildTimeStr.
' versionString a string is created automatically.
' GCBBuildTimeStr is a string that is also created automatically.
' use "GCBVersionNumber.cnt" as this will create a local copy of the versionString tracker.
' if you use <gcbversionnumber.cnt> this is a system wide versionString tracker.</gcbversionnumber.cnt>
Thanks for sharing this good approach.
The build counnter is looks good, not used it. Will now. Just found this Help page - https://gcbasic.sourceforge.io/help/_converters.html