Write a book :)
Seriously, will there be any noticeable/visual changes? like when you changed the programmer selection to gui from text.
or new commands like when the scale function was implemented...which was a great addition.
Any goodies like that or is it more pic additions for mplab or other pic related improvements.
I will download latest version as everyone should. It only really gets tested when lots of people use it.
Thanks for the team effort making the new release.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For AVR a whole new chip family added the ATTINY104s, this also includes the formal release of LGT support, really faster LCD, more GLCDs, new For-Next, foundation for AVR PIC-AS (when someone wants to do it), lots of AVR fixes. Improved Prefs editor.
And, if someone wants add AVR they can easily create AVRInfo ( just PICInfo).
A lot of new AVR capabilities.
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For AVR a whole new chip family added the ATTINY104s, this also includes the formal release of LGT support, really faster LCD, more GLCDs, new For-Next, foundation for AVR PIC-AS (when someone wants to do it), lots of AVR fixes. Improved Prefs editor.
And, if someone wants add AVR they can easily create AVRInfo ( just PICInfo).
A lot of new AVR capabilities.
:-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The lgt looks interesting. Thought you had done a good job except ili touch screen being software spi only. Is it sorted for hwspi as the screen flies with the lgt328 and it seems the fastest ucntrl
but maybe there's a pic that runs that fast.
glcd devices supported by hardware communication with lgt328?
I know ili9341 and lgt328 worked fast for graphics with hwspi.
apparently it was too fast for touch and software spi for graphics is too slow...imo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thick as I am thought separate control of the ilitouch. A software solution for the read touch and leave the display using hwspi...which is really impressive.
At the moment they share the same spi but if software solutions are used as they are, why can't the touch be sorted with software while the screen is using hardware spi?
I think if ili with touch worked with the display using hwspi then it would be a nice display.
ok not nextion but the graphics using trig for the displays would be fast. Everything is faster with the lgt328 but it's not made out to be a big deal, which I think it is.
In reality nextion displays are not that fast...being serial and they are a pain to use and they cost lots.
How much gcb has got on with the lgt328 would be of use.
It worked last time I tried it. Why it doesn't get mentioned I don't know.
People try to speed up their code when this will make any code run twice as fast...er?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't use pics that often but if I do I wouldn't want mplabx installed as I don't use assembler
and that was the whole point of gcb...no asm.
Should there be a consensus of what people want from gcb?
Seems a lot of effort for minority use....or am I in the minority who don't debug their code
via assembler or use mplab?
GCB and avr works nice but I don't know avr asm, so wouldn't debug the asm even if possible with gcb. List it yes but the point is it's supposed to be basic.
Since a lot of effort is being put in to new pics then why try to make gcb universal with old pics
with no ram etc.?
The effort is into new pics which is cool if I thought what would be gained from ploddo avr.
From a users point of view it seems gcb has got more difficult to understand...not necessarily more difficult to use.
a 328 has 2 kb ram...most pics have little. Why not optimise for capable chips?
Last edit: stan cartwright 2021-05-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
no videos except gcb has lost it's roots as an easy way to program u controllers.
For me avr works and plenty of mem.
Pics are a bit more complicated to set up.
Why so much effort into mplabx?
GCB has a range of users and most would ,if me, want improvements to the basic side of gcb...
like supported hardware...not mplab
The idea you could program a uno/nano easy and get it to work with spi or i2c is forgotten
and it's all techno stuff is not what gcb was.
It's great there's new stuff for serious pic programmers but what's new for an "average" coder?
Last edit: stan cartwright 2021-05-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How come the lgt328 don't get mentioned . Isn't it's speed interesting anyone?
I personally thought lgt was a brill addition to gcb but not much feed back about it...pity.
What's so special about new pics that we've lived without for so long?
I tried micro chip dev boards but a uno did more with out setting pins.
gcb and avr look cool but most people don't use the avrtiny...do they?
How many people think gcb is better since last rc?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The LGT is mentioned in the release report. Did you search for LGT? if you use te URL shown below you can create a report that is specific for the LGT changes. There are many.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think the release is a lot better. When I get moment I will write up all the changes but here is a metric... PIC specific changes = 338 AVR specific changes = 188 and 110 of the 188 changes were functional changes.
Attached in the AVR functional changes report.
To document the full release will take a few weeks - it is a huge set of changes.
I will be updating this document as I have no other idea on how to collate two years of changes. This document is the SAME document you get in the installation - just formatted with extra columns.
If folks want more information on a specific change the I can add more information.
Last edit: Anobium 2021-06-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can add the date of the commits. These dates will be very very close to when we did the work. To mimimise my work I will add a date month - to add all dates would ne a huge amount of work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I noticed the second in the list, index 659 -- changed dim glcdpixelcount A.
was a word but words can overflow.
When I look at glcd include, there's a lot of ifdef display xxxx then and ifdef display yyyy then.
so there was a time when using older smaller displays that a word var worked so isn't it sorted at compile time the display and if the glcdpixelcountA needs to be a word or whatever it is now?
Seems to slow glcd for compatibility with larger displays.
or maybe I don't understand the compiler.
Any way thanks to "the team" for still supporting gcb.
How did I get by with gcb for so long with all it's underlying faults? :)
You're trying to make gcb work with old low spec pics and newer pics.. and avr..in many chips/boards. Lots of work, good luck.
Are arrays and table still only bytes or can they be strings? Stuff on the forum about bytes only.
Last edit: stan cartwright 2021-06-02
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The long is only used in the GLCDs where is needs to be used. So, it is left as a WORD or BYTE in those GLCDs that cannot overflow and therefore the allocation of memory has not increased for this GLCDs. But, where there is a danger of overflow the LONG is used.
The long fixes a bug that was reported and therefore the overflow can happen on some GLCDs. This changed is dated 11/10/19 and therefore has been in every build and RC release for the last 18 months.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you want more date change this URL https://sourceforge.net/p/gcbasic/code/1218/log/
Change the log number from 1218 to the number shown in the [1218] in the XLS. Sometimes the righthand brace is missing - sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
index 659 glcd solution is great. sort of optimising at compile.
I like the way the ssd1306 oled can check available ram and still sort a display for low ram.
I like 2K ram to play with.
I always think gcb works and if it doesn't then it's my fault.
That's cos I don't use pics where they get upset easy.
Thinking about it, Would it, in the case of the ssd1306, been easier to just suggest another pic with more ram been easier as the display is tiny anyway?
Last edit: stan cartwright 2021-06-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having just installed it, replaced the various settings with those neded for Geany and the NSDSP programmer my most recent project compiled without error.
As before, many thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The release is ready.
This is a huge release with over 350 changes - some of the changes are huge, there is new capabilities and lots of fixes.
Question
What is the best way to provide an overview of the changes?
The readme.txt ? Video ? Videos ? Post to the forum?
What do you want?
Write a book :)
Seriously, will there be any noticeable/visual changes? like when you changed the programmer selection to gui from text.
or new commands like when the scale function was implemented...which was a great addition.
Any goodies like that or is it more pic additions for mplab or other pic related improvements.
I will download latest version as everyone should. It only really gets tested when lots of people use it.
Thanks for the team effort making the new release.
For AVR a whole new chip family added the ATTINY104s, this also includes the formal release of LGT support, really faster LCD, more GLCDs, new For-Next, foundation for AVR PIC-AS (when someone wants to do it), lots of AVR fixes. Improved Prefs editor.
And, if someone wants add AVR they can easily create AVRInfo ( just PICInfo).
A lot of new AVR capabilities.
:-)
For AVR a whole new chip family added the ATTINY104s, this also includes the formal release of LGT support, really faster LCD, more GLCDs, new For-Next, foundation for AVR PIC-AS (when someone wants to do it), lots of AVR fixes. Improved Prefs editor.
And, if someone wants add AVR they can easily create AVRInfo ( just PICInfo).
A lot of new AVR capabilities.
:-)
The lgt looks interesting. Thought you had done a good job except ili touch screen being software spi only. Is it sorted for hwspi as the screen flies with the lgt328 and it seems the fastest ucntrl
but maybe there's a pic that runs that fast.
glcd devices supported by hardware communication with lgt328?
I know ili9341 and lgt328 worked fast for graphics with hwspi.
apparently it was too fast for touch and software spi for graphics is too slow...imo
LGT is the fastest 8-bit we support.
The touch issue is the Touch IC. I am sure someone will resolve the issue.
Thick as I am thought separate control of the ilitouch. A software solution for the read touch and leave the display using hwspi...which is really impressive.
At the moment they share the same spi but if software solutions are used as they are, why can't the touch be sorted with software while the screen is using hardware spi?
I think if ili with touch worked with the display using hwspi then it would be a nice display.
ok not nextion but the graphics using trig for the displays would be fast. Everything is faster with the lgt328 but it's not made out to be a big deal, which I think it is.
In reality nextion displays are not that fast...being serial and they are a pain to use and they cost lots.
How much gcb has got on with the lgt328 would be of use.
It worked last time I tried it. Why it doesn't get mentioned I don't know.
People try to speed up their code when this will make any code run twice as fast...er?
I don't use pics that often but if I do I wouldn't want mplabx installed as I don't use assembler
and that was the whole point of gcb...no asm.
Should there be a consensus of what people want from gcb?
Seems a lot of effort for minority use....or am I in the minority who don't debug their code
via assembler or use mplab?
GCB and avr works nice but I don't know avr asm, so wouldn't debug the asm even if possible with gcb. List it yes but the point is it's supposed to be basic.
Since a lot of effort is being put in to new pics then why try to make gcb universal with old pics
with no ram etc.?
The effort is into new pics which is cool if I thought what would be gained from ploddo avr.
From a users point of view it seems gcb has got more difficult to understand...not necessarily more difficult to use.
a 328 has 2 kb ram...most pics have little. Why not optimise for capable chips?
Last edit: stan cartwright 2021-05-31
I would much prefer written documentation over videos.
no videos except gcb has lost it's roots as an easy way to program u controllers.
For me avr works and plenty of mem.
Pics are a bit more complicated to set up.
Why so much effort into mplabx?
GCB has a range of users and most would ,if me, want improvements to the basic side of gcb...
like supported hardware...not mplab
The idea you could program a uno/nano easy and get it to work with spi or i2c is forgotten
and it's all techno stuff is not what gcb was.
It's great there's new stuff for serious pic programmers but what's new for an "average" coder?
Last edit: stan cartwright 2021-05-31
How come the lgt328 don't get mentioned . Isn't it's speed interesting anyone?
I personally thought lgt was a brill addition to gcb but not much feed back about it...pity.
What's so special about new pics that we've lived without for so long?
I tried micro chip dev boards but a uno did more with out setting pins.
gcb and avr look cool but most people don't use the avrtiny...do they?
How many people think gcb is better since last rc?
The LGT is mentioned in the release report. Did you search for LGT? if you use te URL shown below you can create a report that is specific for the LGT changes. There are many.
I think the release is a lot better. When I get moment I will write up all the changes but here is a metric... PIC specific changes = 338 AVR specific changes = 188 and 110 of the 188 changes were functional changes.
Attached in the AVR functional changes report.
To document the full release will take a few weeks - it is a huge set of changes.
Here is the URL to the raw data. I am updating all the time but you can run your own reports by using the Excel filter function.
I am NOT going to teach you all how to use Excel. But, a clue. Use ROW 1 to select filters, you can select a filter or you can add a text filter.
https://1drv.ms/u/s!Ase-PX_n_4cvhJAyOaRPd7GXmXg-Rw?e=fEolor
I will be updating this document as I have no other idea on how to collate two years of changes. This document is the SAME document you get in the installation - just formatted with extra columns.
If folks want more information on a specific change the I can add more information.
Last edit: Anobium 2021-06-02
You did a great job ... I wonder how you do it ...
I think that inserting the date also allows you to see the trend of the work.
I can add the date of the commits. These dates will be very very close to when we did the work. To mimimise my work I will add a date month - to add all dates would ne a huge amount of work.
It is a good thing
I noticed the second in the list, index 659 -- changed dim glcdpixelcount A.
was a word but words can overflow.
When I look at glcd include, there's a lot of ifdef display xxxx then and ifdef display yyyy then.
so there was a time when using older smaller displays that a word var worked so isn't it sorted at compile time the display and if the glcdpixelcountA needs to be a word or whatever it is now?
Seems to slow glcd for compatibility with larger displays.
or maybe I don't understand the compiler.
Any way thanks to "the team" for still supporting gcb.
How did I get by with gcb for so long with all it's underlying faults? :)
You're trying to make gcb work with old low spec pics and newer pics.. and avr..in many chips/boards. Lots of work, good luck.
Are arrays and table still only bytes or can they be strings? Stuff on the forum about bytes only.
Last edit: stan cartwright 2021-06-02
The long is only used in the GLCDs where is needs to be used. So, it is left as a WORD or BYTE in those GLCDs that cannot overflow and therefore the allocation of memory has not increased for this GLCDs. But, where there is a danger of overflow the LONG is used.
The long fixes a bug that was reported and therefore the overflow can happen on some GLCDs. This changed is dated 11/10/19 and therefore has been in every build and RC release for the last 18 months.
I have added some dates to the XLS document.
If you want more date change this URL https://sourceforge.net/p/gcbasic/code/1218/log/
Change the log number from 1218 to the number shown in the [1218] in the XLS. Sometimes the righthand brace is missing - sorry.
index 659 glcd solution is great. sort of optimising at compile.
I like the way the ssd1306 oled can check available ram and still sort a display for low ram.
I like 2K ram to play with.
I always think gcb works and if it doesn't then it's my fault.
That's cos I don't use pics where they get upset easy.
Thinking about it, Would it, in the case of the ssd1306, been easier to just suggest another pic with more ram been easier as the display is tiny anyway?
Last edit: stan cartwright 2021-06-03
Just a note to thank you to all involved in the huge release of 0.98.07
I am grateful for the hard work that has gone into it. It is certainly appreciated by me.
Having just installed it, replaced the various settings with those neded for Geany and the NSDSP programmer my most recent project compiled without error.
As before, many thanks.