It has been a busy summer of change for the GC BASIC toolchain. Many updates, new capabilities and many fixes.
The highlights are more chips supported, more libraries and improved quality of the complete toolchain.
As the user community grows it means a wider variety of chips are being used. The quality of the chip DAT are improving based upon user feedback.
LCD, HEF, SAF, USART all have been improved with new capabilities.
GC BASIC: The compiler. The bugs are getting more obscure, harder to resolve but in each case the compiler has been updated to resolve the bugs.
Compiler reporting - the recently introduced Compiler Definition File ( CDF ) has been improved to show more of the inner workings of the compiler. See the Help on how to expose the CDF file.
Compiler PIC-AS support has improved. The compiler now support XC8 v2.45. This means more capabilities have be leveraged between GC Studio and MPLAB-X IDE.
The toolchain now supports the revised location for the core compiler. The new location is GCBASIC. The use of the folder is automatically handled by the installation and/or upgrade process. This change supports the common naming convention.
GC Studio has been improved to support the Legacy IDE SynWrite, and, to further improve the update process.
GC Code has been improved to resolve editor formatting and other GC BASIC dialect issues.
As you may have noticed we have moved to a common naming convention. GC BASIC, GC Studio and GC Code. A lot of work has been completed to normalise the naming, however, there are still places where Great Cow exists - do let us know where you spot these.
What next ?
It is one of three options, unless you have a better option.
Option 1. Add the new AVR chips. The new AVR chip use a different convention to set and manage ports and port.pins. The intent would be for GC BASIC will mask this complexity and use the GC BASIC instructions.
Option 2. Resolve and implement FLOATs. The existing implement of floats is not recommended for use. See https://sourceforge.net/p/gcbasic/discussion/596084/thread/b867317011/ The intent would be to resolve the existing issues and improve the compiler to better handle float type variables.
Option 3. Reach out to Microchip and integrate GC BASIC within MPLAB-X IDE. This has been completed as a prototype but this activity would move GC BASIC into another league. We have the quality, we have the infrastructure ( within GC Studio ) to support the integration. The outcome - GC BASIC available from within MPLAB-X IDE.
What are you thoughts ? option 1, 2, 3 or something else ?
and, should we change the version control? Change from builds to dates. So, move from version 1.01.00 2023-09-01 (Windows 64 bit) : Build 1279to 2023.09.05 build 1279. It is just removal of the version number. ( I got the idea from my Home Automation software.. I know what the version is by the date shown... easier). Again, your thoughts?
Thanks
A huge shout out to Angel who has led the GC Studio implementation. The support of the GC CODE IDE and the Legacy SynWrite Editor was a huge task.
Thank you Angel for driving the changes and driving further changes across the whole tool chain.
A huge shout out to Pete Everrett. The lead developer on PPSTool. He is sharing the development work with Angel. Without PPSTool working with PICs would be so hard. Thank you for all your efforts todate.
👍
2
Last edit: Anobium 2023-09-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just started to use GCBasic couple of weeks, so thank for your efforts to create this nice tool.
If you ask me right now, option 1 would be my preference. One reason to choose GCBasic is exactly that, be able to use AVR as well PIC. Option 3, not really, I find MPLAB X too massif for my hobby approach. Option 2, hum I have never used up to today float type variables. So I vote for option 1 :)
The version topic, I more focusing on version itself, by following many products, I find it more easy to compare the version number that every date. But by keep like you propose the build after the date, you combine both, date and version.
Thank a lot,
👍
1
Last edit: Fabrice Engel 2023-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The process of generating a GCBASIC DAT file is: Get all the tools from this GIT
Identify new chip from MPLAB-X release notes.
Source MPLAB-X DEF files for specific chip. These are included within the MPLAB-X release
Using 18F06Q41 as an example. These are the files that need to be withing the MPLAB-X installation.
Run the converter to produce an INC file. This may involve revising the source program for the (https://github.com/GreatCowBASIC/DATFileGenerator/blob/main/XC8toINC_Converters/PIC18/18F_PIC_to_INCv6_05.exe) to new file locations etc. The (https://github.com/GreatCowBASIC/DATFileGenerator/blob/main/XC8toINC_Converters/PIC18/18F_PIC_to_INCv6_05.exe) is written in FreeBASIC and this is easy to change.
Review the INC and either resolve by doing step 3 again, or. place the newly created INC in the DAT creation folder incfiles\OrgFiles\
Run the Preprocessor on the INC file. gawk -f preprocessIncFile.awk ......\incfiles\OrgFiles\p18F06Q41.inc > ......\incfiles\p18F06Q41.inc This operation sorts the inc file into a consistent order ( this has been done all INC files to data and this is important.) At this point you have an INC file that matches the MPASM standard.
Add the chip to the XLS database . There are many parameters that are needed to be completed. Use the datasheet and JALLIB
Run the executable GETCHIPDATA chipname. This will produce the DAT file in the folder CHIPDATA.
Test the chip and share!
For PPS. Take an existing PPS XML file, copy it and edit by hand using the datasheet as the source.
Easy.....
👍
1
Last edit: Anobium 2023-09-06
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are extensions of exiting chips: 16F17154, 16F17155, 16F17156, 16F17174, 16F17175, 16F17176, 16F18154, 16F18155, 16F18156, 16F18174, 16F18175, 16F18176, 18F44Q71, 18F45Q71, 18F54Q71, and 18F55Q71
These are new parts: 18F06Q20, 18F16Q20. They have I3C that will have to be supported via a new library or hack the registers on a project by project basis. These parts are not tested and the compiler will issue a warning.
Programming I will add to PK+ when I get samples from Microchip.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The next update to GC STUDIO will contain an update to PPSTool. This update will include harmonised naming, improved template and support for new chips.
We are also moving PPPSTOOL to GitHub to bring all components of the GC Studio toolchain into one place. Pete Everett is supporting this move and the existing SourceForge repository will be updated to show the new Git location.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
September 23 update on GC BASIC
It has been a busy summer of change for the GC BASIC toolchain. Many updates, new capabilities and many fixes.
The highlights are more chips supported, more libraries and improved quality of the complete toolchain.
As you may have noticed we have moved to a common naming convention. GC BASIC, GC Studio and GC Code. A lot of work has been completed to normalise the naming, however, there are still places where Great Cow exists - do let us know where you spot these.
What next ?
It is one of three options, unless you have a better option.
Option 1. Add the new AVR chips. The new AVR chip use a different convention to set and manage ports and port.pins. The intent would be for GC BASIC will mask this complexity and use the GC BASIC instructions.
Option 2. Resolve and implement FLOATs. The existing implement of floats is not recommended for use. See https://sourceforge.net/p/gcbasic/discussion/596084/thread/b867317011/ The intent would be to resolve the existing issues and improve the compiler to better handle float type variables.
Option 3. Reach out to Microchip and integrate GC BASIC within MPLAB-X IDE. This has been completed as a prototype but this activity would move GC BASIC into another league. We have the quality, we have the infrastructure ( within GC Studio ) to support the integration. The outcome - GC BASIC available from within MPLAB-X IDE.
What are you thoughts ? option 1, 2, 3 or something else ?
and, should we change the version control? Change from builds to dates. So, move from version
1.01.00 2023-09-01 (Windows 64 bit) : Build 1279to2023.09.05 build 1279. It is just removal of the version number. ( I got the idea from my Home Automation software.. I know what the version is by the date shown... easier). Again, your thoughts?Thanks
A huge shout out to Angel who has led the GC Studio implementation. The support of the GC CODE IDE and the Legacy SynWrite Editor was a huge task.
Thank you Angel for driving the changes and driving further changes across the whole tool chain.
A huge shout out to Pete Everrett. The lead developer on PPSTool. He is sharing the development work with Angel. Without PPSTool working with PICs would be so hard. Thank you for all your efforts todate.
Last edit: Anobium 2023-09-05
Hello,
Just started to use GCBasic couple of weeks, so thank for your efforts to create this nice tool.
If you ask me right now, option 1 would be my preference. One reason to choose GCBasic is exactly that, be able to use AVR as well PIC. Option 3, not really, I find MPLAB X too massif for my hobby approach. Option 2, hum I have never used up to today float type variables. So I vote for option 1 :)
The version topic, I more focusing on version itself, by following many products, I find it more easy to compare the version number that every date. But by keep like you propose the build after the date, you combine both, date and version.
Thank a lot,
Last edit: Fabrice Engel 2023-09-06
I will also add the following 18 new chips.
16F17154, 16F17155, 16F17156, 16F17174, 16F17175, 16F17176, 16F18154, 16F18155, 16F18156, 16F18174, 16F18175, 16F18176
18F06Q20, 18F16Q20
18F44Q71, 18F45Q71, 18F54Q71, and 18F55Q71
Sharing insights into adding new chips.
The process of generating a GCBASIC DAT file is: Get all the tools from this GIT
Using 18F06Q41 as an example. These are the files that need to be withing the MPLAB-X installation.
chipname. This will produce the DAT file in the folder CHIPDATA.For PPS. Take an existing PPS XML file, copy it and edit by hand using the datasheet as the source.
Easy.....
Last edit: Anobium 2023-09-06
Added Anobium
These are extensions of exiting chips: 16F17154, 16F17155, 16F17156, 16F17174, 16F17175, 16F17176, 16F18154, 16F18155, 16F18156, 16F18174, 16F18175, 16F18176, 18F44Q71, 18F45Q71, 18F54Q71, and 18F55Q71
These are new parts: 18F06Q20, 18F16Q20. They have I3C that will have to be supported via a new library or hack the registers on a project by project basis. These parts are not tested and the compiler will issue a warning.
Programming I will add to PK+ when I get samples from Microchip.
PPSTOOL
Heads up.
The next update to GC STUDIO will contain an update to PPSTool. This update will include harmonised naming, improved template and support for new chips.
We are also moving PPPSTOOL to GitHub to bring all components of the GC Studio toolchain into one place. Pete Everett is supporting this move and the existing SourceForge repository will be updated to show the new Git location.