If I have the time - within the next 24 hours. I will publish Windows and Linux.
Evan
Lots of changes and fixes
Fix: For missing constant in the 16F17xx chipfiles to support PMW16 capability. Added PWM16TYPE=1 to dat file. CHIPDATA.CSV updated for 9 chips, these chips were re'gened.[1246]
"Fix: For FOR-NEXT loop when using a negated step value. A negated step value is no longer permitted as this is cast as byte, and, the transform in preprocessor breaks legacy FOR-NEXT support. Resolution: 1) Inspect step variable type and negate is not present 2) Cast in the compiler as integer when the loop variable is an integer[1247,1248]
Considered non critical issue as use of negating was issuing a valid error message."
Fix: Updated reserved words list[1249]
Fix: Updated to support Microchip website changes. Website changes broke Datasheet, Errata and Home page links. Now version v2.90e.
Fix: Updated to XOJO latest release. Now version v2.90G
Fix: For missing constant in the 16F183xx chipfiles to support 31k capability. CHIPDATA.CSV updated for chips, changing 31k OSSCON1 to 64, these chips were re'gened[1250]
Fix: For missing label for 10ms [1251]
Fix: Add Fix for errata bug in DS40001816F in 18fX6K40 chips[1252]
Fix: Add Fix for errata bug in DS40001816F in 18fX6K40 chips[1252]
Fix: Rewrite of NVMADR_EPWrite/EPread to better support 18fxxQxx chips/NVMADRU register moving to ChipSubFamily resolve RD issue and adding Q40 support[1253,1255]
Fix: 18FxxQ40 memory map corrected. Change GETCHIPDATA source to handle Q40s. It was missing from GETCHIPDATA handler.[1256]
Fix: Added ADREADPREREADCOMMAND to AVR read to enable setting of any register prior to ADC read operation[1257,1265,1267]
New: Improved interrupt latency by adding Family 15 ( 12F and 16F ) interrupt handler to use shadow locations for system variables, therefore use chips automatic context saving[1258]
New: Improved interrupt latency for all Family 16 ( 18F ), was just K42 chips, interrupt handler to use shadow locations for system variables, therefore use chips automatic context saving[1259]
Fix: Resolves issue with creation of constants that are not required. Library contains development guideline for the creation of library constants.[1260]
New: Add MVECEN = ON 'not supported' message.[1261]
Update xpt2046.h and the 330_using_glcd_touch_xpt2046_demonstation_for_ili9341_lgtf328p.gcb demo. Revise XPT2046 library to support LGT chips using software SPI[1266]
Add SysMultSub64, SysDivSub64, SysCompEqual64 and SysCompLessThan64[1262,3]. WARNING WARNING - these changes will require updating when IF-THEN support Advanced Variables.
Change USART=0 to USART=1. Change the master CSV and regen these chip files tiny2313 & tiny2313a [1264]
Rename Programmer from Microchip Xpress CNANO Boards USB [16f18466] to Microchip CNANO USB [16F & 18F]
Updated: USB Drivers Setup Great-Cow-BASIC-Demonstration-Sources/USB_Solutions/GreatCowBASIC_Solutions/LIBWINUSB_Solutions/WindowsDeviceDriver/
For Q43 I2C discovery. Revised SI2CDiscovery adding #IFDEF var(I2C1CNTL) and #IFDEF var(I2C1CNT) to isolate Q43 that only supports I2C1CNT[1268]
Fix: Errata and Programming now work after the Microchip website changes... tool now uses an improved Regex to dertermine the PDFs. Now version v2.90i
New: Now launches web page if cannot find ERRATA or PROGRAMMING PDF. Now version v2.90k
Fix: Resolves Q41 family chip EEPROM write error caused by bit naming[1270]
Fix: Resolves silent crash when two functions of same name exists. Now handles and issues correct error message[1269]
Fix: For out of bounds memory array in compiler[1271]
Fix: Resolves Rs232 script creation of constants.[1272]
New: Examines source web page for ERRATA or PROGRAMMING PDF, opening web page if more that one instance found, Also, now exposes search strings in PREFERENCES. Now version v2.90M
Fix: Resolve out of bounds memory array in compiler in 32bit version only in VARADDRESS(), and, resolve pointer warning during compilation [1273]
Fix: Resolve error where generated ASM was optimised incorrectly for end of sub call. Changes to AsmOptimiser() [1274]
Fix: Resolve further error introduced at [1037] where generated ASM was optimised incorrectly for end of sub call. Changes to AsmOptimiser()[1275]
"Fix: Resolve CONCAT system variable issue.[1276]
Fix: Compiler updated to simplify CONCAT. Now supports SYSDEFAULTCONCATSTRING to set the size of the system variable used for concat operations.[1278]"
New: Added USART1_BAUD_RATE support in script so USART1_BAUD_RATE equates to USART_BAUD_RATE.[1277]
Fix: Compiler updated to improve handling of wait parameters. Resolves the incorrect specification of time units. wait 4 10[space]us [1278]
Fix: Scripting in the compiler now correctly handles the existence of constant with no value.[1279]
Fix: Resolve lockup caused by missing #ENDSCRIPT [1280]
Fix: Performance improvement to change 1041[1281]
Fix: Resolves scripting support for IF, DEF() and NODEF() for testing constants [1282]
Fix: Change to Wait() to reduce the cycles by one cycle to resolve wait 1 us error. Implements WAITP1() to expose old timing method.
Fix: Change to Wait() to reduce the wait cycle by one cycle to resolve wait 1 us error in PULSEOUT(). Implements WAITL1() to expose new timing method - this replace change 1046.[1283]
Fix: stdbasic.h Change PULSEx delays to one cycle less using WAITL1 [1284]
New: SynWrite Helpers to add SYSDEFAULTCONCATSTRING.
"New: Add new delay routines for WAIT() when the frequency is less then 96 kHz. This essentially means that WAIT() for 31kHz are now correct. [1286]
MS Delays at Clock frequency’s below 28kHz are not supported and will silently fail.
US Delays at Clock frequency’s below 250kHz are not supported and will silently fail.
US Delays at lower Clock frequency’s is accurate ONLY when nn is divisible by 4. This is caused by the minimum ASM delay loop being a specific number of instructions.
US Delays at lower Clock frequency’ when not divisible by 4 will silently accept the nn value and incorrect delays will be produced.
Delays at Clock frequency’s below 500kHz may be impacted by previous instructions; testing of actual delays is advised. Tested on PIC only. This may work on AVR however this was not tested. This change was implemented by Angel Mier - most grateful". Delays of less than 28kHz are not support and will silently fail.
Added support for 31k to 12(L)F1501 [1287]
Added new MCUs[1288]
18F26K83, 18F27K83, 18F26K83, 18F46K83, 18F47K83
18F26K84, 18F27K84, 18F26K84, 18F46K84, 18F47K84
USART.H updated
EEPROM.H updated
PICAS: Fix for Q83 and Q84 CRC PIC-AS configs. Essentially increase the array size.[1289]
Message update only. SourceForge prompt. Non-functional change[1290]
Corrected K83 chipsubfamily[1291]
Improved GCGB UI for selection of config[]
"Correction to the DAT files for 18FxxQ8x - from information from Microchip. [1293]
The correct amount of GPR bytes for the two device families are 8192 bytes for the x6Q83/84 and 12,800 bytes for the x7Q83/84. The devices also have 256 bytes of RAM that is used as a buffer for the NVM module and 2048 bytes of RAM that is dedicated to use by the CAN FD module’s FIFOs.
The MICROCHIP division has noted the correction and will be reflected in the coming revisions of datasheets and will also make sure that the website matches the 12800 value rather than the 13000 value"
Correct the EE address for table creation on Q40 chipfamily[1294,1297]
PIC-AS support added for 2.35 toolchain. Isolation of 2.32 PIC-AS patches.[1295]
Resolves AVR table read byte to array element. Created cache to ensure the array element is not overwritten.[1295-1296]
Update to SSD1306 library to improve memory requirements message[1298]
Update to ST7735 library to improve libraries isolation[1298]
Update to message to improve errors in SFRs[1298]
Add CANBUS.H and demos [1299] Released build of v0.98.07 build 1064 to release candidate
"Q40 Support added. New Dat files, updated eeprom.h and updated pwm.h[1300]
Added Q40 32 demos. See https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/Vendor_Boards/Great_Cow_Basic_Demo_Board/18f16q40_chiprange_demonstrations"
Removal of Serial debug from the XPT library[1301]
Minor change to automatically selected GCASM when an AVR[1302,1303]
Fix for PIC-AS .S source file comments being expanded into XC8 Macros![1304]
Minor fix: Resolves causes sensitive CONFIG PRAGMA statements[1305]
Another minor fix: Resolves causes sensitive CONFIG PRAGMA statements[1306]
Updated GS+Tools to prevent lock-up with the BEEP API and add support for Promo messages
Updated compiler to use promo messages - update to GS+TOOLS to support promo messages
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It takes a few secs to create a ZIP for Patches. It is all automated. But,
A release for everything, updating the website, all the files, all the version, archiving off the last version, updating the messages inside the build then testing, revising and testing... etc takes six hours. I know... I just timed it,
Released
Full fat software package for Windows
GCGB software package for Windows
Core software package for Windows
Linux software archive
I have not included minimal build as no-one has downloaded for two years. So, no point of just the compiler.
You will notice that the revision did change to v0.99.01. Why? Because I feel confident that the USB and SD Card code works ( folks have these working and this was the test for release completion). If we can sort Real number in this release then we will reach the milestone of v1.00. We all may decide the the Real number support is not required and we could move regardless to v1.00 - thoughts on this?
So, another release done.
Enjoy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have not included minimal build as no-one has downloaded for two years. So, no point of just the compiler.
I had thought that I had pestered for a minimal install many times and had been advised that due to the number of changes across many files this wasn't possible or recommended?
I'm always reluctant to upgrade as it takes me so very, very, very, very, very long to put everything back to how it used to be, and how I like to see it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The mimimal install did not include anything but the compiler and the minimal libraries. It may have been used by command line only in the past. No programmers, no scripts, no took chain - truly pointless. Support for old chip only.
Let us discuss the upgrade issue.
Consider, the build process for a release. It takes hours. If I did by hand it would not even be possible, there would huge variants between releases with a high level of inconsistency. How did I resolve? I have automated the upgrade process - it is a one click operation (what takes the time is uploading and shuffling of all the files in SourceForge which I have not automates but as I write this email... I will automate).
My principle. If you need to do some twice or more. Automate the work.
I use R2BUILD. Free and easy. You can use to merge your release. As R2Build is a step by process you can use many, many different methods to create your ideal working environment.
So,to help. What are the toolchain components you changing?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Use this table to discuss, I lifted this table from the US Congress Open Source list.
Item
Description
Usage/Scope
1
ATMEL programmer
For AVR only
2
AVRDUDE
For AVR only
3
AVRDUDESS
For AVR only
4
CLCDesignerTool
PIC specific config tool
5
DFU-UTIL
For DFU Bootloader only
6
DFU-UTIL
For DFU Bootloader only
7
G+STools
Programmer Control Script and Library Validation
8
Great Cow BASIC Compiler (uFB)
Main compiler
9
Great Cow Graphical BASIC Compiler (uFB)
GCGB GUI
10
16f1454libkwinusb
USB support only
11
GAWK/AWK
Required to support Library Validation
12
Great Cow BASIC Converters (uFB)
Required subsystem
13
gcblibkwinusb
USB Support only
14
imageconverter565
Converter support
15
USB installers from ZADIG
USB support only
16
Program Editor
USE,INI editor
17
usb_libkwinusb_testrig
USB support only
18
Micronucleus Programmer
Specific AVR Programmer
19
PICINFO using uX
PIC Only
20
PK2CMD
Specific PIC Programmer
21
PICKit2 GUI
Specific PIC Programmer
22
ipe-pusher.exe usig uA
Open Source - GPL GENERAL PUBLIC LICENSE
23
PICKit3 I Specific PIC Programmer
24
PICPgm
Specific AVR/PIC Programmer
25
PPSTool
PIC specific config tool
26
psmcdesigner
PIC specific config tool
27
SynWrite
IDE
28
Terminal
Serial Terminal
29
Putty
Serial/IP Terminal
30
TinyBootloader
Bootloader support
31
XpressLoaders
Bootloader supporter
If you are AVR only - then you could delete all the PIC specific items
If you are PIC only - then you could delete all the AVR specific items
If you are editing the IDE . This includes all the ICONS and all the settings - use something r2Build. The ini's can be easily controlled from R2Build.
If you are editing USE.INI to set some specific programmer - use something r2Build. Do not edit by hand. If USE.INI construct is changed then things will break. There was a release (cant remember which one) that forced the deletion of use.ini to ensure the system started with a clean/stable use.ini). In the current releases v0.99.01 there is a change but this should impact existing users.
If you are not using USE.INI via Programmer Editor and using the old batch files then change to USE.INI via Programmer Editor and merge the changes on an upgrade.
Discuss.
Last edit: Anobium 2022-01-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The mimimal install did not include anything but the compiler and the minimal libraries. It may have been used by command line only in the past. No programmers, no scripts, no took chain - truly pointless. Support for old chip only.
As I don't use the IDE, or the programmers it rather suited my needs. As I almost exclusively use the 16F1825/29 the 12F1840 and the 12F1571/2 chips meaning again, for me, support for the latest devices is not an issue.
I don't wish to suggest that a "new" build is made, only for a tiny fraction of users (probably just me), nor to dismiss your generous work in creating the install, only to say that a minimal compiler only, with the chip files where updated, and perhaps some notes on any new or altered compiler options for calling from a command line would suit me rather well.
As it is, whenever I update the IDE is overwritten, all the IDE .ini files reset meaning an external IDE and my Northern Software programmer stop working.
Returning things back to my own preferences is often a hit or miss affair with me changing the programmer in SynWrite, re-editing some batch files and generally faffing about for what seems like an eternity trying to get everything working as it once did.
To answer your question regarding what I'm changing, I only use the compiler for PIC. Once I find the time, I won't be using G+STools as I would prefer to have the compiler progress shown in Geany.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated to the latest version of Great Cow Basic and (really excitingly for me!) having installed it into and over my existing GCB installation directory and I'm delighted to say that it has worked first time, with no faffing required. Yay!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, nothing like the chore I had anticipated, nor as onerous as it has been previously.
Because I've been able to invoke the compiler directly from within Geany, bypassing 'use.ini', 'makehex.bat' and all the other preference files that are overwritten during the install process.
It took me a few hours to figure out the structure of the command line required to give the appropriate response from the compiler and to then pass that on to the NSDSP programmer, but having got that sorted, the new installation worked (from Geany) exactly as I wanted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you call the compiler with a different set of parameters you would not have to edit anything, and, you get the huge advantage of getting the benefits of the Programmer Editor.
You can call all the defaults directky, and it will call the programmer as setup in Programmer Prefs, there is a default NSProg entry! . Just edit in the editor, you can choose verbose, different compilers, selcect comments etc. Adding a Prefs Editor to Geany means no risk of losing your parameters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't understand which file(s) the programmer editor works on or with? There is an entry for the NSDSP programmer in the IDE (and it's related preferences files) though once set, in my experience it is overwritten each time the IDE is updated. Which is what I am trying to avoid?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Help shows how to use, and, I have done many videos on it.
But, do not worry about how to use yet.
NSProg is supported.
The ini file is called USE.INI. And, it is not replaced on a new install. I provide a new one in a specific folder.
Can we move this discussion to the thread you created re Geany?
Last edit: Anobium 2022-01-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Evan, now that I see that I’m not the only one that are welling to use other IDE’s for gcb, I have a little personal project for using Visual Studio Code (open source, linux, mac and windows) as an IDE for great cow basic, I wasn’t sure if it will be of interest to any one, it works and I liked and use it but needs a little of work, I was driven to it because it allows me to create and manage a solution of multiple source files and assets for the project when at the same time can integrate Git sub versioning in one same environment.
So, for your #100 release I got this crazy idea…
I see I can solve or help with two issues:
• On every help post on the forum, the most common problem resides in that no body have the latest compiler version where bugs are solved. Every one has an outdated installation and the process for actual patches is not very clear or user friendly.
• If some one wants to use another IDE, manual shoe honing and a lot of elbow grease will be needed.
I can code in almost no time an IDE launcher that will be the main executable for great cow basic, I have a little framework designed to get automatic updates that I use for my own projects, when launched it will check if a new update its available then it will download it, verify checksum and patch everything up to date (it also allows multiple channels like beta, nightly or stable). in this exe you can config what IDE you want to use (synwrite, genie, vscode, others) and open or create a solution or a file in your favorite IDE.
The system will integrate very well whit the modular nature of gcb.
And speaking of automation…
I can automate the process of build new updates and the upload to the server easily.
Tell me if you like the idea and think it will suit you. To make a small proof of concept for you to evaluate it.
Also, if you want, I can make a Bugzilla system, to keep the records of the bug tracking on that system instead of the spreadsheet, well, you tell me if something is of you interest.
Greetings.
Angel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great ideas. We have to move forward.
I am very, very happy with your proactive approach. Thank you. Let’s do it.
Can we decide regarding Real Number support first? This is the last big hurdle to be jumped, or, we can decide integer maths for ever.
Evan
We do get asked about the IDE. And, we will need to move to more IDE's whilst maintaining the existing 32bit IDE.
We have a huge community. Some want offline to online, you and a few others have active use of GitHub. So, we to cater for a wide community of use cases. Some will be willing to use continuous integration and other will want releases.
Re the IDE I have asked for views but to make this happen takes a lot of effort and ownership. Frank can tell you the time he took to get the current IDE working and the many hours he spends maintaining the tooling.
We are in a good place. The code is stable, we have documentation, and we have IDE helpers, reserved word and great change control.
We need to consider the projects journey. From a ZIP to huge toolchain. Many users do not read or follow the threads, or, download the latest code (not the patches as these are relatively new)... we have users still using v0.95 from 10 years ago. It our job to get them to upgrade and support them to use the easy Programmer Prefs over the previous custom batch files per programmer per user. It is time to move on.
Actually, I am sorry. It is wrong to say that manual shoe horning is required. The issue is determining the IDE, asking and sharing the requirement on the forum, and we could answer and others could learn from these efforts. To move forward will need a community effort.
The compiler has more capabilities than 5 years ago, and, we need to get everyone using these capabilities.
I am very happy that a new IDE launcher can be coded. But, will it get used? What is the scope? We would need to know all the target IDEs and it would have to 32 bit. A great idea.
We have automated updates in PPStool, it can be done. It works well.
Re automation. I started today. I have SVN locally and it push into Git and SForge.
We do need BugZilla. I have had zero feedback on the buglist in the old TXT file or the new Excel. Do people need this ? This is in the context we get very few bugs reported and the current development plan stops very soon, but, tracking is good today as I can locate any change in a few seconds.
I think we need a set of VMs to hold and maintain the mass of code to tools used to create the toolchain. There is little consistency in the dev tools. But, someone coming to help has to find/learn all these odd tools.
In 2021 I an email from the US.Mil about the toolchain Open Source. I have collated many of the dev tools but they need to put into VMs to be part of the build process.
Last edit: Anobium 2022-01-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When will the newest version of installer be put online, including all known "patches" ?
Last edit: Bertrand BAROTH 2022-01-28
Great question.
If I have the time - within the next 24 hours. I will publish Windows and Linux.
Evan
Lots of changes and fixes
Fix: For missing constant in the 16F17xx chipfiles to support PMW16 capability. Added PWM16TYPE=1 to dat file. CHIPDATA.CSV updated for 9 chips, these chips were re'gened.[1246]
"Fix: For FOR-NEXT loop when using a negated step value. A negated step value is no longer permitted as this is cast as byte, and, the transform in preprocessor breaks legacy FOR-NEXT support. Resolution: 1) Inspect step variable type and negate is not present 2) Cast in the compiler as integer when the loop variable is an integer[1247,1248]
Considered non critical issue as use of negating was issuing a valid error message."
Fix: Updated reserved words list[1249]
Fix: Updated to support Microchip website changes. Website changes broke Datasheet, Errata and Home page links. Now version v2.90e.
Fix: Updated to XOJO latest release. Now version v2.90G
Fix: For missing constant in the 16F183xx chipfiles to support 31k capability. CHIPDATA.CSV updated for chips, changing 31k OSSCON1 to 64, these chips were re'gened[1250]
Fix: For missing label for 10ms [1251]
Fix: Add Fix for errata bug in DS40001816F in 18fX6K40 chips[1252]
Fix: Add Fix for errata bug in DS40001816F in 18fX6K40 chips[1252]
Fix: Rewrite of NVMADR_EPWrite/EPread to better support 18fxxQxx chips/NVMADRU register moving to ChipSubFamily resolve RD issue and adding Q40 support[1253,1255]
Fix: 18FxxQ40 memory map corrected. Change GETCHIPDATA source to handle Q40s. It was missing from GETCHIPDATA handler.[1256]
Fix: Added ADREADPREREADCOMMAND to AVR read to enable setting of any register prior to ADC read operation[1257,1265,1267]
New: Improved interrupt latency by adding Family 15 ( 12F and 16F ) interrupt handler to use shadow locations for system variables, therefore use chips automatic context saving[1258]
New: Improved interrupt latency for all Family 16 ( 18F ), was just K42 chips, interrupt handler to use shadow locations for system variables, therefore use chips automatic context saving[1259]
Fix: Resolves issue with creation of constants that are not required. Library contains development guideline for the creation of library constants.[1260]
New: Add MVECEN = ON 'not supported' message.[1261]
Update xpt2046.h and the 330_using_glcd_touch_xpt2046_demonstation_for_ili9341_lgtf328p.gcb demo. Revise XPT2046 library to support LGT chips using software SPI[1266]
Add SysMultSub64, SysDivSub64, SysCompEqual64 and SysCompLessThan64[1262,3]. WARNING WARNING - these changes will require updating when IF-THEN support Advanced Variables.
Change USART=0 to USART=1. Change the master CSV and regen these chip files tiny2313 & tiny2313a [1264]
Rename Programmer from Microchip Xpress CNANO Boards USB [16f18466] to Microchip CNANO USB [16F & 18F]
Updated: USB Drivers Setup Great-Cow-BASIC-Demonstration-Sources/USB_Solutions/GreatCowBASIC_Solutions/LIBWINUSB_Solutions/WindowsDeviceDriver/
For Q43 I2C discovery. Revised SI2CDiscovery adding #IFDEF var(I2C1CNTL) and #IFDEF var(I2C1CNT) to isolate Q43 that only supports I2C1CNT[1268]
Fix: Errata and Programming now work after the Microchip website changes... tool now uses an improved Regex to dertermine the PDFs. Now version v2.90i
New: Now launches web page if cannot find ERRATA or PROGRAMMING PDF. Now version v2.90k
Fix: Resolves Q41 family chip EEPROM write error caused by bit naming[1270]
Fix: Resolves silent crash when two functions of same name exists. Now handles and issues correct error message[1269]
Fix: For out of bounds memory array in compiler[1271]
Fix: Resolves Rs232 script creation of constants.[1272]
New: Examines source web page for ERRATA or PROGRAMMING PDF, opening web page if more that one instance found, Also, now exposes search strings in PREFERENCES. Now version v2.90M
Fix: Resolve out of bounds memory array in compiler in 32bit version only in VARADDRESS(), and, resolve pointer warning during compilation [1273]
Fix: Resolve error where generated ASM was optimised incorrectly for end of sub call. Changes to AsmOptimiser() [1274]
Fix: Resolve further error introduced at [1037] where generated ASM was optimised incorrectly for end of sub call. Changes to AsmOptimiser()[1275]
"Fix: Resolve CONCAT system variable issue.[1276]
Fix: Compiler updated to simplify CONCAT. Now supports SYSDEFAULTCONCATSTRING to set the size of the system variable used for concat operations.[1278]"
New: Added USART1_BAUD_RATE support in script so USART1_BAUD_RATE equates to USART_BAUD_RATE.[1277]
Fix: Compiler updated to improve handling of wait parameters. Resolves the incorrect specification of time units. wait 4 10[space]us [1278]
Fix: Scripting in the compiler now correctly handles the existence of constant with no value.[1279]
Fix: Resolve lockup caused by missing #ENDSCRIPT [1280]
Fix: Performance improvement to change 1041[1281]
Fix: Resolves scripting support for IF, DEF() and NODEF() for testing constants [1282]
Fix: Change to Wait() to reduce the cycles by one cycle to resolve wait 1 us error. Implements WAITP1() to expose old timing method.
Fix: Change to Wait() to reduce the wait cycle by one cycle to resolve wait 1 us error in PULSEOUT(). Implements WAITL1() to expose new timing method - this replace change 1046.[1283]
Fix: stdbasic.h Change PULSEx delays to one cycle less using WAITL1 [1284]
New: SynWrite Helpers to add SYSDEFAULTCONCATSTRING.
"New: Add new delay routines for WAIT() when the frequency is less then 96 kHz. This essentially means that WAIT() for 31kHz are now correct. [1286]
MS Delays at Clock frequency’s below 28kHz are not supported and will silently fail.
US Delays at Clock frequency’s below 250kHz are not supported and will silently fail.
US Delays at lower Clock frequency’s is accurate ONLY when nn is divisible by 4. This is caused by the minimum ASM delay loop being a specific number of instructions.
US Delays at lower Clock frequency’ when not divisible by 4 will silently accept the nn value and incorrect delays will be produced.
Delays at Clock frequency’s below 500kHz may be impacted by previous instructions; testing of actual delays is advised. Tested on PIC only. This may work on AVR however this was not tested. This change was implemented by Angel Mier - most grateful". Delays of less than 28kHz are not support and will silently fail.
Added support for 31k to 12(L)F1501 [1287]
Added new MCUs[1288]
18F26K83, 18F27K83, 18F26K83, 18F46K83, 18F47K83
18F26K84, 18F27K84, 18F26K84, 18F46K84, 18F47K84
USART.H updated
EEPROM.H updated
PICAS: Fix for Q83 and Q84 CRC PIC-AS configs. Essentially increase the array size.[1289]
Message update only. SourceForge prompt. Non-functional change[1290]
Corrected K83 chipsubfamily[1291]
Improved GCGB UI for selection of config[]
"Correction to the DAT files for 18FxxQ8x - from information from Microchip. [1293]
The correct amount of GPR bytes for the two device families are 8192 bytes for the x6Q83/84 and 12,800 bytes for the x7Q83/84. The devices also have 256 bytes of RAM that is used as a buffer for the NVM module and 2048 bytes of RAM that is dedicated to use by the CAN FD module’s FIFOs.
The MICROCHIP division has noted the correction and will be reflected in the coming revisions of datasheets and will also make sure that the website matches the 12800 value rather than the 13000 value"
Correct the EE address for table creation on Q40 chipfamily[1294,1297]
PIC-AS support added for 2.35 toolchain. Isolation of 2.32 PIC-AS patches.[1295]
Resolves AVR table read byte to array element. Created cache to ensure the array element is not overwritten.[1295-1296]
Update to SSD1306 library to improve memory requirements message[1298]
Update to ST7735 library to improve libraries isolation[1298]
Update to message to improve errors in SFRs[1298]
Add CANBUS.H and demos [1299]
Released build of v0.98.07 build 1064 to release candidate
"Q40 Support added. New Dat files, updated eeprom.h and updated pwm.h[1300]
Added Q40 32 demos. See https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/Vendor_Boards/Great_Cow_Basic_Demo_Board/18f16q40_chiprange_demonstrations"
Removal of Serial debug from the XPT library[1301]
Minor change to automatically selected GCASM when an AVR[1302,1303]
Fix for PIC-AS .S source file comments being expanded into XC8 Macros![1304]
Minor fix: Resolves causes sensitive CONFIG PRAGMA statements[1305]
Another minor fix: Resolves causes sensitive CONFIG PRAGMA statements[1306]
Updated GS+Tools to prevent lock-up with the BEEP API and add support for Promo messages
Updated compiler to use promo messages - update to GS+TOOLS to support promo messages
For PIC18FxxQ83 or PIC18FxxQ84 you will need an update to PICKitPlus that support the PIC18FxxQ83 or PIC18FxxQ84 chips, or, an alternative programmer.
Thanks in advance
Done - release
It takes a few secs to create a ZIP for Patches. It is all automated. But,
A release for everything, updating the website, all the files, all the version, archiving off the last version, updating the messages inside the build then testing, revising and testing... etc takes six hours. I know... I just timed it,
Released
Full fat software package for Windows
GCGB software package for Windows
Core software package for Windows
Linux software archive
I have not included minimal build as no-one has downloaded for two years. So, no point of just the compiler.
You will notice that the revision did change to v0.99.01. Why? Because I feel confident that the USB and SD Card code works ( folks have these working and this was the test for release completion). If we can sort Real number in this release then we will reach the milestone of v1.00. We all may decide the the Real number support is not required and we could move regardless to v1.00 - thoughts on this?
So, another release done.
Enjoy.
I had thought that I had pestered for a minimal install many times and had been advised that due to the number of changes across many files this wasn't possible or recommended?
I'm always reluctant to upgrade as it takes me so very, very, very, very, very long to put everything back to how it used to be, and how I like to see it.
The mimimal install did not include anything but the compiler and the minimal libraries. It may have been used by command line only in the past. No programmers, no scripts, no took chain - truly pointless. Support for old chip only.
Let us discuss the upgrade issue.
Consider, the build process for a release. It takes hours. If I did by hand it would not even be possible, there would huge variants between releases with a high level of inconsistency. How did I resolve? I have automated the upgrade process - it is a one click operation (what takes the time is uploading and shuffling of all the files in SourceForge which I have not automates but as I write this email... I will automate).
My principle. If you need to do some twice or more. Automate the work.
I use R2BUILD. Free and easy. You can use to merge your release. As R2Build is a step by process you can use many, many different methods to create your ideal working environment.
So,to help. What are the toolchain components you changing?
To help the discussion. What are you changing?
Use this table to discuss, I lifted this table from the US Congress Open Source list.
If you are AVR only - then you could delete all the PIC specific items
If you are PIC only - then you could delete all the AVR specific items
If you are editing the IDE . This includes all the ICONS and all the settings - use something r2Build. The ini's can be easily controlled from R2Build.
If you are editing USE.INI to set some specific programmer - use something r2Build. Do not edit by hand. If USE.INI construct is changed then things will break. There was a release (cant remember which one) that forced the deletion of use.ini to ensure the system started with a clean/stable use.ini). In the current releases v0.99.01 there is a change but this should impact existing users.
If you are not using USE.INI via Programmer Editor and using the old batch files then change to USE.INI via Programmer Editor and merge the changes on an upgrade.
Discuss.
Last edit: Anobium 2022-01-29
Also, I have many Open Source tools that can help. They are integrated into R2Build but I can certainly share my insights.
I feel that we can get that very long time down to very few seconds with a little automation.
As I don't use the IDE, or the programmers it rather suited my needs. As I almost exclusively use the 16F1825/29 the 12F1840 and the 12F1571/2 chips meaning again, for me, support for the latest devices is not an issue.
I don't wish to suggest that a "new" build is made, only for a tiny fraction of users (probably just me), nor to dismiss your generous work in creating the install, only to say that a minimal compiler only, with the chip files where updated, and perhaps some notes on any new or altered compiler options for calling from a command line would suit me rather well.
As it is, whenever I update the IDE is overwritten, all the IDE .ini files reset meaning an external IDE and my Northern Software programmer stop working.
Returning things back to my own preferences is often a hit or miss affair with me changing the programmer in SynWrite, re-editing some batch files and generally faffing about for what seems like an eternity trying to get everything working as it once did.
To answer your question regarding what I'm changing, I only use the compiler for PIC. Once I find the time, I won't be using G+STools as I would prefer to have the compiler progress shown in Geany.
Ok. So, you dont need all the avr stuff. Sounds a drop and replace of GreatCowBasic (and subs) is all you need.
Take a copy of existing folder. Drop the new stuff in. Test.
If it fails to work in Geany... let's discuss.
When it failed. Delete that 'new' folder. Revert back to old version.
Create new thread called Geany: Migration from Syn@GCB to Geany.
Others may be interested in this.
Already installed ...
Excellent to hear.
Hopefully, you are not the only one. :-)
Following my instructions in this thread: https://sourceforge.net/p/gcbasic/discussion/579125/thread/89d0ea8386/#a85e
I have updated to the latest version of Great Cow Basic and (really excitingly for me!) having installed it into and over my existing GCB installation directory and I'm delighted to say that it has worked first time, with no faffing required. Yay!
Well done.
I am a tad confused tho... this was going to be a big task but it was not?
No, nothing like the chore I had anticipated, nor as onerous as it has been previously.
Because I've been able to invoke the compiler directly from within Geany, bypassing 'use.ini', 'makehex.bat' and all the other preference files that are overwritten during the install process.
It took me a few hours to figure out the structure of the command line required to give the appropriate response from the compiler and to then pass that on to the NSDSP programmer, but having got that sorted, the new installation worked (from Geany) exactly as I wanted.
If you call the compiler with a different set of parameters you would not have to edit anything, and, you get the huge advantage of getting the benefits of the Programmer Editor.
You can call all the defaults directky, and it will call the programmer as setup in Programmer Prefs, there is a default NSProg entry! . Just edit in the editor, you can choose verbose, different compilers, selcect comments etc. Adding a Prefs Editor to Geany means no risk of losing your parameters.
I don't understand which file(s) the programmer editor works on or with? There is an entry for the NSDSP programmer in the IDE (and it's related preferences files) though once set, in my experience it is overwritten each time the IDE is updated. Which is what I am trying to avoid?
The Help shows how to use, and, I have done many videos on it.
But, do not worry about how to use yet.
NSProg is supported.
The ini file is called USE.INI. And, it is not replaced on a new install. I provide a new one in a specific folder.
Can we move this discussion to the thread you created re Geany?
Last edit: Anobium 2022-01-30
Prefs Editor has been part of GCB for 10 years. I think it appeared in SynWrite about 3-4 years ago. WOrks very well.
A PDF is this thread when Evan added PIC-AS suppport https://sourceforge.net/p/gcbasic/discussion/579125/thread/8a5eb03d38/?limit=25#c8f8
And, the Help is good. http://gcbasic.sourceforge.net/help/_using_great_cow_basic.html
The main config file is USE.INI is the same format as the old GCBASIC.INI - that is explained in the Help. But, I just use USE.INI from prefs editor.
And from me all well setup. Although I had to uninstall the old one
Hi Evan, now that I see that I’m not the only one that are welling to use other IDE’s for gcb, I have a little personal project for using Visual Studio Code (open source, linux, mac and windows) as an IDE for great cow basic, I wasn’t sure if it will be of interest to any one, it works and I liked and use it but needs a little of work, I was driven to it because it allows me to create and manage a solution of multiple source files and assets for the project when at the same time can integrate Git sub versioning in one same environment.
So, for your #100 release I got this crazy idea…
I see I can solve or help with two issues:
• On every help post on the forum, the most common problem resides in that no body have the latest compiler version where bugs are solved. Every one has an outdated installation and the process for actual patches is not very clear or user friendly.
• If some one wants to use another IDE, manual shoe honing and a lot of elbow grease will be needed.
I can code in almost no time an IDE launcher that will be the main executable for great cow basic, I have a little framework designed to get automatic updates that I use for my own projects, when launched it will check if a new update its available then it will download it, verify checksum and patch everything up to date (it also allows multiple channels like beta, nightly or stable). in this exe you can config what IDE you want to use (synwrite, genie, vscode, others) and open or create a solution or a file in your favorite IDE.
The system will integrate very well whit the modular nature of gcb.
And speaking of automation…
I can automate the process of build new updates and the upload to the server easily.
Tell me if you like the idea and think it will suit you. To make a small proof of concept for you to evaluate it.
Also, if you want, I can make a Bugzilla system, to keep the records of the bug tracking on that system instead of the spreadsheet, well, you tell me if something is of you interest.
Greetings.
Angel
Great ideas. We have to move forward.
I am very, very happy with your proactive approach. Thank you. Let’s do it.
Can we decide regarding Real Number support first? This is the last big hurdle to be jumped, or, we can decide integer maths for ever.
Evan
We do get asked about the IDE. And, we will need to move to more IDE's whilst maintaining the existing 32bit IDE.
We have a huge community. Some want offline to online, you and a few others have active use of GitHub. So, we to cater for a wide community of use cases. Some will be willing to use continuous integration and other will want releases.
Re the IDE I have asked for views but to make this happen takes a lot of effort and ownership. Frank can tell you the time he took to get the current IDE working and the many hours he spends maintaining the tooling.
We are in a good place. The code is stable, we have documentation, and we have IDE helpers, reserved word and great change control.
We need to consider the projects journey. From a ZIP to huge toolchain. Many users do not read or follow the threads, or, download the latest code (not the patches as these are relatively new)... we have users still using v0.95 from 10 years ago. It our job to get them to upgrade and support them to use the easy Programmer Prefs over the previous custom batch files per programmer per user. It is time to move on.
Actually, I am sorry. It is wrong to say that manual shoe horning is required. The issue is determining the IDE, asking and sharing the requirement on the forum, and we could answer and others could learn from these efforts. To move forward will need a community effort.
The compiler has more capabilities than 5 years ago, and, we need to get everyone using these capabilities.
I am very happy that a new IDE launcher can be coded. But, will it get used? What is the scope? We would need to know all the target IDEs and it would have to 32 bit. A great idea.
We have automated updates in PPStool, it can be done. It works well.
Re automation. I started today. I have SVN locally and it push into Git and SForge.
We do need BugZilla. I have had zero feedback on the buglist in the old TXT file or the new Excel. Do people need this ? This is in the context we get very few bugs reported and the current development plan stops very soon, but, tracking is good today as I can locate any change in a few seconds.
I think we need a set of VMs to hold and maintain the mass of code to tools used to create the toolchain. There is little consistency in the dev tools. But, someone coming to help has to find/learn all these odd tools.
In 2021 I an email from the US.Mil about the toolchain Open Source. I have collated many of the dev tools but they need to put into VMs to be part of the build process.
Last edit: Anobium 2022-01-30