This the change log. As raw as it is, it is what it is.
There a host of changes, new capabilities and fixes. This is a big release.
Evan
Read each row as follows:
1. The first number is a simple index number.
2. Fix or New
3. Scope/Impact area
4. Description, if with [] where [nnn] is the SVN commit number, No [] means not commited yet. We have to do this as many parts of the solution need to go out as a complete release,
Read each row as follows:
1. The first number is a simple index number.
2. Fix or New
3. Scope/Impact area
4. Description, if with [] where [nnn] is the SVN commit number, No [] means not commited yet. We have to do this as many parts of the solution need to go out as a complete release,
The next release has a major change with respect to the setting up of the oscillator when NOT using the internal oscillator.
Some background
We need enable the user to use other internal oscillators like LFINT, and, to expose the oscillator type (with frequency) and class to the user. So, the users know what is going on.
So we needed to
1. A method to enable setting of alternative internal oscillators.
1. NOT set the Oscillator when using a non-internal Oscillator
Changes
A constant so we can change the setup (within initsys() ) to handle non-internal and other clock sources specifically LFINT (which is an internal Oscillator).
A constant that specifies the oscillator type. We need to be able to determine what is INT (as is today), what is external – so, we can set the internal clock sources, and, if external let the use the user do it as we would be guessing.
A consistent method of exposing the selected oscillator and frequency for reporting to the user, with the frequency.
A method of automatically selecting internal SOSC when the selected 0.03268 is the operating frequency. Therefore the compiler needs to set the config appropriately.
Using the latest compiler.
What does the user now see?
In the IDE the following are examples. Note the clock source, the frequency and more key information.
ChipUsingIntOsc will exist if the internal oscillator is selected by the compiler. ChipOsc constant gives the actual oscillator chosen, which matches what is displayed during compilation. ChipOsc is the user specified or compiler select oscillator, Use ChipOsc the same as the constant ChipName. ChipOsc matches whatever is shown for the Osc in verbose mode, so for example when the 16F88 is configured for internal, it uses INTRC_IO in the assembly, and this tests true:
#ifdefChipOscINTRC_IO
….
…..
#endif
Usage
Users we be able to use #if ChipUsingIntOsc in the source code to handle internal oscillator in initsys, and the ChipOSC constant as a fallback.
Note: If there is some new type of internal oscillator that the ConfigValueMatch() routine in gcbasic.bas does not correctly recognise as an internal oscillator we will have to update the compiler
The following changes have been made uses these new constants.
When a user specifies a frequency of 0.031, at the moment, ONLY this frequency, and the chip has an internal LFINTOSC the compiler will automatically setup the clock.
When a user specifies a frequency that is NOT an internal chip frequency the compiler will NO LONGER setup the oscillator registers. The user will no longer be confused by the compiler trying to setup the internal oscillator.
When a user specifies a clock source the constants will match the selected clock source
Prerequisites
To make this all work.... you will need a compiler version 0.98.07 or greater AND new dat dated 30 Jan 2020 or later.
Question
Should we add a new user constant to stop ANY setup of the oscillator registers? Leaving the oscillator register setup totally to the user.
Last edit: Anobium 2020-01-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Edited... I made a bit of error.. not SOSC but LFINTOSC. Correct below.
During testing I found specifying the LFINTOSC clock frequency as non-intutive... getting 0.031 correct is hard. I had even incorrectly typed in these posts.
So, we may (not this is passive) add another feature where you can specify 31k as the frequency to aid usage. So, the following could be implemented.
#chip 16f18326, 31k
Last edit: Anobium 2020-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Should we add a new user constant to stop ANY setup of the oscillator registers? Leaving the oscillator register setup totally to the user.
Not a bad Idea, Something like..
#OptionUserOSC
As it is not feasible for the compiler to be able to preempt or handle all of the possible clock options having an override will let the user manually configure the Internal or External OSC to allow fringe cases, accurate timing or synchronised clock situations.
GCBASIC’s ability to use Direct register access will allow the user to setup the Internal and External options to suit their own application or hardware specification.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Frank has updated the IDE to support the two new frequency as constants. Which means these specific chip frequences will be shown in black and not as numerical values.
This changes help you get these constants correct.
#chip 16f18326, 32.768k
#chip 16f18326, 31k
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We are close to the release. And, I need folks to test, compile code and try to use the new release.
So, if you are a Windows user - please ping me. You need to be willing to compile existing projects and test again what you know works. We need to be assured that we have no broken anything. We have 1000s of static and closed loop feedback tests (we know what the output should be with the static tests) but there is nothing like users testing the code.
In the past I emailed many of you. Not this time.
Please offer your help - your level of skill is not critical - we need you compile your code and to tell us that all is good.
Cheers
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
USB Library updated. Demonstration code will need to fixed.
WIP
12
New
Support for AVRrc chips. With Hugh to complete development to handle systempN variables. AVRrc chips are: ATtiny10,ATtiny20,ATtiny4,ATtiny40.ATtiny5,ATtiny9
WIP
13
Fix
AVR simple numeric maths fails when constant is first part of the calcuation
Complete
Last edit: Anobium 2020-08-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This the change log. As raw as it is, it is what it is.
There a host of changes, new capabilities and fixes. This is a big release.
Evan
Read each row as follows:
1. The first number is a simple index number.
2. Fix or New
3. Scope/Impact area
4. Description, if with [] where [nnn] is the SVN commit number, No [] means not commited yet. We have to do this as many parts of the solution need to go out as a complete release,
Last edit: Anobium 2020-01-28
Updated outstanding fixes/new capabilities in the pipe.
Last edit: Anobium 2020-01-28
Adding changes 690-704
Read each row as follows:
1. The first number is a simple index number.
2. Fix or New
3. Scope/Impact area
4. Description, if with [] where [nnn] is the SVN commit number, No [] means not commited yet. We have to do this as many parts of the solution need to go out as a complete release,
Is this changelog available somewhere as a file? It's hard to read using the scrollbar to go left and right.
No. I can give you access to the private SVN for all the changes, but, if you have an RC release you have this file in your GreatCowBASIC folder.
It is maintained as we progress through the backlog,
Are you going to fix the binary table problem I brought up some time ago?
https://sourceforge.net/p/gcbasic/discussion/596084/thread/adc1781daf/
I've taken to using the "old" method b'00000000' instead of 0b00000000 to get round this bug.
Last edit: David Stephenson 2020-01-27
Resolved. See the release notes.
It was in the change backlog. But, it is added, #8, and is now resolved.
Jim, you can copy and paste from this thread to any editor to get full width.
I just figured out... this a huge release!!!
Lots of great new capabilities, changes and fixes plus quality improvements.
:-)
Status of outstanding items for this release as at 1700 28 Jan
Last edit: Anobium 2020-01-28
The next release has a major change with respect to the setting up of the oscillator when NOT using the internal oscillator.
Some background
We need enable the user to use other internal oscillators like LFINT, and, to expose the oscillator type (with frequency) and class to the user. So, the users know what is going on.
So we needed to
1. A method to enable setting of alternative internal oscillators.
1. NOT set the Oscillator when using a non-internal Oscillator
Changes
Using the latest compiler.
What does the user now see?
In the IDE the following are examples. Note the clock source, the frequency and more key information.
New constants ChipUsingIntOsc and ChipOsc
Two new chip specific constants now exist.
ChipUsingIntOsc
will exist if the internal oscillator is selected by the compiler.ChipOsc
constant gives the actual oscillator chosen, which matches what is displayed during compilation.ChipOsc
is the user specified or compiler select oscillator, UseChipOsc
the same as the constantChipName
.ChipOsc
matches whatever is shown for the Osc in verbose mode, so for example when the 16F88 is configured for internal, it uses INTRC_IO in the assembly, and this tests true:Usage
Users we be able to use
#if ChipUsingIntOsc
in the source code to handle internal oscillator in initsys, and theChipOSC
constant as a fallback.Note: If there is some new type of internal oscillator that the ConfigValueMatch() routine in gcbasic.bas does not correctly recognise as an internal oscillator we will have to update the compiler
Example compilation
Example user code
Changes to core setup
The following changes have been made uses these new constants.
Prerequisites
To make this all work.... you will need a compiler version 0.98.07 or greater AND new dat dated 30 Jan 2020 or later.
Question
Should we add a new user constant to stop ANY setup of the oscillator registers? Leaving the oscillator register setup totally to the user.
Last edit: Anobium 2020-01-30
Chip listed in the attachment will have the LFINTOSC clock source set correctly when the frequency is
31k
for LFINT or LFINTOSCThe 96 chips are essentially the following chip classes
Enjoy when you get your hands on the release.
Thanks to all involved in supporting this functional change - Hugh, Jim, Pierre and me!
Last edit: Anobium 2020-01-30
Edited... I made a bit of error.. not SOSC but LFINTOSC. Correct below.
During testing I found specifying the LFINTOSC clock frequency as non-intutive... getting 0.031 correct is hard. I had even incorrectly typed in these posts.
So, we may (not this is passive) add another feature where you can specify
31k
as the frequency to aid usage. So, the following could be implemented.#chip 16f18326, 31k
Last edit: Anobium 2020-01-31
Not a bad Idea, Something like..
As it is not feasible for the compiler to be able to preempt or handle all of the possible clock options having an override will let the user manually configure the Internal or External OSC to allow fringe cases, accurate timing or synchronised clock situations.
GCBASIC’s ability to use Direct register access will allow the user to setup the Internal and External options to suit their own application or hardware specification.
Cheers
Chris
Added new frequency option for crystal clock sources.
#chip 16f18326, 32.768k
For crystal clock sources.So, I have have added two options, the one above and this one.
#chip 16f18326, 31k
For LFINTOSC clock sources.Frank has updated the IDE to support the two new frequency as constants. Which means these specific chip frequences will be shown in black and not as numerical values.
This changes help you get these constants correct.
#chip 16f18326,
32.768k
#chip 16f18326,
31k
Status of outstanding items for this release as at 1700 30 Jan
So, making progress.
Last edit: Anobium 2020-01-31
Status of outstanding items for this release as at 1700 1 Feb
Added item #10
So, making progress.
Last edit: Anobium 2020-02-03
WANTED
Looking for people to review the next release.
We are close to the release. And, I need folks to test, compile code and try to use the new release.
So, if you are a Windows user - please ping me. You need to be willing to compile existing projects and test again what you know works. We need to be assured that we have no broken anything. We have 1000s of static and closed loop feedback tests (we know what the output should be with the static tests) but there is nothing like users testing the code.
In the past I emailed many of you. Not this time.
Please offer your help - your level of skill is not critical - we need you compile your code and to tell us that all is good.
Cheers
Status of outstanding items for this release as19 Feb
Added item #11
Last edit: Anobium 2020-04-02
Status of outstanding items for this release as 31 March
Last edit: Anobium 2020-04-02
Status of outstanding items for this release as 6th August 2020
Last edit: Anobium 2020-08-07
Changes add since #704.
This is huge release. :-)