I don't know.
I just tried it and it printed "ok" the first time but the second time I built and programmed it printed garbage, then I built and programmed again and got "ok". It keeps alternating with working and not working on every build.
But I never got 0.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I may have finally reproduced your garbage characters issue.
Every OTHER time I program it, the display is garbage but if I cycle power on the PIC then it works.
Removing and reattaching your PICkit 3 may be cycling the power.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, since I've been all over the place on different issues, I don't know which one the code run was for. Was it trying to write to a string with the MID command??
Something I came across when more and more of my variables were starting to act and fail compiling is I was using to many variables (I created a lot for testing sections) and when I reduced said variables then the weird errors stopped and strings started working again, well all but writing to a MID statement as in: Dim TmpString as String
TmpString=" " '-4_space_holders
Mid(TmpString,1)="A"
what I think is being said doesn't work that way. and only as TmpString=Mid(String,num)
Please correct if I got it wrong, and wonder if the creators would consider this command to write to then their update(s)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is crazy....
As you might remember I said I had re-built another breadboard with the same issue. After sending your code to the PIC with the PICkit3 On, I have the results .. Turn it on, wait a few seconds. then turn it Off for a few seconds.
Out of the dozen tries, it show the "hello", then a second later "Test" then roughly 250ms later garbage.And at times, didn't even get to "TEST" before garbage. all 12 times, then removed PICkit3 and did it a dozen times and no garbage...
I have even went from 10k (from MCLR) down to 4.7k as suggested in the PICkit3 Docs... Guess I'll try Isolating the LCD further away (Off) the breadboard. And see if that changes things. or go thru a variation of resistors on LCD
Thanks for the Input.
Vic
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In GCBASIC, strings are just arrays that get some special treatment. It's possible to set the first character like this:
TmpString(1)="A"
As for the weird LCD behaviour, I'd be interested to know if anyone works out what's happening - I've been seeing this sort of behaviour for years! With a 16F877A (with 20 MHz crystal) on a breadboard, an LCD and a PICkit 2, the program won't run after I've downloaded it unless I unplug the PICkit 2, or toggle the MCLR line in the PICkit 2 GUI. The same thing is happening here with a KS0108 graphical LCD, and I've observed it with 44780 based displays too. The problem seems specific to the 16F877A, I just replaced the '877A with an 18F4620 and it works fine. If anyone is feeling particularly curious, maybe an oscilloscope or logic probe on the Vcc and MCLR lines would reveal something?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've seen similar results recently with a PIC16F886 but intermittent.
I also found reset of the MCLR pin didn't reset the LCD (even thought I had external MCLR enabled). I had to cycle power. But once the part was programmed, I could power it up and down multiple times without issue.
Then I realized that the LCD is tied to the same power line as the PIC. While programming, the LCD also boots up and may get corrupted data on the floating data lines. Cycling power resets both the LCD and the PIC.
I've seen that some development boards, like theMicrochip PICDEM2 Plus, power the LCD through a transistor. An I/O pin must drive the transistor to power the LCD. This allows the LCD to be reset by the PIC. I wonder if this is why such circuitry is required?
There may be a difference in how the data looks on the I/O of the 18F vs the 16F877a. This could be why the 877A produces it more often. The 886 is an upgrade to the 876a/877a family so they may share the same I/O issue during programming.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thank you -- THANK YOU..
I was believing I was somehow causing this issue.
Bitter-sweet moment, to know it isn't just my circuit, but that an issue with the 16F8xx's
is the major cause. And it's great to know that these good people here want to help.
AND a big thanks to all that offer help on anyone's problems.
Until I find a solution (short of building a time delay circuit for MCLR) I am using this configuration. I have put a switch in (some could use a pair of pins and jumper to program the PIC) and when the contacts are closed, you can program the 16F8xx with no probs.
Power Off PIC, remove jumper/Toggle Switch Off. Powerup the PIC. I have found in my experiments that you can still cycle the power and then open the switch or jumpers and it will START from the beginning of your code then.
If the switch or jumper is still closed, the program will not run until they are opened. I am using the R/W to a Port pin and not to ground as used with the '#define LCD_NO_RW. (Since I acquired 10+ 16F877s I needed some type of work around.)
What I settled on is using is a mini DPDT (Double Pole, Double Throw) switch with a center off. (that I am selling elsewhere, but I won't advertize that here). you can contact me for further info. I have attached a pic of how I used the switch. Instantly slide the switch and go..
And again Thanks to all, and If anyone find a better solution, please Post!
vic
The link> www.microchip.com/forums/m48207-print.aspx
Stalled on loading page for a few minutes, (maybe they were doing Maintenance..) but did find it and posted, as link below..
I recently used a display that got confused by the LCDReady routine in lcd.h only reading the first nibble of the byte to check the busy flag. Modifying LCDReady to read both nibbles stopped it from displaying garbage. Here is the version of lcd.h if you want to give it a try. I'll attach the whole thing as it has various changes that didn't solve the immediate problem but didn't do any harm.
You might also try a pull down resistor on the LCD Enable pin to stop it floating while the PIC is Reset if that hasn't been suggested already.
I am driving the power via the prototyping board not the PICKIT3.
The LCD is stable when programming and power on and off 5v.
I get garbage ever other time when pressing MCLR (yes, every other time of pressing MCLR). The garbage is high speed characters wizzing by on the top line of the LCD. Is this the experience you had/have?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This LCD.h file is intended to fix the LCD 4 bit init sequence, it also includes some
new commands
- LCDHOME - send cursor home
- LCDSPACE ( number of space ) - move cursor number of spaces
- LCDCreateGraph - create a Graph character in CGRAM
- LCDCursor - control cursor and display. ON, FLASH or OFF, FLASHON, LCDOFF
Please let me know the results.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First I verified that the issue was still present. Every other program load created junk characters.
Then I went to GCB@SYN>Great Cow Basic>include>low level folder and renamed lcd.h to lcd1.h.
Then downloaded your lcd.h into this same location.
I cannot get it to fail so its working great.
What was the issue?
Will you have details on the new commands?
How about some sample code?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you. That's what I needed, some validation. The core issue was garbage on reset or garbage after programming.
Lets check. Where you using 4bit LCD? I hope so.
Regarding the new\revised commands. I will post a new help file in a day or two. I will also update the online help as this is the easiest for everyone to use.
Thank you for your time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, 4 bit mode.
I drove a DFRobot LCD shield from a PIC16F886 CHIPINO module.
The code can be seen at my site GreatCowBasic.com on the sample projects page.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a follow up. I ran into another problem with the lcd driver. I was unable to get the code to work about 16mhz.
Then, I remembered the Read/Write/Modify feature of the later chips. I was using a 16f1847.
So, I have another lcd.h that now supports LATx port driving at 32mhz and all is ok. I have retained backwards compatibility but if you want to drive at higher clock speeds then you will required the latest lcd.h.
Again, looking for a few testers before I upload into Sourceforge.
The new command is simple. #define LCD_LAT. You define your port as LATx but for DIRection support your also need to define the PORTx also. Why? LCD.h support multiple use of the port so port switching was supported - it still is.
I don't know.
I just tried it and it printed "ok" the first time but the second time I built and programmed it printed garbage, then I built and programmed again and got "ok". It keeps alternating with working and not working on every build.
But I never got 0.
I may have finally reproduced your garbage characters issue.
Every OTHER time I program it, the display is garbage but if I cycle power on the PIC then it works.
Removing and reattaching your PICkit 3 may be cycling the power.
This works if I cycle power every time. (Assume all the LCD setup is included)
I get:
Hello
test
Morning. Off skiing in a moment.
But, I did check the base code for 4 bit LCD. It all looks ok. Not much help telling you this but I did check the code. :-(
And, I just ran up the code in LCD 4 bit in the simulator. All looks ok. :-(
Last edit: Anobium 2014-03-08
Sorry, since I've been all over the place on different issues, I don't know which one the code run was for. Was it trying to write to a string with the MID command??
Something I came across when more and more of my variables were starting to act and fail compiling is I was using to many variables (I created a lot for testing sections) and when I reduced said variables then the weird errors stopped and strings started working again, well all but writing to a MID statement as in:
Dim TmpString as String
TmpString=" " '-4_space_holders
Mid(TmpString,1)="A"
what I think is being said doesn't work that way. and only as
TmpString=Mid(String,num)
Please correct if I got it wrong, and wonder if the creators would consider this command to write to then their update(s)
This is crazy....
As you might remember I said I had re-built another breadboard with the same issue. After sending your code to the PIC with the PICkit3 On, I have the results .. Turn it on, wait a few seconds. then turn it Off for a few seconds.
Out of the dozen tries, it show the "hello", then a second later "Test" then roughly 250ms later garbage.And at times, didn't even get to "TEST" before garbage. all 12 times, then removed PICkit3 and did it a dozen times and no garbage...
I have even went from 10k (from MCLR) down to 4.7k as suggested in the PICkit3 Docs... Guess I'll try Isolating the LCD further away (Off) the breadboard. And see if that changes things. or go thru a variation of resistors on LCD
Thanks for the Input.
Vic
In GCBASIC, strings are just arrays that get some special treatment. It's possible to set the first character like this:
TmpString(1)="A"
As for the weird LCD behaviour, I'd be interested to know if anyone works out what's happening - I've been seeing this sort of behaviour for years! With a 16F877A (with 20 MHz crystal) on a breadboard, an LCD and a PICkit 2, the program won't run after I've downloaded it unless I unplug the PICkit 2, or toggle the MCLR line in the PICkit 2 GUI. The same thing is happening here with a KS0108 graphical LCD, and I've observed it with 44780 based displays too. The problem seems specific to the 16F877A, I just replaced the '877A with an 18F4620 and it works fine. If anyone is feeling particularly curious, maybe an oscilloscope or logic probe on the Vcc and MCLR lines would reveal something?
I've seen similar results recently with a PIC16F886 but intermittent.
I also found reset of the MCLR pin didn't reset the LCD (even thought I had external MCLR enabled). I had to cycle power. But once the part was programmed, I could power it up and down multiple times without issue.
Then I realized that the LCD is tied to the same power line as the PIC. While programming, the LCD also boots up and may get corrupted data on the floating data lines. Cycling power resets both the LCD and the PIC.
I've seen that some development boards, like theMicrochip PICDEM2 Plus, power the LCD through a transistor. An I/O pin must drive the transistor to power the LCD. This allows the LCD to be reset by the PIC. I wonder if this is why such circuitry is required?
There may be a difference in how the data looks on the I/O of the 18F vs the 16F877a. This could be why the 877A produces it more often. The 886 is an upgrade to the 876a/877a family so they may share the same I/O issue during programming.
thank you -- THANK YOU..
I was believing I was somehow causing this issue.
Bitter-sweet moment, to know it isn't just my circuit, but that an issue with the 16F8xx's
is the major cause. And it's great to know that these good people here want to help.
AND a big thanks to all that offer help on anyone's problems.
Until I find a solution (short of building a time delay circuit for MCLR) I am using this configuration. I have put a switch in (some could use a pair of pins and jumper to program the PIC) and when the contacts are closed, you can program the 16F8xx with no probs.
Power Off PIC, remove jumper/Toggle Switch Off. Powerup the PIC. I have found in my experiments that you can still cycle the power and then open the switch or jumpers and it will START from the beginning of your code then.
If the switch or jumper is still closed, the program will not run until they are opened. I am using the R/W to a Port pin and not to ground as used with the '#define LCD_NO_RW. (Since I acquired 10+ 16F877s I needed some type of work around.)
What I settled on is using is a mini DPDT (Double Pole, Double Throw) switch with a center off. (that I am selling elsewhere, but I won't advertize that here). you can contact me for further info. I have attached a pic of how I used the switch. Instantly slide the switch and go..
And again Thanks to all, and If anyone find a better solution, please Post!
vic
Ok, gotcha on the TmpString(1)="A"
that worked great.. thanks
vic
Any help? http://www.microchip.com/forums/m48207.aspx
Last edit: Anobium 2014-03-13
The link> www.microchip.com/forums/m48207-print.aspx
Stalled on loading page for a few minutes, (maybe they were doing Maintenance..) but did find it and posted, as link below..
Thanks, vic
http://www.microchip.com/forums/m48207.aspx?print=true
Last edit: vmatthews 2014-03-13
I recently used a display that got confused by the LCDReady routine in lcd.h only reading the first nibble of the byte to check the busy flag. Modifying LCDReady to read both nibbles stopped it from displaying garbage. Here is the version of lcd.h if you want to give it a try. I'll attach the whole thing as it has various changes that didn't solve the immediate problem but didn't do any harm.
You might also try a pull down resistor on the LCD Enable pin to stop it floating while the PIC is Reset if that hasn't been suggested already.
Last edit: Frank 2014-03-10
I did try a pull-up and a Pull-down, and no change there, but I will grab your LCH.h file and that a try..
Thanks !
vic
Interesting.
I have build the 16F887a config on the test bed just now. No issues.
I have an LCD displaying 'Key Press is: ...; ' and upon power up some messages do fly.
The LCD has no pulls-up - see http://embedded-lab.com/blog/wp-content/uploads/2011/09/IO_Board.png for my LCD, and see page 3 a http://www.sparkfun.com/datasheets/DevTools/PICAXE/AXE091.pdf for the 16f887a board circuitry.
I am driving the power via the prototyping board not the PICKIT3.
The LCD is stable when programming and power on and off 5v.
I get garbage ever other time when pressing MCLR (yes, every other time of pressing MCLR). The garbage is high speed characters wizzing by on the top line of the LCD. Is this the experience you had/have?
That is exactly what I have with a PIC16F886.
And, more interesting....
Using 16F1937 same issue only when MCLRE is ON.
When I use, means MCLRE is OFF.
:-)
I like your workaround.
Last edit: Anobium 2014-03-22
I have an alternative LCD.H that seems to work.
Anybody will test? I have tested on 16F1637 and 16F877a and I no longer have the error condition.
Update. LCD has been on test for a few hours. I believe the root cause is an incorrect initialisation of the LCD. I have updated LCD.h.
Last edit: Anobium 2014-03-22
Send me the LCD.H file and I'll try it with the 16F886 setup I have.
I just posted it. I have discussed and we are happy to release.
See https://sourceforge.net/p/gcbasic/code/HEAD/tree/GCBASIC/trunk/include/lowlevel/lcd.h
This LCD.h file is intended to fix the LCD 4 bit init sequence, it also includes some
new commands
- LCDHOME - send cursor home
- LCDSPACE ( number of space ) - move cursor number of spaces
- LCDCreateGraph - create a Graph character in CGRAM
- LCDCursor - control cursor and display. ON, FLASH or OFF, FLASHON, LCDOFF
Please let me know the results.
First I verified that the issue was still present. Every other program load created junk characters.
Then I went to GCB@SYN>Great Cow Basic>include>low level folder and renamed lcd.h to lcd1.h.
Then downloaded your lcd.h into this same location.
I cannot get it to fail so its working great.
What was the issue?
Will you have details on the new commands?
How about some sample code?
Thank you. That's what I needed, some validation. The core issue was garbage on reset or garbage after programming.
Lets check. Where you using 4bit LCD? I hope so.
Regarding the new\revised commands. I will post a new help file in a day or two. I will also update the online help as this is the easiest for everyone to use.
Thank you for your time.
Yes, 4 bit mode.
I drove a DFRobot LCD shield from a PIC16F886 CHIPINO module.
The code can be seen at my site GreatCowBasic.com on the sample projects page.
Excellent. A good test.
I have posted code and I will post the new help file with the new commands at the weekend.
As a follow up. I ran into another problem with the lcd driver. I was unable to get the code to work about 16mhz.
Then, I remembered the Read/Write/Modify feature of the later chips. I was using a 16f1847.
So, I have another lcd.h that now supports LATx port driving at 32mhz and all is ok. I have retained backwards compatibility but if you want to drive at higher clock speeds then you will required the latest lcd.h.
Again, looking for a few testers before I upload into Sourceforge.
The new command is simple. #define LCD_LAT. You define your port as LATx but for DIRection support your also need to define the PORTx also. Why? LCD.h support multiple use of the port so port switching was supported - it still is.
An example of setting up the new lcd driver.
~~~~~
'LCD connection settings
#define LCD_IO 4
#define LCD_NO_RW
' New Command
#define LCD_LAT
#define LCD_DB4 LATB.4
#define LCD_DB5 LATB.5
#define LCD_DB6 LATB.6
#define LCD_DB7 LATB.7
#define LCD_RS LATA.7
#define LCD_Enable LATA.6
' Port drivers for legacy support of LAT
#define _LCD_DB4 PORTB.4
#define _LCD_DB5 PORTB.5
#define _LCD_DB6 PORTB.6
#define _LCD_DB7 PORTB.7
#define _LCD_RS PORTA.7
#DEFINE _LCD_Enable PORTA.6
~~~~
:-)