I have also tested EE writes and read. They are correct. I used C:\GCstudio\gcbasic\demos\Vendor_Boards\Great_Cow_Basic_Demo_Board\18f26q43_chiprange_demonstrations\160_showing_eeprom_data_to_serial_terminal.gcb
No issues. The issue when we were testing ( see above ) is likely to be caused by the serial USART library not working as expected.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is what i get in windows communication program when i power on Amsrtad CPC with the PIC board connected, so i suppose it's ok.
But when i'm trying my code (with the same uart settings) i still don't get a response... Perhaps there is a problem with the CLC definitions, this is what i used for Q43:
Ok, i think i got it.... Q43 uses complete different codes for declaring CLC outputs as inputs to other clc, for example setting clc1 out, as input to another clc with Q10, code is 0x21 (CLC1SEL=0x21) where for Q43 is 0x33 (CLCNSEL1=0X33), so i had to change such codes in clc declarations too! First tests seem promising, for the first time board worked on Amstrad CPC using a PIC 18F47Q43! @evanvennn thanks again for the help! :-)
Last edit: ikonsgr74 2025-08-10
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
yes i'm using the new usart.h. serial port which seems to work ok, at least all direct I/O with uart works ok. I still have problems connecting with a usb host module though, but most probable this doesn't have to do with the uart function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To resolve CLC when GCBASIC with PIC , use the MPLAB Code Configurator (MCC) is a great for setting up peripherals like the Configurable Logic Cell (CLC) and USART. Here’s a quick summary and how you can use MCC’s generated C code in GCBASIC projects.
What is MCC?
MCC is Microchip’s free tool for configuring peripherals on PIC devices. It comes as a standalone application:
- Graphical Interface: Easily configure USART, CLC, ADC, PWM, etc., without diving into datasheets.
- C Code Generation: Produces clean C code for peripheral initialization and pin setups (e.g., PPS for USART).
- Validation: Checks for pin conflicts, valid baud rates, and resource compatibility.
- Support: Works with 8/16/32-bit MCUs, using MCC Melody (modern devices), MCC Classic (legacy), or MPLAB Harmony (32-bit).
- Standalone Option: No need for MPLAB X—perfect for lightweight workflows.
Using MCC with GCBASIC
MCC generates C code that you can open and extract register settings from to use directly in GCBASIC. This is super handy for peripherals like CLC (for logic gates/latches) or USART (for serial comms). Here’s how:
Configure in MCC:
Open MCC (standalone or in MPLAB X).
Select your MCU (e.g., PIC18F27Q43).
Set up peripherals (e.g., USART2 at 115200 baud, CLC for signal modulation) and PPS (e.g., RB2 for TX2, RB1 for RX2).
Generate code to get .c and .h files.
Extract Register Settings:
Open the generated files (e.g., uart2.c for USART, clc1.c for CLC).
Look for register assignments, like:
// USART2 exampleU2CON0=0x80;// Enable UART, TXU2BRG=0x36;// Baud rate for 115200RB2PPS=0x23;// TX2 on RB2U2RXPPS=0x09;// RX2 on RB1// CLC exampleCLC1CON=0x82;// Enable CLC, D Flip-Flop modeCLC1SEL0=0x10;// Input source (e.g., NCO)
Add to GCBASIC:
Copy these into your GCBASIC program, e.g., in an InitPPS sub:
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool.
Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register:
U2BRG = 0x36; // Baud rate for 115200
But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this:
INITUSART
;Set the default value for USART handler - required when more than one USART;comport = SCRIPT_DEFAULT_COMPORT
movlw 1
movwf COMPORT,ACCESS
;PIC USART 2 Init;U2BRGH=SPBRGH_TEMP2
banksel U2BRGH
clrf U2BRGH,BANKED
;U2BRGL=SPBRGL_TEMP2
movlw 137
movwf U2BRGL,BANKED
;U2BRGS = BRGS2_SCRIPT
bsf U2CON0,U2BRGS,BANKED
;ON_U2CON1=1
bsf U2CON1,ON_U2CON1,BANKED
;U2TXEN=1
bsf U2CON0,U2TXEN,BANKED
;U2RXEN=1
bsf U2CON0,U2RXEN,BANKED
banksel 0
return
As you can clearly see, usart port speed for 115200 is made by setting U2BRGH=0 and U2BRGL=137 . I suppose U2BRGL and U2BRG are pointing to the same low byte of U2BRG register, but for the same speed (115200), your USART2 example from MCC , uses a completely different value (0x36) compared to the value shown in asm code (137=0x89).
Does this mean that GCB compiler doesn't set the correct U2BRG values for setting various usart speeds properly?
Also, with PIC18F47Q10 i use UNLOCKPPS/LOCKPPS nesting only for PPS , TX/RX registers and CLCOUT pins in INITPPS routine:
I set all other CLC and usart speed registers directly without using UNLOCKPPS/LOCKPPS and never had any problems.
You think that PIC18F47Q43 needs nesting with UNLOCKPPS/LOCKPPS for these too?
Last edit: ikonsgr74 2025-08-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ignore the USART setup. You know GCBASIC sets this correctly. Unless you config the whole chip in MCC exactly the same as GCBASIC you will run into issues with respect to baud rate registers.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, i'm asking because, despite correct basic funcntion of USART port, i still have problems when trying to connect a CH376 usb host module.
I manage to "pinpoint" the problem where code execution freeze (e.g. reading bytes from a large 16k table written in PIC's flash memory, table acts as ROM for the board reading Z80 asm code) when a command byte sequence is sent from PIC to host module, and i never get a response for no obvious reason... I also experience other erratic problems, which reminds the ones i had with reading large byte tables with 18F47Q10 a few years ago: https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25
The problem then, was in the MCU chip description file, so i was wondering if we experience something similar with the newest 18F47Q43...
Last edit: ikonsgr74 2025-08-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That old thread refers to chipdata file issue. So, I have compared to Datasheet and JAL. These are my references. The Q43 have a different memory model from the Q10. So, I want you to remove the memory buffer (page 71 in the datasheet) from DAT file.
Change and test.
'This constant is exposed as ChipMaxAddress
MaxAddress=9727
to
'This constant is exposed as ChipMaxAddressMaxAddress=9471
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, i change in 18F47Q43.DAT file:
'This constant is exposed as ChipMaxAddress
MaxAddress=9471
and re-compile, unfortunately no changes, i still get the same erratic behavior and hung ups...
My PIC18F47Q43 has "2032MOC" on it, and purchased from MICROCHIP directly a few years ago.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PIC-AS will validate the ASM generated. Think of PIC-AS validating the ASM and ensure that any potential issues in GCASM are eliminated. PIC-AS takes only a few seconds more than GCASM to compile.
The PIC-AS error log may reveal something.
The ASM memory usage looks ok. The buffer you are using doing exceed 0x24FF which is good.
As you have a PICKit4. You could load the .S file into MPLAB-X and run the MPLAB-X debugger live to see what is happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i made a few more tests using a serial connection between PC and Amstad CPC. Initially it wroks ok (i can get catalogues of directories in PC to Amstrad CPC screen), but when i'm trying to load something it crashes. This really resembles the symptoms we got with 18F47Q10 when it couldn't read correctly bytes from large byte tables written in PIC's flash memory.
Btw ,here is the .s file produced
I have also tested EE writes and read. They are correct. I used C:\GCstudio\gcbasic\demos\Vendor_Boards\Great_Cow_Basic_Demo_Board\18f26q43_chiprange_demonstrations\160_showing_eeprom_data_to_serial_terminal.gcb
No issues. The issue when we were testing ( see above ) is likely to be caused by the serial USART library not working as expected.
Ok, now it seems that both test codes work: https://www.dropbox.com/scl/fi/dvfyeknzz11cjvw33xx3w/uart_test.jpg?rlkey=473iiv1tdug9kgjnrl6nh5gvw&dl=0
This is what i get in windows communication program when i power on Amsrtad CPC with the PIC board connected, so i suppose it's ok.
But when i'm trying my code (with the same uart settings) i still don't get a response... Perhaps there is a problem with the CLC definitions, this is what i used for Q43:
And these were the original CLC definitions for Q10 that work:
It seems like the CLC that also control the uart port (using IN/OUT commands at specific addresses) doesn't work at all.... Any ideas?
Ok, i think i got it.... Q43 uses complete different codes for declaring CLC outputs as inputs to other clc, for example setting clc1 out, as input to another clc with Q10, code is 0x21 (CLC1SEL=0x21) where for Q43 is 0x33 (CLCNSEL1=0X33), so i had to change such codes in clc declarations too! First tests seem promising, for the first time board worked on Amstrad CPC using a PIC 18F47Q43! @evanvennn thanks again for the help! :-)
Last edit: ikonsgr74 2025-08-10
Can I check. The USART is working at expected? and, you are now using the new usart
h?
yes i'm using the new usart.h. serial port which seems to work ok, at least all direct I/O with uart works ok. I still have problems connecting with a usb host module though, but most probable this doesn't have to do with the uart function.
USART - great news.
To resolve CLC when GCBASIC with PIC , use the MPLAB Code Configurator (MCC) is a great for setting up peripherals like the Configurable Logic Cell (CLC) and USART. Here’s a quick summary and how you can use MCC’s generated C code in GCBASIC projects.
What is MCC?
MCC is Microchip’s free tool for configuring peripherals on PIC devices. It comes as a standalone application:
- Graphical Interface: Easily configure USART, CLC, ADC, PWM, etc., without diving into datasheets.
- C Code Generation: Produces clean C code for peripheral initialization and pin setups (e.g., PPS for USART).
- Validation: Checks for pin conflicts, valid baud rates, and resource compatibility.
- Support: Works with 8/16/32-bit MCUs, using MCC Melody (modern devices), MCC Classic (legacy), or MPLAB Harmony (32-bit).
- Standalone Option: No need for MPLAB X—perfect for lightweight workflows.
Using MCC with GCBASIC
MCC generates C code that you can open and extract register settings from to use directly in GCBASIC. This is super handy for peripherals like CLC (for logic gates/latches) or USART (for serial comms). Here’s how:
Generate code to get
.cand.hfiles.Extract Register Settings:
uart2.cfor USART,clc1.cfor CLC).InitPPSsub:ComplexTest.gcb) is validated for compatibility, saving debugging time.Why Use MCC with GCBASIC?
Where to Get MCC
MCC can generate and validate USART/CLC setups, making your GCBASIC code more robust.
Took me way too long to find the executeable, but here's where I found it:
https://www.microchip.com/en-us/tools-resources/configure/mplab-code-configurator
Knowing Microchip it will be in a different location tomorrow.
I used a lot MCC in the past, to setup CLC's for my project, but then i start using CLCdesigner ,which is much easier and faster tool.
Anyway, i noticed something strange in the USART2 example you give, serial port speed for 115200 is set by a single register:
U2BRG = 0x36; // Baud rate for 115200
But when i set deafult usart2 speed @ 115200 in GCB code ( #define USART2_BAUD_RATE 115200) the asm code for INITUSART routine give this:
As you can clearly see, usart port speed for 115200 is made by setting U2BRGH=0 and U2BRGL=137 . I suppose U2BRGL and U2BRG are pointing to the same low byte of U2BRG register, but for the same speed (115200), your USART2 example from MCC , uses a completely different value (0x36) compared to the value shown in asm code (137=0x89).
Does this mean that GCB compiler doesn't set the correct U2BRG values for setting various usart speeds properly?
Also, with PIC18F47Q10 i use UNLOCKPPS/LOCKPPS nesting only for PPS , TX/RX registers and CLCOUT pins in INITPPS routine:
I set all other CLC and usart speed registers directly without using UNLOCKPPS/LOCKPPS and never had any problems.
You think that PIC18F47Q43 needs nesting with UNLOCKPPS/LOCKPPS for these too?
Last edit: ikonsgr74 2025-08-15
Ignore the USART setup. You know GCBASIC sets this correctly. Unless you config the whole chip in MCC exactly the same as GCBASIC you will run into issues with respect to baud rate registers.
There is no real need for PPS lock and unlock unless there is a risk that your program changes these by accident, which is should not.
Ok, i'm asking because, despite correct basic funcntion of USART port, i still have problems when trying to connect a CH376 usb host module.
I manage to "pinpoint" the problem where code execution freeze (e.g. reading bytes from a large 16k table written in PIC's flash memory, table acts as ROM for the board reading Z80 asm code) when a command byte sequence is sent from PIC to host module, and i never get a response for no obvious reason... I also experience other erratic problems, which reminds the ones i had with reading large byte tables with 18F47Q10 a few years ago:
https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25
The problem then, was in the MCU chip description file, so i was wondering if we experience something similar with the newest 18F47Q43...
Last edit: ikonsgr74 2025-08-16
Can we check the basics?
Where was the Q43 sourced from?
That old thread refers to chipdata file issue. So, I have compared to Datasheet and JAL. These are my references. The Q43 have a different memory model from the Q10. So, I want you to remove the memory buffer (page 71 in the datasheet) from DAT file.
Change and test.
to
Ok, i change in 18F47Q43.DAT file:
'This constant is exposed as ChipMaxAddress
MaxAddress=9471
and re-compile, unfortunately no changes, i still get the same erratic behavior and hung ups...
My PIC18F47Q43 has "2032MOC" on it, and purchased from MICROCHIP directly a few years ago.
Ok. To get the revision look in the PickitPlus GUI that shows the revision. We need that revision to ensure the silicon is safe to use.
So, changing the DAT proves the buffer was not the issue.
Send me your ASM. I will inspect the memory allocation.
From PICKIT4 output:
Target device PIC18F47Q43 found.
Device Revision Id = 0xa0420000
Device Id = 0x74a0
When you say "ASM" you mean the asm file produced by GCB compiler right?
Last edit: ikonsgr74 2025-08-16
Your chip is a good chip. The Microchip errata did show a mega issue for earlier versions of this chip type.
I will look at asm now.
The "Rom Code" where the problem occurs, is the Table named: RSX_CODE
You need to compile using PIC-AS as MPASM ( the Q43 is meant to be supported by MPASM ) is throwing some odd errors. You could install PIC-AS from https://sourceforge.net/projects/gcbasic/files/Support%20Files/MicrochipCompilers/xc8-v3.00-full-install-windows-x64-installer.exe/download and then select PIC-AS as the assembler.
PIC-AS will validate the ASM generated. Think of PIC-AS validating the ASM and ensure that any potential issues in GCASM are eliminated. PIC-AS takes only a few seconds more than GCASM to compile.
The PIC-AS error log may reveal something.
The ASM memory usage looks ok. The buffer you are using doing exceed 0x24FF which is good.
As you have a PICKit4. You could load the .S file into MPLAB-X and run the MPLAB-X debugger live to see what is happening.
When i try to edit programmer preferences (to change the assembler) i get this:
btw i'm using Legacy studio mode as i'm used to it for many years :-)
i tried modern studio mode but still i got an error when tried to open programmer preferences:
Can we do a conf call to get this sorted? Please
Ok, i re-update GCB and it works. I compile project with PIC-AS compiler and create an .s file. I didn't get any errors upon compiling.
i made a few more tests using a serial connection between PC and Amstad CPC. Initially it wroks ok (i can get catalogues of directories in PC to Amstrad CPC screen), but when i'm trying to load something it crashes. This really resembles the symptoms we got with 18F47Q10 when it couldn't read correctly bytes from large byte tables written in PIC's flash memory.
Btw ,here is the .s file produced
Last edit: ikonsgr74 2025-08-17
I have compiled the .s here. As you say - no errors or warning.
Remind me how we resolve the Q10 issue.