For/Next and Repeat run forever regardless of variable, explicit or not.
Wait with constant time values work, but Wait with variable time values wait an arbitrary time.
Re the config. Setting the config is not needed as the .64 will override. Look in PICINFO for the defaults but you may only need the non frequency configs.
I am looking at the memory now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason I do the demo is not for my good health but to fully test the compiler. I can no longer do this for every chip. So, as time goes by the testing needs to picked up others.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Evan,
I'm building and testing a couple of tiny PIC18F05Q40 boards with a 128x32 OLED, SSD1306 type. I will send you one, assuming I get it working.
My aim is to test-out the GLCD driver, to take some screenshots of different font attributes, for the full GFX option (costs 1024B RAM) and the low-memory (same behaviour, slower, but 128B RAM cost) and the character-only option. All this for both of the two SSD1306 drivers - the full-fat 64-row, and the 32-row. Currently they seem to have different font sizes for the same definitions.
To this end, I need to make a GCB program that takes UART input, ideally from the PICKIT2 UART tool, and allows me to construct GLCD calls as though they were called within a stand-alone GCB program. i.e. with the ability to force [GLCDFontWidth, GLCDfntDefault, GLCDfntDefaultsize] .
If there is something already defined - like the RS232 format and content - then I'd like to be compatible with it, or even copy it. So, any "test suite" you have for GLCD would be most useful.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I produce the same demos for all chips. Why? Then I know what results to see. But, this means that you can use the GLCD 'Simple' demos as your resource.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The boards are in the pillar box, on their way - with SSD1306 OLED, and 2 processor boards. I tried to get the same GCB program that ran on a 12LF1552, to run on an 18F05Q40. It compiled, but looked suspicious as it used less RAM. It didn't work as intended, and even stripping it right back to "blink" function didn't work:
#chip PIC18F05Q40,16
#option explicit
'Turn LED on to show it is complete
dir porta.5 out
Do Forever
porta.5 = !porta.5
wait 1 s
Loop
end
From the title of this thread, it's clear that I need an up-to-date compiler for the 18F05Q40, and I think I do - mine is: 0.98.07 2021-07-24 (Windows 64 bit) : Build 1005.
There are Microchip errata dated 05/2022 that show the shadow registers as not working properly - https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/PIC18F04-05-14-15Q40-Silicon-Errata-and-Data-Sheet-Clarifications.pdf
I'm not sure if I have fixed silicon or not, I'd hope so given it's dated 2023. GCB can either use shadow registers or ignore them (with minor impact) - it would be nice to know.
Anyway, I've sent a board, and just getting "blink" to work should be trivial, for the gods of GCB, and as we all know, progress thereafter is exponential.
I'm hoping that the 18F05 might be a useful "superset" part for all sorts of projects, not some dead-end compatibility burden.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FWIW, the 18F05Q40 is a most interesting part - only 14-pins, but 64MHz, 64kB ROM,4kB RAM, tons of peripherals, and less than £1. It would be a nightmare to set-up in assembler, several days work - but GCB avoids all that.
Last edit: Bonkers 2023-04-18
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are no know issues with the Q41. Q41 are different chip family from the Q40.
See your installation there are 32 demos in the C:\GCB@Syn\GreatCowBasic\Demos\vendor_boards\great_cow_basic_demo_board\18f16q41_chiprange_demonstrations folder.
So, do try ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been using the 18F15Q40 which I understand to be the same device as the 05Q40, but with 20 pins opposed to 14. I have been using these for a while now and they are indeed great. The boost in speed makes some difference, but that extra program space is just wonderful. If I could get the 18F05Q40 in the DIL (DIP?) package more easily I'd be using more of those too. I'm on a later release than you (one of the V1.xx releases) and having no problems that being a better coder wouldn't fix.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From the change log: 18/08/2021 1017 FIX DAT COMPILER Yes PIC Not required Fix: 18FxxQ40 memory map corrected. Change GETCHIPDATA source to handle Q40s. It was missing from GETCHIPDATA handler.[1256]
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It works !! - It flashes an LED
I'm on 0.99.01 2022-01-27 (Windows 64 bit) : Build 1073.
It didn't work with this alone, but needed the PPS code to be added. (re-checked, and this is true)
I used the PPS tool and defined the I2C pins as their defaults, even though I'm not using them in the "blink" program.
Here's what was added to make it work: (both gcb files attached also)
'Generated by PIC PPS Tool for Great Cow Basic
'PPS Tool version: 0.0.6.2
'PinManager data: Not available (3)
'Generated for 18f05q40
'
'Template comment at the start of the config file
'
#startup InitPPS, 85
#define PPSToolPart 18f05q40
SubInitPPS'Module: I2C1I2C1SCLPPS=0x0010'RC0 > SCL1RC0PPS=0x0021'SCL1 > RC0 (bi-directional)RC1PPS=0x0022'SDA1 > RC1I2C1SDAPPS=0x0011'RC1 > SDA1 (bi-directional)End Sub'Template comment at the end of the config file
That doesn't make any sense at all (setting PPS for something totally unrelated).
But what DOES make sense is that the IO pins power up in analog mode, so when you try to read PORTA.5 to toggle it, it'll always read '0'.
Try using the LAT instead and it should work...
lata.5 = !lata.5
Or, set the pin to digital mode.
Also, the shadow register issue isn't a problem unless you try to modify the contents of the shadow registers before restoring them, which isn't something most people do. The shadow registers work fine for normal save/restore type operations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
All ports should be set to digital out, port is transparently coverted to LAT ( as and when required).
I will test on real silicon.
What is very important is a total power cycle of these chips, and, setting/clearing of PPS. A programming cycle will not and does not power cycle the chip to set everything to POR values. And, I will ask anyway, any bootloader ? Bootraders will require ports to be set/cleared to ensure a know state.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jerry - thanks for the clarification on shadow registers, for sure they're keepsafes, not intended to be modified.
I'm not sure if it is a port set-up issue with the PPS code - both versions call INITSYS, which sets-up the ports, disables the default ADC assignment - and the asm code is identical.
The PPS code, is only called by the (working) blinkwPPS.gcb code, and defines the RC0PPS and RC1PPS registers - and not anything to do with RA.5 (my LED pin).
So, not sure why the one works and the other not - but happy to accept that it is good practise to define the PPS registers and not rely on POR defaults. I routinely power-cycle the PIC using the "Vdd" box on the pickit2, after programming.
Anobium - I've no bootloader, just manually importing asm files into pickit2 - I've not managed to get it working with GCB like it did on previous machine.
I'm now trying to convert the test program: LowMemorySS1306_test068.gcb to run on the 18F05, and hitting a similar problem, the heartbeat LED on RA.5 doesn't blink.
I will continue this discussion back in its original thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have just examined the two programs ( one with PPS and one without PPS) - I can see no rational explanation for the two programs to operate differently - the PPS would have no impact on the operation of thee specific programs.
The memory access looks correct. With [FreeRAM] at 500:CFF and [NoBankRAM] at 500:55F and 460:4FF
There shadow registers is not relevant to the issue described as there is
So, I am puzzled. I think we could be looking at a programing failure and not a compiler issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
RESOLVED - GET LATEST PATCH VERSION
See https://sourceforge.net/p/gcbasic/discussion/579125/thread/9eb0259f9e/#e27c below
I can't make variables work on 18f05Q40!
For/Next and Repeat run forever regardless of variable, explicit or not.
Wait with constant time values work, but Wait with variable time values wait an arbitrary time.
GCB 04/06/2021:v0.98.07
Thanks, Jim
Last edit: Anobium 2021-08-18
Oooops. The memory map is incorrect. I need time to review and resolve.
Thanks Evan. Do you ever sleep? ;=}
I appreciate your commitment to GCB! It's a hell of a tool.
Also: #chip 18F05Q40, 64 seems to output fuse hex for HFINTOSC_4MHZ.
But #CONFIG RSTOSC=HFINTOSC_64MHZ does get 64 mhz.
Thanks much,
Jim
Oh yes. I am a 9hours a day sleeper.
Re the config. Setting the config is not needed as the .64 will override. Look in PICINFO for the defaults but you may only need the non frequency configs.
I am looking at the memory now.
Update to the Q40 chipdata file. The memory map was incorrect.
See here for the online release note https://1drv.ms/x/s!Ase-PX_n_4cvhJAysbPF3VJAnYaj3A?e=lgkZnV index item #1017
Download from https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/Patches/
Update and enjoy
@Jim Henson. The issue why this was not found... there are no demo test programs. So, I do not know if there are other issues.
What is really needed is a full test suite from setting a port to complex I2C with GLCD etc. Something like https://github.com/Anobium/Great-Cow-BASIC-Demonstration-Sources/tree/master/Vendor_Boards/Great_Cow_Basic_Demo_Board/18F25Q10_ChipRange_Demonstrations but for the Q40s.
The reason I do the demo is not for my good health but to fully test the compiler. I can no longer do this for every chip. So, as time goes by the testing needs to picked up others.
Hi Evan,
I'm building and testing a couple of tiny PIC18F05Q40 boards with a 128x32 OLED, SSD1306 type. I will send you one, assuming I get it working.
My aim is to test-out the GLCD driver, to take some screenshots of different font attributes, for the full GFX option (costs 1024B RAM) and the low-memory (same behaviour, slower, but 128B RAM cost) and the character-only option. All this for both of the two SSD1306 drivers - the full-fat 64-row, and the 32-row. Currently they seem to have different font sizes for the same definitions.
To this end, I need to make a GCB program that takes UART input, ideally from the PICKIT2 UART tool, and allows me to construct GLCD calls as though they were called within a stand-alone GCB program. i.e. with the ability to force [GLCDFontWidth, GLCDfntDefault, GLCDfntDefaultsize] .
If there is something already defined - like the RS232 format and content - then I'd like to be compatible with it, or even copy it. So, any "test suite" you have for GLCD would be most useful.
Sounds very good.
I produce the same demos for all chips. Why? Then I know what results to see. But, this means that you can use the GLCD 'Simple' demos as your resource.
Understood, I'm after a similar result. I will look at the 'simple' demos to see what font and graphics options are tested, that's a good redirect.
The boards are in the pillar box, on their way - with SSD1306 OLED, and 2 processor boards. I tried to get the same GCB program that ran on a 12LF1552, to run on an 18F05Q40. It compiled, but looked suspicious as it used less RAM. It didn't work as intended, and even stripping it right back to "blink" function didn't work:
#chip PIC18F05Q40,16
#option explicit
'Turn LED on to show it is complete
dir porta.5 out
Do Forever
porta.5 = !porta.5
wait 1 s
Loop
end
From the title of this thread, it's clear that I need an up-to-date compiler for the 18F05Q40, and I think I do - mine is: 0.98.07 2021-07-24 (Windows 64 bit) : Build 1005.
There are Microchip errata dated 05/2022 that show the shadow registers as not working properly - https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/Errata/PIC18F04-05-14-15Q40-Silicon-Errata-and-Data-Sheet-Clarifications.pdf
I'm not sure if I have fixed silicon or not, I'd hope so given it's dated 2023. GCB can either use shadow registers or ignore them (with minor impact) - it would be nice to know.
Anyway, I've sent a board, and just getting "blink" to work should be trivial, for the gods of GCB, and as we all know, progress thereafter is exponential.
I'm hoping that the 18F05 might be a useful "superset" part for all sorts of projects, not some dead-end compatibility burden.
Oh my... the 0.98.07 ... that is so old. :-)
I will await my mail.
The boards are great.
The demonstration is wonderful.
You have proven what you can do with GLCD and very little RAM!!
FWIW, the 18F05Q40 is a most interesting part - only 14-pins, but 64MHz, 64kB ROM,4kB RAM, tons of peripherals, and less than £1. It would be a nightmare to set-up in assembler, several days work - but GCB avoids all that.
Last edit: Bonkers 2023-04-18
Does this fix applies to Q41 as well?
I can try Jim's program on PIC18F16Q41 as my first Great Cow project.
There are no know issues with the Q41. Q41 are different chip family from the Q40.
See your installation there are 32 demos in the C:\GCB@Syn\GreatCowBasic\Demos\vendor_boards\great_cow_basic_demo_board\18f16q41_chiprange_demonstrations folder.
So, do try ...
I've been using the 18F15Q40 which I understand to be the same device as the 05Q40, but with 20 pins opposed to 14. I have been using these for a while now and they are indeed great. The boost in speed makes some difference, but that extra program space is just wonderful. If I could get the 18F05Q40 in the DIL (DIP?) package more easily I'd be using more of those too. I'm on a later release than you (one of the V1.xx releases) and having no problems that being a better coder wouldn't fix.
I am with @CCin... upgrade.
From the change log:
18/08/2021 1017 FIX DAT COMPILER Yes PIC Not required Fix: 18FxxQ40 memory map corrected. Change GETCHIPDATA source to handle Q40s. It was missing from GETCHIPDATA handler.[1256]It works !! - It flashes an LED
I'm on 0.99.01 2022-01-27 (Windows 64 bit) : Build 1073.
It didn't work with this alone, but needed the PPS code to be added. (re-checked, and this is true)
I used the PPS tool and defined the I2C pins as their defaults, even though I'm not using them in the "blink" program.
Here's what was added to make it work: (both gcb files attached also)
'Generated by PIC PPS Tool for Great Cow Basic
'PPS Tool version: 0.0.6.2
'PinManager data: Not available (3)
'Generated for 18f05q40
'
'Template comment at the start of the config file
'
#startup InitPPS, 85
#define PPSToolPart 18f05q40
That doesn't make any sense at all (setting PPS for something totally unrelated).
But what DOES make sense is that the IO pins power up in analog mode, so when you try to read PORTA.5 to toggle it, it'll always read '0'.
Try using the LAT instead and it should work...
lata.5 = !lata.5
Or, set the pin to digital mode.
Also, the shadow register issue isn't a problem unless you try to modify the contents of the shadow registers before restoring them, which isn't something most people do. The shadow registers work fine for normal save/restore type operations.
It is odd.
All ports should be set to digital out, port is transparently coverted to LAT ( as and when required).
I will test on real silicon.
What is very important is a total power cycle of these chips, and, setting/clearing of PPS. A programming cycle will not and does not power cycle the chip to set everything to POR values. And, I will ask anyway, any bootloader ? Bootraders will require ports to be set/cleared to ensure a know state.
reading the PORT will be converted to the LAT? I doubt that.
Does gcb automatically set pins to digital mode? Otherwise it'll read the port in analog mode, and always read 0
'as and when required' the compiler examines the state and should handle appropriately.
Jerry - thanks for the clarification on shadow registers, for sure they're keepsafes, not intended to be modified.
I'm not sure if it is a port set-up issue with the PPS code - both versions call INITSYS, which sets-up the ports, disables the default ADC assignment - and the asm code is identical.
The PPS code, is only called by the (working) blinkwPPS.gcb code, and defines the RC0PPS and RC1PPS registers - and not anything to do with RA.5 (my LED pin).
So, not sure why the one works and the other not - but happy to accept that it is good practise to define the PPS registers and not rely on POR defaults. I routinely power-cycle the PIC using the "Vdd" box on the pickit2, after programming.
Anobium - I've no bootloader, just manually importing asm files into pickit2 - I've not managed to get it working with GCB like it did on previous machine.
I'm now trying to convert the test program: LowMemorySS1306_test068.gcb to run on the 18F05, and hitting a similar problem, the heartbeat LED on RA.5 doesn't blink.
I will continue this discussion back in its original thread.
I have just examined the two programs ( one with PPS and one without PPS) - I can see no rational explanation for the two programs to operate differently - the PPS would have no impact on the operation of thee specific programs.
The memory access looks correct. With [FreeRAM] at 500:CFF and [NoBankRAM] at 500:55F and 460:4FF
There shadow registers is not relevant to the issue described as there is
So, I am puzzled. I think we could be looking at a programing failure and not a compiler issue.
Then, I went to post my the information on my toolchain.
I am using I am using 1.00.00 2023-04-13 (Windows 64 bit) : Build 1237
You are using 0.99.01 2022-01-27 (Windows 64 bit) : Build 1073.
That is a very old compiler. Update and retest please