Profiles

Forums

Everything posted by wittend

I had a look at your projects and then went to see what chips I had on hand. I don't have any 16F873's, though I do have 16F877's. I will pursue this further soon.
But I also saw your LCD solution using a 16F628. I did have some of those lying around, so I burned your code into one and hooked it up to my displays to see if I had some bad parts, of if I am just cursed. I did determine that one older surplus LCD was at at best marginal, but when I hooked up to my better ones they worked fine.
So your solution did at least give me confidence that my tools & parts are in spec, and whatever is bedeviling me is in the code. I would just do it your way, since it works well, but I want to use the 16F689 and a four bit interface to the LCD because I want to make a little backpack board with a choice of RS232, I2C, or SPI jumper selectable. I use I2C a lot more than RS232 and I have some good uses for an SPI device as well.
Thanks for the suggestion & the project examples. How did anyone *ever* learn to do this stuff before the 'net?
-- Dave W.

Thanks for the info!
Sometimes it is the lack of this kind of 'oral tradition' information & perspective that makes me crazy. At least one of the LCDs that I am testing specifically uses the original HD44780. The Optrexs use a Samsung clone, and one uses house labeled parts I can't identify, but which were sold as a clone of the Hitachi.
I don't have a logic analyzer, but perhaps it is time to invest in one.
I suspect that my problem may lie in the configuration of registers selecting the function of some of the port pins I am using. I believe that I have disabled the ADC functionality, but I am less certain about some of the other functions, particularly the comparators. The registers have different names and different organization than in older chips.
-- Dave Witten

No joy...
I've tried portB with results that seem the same as always. I set the backlight so that I can barely see the background, turn on power, and twiddle the backlight port hoping to see something. But there is nothing.
A question:
I have tried all of this using the high 4 data bits, the low 4 databits, and with the option for high 4/low 4 set in the code. In (I believe) all possible combinations. The LCD datasheet I am using for reference - specifically the Optrex DMC LCD Family datasheet - indicates that in four bit mode, only the high nibble should be used. One of the LCDs that I am using is a member of that family, but others are not. Is it generally true that only one or the other nibbles is available on the LCD, or can some use either? (all are text-mode only LCDs).
-- Dave Witten

Thanks.
I have tried several LCDs including two 'virgins' still in sealed wrappers from DigiKey. I may try portb, but if that is the only way it can work, the LCD library is useless to me. It leaves the SPI & EUSART hardware unusable, which makes the chips essentially worthless.
I am almost ready to give up on this. It has taken up an obscene amount of time for results which do not seem worth the effort.
-- Dave Witten

When you say no results, what do you mean exactly?
I knew someone once how spent weeks trying to get their LCD software working, only to find that the contrast setting on the LCD display was not connect - so the output on the display could not be seen.
Regards
Dave
<{POST_SNAPBACK}>
I've checked for that. I had the clock setup wrong for a while, and I wasn't certain that I could use the internal source until I wrote a little program to verify that it was working - that just blinked an led.
The biggest difference between my code and the setups shown in the comments is that I use ports A & C rather than A & B. I want to use I2C or SPI when all is said & done, and the communications hardware uses the four B port pins which are implemented.
It is probably something dumb, but I just don't see a source of the problem.

I have spent some time trying to be sure that I am setting the correct register to put the ADC - capable pins into digital mode, but I am still unsure that I am doing the right thing. As best I can make out, on this processor the ANSEL andd ANSELH registers are responsible for this, with one bit for each pin. Because I am only concerned with RA0-RA3 and RC0-RC3, I set all of the ANSEL bits to 0. My read of the specs suggests that this should cover me. If someone else is familiar with this series of chips (PICF687/688/689/690) and can confirm or correct me I would be greatly appreciative.
Thanks,
-- Dave
<{POST_SNAPBACK}>
Still no luck!
I have spent quite a bit of time trying to make this work - studying and experimenting with the ADC registers, the _CONFIG settings, rebuilding my test harness - four times with new components. Everything I can think of. I have built new programs to test the I/O register configurations & clock settings. Simple led blinkers, etc. They work fine.
It is only when I try to use the LCD library with the PIC16F689 that I get no results. I hate to suggest that the problem is not in my setup or code, but because I can't find any other source and because I see no indication that the LCD code has actually been tested with this chip or any of its nearest relatives (F687, F688, or F690), I have to suspect that there might be a problem there.
I hate to expose myself to possible (probable!) embarrasment by questioning the library, but I am at wits end.
-- Dave

I have spent some time trying to be sure that I am setting the correct register to put the ADC - capable pins into digital mode, but I am still unsure that I am doing the right thing. As best I can make out, on this processor the ANSEL andd ANSELH registers are responsible for this, with one bit for each pin. Because I am only concerned with RA0-RA3 and RC0-RC3, I set all of the ANSEL bits to 0. My read of the specs suggests that this should cover me. If someone else is familiar with this series of chips (PICF687/688/689/690) and can confirm or correct me I would be greatly appreciative.
Thanks,
-- Dave

I am fairly inexperienced with programming PIC's, and what I have done was a while ago. I am unsure whether the LCD library works with the chip I am attempting to use and if so, whether I am setting all of the necessary parameters.
I am trying to use the LCD code provided with the BoostC compiler & SourceBoost IDE to drive an LCD with a PIC16F689. This is (you probably know) a 20 pin device with 12 A/D inputs, SSP, and EUSART with 4096 words of flash & 256 bytes RAM.
The code as I have it set up runs in the simulator, but I have no luck
when I try to run it in the chip.
One particular thing that confuses me is the comment in the code:
////////////////////////////////////////////////////////////////////////////
// LCD template arguments - defines how the LCD is connected to the PIC
////////////////////////////////////////////////////////////////////////////
// These must be define before template header file is included
// Remember when using LCD in 4 bit mode you must connect to the LCDs
// DB4-DB7 pin
Does this mean that only the high nibble mode works, is it just a
comment about one of the tested chips, or is it one of those ambiguities
that tend to remain in comments long after their usefullness? Perhaps
it meant something at one time, but the limitation has been removed. Or
perhaps I am misunderstanding altogether.
Here is what I'm doing...
// RS to RA0
// R/W to RA1
// E to RA2
// DB0 to RC0
// DB1 to RC1
// DB2 to RC2
// DB3 to RC3
// DB4 (nc)
// DB5 (nc)
// DB6 (nc)
// DB7 (nc)
Settings that I am using:
=========================
#define LCD_ARGS 1, // 2 = 4 bit(upper nibble)
1, // 1 = use busy signal
PORTC, // data
TRISC, // data
PORTA, // control
TRISA, // control
0, // port pin for RS
1, // port pin for RW
2 // port pin for E
The default pragmas defined in the sample code:
#ifdef _PIC16
#pragma DATA _CONFIG, _CP_OFF & _PWRTE_OFF &_WDT_OFF&_INTRC_OSC_NOCLKOUT
#else
... N.A.
#endif
I want to use the 8 MHz internal clock (INTOSCIO mode 8 - RA4 & RA5
available for I/O - according to the documentation.):
#pragma CLOCK_FREQ 8000000
and when I write to flash I recompile with this commented out:
//#define RUN_UNDER_SIM
and in main() I settled on:
void main()
{
// most important line that is often forgotten
// - turn PortA inputs that we are using into digital mode.
// adcon1 = 00001110b;
ansel = 00000000b; // should RA0, RA1, RA2
// and RC0, RC1, RC2, RC3 in digital mode.
lcd_setup();
...
}
I am using the current version of the compiler & IDE