I have written a program that is almost 6,500 line long. [Gulp!] It has reached the point where it will soon be too large for the 18F16Q41 I'm using. It originally fitted into a 16F1829 but feature creep has stretched it. Mostly the menus and additional functions, along with text strings for the display(s).
I'm now considering using an 18F27Q43 with all of the 128K code space it offers. Initially I want to try to use the original PCB design, and socket. I have drawn an adaptor that will enable me to convert the 28 pin SSOP package to a 20 pin DIL, with the 5V, Gnd and programming pins aligned with those of the 1829/16Q41. This way I can (hopefully) prototype the program without having to go to the expense of redesigning the whole thing. It also means (if I code it right) that any improvements to the general code can be backported to the originals.
My sticking point is that port definitions are read regardless of conditional defines. I see that there is a new-ish command 'UnDefine' which overwrites any previous definitions. Can I use this in the way I am intending?
It certainly compiles when I declare Using16F18Q41 or with Using18F27Q43 (and the appropriate Chip definitions). When selecting the 16F18Q41 it compiles, programs and runs. As I don't have any 18F27Q43 nor have I ordered any adaptors yet, I just wanted to clarify that I'm on the right track here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your reply. Pleased I understood (for once).
I'm not sure I'd be of much use regarding the debugging Alpha. Some days I struggle to write a single line of coherent code, never mind get it to compile and run!
Last edit: c-conversion 2026-01-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This journey has been a few years in the making. The pieces are now all there.
GCSTUDIO and GCCODE - the platform and IDE to deliver the capabilities
GCBASIC preprocessor and compiler as the foundation.
GCASM - as the core linker. PIC-AS and AVRASM2 integration as the key alternative liners.
GCDebugger at the way to delve into the details of the operations.
- the basic: a simulator
- the next level: the MPLAB-X debugger programmer
- the next level: PICKitXtra. A new paradigm. Debugging and programming without MPLAB-X.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Having opened this up again I have enabled the .CDF file as suggested.
An abbreviated form of the results from the compile with the chip set to 18F16Q41:
So it does look as though the 'UnDefine' is doing it's magic, thanks. I often use different devices in my designs and using this will save me having differing versions of code for every version.
The 18F27Q43 and the adaptors should be with me before too long so I can assemble a few boards and chips and start thinking about how I am going to implement the changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've run into a problem.
I need to 'swap' the port definitions for a softserial port.
If I do this:
#DefineSER1_BAUD9600'#Define SER1_BAUD 9600 ' baudrate must be defined'#Define SER1_DATABITS 7 ' databits optional (default = 8)'#Define SER1_STOPBITS 2 ' stopbits optional (default = 1)'#Define SER1_INVERT Off ' inverted polarity optional (default = Off)#DefineSER1_TXPORTPORTC' I/O Port (without .bit) must be defined#DefineSER1_TXPIN7' Port Bit must be defined#DefineSER1_RXPORTPORTB#DefineSER1_RXPIN0
It compiles and works.
If I do this:
#IfDefUsing18F27Q43#DefineSER1_BAUD9600'#Define SER1_BAUD 9600 ' baudrate must be defined'#Define SER1_DATABITS 7 ' databits optional (default = 8)'#Define SER1_STOPBITS 2 ' stopbits optional (default = 1)'#Define SER1_INVERT Off ' inverted polarity optional (default = Off)#DefineSER1_TXPORTPORTC' I/O Port (without .bit) must be defined#DefineSER1_TXPIN7' Port Bit must be defined#DefineSER1_RXPORTPORTB#DefineSER1_RXPIN0#EndIf
The same code, just in a 'Define' query.
An error is thrown (well, two errors).
I took all the 'UnDefine statements out and pared it back to what caused the problems. With two definitions in, and the 'UnDefine statements it actually compiled and ran but there was no activity on the serial port. It took me a while to pick out the problem.
For the time being, I'll just alter the port definitions manually so not a huge problem, but I had expected it to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This may be the the time to use a script. :-) I would.
Scripts give a lot more flexibility and a lot less complex.
Script make and manage constants during the preprocessor phase of compilation. You are working with constants. Check the CDF to see the outcome.
I have added some checks ( warnings ) you can remove.
Evan
//#chip 18F27Q43#chip 18F25K22#scriptSER1_BAUD=9600CHIPSELECT=0IfCHIPNAME=18F27Q43ThenSER1_TXPORT=PORTCSER1_TXPIN=7SER1_RXPORT=PORTBSER1_RXPIN=0CHIPSELECT=CHIPSELECT+1EndIfIfCHIPNAME=18F25K22Then' example for another chipSER1_TXPORT=PORTASER1_TXPIN=4SER1_RXPORT=PORTCSER1_RXPIN=5CHIPSELECT=CHIPSELECT+1EndIfIfCHIPSELECT=0ThenError"No SoftSerial pins defined for this chip variant"EndIfIfCHIPSELECT>1ThenError"Mulitple SoftSerial defined - check script"EndIfIfCHIPSELECT=1ThenWarning"SER1_TXPORT = "SER1_TXPORTWarning"SER1_TXPIN = "SER1_TXPINWarning"SER1_RXPORT = "SER1_RXPORTWarning"SER1_RXPIN = "SER1_RXPINEndif#endscript#include <SoftSerial.h>Ser1Send13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many thanks for the suggestion. I was looking for guidance on scripts when I came across UnDefine. I do like the checks too, I'll make use of them.
I'm not going to have a chance to look again until after the weekend, and if next week is as busy as this, possibly not until mid February. Once I get the time, I'll report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The script worked very well, the soft serial is operating and (almost) all re-directed pins function as they should.
I say almost...
I have an unused pin, Pin 10, RB7 on the physical 18F16Q41 which on my SOIC 28pin - 20pin DIL adaptor for the 27Q43 is connected to Pin 9, RA7. I'm using this as a serial debug out to send information about various parameters within critical subroutines for debugging, this is then displayed on a remote 4 line LCD display. To make this work I'm using PPS to swap the serial out onto the correct pins. This fails to work for no great reason that I can see. I wonder if it is the sequence in which some items are declared or defined as initially it was the 27Q43 that failed. I made some changes realising that my comport was UARTTx4 and I needed to use HSerPrint "Print This",4 when I'd been using UARTTx1 which doesn't need the "Port" parameter. Re-writing the HSerPrint routines to use a constant that was altered in the script seemed to correct this. Re-compiling for the 16Q41 showed that it had stopped working. 'Eck!
I'm going to keep looking at this. I tried a load of things yesterday with no success. I could have one device working, but not the other. I must be missing something, but I've yet to spot it. When I look at the .asm it looks as though the correct PPS is working, it looks as though the correct comport parameter is being set, but it fails to work. It may be something unrelated to the comport, possibly one of my pullup settings, but it's not (yet) working.
Everything else runs normally, multiple serial signals are sent and received the display, button and lights all work, just the hardware serial out. Very irritating.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As much as I can gather, this was related to me using (hardware) USART 1 on the 18F16Q41 and USART 4 on the 18F27Q43.
Defining the USART_BAUD_RATE as 9600 caused no issues, but defining USART4_BAUD_RATE 9600 threw an error when compiling for the 16Q41. No doubt as it has no USART4. I'd moved these within a "IfDef" test which cleared the errors, but something must have been silently failing.
I tried placing the USART_BAUD_RATE declarations within the script but that didn't work.
Eventually I realised that on both devices I could place USARTTx3 onto the appropriate pin using PPS to use the same 'leg' of the chip or chip + adaptor. As this requires only one USART3_BAUD_RATE declaration, and both devices have a USART3 the problem is bypassed.
I doubt this experience will help many people. I don't suppose many people are attempting to use one version of code on multiple devices, least of all where those devices have different ports mapped to different physical pins. Still, another lesson learned the very hard way.
Last edit: c-conversion 4 days ago
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The only things I changed was to move both hardware serial outs onto USART3 which was the only available one that covered both 'legs' and ports that I needed. That single change allowed both devices to work.
Using USART(1) and USART4 in the same program failed with no indication that it would. I'm pretty sure that the 18F27Q43 did work, as it does have both USART(1) and USART4, the 18F16Q41 certainly didn't. A change to the PPS for both devices to move USART3 and then defining a single instance of USART3 cured it. Instantly.
As I say, an odd combination of devices and serial port requirements which will probably never again be encountered, but it had me going for almost a week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am not sure I am seeing any issue. Have a look at this.
#chip 18F27Q43//#chip 18F16Q41 #scriptSER1_BAUD=9600CHIPSELECT=0IfCHIPNAME=18F27Q43ThenSER1_TXPORT=PORTCSER1_TXPIN=7SER1_RXPORT=PORTBSER1_RXPIN=0CHIPSELECT=CHIPSELECT+1USART_BAUD_RATE=9600USART_TX_BLOCKING=""USART_DELAY=OFFUSART4_BAUD_RATE=9600USART4_TX_BLOCKING=""USART4_DELAY=OFFEndIfIfCHIPNAME=18F16Q41Then' example for another chipSER1_TXPORT=PORTASER1_TXPIN=4SER1_RXPORT=PORTCSER1_RXPIN=5CHIPSELECT=CHIPSELECT+1USART_BAUD_RATE=9600USART_TX_BLOCKING=""USART_DELAY=OFFEndIfIfCHIPSELECT=0ThenError"No SoftSerial pins defined for this chip variant"EndIfIfCHIPSELECT>1ThenError"Mulitple SoftSerial defined - check script"EndIfIfCHIPSELECT=1ThenWarning"SER1_TXPORT = "SER1_TXPORTWarning"SER1_TXPIN = "SER1_TXPINWarning"SER1_RXPORT = "SER1_RXPORTWarning"SER1_RXPIN = "SER1_RXPINEndif#endscript#include <SoftSerial.h>Ser1Send13#IF CHIPNAME = 18F16Q41HserSend1,1#ENDIF#IF CHIPNAME = 18F27Q43HserSend1,1HserSend1,4#ENDIF
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have written a program that is almost 6,500 line long. [Gulp!] It has reached the point where it will soon be too large for the 18F16Q41 I'm using. It originally fitted into a 16F1829 but feature creep has stretched it. Mostly the menus and additional functions, along with text strings for the display(s).
I'm now considering using an 18F27Q43 with all of the 128K code space it offers. Initially I want to try to use the original PCB design, and socket. I have drawn an adaptor that will enable me to convert the 28 pin SSOP package to a 20 pin DIL, with the 5V, Gnd and programming pins aligned with those of the 1829/16Q41. This way I can (hopefully) prototype the program without having to go to the expense of redesigning the whole thing. It also means (if I code it right) that any improvements to the general code can be backported to the originals.
My sticking point is that port definitions are read regardless of conditional defines. I see that there is a new-ish command 'UnDefine' which overwrites any previous definitions. Can I use this in the way I am intending?
Here's my port definitions:
It certainly compiles when I declare Using16F18Q41 or with Using18F27Q43 (and the appropriate Chip definitions). When selecting the 16F18Q41 it compiles, programs and runs. As I don't have any 18F27Q43 nor have I ordered any adaptors yet, I just wanted to clarify that I'm on the right track here.
Check the CDF for the constants for each chip. The CDF file will show you the end state of the constants ( and lots more info ).
Looks good. You are using the capabilities as intended.
Can I recommend that we get you on the current Alpha build? This has true debugging and you can walk your code to if all is good.
Thanks for your reply. Pleased I understood (for once).
I'm not sure I'd be of much use regarding the debugging Alpha. Some days I struggle to write a single line of coherent code, never mind get it to compile and run!
Last edit: c-conversion 2026-01-22
The alpha is completed and you just press Ctrl-F5 to launch the debugger.
When you are ready = just asked.
Would this require an MpLab install for it's simulation 'engine'?
A simulator would be very helpful I can't deny.
No.
The 2026 GCSTUDIO comes with a complete environment. So, no need for MPLAB-X.
I will post a secret video soon.
I can't deny, I'm intrigued by the prospect of this. If I need to sign up for the 'Secret' video and (or) sign the Official Secrets Act, sign me up.
I will post a video tomorrow.
This journey has been a few years in the making. The pieces are now all there.
GCSTUDIO and GCCODE - the platform and IDE to deliver the capabilities
GCBASIC preprocessor and compiler as the foundation.
GCASM - as the core linker. PIC-AS and AVRASM2 integration as the key alternative liners.
GCDebugger at the way to delve into the details of the operations.
- the basic: a simulator
- the next level: the MPLAB-X debugger programmer
- the next level: PICKitXtra. A new paradigm. Debugging and programming without MPLAB-X.
See https://youtu.be/RD3by77L6fM?si=8JJ2DaxFTK5sLZU-
One word... Witchcraft. If I was to add a second word: Genius.
I was watching the video with my jaw totally dropped.
David Copperfield couldn't pull a better trick than that. I've no idea how it's done, but it's genius.
I'm sure there's more to learn such as how I could simulate button presses and or input, but my word, that's clever. Very clever indeed.
This magic is brilliant. Simulate... no... do it on the real hardware. :-)
We may be a a week or so to get a Beta release out. But, as you can see... it is stable.
Having opened this up again I have enabled the .CDF file as suggested.
An abbreviated form of the results from the compile with the chip set to 18F16Q41:
And the same section from the compile with the 18F27Q43 'declared':
So it does look as though the 'UnDefine' is doing it's magic, thanks. I often use different devices in my designs and using this will save me having differing versions of code for every version.
The 18F27Q43 and the adaptors should be with me before too long so I can assemble a few boards and chips and start thinking about how I am going to implement the changes.
Excellent use of the CDF.
I've run into a problem.
I need to 'swap' the port definitions for a softserial port.
If I do this:
It compiles and works.
If I do this:
The same code, just in a 'Define' query.
An error is thrown (well, two errors).
I took all the 'UnDefine statements out and pared it back to what caused the problems. With two definitions in, and the 'UnDefine statements it actually compiled and ran but there was no activity on the serial port. It took me a while to pick out the problem.
For the time being, I'll just alter the port definitions manually so not a huge problem, but I had expected it to work.
This may be the the time to use a script. :-) I would.
Scripts give a lot more flexibility and a lot less complex.
Script make and manage constants during the preprocessor phase of compilation. You are working with constants. Check the CDF to see the outcome.
I have added some checks ( warnings ) you can remove.
Evan
Many thanks for the suggestion. I was looking for guidance on scripts when I came across UnDefine. I do like the checks too, I'll make use of them.
I'm not going to have a chance to look again until after the weekend, and if next week is as busy as this, possibly not until mid February. Once I get the time, I'll report back.
The script worked very well, the soft serial is operating and (almost) all re-directed pins function as they should.
I say almost...
I have an unused pin, Pin 10, RB7 on the physical 18F16Q41 which on my SOIC 28pin - 20pin DIL adaptor for the 27Q43 is connected to Pin 9, RA7. I'm using this as a serial debug out to send information about various parameters within critical subroutines for debugging, this is then displayed on a remote 4 line LCD display. To make this work I'm using PPS to swap the serial out onto the correct pins. This fails to work for no great reason that I can see. I wonder if it is the sequence in which some items are declared or defined as initially it was the 27Q43 that failed. I made some changes realising that my comport was UARTTx4 and I needed to use HSerPrint "Print This",4 when I'd been using UARTTx1 which doesn't need the "Port" parameter. Re-writing the HSerPrint routines to use a constant that was altered in the script seemed to correct this. Re-compiling for the 16Q41 showed that it had stopped working. 'Eck!
I'm going to keep looking at this. I tried a load of things yesterday with no success. I could have one device working, but not the other. I must be missing something, but I've yet to spot it. When I look at the .asm it looks as though the correct PPS is working, it looks as though the correct comport parameter is being set, but it fails to work. It may be something unrelated to the comport, possibly one of my pullup settings, but it's not (yet) working.
Everything else runs normally, multiple serial signals are sent and received the display, button and lights all work, just the hardware serial out. Very irritating.
As much as I can gather, this was related to me using (hardware) USART 1 on the 18F16Q41 and USART 4 on the 18F27Q43.
Defining the USART_BAUD_RATE as 9600 caused no issues, but defining USART4_BAUD_RATE 9600 threw an error when compiling for the 16Q41. No doubt as it has no USART4. I'd moved these within a "IfDef" test which cleared the errors, but something must have been silently failing.
I tried placing the USART_BAUD_RATE declarations within the script but that didn't work.
Eventually I realised that on both devices I could place USARTTx3 onto the appropriate pin using PPS to use the same 'leg' of the chip or chip + adaptor. As this requires only one USART3_BAUD_RATE declaration, and both devices have a USART3 the problem is bypassed.
I doubt this experience will help many people. I don't suppose many people are attempting to use one version of code on multiple devices, least of all where those devices have different ports mapped to different physical pins. Still, another lesson learned the very hard way.
Last edit: c-conversion 4 days ago
Hard to say without the code/program.
Many people have mutliple configs is a program. So, this should work.
Last edit: Anobium 3 days ago
The only things I changed was to move both hardware serial outs onto USART3 which was the only available one that covered both 'legs' and ports that I needed. That single change allowed both devices to work.
Using USART(1) and USART4 in the same program failed with no indication that it would. I'm pretty sure that the 18F27Q43 did work, as it does have both USART(1) and USART4, the 18F16Q41 certainly didn't. A change to the PPS for both devices to move USART3 and then defining a single instance of USART3 cured it. Instantly.
As I say, an odd combination of devices and serial port requirements which will probably never again be encountered, but it had me going for almost a week.
I am not sure I am seeing any issue. Have a look at this.