This release candidate is NOT a normal few tweaks or changes. This has a totally new capability - yes, there are tweaks and fixes.
This release introduces PIC-AS support.
PIC-AS support is a ZERO impact change if you do not need use MPLAB-X for teaching, debugging or support (see below).
PIC-AS support is a major change. A lot of work.
So, if you are not using MPLAB-X for teaching, debugging or support then this is intended to have zero impact. Therefore, read no further.
And, if you are a AVR, LGT, PIC10, PIC12 user.. this is release contains bug fixes but PIC-AS is not supported yet. So, for you.. just consider the release as a bug fix release.
Evan
Microchip Technology recently released a new assembler for their PIC and AVR microcontroller devices.
The new compiler called the MPLAB XC8 PIC Assembler, is meant to replace the now decades old MPASM assembler. Commonly called PIC-AS
Why does Great Cow BASIC need PIC-AS support ?
Teaching aid - cannot do this as Microchip only support PIC-AS
Debugging - cannot debug an ASM source files as Microchip only support PIC-AS
Support from Microchip - cannot get support from Microchip as they only support PIC-AS
AND... MPASMx is not supported by new chips
A few insights.
PIC--AS changes are isolated from existing PIC, AVR or LGT code
PIC--AS is additive to the Great Cow BASIC compiler
PIC--AS is essentially a translator that produces the PIC-AS source file.
PIC--AS source file is called .S
PIC--AS required the co be installed (this is NO different from ATMEL Studio, MPASMx etc)
PIC--AS support has to be enabled by a user - by installing the Microchip XC8 PIC-AS compiler and then editing the USE.INI file.
How do enable PIC-AS ?
See the video below. But, it is as simple as:
Install Great Cow BASIC
Install the Microchip XC8 PIC-AS compiler
Edit the USE.INI to 1) ensure the directory for PIC-AS is correct 2) set the assembler = pic-as
Now Great Cow BASIC will generated .ASM and .S PIC-AS source.
If want to use with MPLAB-X
Install MPLAB-X
Create a project, selecting the Microchip XC8 PIC-AS compiler as the compiler
As the .S PIC-AS source.
Compile or Compile for debugging etc.
See this video for the full details. It is a long video but this is a huge subject!
Update. I will be posted a later version of RC39 for PIC-AS support.
Fixed an issue where the .DAT file caused a config mismatch in PIC-AS. This condition was a latent issue (been there for years). Resolved by fixing the DAT generator.
Updated system.h. The incorrect system.h was in the build.
PIC-As Test results.
All passed 16F18855: ..\Demos\vendor_boards\mplab_xpress_board_pic16f18855
All passed 18F16Q41: Demos\vendor_boards\microchip_low_pin_count_demo_board\pickit2_board\18f16q41
12F and 10F not tested yet.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had forgot to resolve the USE.INI issue. The release will replace your USE.INI
@RC38.05947 Installer Installer now replaces USE.INI to ensure setup is stable. Later release(s) 'may' edit USE.INI to update with new information only.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why replace USE.INI default? What was wrong with it before?
It was posted it was requested.
gcb getting more complicated. lgt having to be sorted again cos disappeared in ini.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You know best. I don't know what ini is, like chipdata, stuff you don't really want to mess with.
Do you recommend saving working ini. before updating latest rc, then copying it back?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Evan, I got the vibe you took it out cos not sorted completely.
Let us least try the device as it's fast for a pic,
Like you said we now have lgt328!.... then remove it.
Get more avr users to try lgt328 and feed back.
They seem cheap for a usb board with voltage reg and xtal
in an arduino nano package.
A list of not sorted lgt stuff, like runs on arduino nano,16
but not lgtnano,16 might get help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LGT was not removed. You probably lost the programmer as the use.ini was not updated on your system.
There is no list of what is not supported by LGT. The issue with Touch is not an LGT issue but a touch sensor issue. I emailed you a set of tests to figure out the touch sensor performance limitations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Adds new chips, improves support for PIC-AS by adding support for large 16F programs, adding 10F support and adding an ability to 'patch' the config if required.
@RC40 Compiler Initial PIC-AS for 16f large programs[1180]948 DAT Added new MCUs[1179] PIC16F15213 PIC16F15214 PIC16F15223 PIC16F15224 PIC16F15225 PIC16F15243 PIC16F15244 PIC16F15245 PIC16F15254 PIC16F15255 PIC16F15256 PIC16F15274 PIC16F15275 PIC16F15276949 Compiler Small update to use the ini file to handle corrections between ASM and PICAS.[1181] The ini file will search and replace config(s) Example shown below: [patch=asm2picas] desc = PICAS correction entries. Format is STRICT as follows: Must have quotes and the equal sign as the delimeter. PartName +COLON+"BadConfig"="GoodConfig" Where BadConfig is from .s file and GoodConfig is from .cfgmap file 16f8x:"intrc = IO"="FOSC=INTOSCIO" 12f67x:"intrc = OSC_NOCLKOUT"="FOSC=INTRCIO" 16F69x:"INTOSCIO = "="FOSC=INTRCIO"950 Compiler Added Support for 10Fxx chips[]
Last edit: Anobium 2021-02-23
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Linux distribution doesn't include the "Help" folder. Is this intentional, or an oversight? I have been using the .chm file and just noticed after updating yesterday it isn't there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, I can pull from the Windows .exe if needed. I see the .chm file I have is dated May 2018 so I guess it hasn't disappeared, more that I never noticed it wasn't there.
I do use it though, I finally got context sensitive help working and find it really useful. All formats can't take up that much space surely?
So, if it isn't any hardship, all formats, yes please.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I update my installation I often find that things that were working, stop working. More often than I'd like, fonts and colours get replaced with default ones and any custom toolsets I've added to the IDE menu(s) get lost. This leaves me very reluctant to upgrade. The last time I upgraded from RC09 to RC42 (I think) at work, it took me well over 4 hours to get the compiler to run again without error, and that time I thought I would be clever and install the whole new installation initially, then copy back the .ini files and my custom scripts later, once everything else was working. This all having been working perfectly up until the point I tried to upgrade.
Is there a more obvious, clever way of managing updating that I'm missing? Something that will preferably maintain my custom files, my commands for using the NSDSP programmer and the like?
It puts me off upgrading and so I tend to stick with what is working as I can't face the turmoil I seem to suffer when I do upgrade.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are a few ini files that need to be managed. This is not a new or unique issue to this install process but we need someone to figure out all the install options and how to manage the new/update process.
As we use InnoSetup for Windows then I would imagine that is all resolveable.
But, this is not a piece of work that I would want someone to pickup and run with. InnoSetup is well documented and the Great Cow BASIC setup file is avaialble.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At one time, there was a "Minimal" install option. As I recall, that contained only the necessary updated files. That hasn't been updated recently though.
I realise that would not suit many people who might prefer the fully automated install package, but I always found it vastly more manageable.
Is there any chance that a very, very minimal, zipped file could be made available which had only the "new" files along with any specific support files required by any new release?
Or a simple zipped file (with everything in it) as opposed to a full installer, with a list of updated files since the last release so I could pick them out myself and move them into my installation without performing a blanket replacement of everything?
Or could a description of (only) the updated files be included in the installer? Then I could install to a "dummy" folder, pick out the updated files, move them into place manually, then delete the new "dummy" installation.
I would find myself holding off updating much less if I thought it wasn't going to stop me working for a number of hours every time I did update. At work, I don't have that time to put aside for updating, so am even less likely to update unless I absolutely have to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are all the questions that need to be answered.
Great Cow BASIC is changing and improving as more developers add more fumctionality. The last year has had 45 major updates... change will be constant.
Each release needs to be impacted for what the end state needs to look like. The starting point can be anything from a new install to any state.
This is NOT the case of what changed. There may be changes within in INI files that have changed.
The easy way to resolve would be a configurator. There would be a known end state and the configurator would inspect and impact everything.
Re a list of what changed. The releasenote.txt has a list of all the functional changes, but, it is very safe to assume 100% of the compiler files change per release. We dont change the supporting programmers, but, PPS is typically 100% changed.
I no longer provide the minimal installers as the tool chain is too large to manage. It takes over 12 hours to build and test a release - just the packaging not the functional changes.
So, what changes that impacts the users? The ini files. Anyone playing with the batch files or using batch files should stop. There is no need to change any batch file. Change the ini's.
InnoSetup can assess ini files. And, a configurator would resolve differences.
My rules. Install and use. Use Programmer Preferences to make my programmer changes. NSProg and PK+ just need the files dropping into the default folders. I personally so not change the IDE.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This release candidate is NOT a normal few tweaks or changes. This has a totally new capability - yes, there are tweaks and fixes.
This release introduces PIC-AS support.
PIC-AS support is a ZERO impact change if you do not need use MPLAB-X for teaching, debugging or support (see below).
PIC-AS support is a major change. A lot of work.
So, if you are not using MPLAB-X for teaching, debugging or support then this is intended to have zero impact. Therefore, read no further.
And, if you are a AVR, LGT, PIC10, PIC12 user.. this is release contains bug fixes but PIC-AS is not supported yet. So, for you.. just consider the release as a bug fix release.
Evan
Microchip Technology recently released a new assembler for their PIC and AVR microcontroller devices.
The new compiler called the MPLAB XC8 PIC Assembler, is meant to replace the now decades old MPASM assembler. Commonly called PIC-AS
Why does Great Cow BASIC need PIC-AS support ?
A few insights.
How do enable PIC-AS ?
See the video below. But, it is as simple as:
Now Great Cow BASIC will generated .ASM and .S PIC-AS source.
If want to use with MPLAB-X
See this video for the full details. It is a long video but this is a huge subject!
Evan
Key moments in the video
Why do this? https://youtu.be/UXHbEX9ImPA?t=18
What has changed ? https://youtu.be/UXHbEX9ImPA?t=128
How to install the release? https://youtu.be/UXHbEX9ImPA?t=379
How to enable PIC-AS? https://youtu.be/UXHbEX9ImPA?t=649
How to change USE.INI ? https://youtu.be/UXHbEX9ImPA?t=812
What the changes between .ASM and .S ? https://youtu.be/UXHbEX9ImPA?t=975
How to create a MPLAB-X project? https://youtu.be/UXHbEX9ImPA?t=1027
Summary https://youtu.be/UXHbEX9ImPA?t=1433
Changes Since RC38
Last edit: Anobium 2021-02-10
Update. I will be posted a later version of RC39 for PIC-AS support.
PIC-As Test results.
All passed 16F18855: ..\Demos\vendor_boards\mplab_xpress_board_pic16f18855
All passed 18F16Q41: Demos\vendor_boards\microchip_low_pin_count_demo_board\pickit2_board\18f16q41
12F and 10F not tested yet.
And, AVR is not yet supported with respect to PIC-AS
Last edit: Anobium 2021-02-10
Posted new updates to RC39. See https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/GCB_Installer-v0.98.07%20RC39.exe/download replace what you have and try again.....
Changes include new .dat to resolve latent issues, new warning message for when using PIC-AS that is not supported.
I have also regened all the DAT files and then rerun the PICInfo database as this was out of date with the new fixes.
RC39 Patch
See https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/Patches/
Copy updated compiler to your installation.
11/02/2021
Enjoy
Last edit: Anobium 2021-02-11
RC39 Patch
See https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/Patches/
Copy updated compiler to your installation.
11/02/2021
Further improvements.
Wow! This is a ton of work, kudos!
Another change.
I had forgot to resolve the USE.INI issue. The release will replace your USE.INI
Why replace USE.INI default? What was wrong with it before?
It was posted it was requested.
gcb getting more complicated. lgt having to be sorted again cos disappeared in ini.
Use.ini contains the setup and you programmers.
The reason LGT disappeared was because use.ini was not replaced. In the future it will be replaced to prevent this from happening in the future.
You know best. I don't know what ini is, like chipdata, stuff you don't really want to mess with.
Do you recommend saving working ini. before updating latest rc, then copying it back?
I do not recommend copying an old ini back into the folder.
There are new settings and programmers that will be lost when you copy old ini over a rc39 ini.
Evan, I got the vibe you took it out cos not sorted completely.
Let us least try the device as it's fast for a pic,
Like you said we now have lgt328!.... then remove it.
Get more avr users to try lgt328 and feed back.
They seem cheap for a usb board with voltage reg and xtal
in an arduino nano package.
A list of not sorted lgt stuff, like runs on arduino nano,16
but not lgtnano,16 might get help.
LGT was not removed. You probably lost the programmer as the use.ini was not updated on your system.
There is no list of what is not supported by LGT. The issue with Touch is not an LGT issue but a touch sensor issue. I emailed you a set of tests to figure out the touch sensor performance limitations.
RC40
Adds new chips, improves support for PIC-AS by adding support for large 16F programs, adding 10F support and adding an ability to 'patch' the config if required.
See https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/ folder.
Enjoy
Last edit: Anobium 2021-02-23
RC42 posted.
more updates and a new S&7789 GLCD driver.
The Linux distribution doesn't include the "Help" folder. Is this intentional, or an oversight? I have been using the .chm file and just noticed after updating yesterday it isn't there.
As the build process is automated. I just push an icon... I would say this Help was always missing.
I can add to the automated process. Add all formats?
Well, I can pull from the Windows .exe if needed. I see the .chm file I have is dated May 2018 so I guess it hasn't disappeared, more that I never noticed it wasn't there.
I do use it though, I finally got context sensitive help working and find it really useful. All formats can't take up that much space surely?
So, if it isn't any hardship, all formats, yes please.
It is no problem. All formats.
When I update my installation I often find that things that were working, stop working. More often than I'd like, fonts and colours get replaced with default ones and any custom toolsets I've added to the IDE menu(s) get lost. This leaves me very reluctant to upgrade. The last time I upgraded from RC09 to RC42 (I think) at work, it took me well over 4 hours to get the compiler to run again without error, and that time I thought I would be clever and install the whole new installation initially, then copy back the .ini files and my custom scripts later, once everything else was working. This all having been working perfectly up until the point I tried to upgrade.
Is there a more obvious, clever way of managing updating that I'm missing? Something that will preferably maintain my custom files, my commands for using the NSDSP programmer and the like?
It puts me off upgrading and so I tend to stick with what is working as I can't face the turmoil I seem to suffer when I do upgrade.
We are at RC45.
The process can be improved - I agree.
There are a few ini files that need to be managed. This is not a new or unique issue to this install process but we need someone to figure out all the install options and how to manage the new/update process.
As we use InnoSetup for Windows then I would imagine that is all resolveable.
But, this is not a piece of work that I would want someone to pickup and run with. InnoSetup is well documented and the Great Cow BASIC setup file is avaialble.
At one time, there was a "Minimal" install option. As I recall, that contained only the necessary updated files. That hasn't been updated recently though.
I realise that would not suit many people who might prefer the fully automated install package, but I always found it vastly more manageable.
Is there any chance that a very, very minimal, zipped file could be made available which had only the "new" files along with any specific support files required by any new release?
Or a simple zipped file (with everything in it) as opposed to a full installer, with a list of updated files since the last release so I could pick them out myself and move them into my installation without performing a blanket replacement of everything?
Or could a description of (only) the updated files be included in the installer? Then I could install to a "dummy" folder, pick out the updated files, move them into place manually, then delete the new "dummy" installation.
I would find myself holding off updating much less if I thought it wasn't going to stop me working for a number of hours every time I did update. At work, I don't have that time to put aside for updating, so am even less likely to update unless I absolutely have to.
These are all the questions that need to be answered.
Great Cow BASIC is changing and improving as more developers add more fumctionality. The last year has had 45 major updates... change will be constant.
Each release needs to be impacted for what the end state needs to look like. The starting point can be anything from a new install to any state.
This is NOT the case of what changed. There may be changes within in INI files that have changed.
The easy way to resolve would be a configurator. There would be a known end state and the configurator would inspect and impact everything.
Re a list of what changed. The releasenote.txt has a list of all the functional changes, but, it is very safe to assume 100% of the compiler files change per release. We dont change the supporting programmers, but, PPS is typically 100% changed.
I no longer provide the minimal installers as the tool chain is too large to manage. It takes over 12 hours to build and test a release - just the packaging not the functional changes.
So, what changes that impacts the users? The ini files. Anyone playing with the batch files or using batch files should stop. There is no need to change any batch file. Change the ini's.
InnoSetup can assess ini files. And, a configurator would resolve differences.
My rules. Install and use. Use Programmer Preferences to make my programmer changes. NSProg and PK+ just need the files dropping into the default folders. I personally so not change the IDE.