Correct. I have to test the other Q20 files. I used the 18Fx6Q20 as the master test chip and I need to regen all the Q20 when testing is completed. At the moment the 18Fx6Q20 is released. I will get to the rest soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Q20 is an interesting chip family from a compiler and programming point of view.
The configuration memory is not contiguous and specific configuration bytes are write once. This means the compiler needs to address the contiguous memory issue, and, like the Q71s, the Code Protection and Data Protection configuration bits are not in the same Configuration byte. This means the compiler must write the configuration byte in a different sequence and programming is a challenge.
I have PICKitPlus working. Functional changes were required as the verification process is very different from other 18Fs and the Q20s returns configuration bit values that are always set... when according to the datasheet they should not be set.
Finally, like the Microchip implemented of the Q20. The new write once configuration operation is not part of the 'standard' programming process. Users will have to set this bit explicitly in the programmer.
Summary. Q20 is not just another 18f. Is has very specific use cases and with those use cases come specific risks. GCBASIC will protect the user by limiting the use of the write once operations.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
GCBASIC will protect the user by limiting the use of the write once operations.
That's probably a good feature. To be honest, I'm still trying to figure out why they now have write-once bytes that cannot be changed vs the old method of code protection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I asked Microchip. This is to created a protected chip area for a bootloader. Some customer must have a specific need to ensure there is no risk of a program overwrite the bootloader.
It is easy to overwrite a bootloader... ask many UNO users. The Q20 will prevent the corruption of the bootloader.
Last edit: Anobium 2023-10-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I don't understand.... why use SAF memory for this? SAF has specific constraints but I guess that writing once does overcome the SAF high/low issue.
It does smack of someone not really thinking the architecture though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A number of devices already have a BootBlock which can be write-protected, but that's located in low-memory starting at addr 0.
Since the SAF is at the end of memory I guess you can put your bootloader there now and protect it, although I never cared much for that arrangement.
Still, I wonder why write-once? With the old scheme, once you protected the bootloader the only way to be able to write/erase it was by using ICSP and erase the device first to clear the write-protect config.
Oh well, there's lots of choices they make that I don't get sometimes. I'm sure it made sense to somebody...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Q20 DAT files shipped with build 1289 are invalid. They will issue a warning.
Warning: This is a development chip definition file (.DAT) and the chip has not been validated by the developers of the compiler. There may be errors in the ASM and/or the
generated HEX file - please be aware that the libraries may or may not support this chip.
This is correct.. as the build actually has the development Q20 DAT files.
Anyone wanting to test the Q20 - ping me and I will provide a product Q20 DAT files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have committed improved support for Q20, as follows:
GCBASIC now supports the Q20 chip family from build 1293
Build 1293 has revised DAT files with corrected config for CP and CPD.
PICInfo has been updated to support Q20
PPSTool has support for Q20. This is interim support, for some reason the 14pin device shows up as a 20 pin device. Will be sorted in the future.
GCBASIC does not support Config9 or Config 14 operations. If you need these I can add.
PICKITPlus has been updated to support the Q20 from release 6.6.0.76 ( database 3.63.239.4)
GCBASIC has been tested against MPLAB-X, and HEX into MPLAB-IPE, and, using GCASM and PIC-AS 2.15
All looks ok, but, there are no demos as yet. The basics are done to enable usage - only when someone uses the chip will we know if the Q20 actually works... demos are needed.
I need to be very clear. The work so far enables compilation and programming. I have no time to test, I have not formally test the simplest I/O on and off. The first user needs to start with the absolute assumption that nothing has been tested.
Last edit: Anobium 2023-10-25
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These have taken a long time to complete - other developments with GCBASIC took priority. :-)
PT1: PIC18xxQ20 chip Family - Using the GCBASIC to do the basics.. flash some LEDs
PT2: PIC18xxQ20 chip Family - Using the GCBASIC to rotate the LEDs using GCBASIC and PT3: PIC18xxQ20 chip Family - Using the GCBASIC to set the LEDs using an ADC value
PT4: PIC18xxQ20 chip Family - Using the GCBASIC sequence the LEDs with a delay using the PT5: PIC18xxQ20 chip Family - Using an input to set the state of the LEDs
PT6: PIC18xxQ20 chip Family - Using the reset switch as an input or to reset the chip
PT7: PIC18xxQ20 chip Family - Using the switch, ADC – the LEDs flash in a sequence with PT8: PIC18xxQ20 chip Family - Using serial/USART to show the state/values of the switch, PT9: PIC18xxQ20 chip Family - Using clock timers to sequence the LEDs
PT10: PIC18xxQ20 chip Family - Using EEPROM
PT11: PIC18xxQ20 chip Family - Using I2C Discovery
PT13: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with SPI and a GLCD
PT12: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with I2C and a GLCD
PT14: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with PWM - 7 ways
PT15: PIC18FxxQ20 chip Family - Using the Interrupts with the PIC18FxxQ20
PT16: PIC18FxxQ20 chip Family - Using Storage with the PIC18FxxQ20
PT17: PIC18FxxQ20 chip Family - Using CLC with the PIC18FxxQ20
PT18: PIC18FxxQ20 chip Family - The GCBASIC toolchain
PT19: PIC18FxxQ20 chip Family - ASM and integration with MPLAB
PT20: PIC18FxxQ20 chip Family - Tutorial summary
This tutorials have two uses 1. The show how the Q20 works 2. The demo programs validate the GCSTUDIO toolchain. This dual purpose means there is some confidence that this specific chip family works as expected.
Enjoy
❤️
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
These are new parts: 18F04Q20, 18F05Q20, 18F06Q20, 18F14Q20, 18F15Q20,18F16Q20 added to GC BASIC.
Testing using PICKitPlus - you will need the latest version of PICKitPlus
These new parts are very interesting:
- Small footprint
- Protected Bootloader capability
- Differing voltage
- Virtual Port addressing
- I3C
Enjoy
PICKitPlus now supports the Q20 chipfamily.
https://www.youtube.com/watch?v=KHFcoSDwxew
Enjoy
Hi Evan,
I just loaded the latest gcstudio update (1.01.02) and all I see are files for the 18F06Q20 and 18F16Q20. Are the others not included yet?
Jerry
Correct. I have to test the other Q20 files. I used the 18Fx6Q20 as the master test chip and I need to regen all the Q20 when testing is completed. At the moment the 18Fx6Q20 is released. I will get to the rest soon.
I am just revising and release new 18Fx6Q20 support.
The reason there is no support in MPLAB-C 6.15 yet for the other Q20s. When Microchip release the other Q20s then I can create the DAT.
.
The Q20 is an interesting chip family from a compiler and programming point of view.
The configuration memory is not contiguous and specific configuration bytes are write once. This means the compiler needs to address the contiguous memory issue, and, like the Q71s, the Code Protection and Data Protection configuration bits are not in the same Configuration byte. This means the compiler must write the configuration byte in a different sequence and programming is a challenge.
I have PICKitPlus working. Functional changes were required as the verification process is very different from other 18Fs and the Q20s returns configuration bit values that are always set... when according to the datasheet they should not be set.
Finally, like the Microchip implemented of the Q20. The new write once configuration operation is not part of the 'standard' programming process. Users will have to set this bit explicitly in the programmer.
Summary. Q20 is not just another 18f. Is has very specific use cases and with those use cases come specific risks. GCBASIC will protect the user by limiting the use of the write once operations.
That's probably a good feature. To be honest, I'm still trying to figure out why they now have write-once bytes that cannot be changed vs the old method of code protection.
I asked Microchip. This is to created a protected chip area for a bootloader. Some customer must have a specific need to ensure there is no risk of a program overwrite the bootloader.
It is easy to overwrite a bootloader... ask many UNO users. The Q20 will prevent the corruption of the bootloader.
Last edit: Anobium 2023-10-01
What I don't understand.... why use SAF memory for this? SAF has specific constraints but I guess that writing once does overcome the SAF high/low issue.
It does smack of someone not really thinking the architecture though.
A number of devices already have a BootBlock which can be write-protected, but that's located in low-memory starting at addr 0.
Since the SAF is at the end of memory I guess you can put your bootloader there now and protect it, although I never cared much for that arrangement.
Still, I wonder why write-once? With the old scheme, once you protected the bootloader the only way to be able to write/erase it was by using ICSP and erase the device first to clear the write-protect config.
Oh well, there's lots of choices they make that I don't get sometimes. I'm sure it made sense to somebody...
I also need to create PPSTool XML . I will get to this at some time in October.
The Q20 DAT files shipped with build 1289 are invalid. They will issue a warning.
Warning: This is a development chip definition file (.DAT) and the chip has not been validated by the developers of the compiler. There may be errors in the ASM and/or the generated HEX file - please be aware that the libraries may or may not support this chip.This is correct.. as the build actually has the development Q20 DAT files.
Anyone wanting to test the Q20 - ping me and I will provide a product Q20 DAT files.
Q20 Update- build 1293
I have committed improved support for Q20, as follows:
All looks ok, but, there are no demos as yet. The basics are done to enable usage - only when someone uses the chip will we know if the Q20 actually works... demos are needed.
I need to be very clear. The work so far enables compilation and programming. I have no time to test, I have not formally test the simplest I/O on and off. The first user needs to start with the absolute assumption that nothing has been tested.
Last edit: Anobium 2023-10-25
PIC18FxxQ20 - a completed set of 20 videos.
https://youtube.com/playlist?list=PLN9gcw34mhuoyeGZxXaLAt-aXZ8r_vu6u&si=h128N70-Za-bMURC
These have taken a long time to complete - other developments with GCBASIC took priority. :-)
PT1: PIC18xxQ20 chip Family - Using the GCBASIC to do the basics.. flash some LEDs
PT2: PIC18xxQ20 chip Family - Using the GCBASIC to rotate the LEDs using GCBASIC and PT3: PIC18xxQ20 chip Family - Using the GCBASIC to set the LEDs using an ADC value
PT4: PIC18xxQ20 chip Family - Using the GCBASIC sequence the LEDs with a delay using the PT5: PIC18xxQ20 chip Family - Using an input to set the state of the LEDs
PT6: PIC18xxQ20 chip Family - Using the reset switch as an input or to reset the chip
PT7: PIC18xxQ20 chip Family - Using the switch, ADC – the LEDs flash in a sequence with PT8: PIC18xxQ20 chip Family - Using serial/USART to show the state/values of the switch, PT9: PIC18xxQ20 chip Family - Using clock timers to sequence the LEDs
PT10: PIC18xxQ20 chip Family - Using EEPROM
PT11: PIC18xxQ20 chip Family - Using I2C Discovery
PT13: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with SPI and a GLCD
PT12: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with I2C and a GLCD
PT14: PIC18FxxQ20 chip Family - Using the PIC18FxxQ20 with PWM - 7 ways
PT15: PIC18FxxQ20 chip Family - Using the Interrupts with the PIC18FxxQ20
PT16: PIC18FxxQ20 chip Family - Using Storage with the PIC18FxxQ20
PT17: PIC18FxxQ20 chip Family - Using CLC with the PIC18FxxQ20
PT18: PIC18FxxQ20 chip Family - The GCBASIC toolchain
PT19: PIC18FxxQ20 chip Family - ASM and integration with MPLAB
PT20: PIC18FxxQ20 chip Family - Tutorial summary
This tutorials have two uses 1. The show how the Q20 works 2. The demo programs validate the GCSTUDIO toolchain. This dual purpose means there is some confidence that this specific chip family works as expected.
Enjoy