Hello.
I've written a program that uses a 16F1829 and an LCD character display to create a simple oscilloscope, or enhanced logic probe depending on your point of view.
I saw that the 16F1459 had a very similar pin arrangement to the 1829 but runs at 48Mhz rather than 32Mhz. Thinking I could take advantage of the improved speed, I ordered five 1459 chips. They arrived today and I changed my chip definition from:
'#Chip 16F1829, 32
to:
'#Chip 16F1459, 48
and re-compiled. I had no errors on compilation so programmed the 1459, plugged it into my breadboard circuit expecting to see everything running half as fast again, but not quite.
The LCD running in LCD_IO 8, with the data port set to PortC, never initialises. Thinking this was due to ICSPDAT/CLK pins on PortC.0 and C.1 I tried using LCD_IO 4, using PortC.4 to PortC.7. Still no LCD display. To check if I'd made a mistake in my LCD_IO 4 wiring, I compiled the 1829 version with the LCD set up as a 4 line data bus and it worked perfectly. Hmmm.
Am I missing something obvious here? I know the programming ICSPDAT and ICSPCLK are on different pins, I know that pin 17 on the 1459 is the USB+3V3 connection but I'm not using pin 17 anyway.
I am also slightly confused by the speed of the 1459. I have PortB.5 set as an input and PortB.6 an output. I test the data capture of the 'scope by coupling the input to output which causes it to generate a square wave. With the 1829 version running at 32Mhz I get a square wave of 50Khz, the 1459 version running at 48Mhz gives a square wave of 25khz (I'd expected 75Khz) at 32Mhz, 12Khz, 16Mhz 25Khz (again), 8Mhz 12Khz (again) and 4Mhz 7Khz. The 1829 at 16Mhz does give the expected half of 50Khz, 25Khz, with 8Mhz 12Khz, again as I'd expect. Not sure if that is anything to do with why the LCD won't start-up, but the two 'Wait 5000 mS' pauses whilst the start-up screen should be displayed on the 1829 version seem to be 'inconsistent' too. With the:
'#Chip 16F1459, 48
definition, the two 5000 mS pauses (Waits) take at least 20 seconds, at 32Mhz this takes 30 seconds, at 16Mhz it takes the expected 10 seconds.
All suggestions gratefully accepted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I opened up the 16F1459.dat file and found the the IntOsc section only had entries for values of 16 (Mhz) and below. Manually adding the 48 and 32 entries has allowed me to get consistent speed results. Running the 1459 at 48Mhz now causes the square wave to be generated at the expected 75Khz, and 32Mhz gives a 50Khz square wave, matching the 16F1829 as I'd anticipated.
The LCD won't initialise though and I can't see why that should be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried using PortA (in 4 wire mode) but still failed to get the LCD to initialise.
I then tried to re-initialise the LCD, sending the data again but much slower than in the LCD.h, that didn't work either.
I can drop the 16F1829 into the breadboard and the LCD works perfectly (using PortC for D0-D7 and PortA.0, PortA.1 for RS and EN) and it works perfectly, use the same setup for the 16F1459, no LCD.
I'm sure I'm missing something obvious here, but can't see what that might be. As I have everything working on the 1829, I'll stick with it for the time being, but I'd like to know why the 1459 doesn't work.
If anyone else has the 16F1459 working with a 4 wire/8 wire LCD display, can you let me in on the secret?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just a curveball, how are you programming the PIC and running the code?
I had a similar problem which occurred when using a PICkit3 over ISCP and disconnecting the programmer from the circuit. Leaving the programmer connected solved it, as did pulldown resistors on the ISCP pins: https://sourceforge.net/p/gcbasic/discussion/579126/thread/646e9113/?limit=25#3076
There was another issue in the LCD driver related to timing, but this was resolved at the time. I'm not sure if there's a similar, specific issue which affects your PIC.
If you are using 4 wire LCD, have you tied the unused pins to ground?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your suggestions. I've been programming both 16F1829 and 16F1459 chips using a (clone) PicKit3, using ISCP. The PicKit has a ZIF socket adapter which I use for the 1829, as the pin configuration of this didn't match the 1459 I made a breadboard adapter for it insted of the ZIF socket.
I don't have any pullup resistors in the circuit, it's true, but as they aren't needed for the 1829, I (possibly wrongly) assumed they wouldn't be needed for the 1459 either. It didn't cross my mind that they might be required for four wire mode to work. I did try the 1829 in four wire mode, using the same pin designations as the 1459 (that didn't work) though I simply re-compiled for four wire operation, and plugged it back into the breadboard with the unused four data pins still wired to the PIC as for eight wire mode. This worked (again) for the 1829, but not (again) for the 1459.
The simplest LCD test program for the 1459 just failed to work, no matter how I tried. Sadly I gave up.
This works for the 16F1829, not for the 16F1459. The reason for the Signal and Status_LED potion of the program serves partly to prove that the chip is doing something and partly to allow me to measure the speed. With the speed initially being incorrect (as I mentioned in my second post) I wondered if that was my issue so included the Signal/Status_LED as a convenient way of attaching a simple scope to the Status_LED to measure how quickly it toggles on and off at various processor frequencies.
Last edit: mkstevo 2016-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I fired up a 16f1455, same family as 16f1459, and LCD works just fine in 4 bit mode and no R/W (wired to gnd). What is happening here is gcb assumes that a crystal (OSC=HS) when Mhz is specified greater than the inbuilt max INTOSC speed. So when the Mhz is more than 16, then the INTOSC must be configured explicitly, along with enabling the PLL.
So no problem up to 16Mhz speed with the intosc. If you cannot get anything then the wiring is wrong ,R/W is not grounded, the contrast pot is not set properly, or the device is duff? The OSCCON register bits look good in the .asm output. Here is code that works fine with 48Mhz using the HFINTOSC:
#Chip 16F1455, 48
'must be explicit when INTOSC > 16 and uses PLL
#config OSC=INTOSC, PLLEN=On
'*****setup 4bit LCD*****
#define LCD_IO 4
'be sure to gnd R/W pin
#define LCD_NO_RW
#define LCD_DB4 PORTC.2
#define LCD_DB5 PORTC.3
#define LCD_DB6 PORTC.4
#define LCD_DB7 PORTC.5
#define LCD_RS PORTC.1
'#define LCD_RW PORTA.4
#define LCD_Enable PORTA.5
#define led PortA.4
Do
CLS
Print "Hello"
Set led On
wait 1 s
Set led Off
wait 1 s
Loop
Last edit: kent_twt4 2016-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many, many thanks, I really appreciate your kindness in looking into this on my behalf.
As you probably saw, I had noticed that the speed of the 16F1459 was incorrect, and had modified the chip data file for the 1459 to include the 48 and 32Mhz frequencies which had corrected the operational frequencies. I have not tried including the OSC=INTOCSC or PLLEN=On declarations in my source. I'll try that later this week and report back. I had tried running the 1459 at frequencies of 48, 32, 16, 8 and 4Mhz none of which had worked for initialising the LCD.
Being relatively new to the world of PICs, I probably (certainly?) don't understand the importance or relevance of the #Config commands. As I have not yet required to use the OSC or PLLEN statements in the programs I've written for the 16F1829/1825 I've never given them any consideration so far and they simply weren't on my horizon.
I'm reasonably confident that the wiring for the LCD R/W and contrast are correct as I am taking the working 16F1829 out of the breadboard, and putting in the 16F1459 in, which fails to work.
As I said, I am most grateful for your assistance and suggestions, and will give your program a try once I have some time during the evening this week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had spotted that RA0 and RA1 were listed as being for the D-/D+ USB, and had (at least at one point) tried using RA4/RA5 instead. There is the possibility that I tried that before realising the speed was wrong, and reverted back to RA0/RA1 after correcting the speed in the chip .Dat file.
I hadn't spotted that RA0 and RA1 were inputs only, whilst I'd checked the data sheet momentarily, that nugget of information had passed me by.
Having tried again with:
#Chip16F1455,48'must be explicit when INTOSC > 16 and uses PLL#configOSC=INTOSC,PLLEN=On
and using RA4 and RA5 for RS and EN, I still had no success. The LCD did appear to initialise (I got a 'clear' screen rather than the top row showing a line of blocks) but nothing printed.
I'd like to thank all the kind replies, I'm sure I've missed something else that shows my further stupidity (as with RA0 and RA1 being input only) but I don't want to waste your time any more and I shall draw a line underneath it until I have a few hours to while away.
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Huh, I would take Anobium up on his offer to test the 16f1459, I am out of ideas. He apparently has a teleportation device that is hooked up directly to Microchip Direct :-)
For instance a PIC18f14k22 and other parts can go up to 64Mhz with the internal osc. Or if the internal adc speed is a factor than check out 200ksps 18fxx31 series, or even 500ksps 18f65j94 and up series.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks, I'll take a look at that once my head cools down after today's heavy thinking. At the moment I'm not using the ADC, for my 'scope project I don't need it as it is perhaps less a 'scope and more an uprated logic probe. I do have in mind a project that does require some fast ADC, storing it to some sort of memory device for playback later, at a much slower speed. If I can get my 'scope sorted, it is about two projects down the line...
Last edit: mkstevo 2016-09-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yet again, thanks for everyone's patience and understanding.
I have at last managed to get the LCD display working. I think it was a combination of the Config bits for OSC=INTOSC and PLLEN=On that allowed the LCD to work as it should, along with the corrected error of attempting to use RA.0 and RA.1 as outputs, when as kindly pointed out, they are inputs only on the 1459.
The reason for it not working immediately once I'd corrected those errors was twofold. Firstly, I'd added the #Chip 16F1459, 48 declaration, along with the #Config bits and the redirected RS/EN declarations for RA.5 and RA.4 but I'd encased them within a #IfDef ... #EndIf block to allow me to be able to define use of either the 1829 or 1459, using the same code. It took me a while to realise that compiler directives such as #Chip, #Config and #Define can't be placed within a conditional define block. My second error was that immediately following my initialisation code, before any further processing, I call a subroutine that writes the version number and other data into Eeprom, using EpWrite. This caused the processor to crash or freeze when using the 1459 as it has no Eeprom, instead having High Endurance Flash.
So again, a lot of my headache and confusion was self inflicted. Had I attempted to add the correct #Config bits and the adjusted RS/EN declarations to my simple test program above, rather than into my (admittedly working on the 1829) complete program I might have made progress quicker.
I'm genuinely grateful for all the help that I've had, I really appreciate it. Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello.
I've written a program that uses a 16F1829 and an LCD character display to create a simple oscilloscope, or enhanced logic probe depending on your point of view.
I saw that the 16F1459 had a very similar pin arrangement to the 1829 but runs at 48Mhz rather than 32Mhz. Thinking I could take advantage of the improved speed, I ordered five 1459 chips. They arrived today and I changed my chip definition from:
'#Chip 16F1829, 32
to:
'#Chip 16F1459, 48
and re-compiled. I had no errors on compilation so programmed the 1459, plugged it into my breadboard circuit expecting to see everything running half as fast again, but not quite.
The LCD running in LCD_IO 8, with the data port set to PortC, never initialises. Thinking this was due to ICSPDAT/CLK pins on PortC.0 and C.1 I tried using LCD_IO 4, using PortC.4 to PortC.7. Still no LCD display. To check if I'd made a mistake in my LCD_IO 4 wiring, I compiled the 1829 version with the LCD set up as a 4 line data bus and it worked perfectly. Hmmm.
Am I missing something obvious here? I know the programming ICSPDAT and ICSPCLK are on different pins, I know that pin 17 on the 1459 is the USB+3V3 connection but I'm not using pin 17 anyway.
I am also slightly confused by the speed of the 1459. I have PortB.5 set as an input and PortB.6 an output. I test the data capture of the 'scope by coupling the input to output which causes it to generate a square wave. With the 1829 version running at 32Mhz I get a square wave of 50Khz, the 1459 version running at 48Mhz gives a square wave of 25khz (I'd expected 75Khz) at 32Mhz, 12Khz, 16Mhz 25Khz (again), 8Mhz 12Khz (again) and 4Mhz 7Khz. The 1829 at 16Mhz does give the expected half of 50Khz, 25Khz, with 8Mhz 12Khz, again as I'd expect. Not sure if that is anything to do with why the LCD won't start-up, but the two 'Wait 5000 mS' pauses whilst the start-up screen should be displayed on the 1829 version seem to be 'inconsistent' too. With the:
'#Chip 16F1459, 48
definition, the two 5000 mS pauses (Waits) take at least 20 seconds, at 32Mhz this takes 30 seconds, at 16Mhz it takes the expected 10 seconds.
All suggestions gratefully accepted.
One problem solved.
I opened up the 16F1459.dat file and found the the IntOsc section only had entries for values of 16 (Mhz) and below. Manually adding the 48 and 32 entries has allowed me to get consistent speed results. Running the 1459 at 48Mhz now causes the square wave to be generated at the expected 75Khz, and 32Mhz gives a 50Khz square wave, matching the 16F1829 as I'd anticipated.
The LCD won't initialise though and I can't see why that should be.
A good workaround.
We will resolve at source as the 16f11459 and its family of chips and then include in the next release.
I tried using PortA (in 4 wire mode) but still failed to get the LCD to initialise.
I then tried to re-initialise the LCD, sending the data again but much slower than in the LCD.h, that didn't work either.
I can drop the 16F1829 into the breadboard and the LCD works perfectly (using PortC for D0-D7 and PortA.0, PortA.1 for RS and EN) and it works perfectly, use the same setup for the 16F1459, no LCD.
I'm sure I'm missing something obvious here, but can't see what that might be. As I have everything working on the 1829, I'll stick with it for the time being, but I'd like to know why the 1459 doesn't work.
If anyone else has the 16F1459 working with a 4 wire/8 wire LCD display, can you let me in on the secret?
Just a curveball, how are you programming the PIC and running the code?
I had a similar problem which occurred when using a PICkit3 over ISCP and disconnecting the programmer from the circuit. Leaving the programmer connected solved it, as did pulldown resistors on the ISCP pins:
https://sourceforge.net/p/gcbasic/discussion/579126/thread/646e9113/?limit=25#3076
There was another issue in the LCD driver related to timing, but this was resolved at the time. I'm not sure if there's a similar, specific issue which affects your PIC.
If you are using 4 wire LCD, have you tied the unused pins to ground?
Thanks for your suggestions. I've been programming both 16F1829 and 16F1459 chips using a (clone) PicKit3, using ISCP. The PicKit has a ZIF socket adapter which I use for the 1829, as the pin configuration of this didn't match the 1459 I made a breadboard adapter for it insted of the ZIF socket.
I don't have any pullup resistors in the circuit, it's true, but as they aren't needed for the 1829, I (possibly wrongly) assumed they wouldn't be needed for the 1459 either. It didn't cross my mind that they might be required for four wire mode to work. I did try the 1829 in four wire mode, using the same pin designations as the 1459 (that didn't work) though I simply re-compiled for four wire operation, and plugged it back into the breadboard with the unused four data pins still wired to the PIC as for eight wire mode. This worked (again) for the 1829, but not (again) for the 1459.
The simplest LCD test program for the 1459 just failed to work, no matter how I tried. Sadly I gave up.
This works for the 16F1829, not for the 16F1459. The reason for the Signal and Status_LED potion of the program serves partly to prove that the chip is doing something and partly to allow me to measure the speed. With the speed initially being incorrect (as I mentioned in my second post) I wondered if that was my issue so included the Signal/Status_LED as a convenient way of attaching a simple scope to the Status_LED to measure how quickly it toggles on and off at various processor frequencies.
Last edit: mkstevo 2016-09-15
I fired up a 16f1455, same family as 16f1459, and LCD works just fine in 4 bit mode and no R/W (wired to gnd). What is happening here is gcb assumes that a crystal (OSC=HS) when Mhz is specified greater than the inbuilt max INTOSC speed. So when the Mhz is more than 16, then the INTOSC must be configured explicitly, along with enabling the PLL.
So no problem up to 16Mhz speed with the intosc. If you cannot get anything then the wiring is wrong ,R/W is not grounded, the contrast pot is not set properly, or the device is duff? The OSCCON register bits look good in the .asm output. Here is code that works fine with 48Mhz using the HFINTOSC:
Last edit: kent_twt4 2016-09-15
Many, many thanks, I really appreciate your kindness in looking into this on my behalf.
As you probably saw, I had noticed that the speed of the 16F1459 was incorrect, and had modified the chip data file for the 1459 to include the 48 and 32Mhz frequencies which had corrected the operational frequencies. I have not tried including the OSC=INTOCSC or PLLEN=On declarations in my source. I'll try that later this week and report back. I had tried running the 1459 at frequencies of 48, 32, 16, 8 and 4Mhz none of which had worked for initialising the LCD.
Being relatively new to the world of PICs, I probably (certainly?) don't understand the importance or relevance of the #Config commands. As I have not yet required to use the OSC or PLLEN statements in the programs I've written for the 16F1829/1825 I've never given them any consideration so far and they simply weren't on my horizon.
I'm reasonably confident that the wiring for the LCD R/W and contrast are correct as I am taking the working 16F1829 out of the breadboard, and putting in the 16F1459 in, which fails to work.
As I said, I am most grateful for your assistance and suggestions, and will give your program a try once I have some time during the evening this week.
I can get one of these chips. Validate here etc. I will take a day or two. Your call if you want me to.
RA0, and RA1 (i.e. D+, D-) are input only per the data sheet. I avoided these pins in my code, not knowing what the USB pins held in store for me.
I had spotted that RA0 and RA1 were listed as being for the D-/D+ USB, and had (at least at one point) tried using RA4/RA5 instead. There is the possibility that I tried that before realising the speed was wrong, and reverted back to RA0/RA1 after correcting the speed in the chip .Dat file.
I hadn't spotted that RA0 and RA1 were inputs only, whilst I'd checked the data sheet momentarily, that nugget of information had passed me by.
Having tried again with:
and using RA4 and RA5 for RS and EN, I still had no success. The LCD did appear to initialise (I got a 'clear' screen rather than the top row showing a line of blocks) but nothing printed.
I'd like to thank all the kind replies, I'm sure I've missed something else that shows my further stupidity (as with RA0 and RA1 being input only) but I don't want to waste your time any more and I shall draw a line underneath it until I have a few hours to while away.
Thanks again.
Huh, I would take Anobium up on his offer to test the 16f1459, I am out of ideas. He apparently has a teleportation device that is hooked up directly to Microchip Direct :-)
FYI, here is the PIC part selector if you are not familar with it http://www.microchip.com/maps/microcontroller.aspx
For instance a PIC18f14k22 and other parts can go up to 64Mhz with the internal osc. Or if the internal adc speed is a factor than check out 200ksps 18fxx31 series, or even 500ksps 18f65j94 and up series.
Thanks, I'll take a look at that once my head cools down after today's heavy thinking. At the moment I'm not using the ADC, for my 'scope project I don't need it as it is perhaps less a 'scope and more an uprated logic probe. I do have in mind a project that does require some fast ADC, storing it to some sort of memory device for playback later, at a much slower speed. If I can get my 'scope sorted, it is about two projects down the line...
Last edit: mkstevo 2016-09-20
Yet again, thanks for everyone's patience and understanding.
I have at last managed to get the LCD display working. I think it was a combination of the Config bits for OSC=INTOSC and PLLEN=On that allowed the LCD to work as it should, along with the corrected error of attempting to use RA.0 and RA.1 as outputs, when as kindly pointed out, they are inputs only on the 1459.
The reason for it not working immediately once I'd corrected those errors was twofold. Firstly, I'd added the #Chip 16F1459, 48 declaration, along with the #Config bits and the redirected RS/EN declarations for RA.5 and RA.4 but I'd encased them within a #IfDef ... #EndIf block to allow me to be able to define use of either the 1829 or 1459, using the same code. It took me a while to realise that compiler directives such as #Chip, #Config and #Define can't be placed within a conditional define block. My second error was that immediately following my initialisation code, before any further processing, I call a subroutine that writes the version number and other data into Eeprom, using EpWrite. This caused the processor to crash or freeze when using the 1459 as it has no Eeprom, instead having High Endurance Flash.
So again, a lot of my headache and confusion was self inflicted. Had I attempted to add the correct #Config bits and the adjusted RS/EN declarations to my simple test program above, rather than into my (admittedly working on the 1829) complete program I might have made progress quicker.
I'm genuinely grateful for all the help that I've had, I really appreciate it. Thanks.