With the global chip shortage, we're struggling to obtain my favourite 16F1829 devices. I had a look and it seemed as though the 18F15Q40 should be suitable as a replacement.
I've had my chips arrive today and compiled my program only changing the chip definition from 16F1829 to 18F15Q40.
Sadly things are not as simple as I thought. Are they ever?
The program only 'partly' works. The immediate problem is that the LCD is initialised as normal but is possibly not being set to 4 bit mode or the data values (text) is becoming corrupted when being sent to the LCD. Either way, the LCD show characters in the approximate locations, but they are all hieroglyphics. Secondly a countdown timer or loop doesn't flow correctly.
Recompile the program back for the 16F1829 and it works perfectly, timing (using looped delays) button presses and LCD work normally, on the 18F15Q40, parts of the program work, parts don't.
Have I missed something on the 18F15Q40 datasheet that is blindingly obvious (like the USB port on the 16F1459 that I had to move using PPS?) or something similar? Any clues would be welcome!
I've tried LCD_Speed Fast/Slow/Medium but that seems not to improve the operation.
If you still have the Binary/Hex calculator, it is connected using the same pin arrangement. Compiling the file for the 16F1829 works, for the 18F15Q40 gives a similar corrupted display?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've tried at 64, 8, 4 and 2MHz. I get no sensible display on either. At 2MHz the display could be seen updating, but no sensible characters were displayed.
Again, I tried the 1829 at 2MHz, no problem, 18F15Q40, incorrect LCD operation. Sorry.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hopefully fixed. There is change on these chips that was not apparent when the larger RAM chips were tested.
If the past only chip with greater than 4096 bytes of RAM required different movffl and lfsr instructions. It turns out that the Q40 and q41 have different movffl and lfsr instruction - so, the additional movffl and lfsr handler is required.
Please download and install the latest patch zip to resolve.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Download the zip,
unzip all files to a temp folder,
apply all files to your installation replacing all the existing files,
then, rename the compiler EXE for your operating system - you need to ensure either GCBASIC64.exe or GCBASIC32.exe is renamed as GCBASIC.exe
Enjoy
Using single files may make your installation unstable. Use all the patch files.
Many thanks, I really appreciate this. I hadn't expected you, or anyone, to immediately start work on the problem, I was just looking for some advice that I was (or wasn't) missing the obvious, which is usually the case, and what caused me problems when I last tried to use a different chip.
I don't work Fridays so have limited room for testing this at home, however, I've downloaded the patch, installed it and have compiled my Bin/Hex/Dec calculator code into an 18F15Q40 and it is displaying happily on the LCD, using LCD_IO_4.
This global chip shortage is starting to hit our products rather badly. As I've said before, my favourite chips are the 12F1840, 16F1825 and 16F1829. All of these are starting to show delivery dates well into 2023. We don't hold huge stocks of any of these (50 or so of each) preferring (normally) to order devices when we are asked to make a batch of PCBs. We've got an order for 25 PCBs which need two 12F1840 and one 16F1829, all listed as low/no stock or suppliers have doubled the usual cost price. I've been able to replace the 12F1840s with one 12F1571 and one 12F1572 and was (am?) hoping to use the 18F15Q40 instead of the 1629, they seemed pin compatible, had as much (if not more) program space and were faster - all at a lower price that the 16F1829. I presume that stocks of these might start to get tight too in the future. Then we'll be truly stuffed!
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was ok to fix yesterday. I had missed this rather technical change.
Everyone is having the same issue re chips. I have sold some of my test stock to help people. However, look on the Microchip site - they are pushing specific chips - these chips are the production focus and should have a better supply. They want everyone to focus on specific chips. This is the clean out that Microchip needed to do. Long live the old chips... only the new chips will survive.
Covid has created an end of life crisis for specific chips.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the global chip shortage, we're struggling to obtain my favourite 16F1829 devices. I had a look and it seemed as though the 18F15Q40 should be suitable as a replacement.
I've had my chips arrive today and compiled my program only changing the chip definition from 16F1829 to 18F15Q40.
Sadly things are not as simple as I thought. Are they ever?
The program only 'partly' works. The immediate problem is that the LCD is initialised as normal but is possibly not being set to 4 bit mode or the data values (text) is becoming corrupted when being sent to the LCD. Either way, the LCD show characters in the approximate locations, but they are all hieroglyphics. Secondly a countdown timer or loop doesn't flow correctly.
Recompile the program back for the 16F1829 and it works perfectly, timing (using looped delays) button presses and LCD work normally, on the 18F15Q40, parts of the program work, parts don't.
Have I missed something on the 18F15Q40 datasheet that is blindingly obvious (like the USB port on the 16F1459 that I had to move using PPS?) or something similar? Any clues would be welcome!
I've tried LCD_Speed Fast/Slow/Medium but that seems not to improve the operation.
Need more info.
Version of compiler? is this a stock install? what happens when freq is 32? what freq are you using? What else is in the code , interrupts?
Does this happen on a stock/clean install of lastest build? ie DAT files are correct.
Can you post an example program with just the LCD capabilities that reproduces the error?
I have completed extensive testing for Q40 but the info above is needed.
If you still have the Binary/Hex calculator, it is connected using the same pin arrangement. Compiling the file for the 16F1829 works, for the 18F15Q40 gives a similar corrupted display?
This is my compiler: Great Cow BASIC (0.99.01 2022-01-27 (Windows 64 bit) : Build 1073)
And I'm reasonably sure I did a stock install and update only a week or two back?
What about the freq? try ,32
I always have the frequency set to 32MHz.
I've tried at 64, 8, 4 and 2MHz. I get no sensible display on either. At 2MHz the display could be seen updating, but no sensible characters were displayed.
Again, I tried the 1829 at 2MHz, no problem, 18F15Q40, incorrect LCD operation. Sorry.
The HEX calc works on the LCDDEMO code.
It does not work with your HEX Calculator code.
So, what is in your code..... I am looking
WRONG - My statements above are wrong - I was testing with an incorrect assumption
The issue is in the chip .dat file. I am not sure what it is yet but there is an issue.
If you compile for a 16Fq40 and program to a 15q40 I believe it will work. So, does NSPROG permit oversized hexs to be loaded? PK+ does.
My guess. Is the memory map is incorrect hence the Pacman works sometimes....
Last edit: Anobium 2022-02-17
As I said there is an error in the DAT file. I am trying to resolve.
Guys - I need help. Someone else needs to pick up some this stuff.
Hopefully fixed. There is change on these chips that was not apparent when the larger RAM chips were tested.
If the past only chip with greater than 4096 bytes of RAM required different movffl and lfsr instructions. It turns out that the Q40 and q41 have different movffl and lfsr instruction - so, the additional movffl and lfsr handler is required.
Please download and install the latest patch zip to resolve.
See https://sourceforge.net/projects/gcbasic/files/Release%20Candidates/Patches/
To install these patches:
Download the zip,
unzip all files to a temp folder,
apply all files to your installation replacing all the existing files,
then, rename the compiler EXE for your operating system - you need to ensure either GCBASIC64.exe or GCBASIC32.exe is renamed as GCBASIC.exe
Enjoy
Using single files may make your installation unstable. Use all the patch files.
See https://1drv.ms/x/s!Ase-PX_n_4cvhJAysbPF3VJAnYaj3A for changelog.
Please see here https://sourceforge.net/p/gcbasic/discussion/579126/thread/0d009b1785/ to see the Software Bill of Materials (SBOM) to meet the US.gov Executive Order May 2021 requirement.
Many thanks, I really appreciate this. I hadn't expected you, or anyone, to immediately start work on the problem, I was just looking for some advice that I was (or wasn't) missing the obvious, which is usually the case, and what caused me problems when I last tried to use a different chip.
I don't work Fridays so have limited room for testing this at home, however, I've downloaded the patch, installed it and have compiled my Bin/Hex/Dec calculator code into an 18F15Q40 and it is displaying happily on the LCD, using LCD_IO_4.
This global chip shortage is starting to hit our products rather badly. As I've said before, my favourite chips are the 12F1840, 16F1825 and 16F1829. All of these are starting to show delivery dates well into 2023. We don't hold huge stocks of any of these (50 or so of each) preferring (normally) to order devices when we are asked to make a batch of PCBs. We've got an order for 25 PCBs which need two 12F1840 and one 16F1829, all listed as low/no stock or suppliers have doubled the usual cost price. I've been able to replace the 12F1840s with one 12F1571 and one 12F1572 and was (am?) hoping to use the 18F15Q40 instead of the 1629, they seemed pin compatible, had as much (if not more) program space and were faster - all at a lower price that the 16F1829. I presume that stocks of these might start to get tight too in the future. Then we'll be truly stuffed!
Thanks again.
I was ok to fix yesterday. I had missed this rather technical change.
Everyone is having the same issue re chips. I have sold some of my test stock to help people. However, look on the Microchip site - they are pushing specific chips - these chips are the production focus and should have a better supply. They want everyone to focus on specific chips. This is the clean out that Microchip needed to do. Long live the old chips... only the new chips will survive.
Covid has created an end of life crisis for specific chips.