PICDEM2+ LCD problem 1

[logbook]

I just bought this PICDEM2+ demo board. £56 from RS components. Wonderful little thing with all sorts of goodies. Run up the pre-programmed demo code and it does lots of good things. Then comes the hard bit. The demo code is in assembler, and lots of it. Hundred of lines of code per file.

Of course I have the Microchip C18 compiler with precious few examples. What a pain! I managed to get the I/O pins to toggle and input and make the buzzer beep. It has been a struggle but I finally got to the other side of the “adventure game” they call manuals (the 18F4520 data sheet is 390 pages alone).

Now I can get the display to display 8 alpha-numeric characters, but then it hangs. Writing 7 characters is fine. (I have recompiled all the XLCD functions as required.)

The LCD type written in the manual doesn’t seem to have a data sheet on the web. The display is 2x16 lines and the hardware is clearly working since the assembler code works.

Any clues?

 

[MikeHalloran]

Your code typically needs to send a few bytes of initialization code to a display of that type to tell it how you want it to behave. It should be near the beginning of the assembler examples.

Of course, check your code for strangeness.

I think the LCD has a strobe input. Probe that to see what's really going on.




Mike Halloran
Pembroke Pines, FL, USA

 

[logbook]

Yes the OpenXLCD( ) function included with the C18 compiler generates the startup stuff. Finding the startup code in the assembler is not going to be fun. The LCD driver is about 500 lines long and it is not at all clear where it starts! (Sure, you would think it starts at the top, but there are an awful lot of little routines and labels to wade through first. Having found what look like initialisation strings, I then have to translate the C18 versions to see what I have to send it. What fun, NOT!


I forget the exact command name, but it is basically

write_the_string_to_the_LCD(“help I am too long”);

of which only the first 8 characters of the string will print. Furthermore there is a shift command to shift the display data right and this works when there are 7 characters displayed, but not 8. It seems as if the display thinks (or has been told) it only has 8 characters available.

 

[MikeHalloran]

The 2x16 displays I have used start up in a mode where they expect four bits of data at a time, e.g. for use with 4 bit uCs. I've never used them in that mode, and I'm working from dim memory, but I'm conjecturing that if, for instance, you send a character count as a single byte to a display in that mode, the count as received can range only from 0..7. That's why you need to duplicate the initialization code, so the uC in the display will listen to all of what you are sending.

Before that, as an experiment, you might try converting your shift count to octal and sending it as two bytes.

The display I used had 256 bytes of ram, that could be paged into the display area with short commands for fast updates, or used to hold custom characters that you could build and send, or just used as hidden data memory. The uC in the display was probably more powerful than the uCs I was using to control it. They can do some pretty cool stuff, that most programmers never discover. Try downloading the manual for any similar display and try what's in that. I suspect it will mostly work.






Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

I'm with Mike on the problem. Those displays default to 4-bits and 1 line.

They are all based on the Hitachi Display Controller. Find that manual on the web and all will start becoming much clearer. There isn't much to it, but then there isn't much to a combination lock if you have the combination.

If you look around you will even find one of the hundred sites that discuss those displays has all the C driver source for downloading.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[logbook]

I suppose one has to guess that the LCD on the PICDEM2 has something to do with the Hitachi HD44780 LCDE controller. Having done that one finds that Hitachi sold the business to Renesas, and they discontinued it. The Microchip Help forum cites Fema Electronics CG1621 and/or P-Tec PCOG-1602, both obsolete.

There is a discontinued data sheet on the HD44780, but the Samsung KS0066U data sheet is better (but still poor) at explaining things.

After reading the assembler code, and following along with the data sheet, I have managed to get it working a bit better now. I can write to all characters on both lines. Hurray!

The C18 supplied function

putrsXCLD()

fails after writing 8 characters, for no clearly defined reason.

The source code is simple:

void putrsXLCD(const rom char *buffer)
{
while(*buffer) // Write data to LCD up to null
{
while(BusyXLCD()); // Wait while LCD is busy
WriteDataXLCD(*buffer); // Write character to LCD
buffer++; // Increment buffer
}
return;
}

I can’t see how that fails, but it does. If you just do WriteDataXLCD( ) commands with constant chars (eg ‘A’) it is fine.

You have to send the display a
WriteComandXCLD(0x80) for the first display line and
WriteComandXCLD(0xC0) for the second line.

I am not sure why and frankly life is too short to worry about it!

There is apparently some sort of memory addressing problem still afoot. Something to do with the locations of const rom data and variables which I have not got to the bottom of and which is still causing programming issues (simple code sequences just don’t work in the expected manner ).

 

[MikeHalloran]

Uh, "buffer" is how big?

If it's any consolation, C never does what I expect it to, either.



Mike Halloran
Pembroke Pines, FL, USA

 

[TurboXS]

Sounds like you have a work around.

The LCD character displays seem to have different configurations but in the past when I have used them I have found that the display memory is not continuous as you would assume. I think it is because the controller is designed for larger displays. So for a 8 x 2 display you have to write the first 8 characters for the top line, then jump a number of memory addresses to the second line. Basically I think it is because they use the same controller for (say) a 32 x 2 display as the 8 x 2 display. So the second line starts 32 characters away (for example)

 

[logbook]

Mike,
buffer is of course a pointer, so it should handle any size of character array passed into the function like this

putrsXLCD("ABCDEFGHIJK");

The display is 16 characters long on each of two lines. Writing the characters using the WritaDataXLCD() function 16 times just works.

Now I find that the strncpy function doesn't work either. I have had to write my own. I have to conclude that there is a memory model problem, or something similar. I am using the large code model and far pointers. No doubt there is something in some manual somewhere that resolves the problem, but finding that page out of the 1500+ pages of data sheets/manuals is non-trivial!

 

[logbook]

Some of the problems I have been having are due to the fact that the ROM and RAM have incompatible pointer types associated with them. A string such as "the string" has a pointer of type

const rom char *

which is not compatible with a function call

writeMe( const char *str )

since the default pointer type is "ram"
Thus the function above is actually

writeMe( const ram char *str )

or in its full glory

writeMe( auto const ram char *str )

PHEW!

 

[MikeHalloran]

Uh, 'glory' is not the word I would use for having to type all that stuff to say 'display the string that's there()'.




Mike Halloran
Pembroke Pines, FL, USA

 

[Madcow]

Seems to be a popular problem.
Looks like their driver needs some work.
One problem is it doesn't check to see if its
busy. Maybe some delay loops.

http://www.ccsinfo.com/forum/viewtopic.php?p=76227&sid=dc6de4f2c2d0f7985db2e1ecf6f8cafb

Data sheet in this thread.

http://forum.microchip.com/tm.aspx?m=164428

http://www.ccsinfo.com/forum/viewtopic.php?t=22916&view=next&sid=40e351b8ee16bf6850a50d95917469b7

This guy rewrote the driver.

But to me it looks like a driver problem.

Best of Luck

 

[logbook]

Thanks madcow. Some interesting posts.

My problems are all solved now and the system is working as required.

 

[itsmoked]

All your problems are solved??

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[potcore]

Hi Logbook,

ill try to help as youve helped me much in the past.(i was under a different guise then!)
If you are after a system to allow writing to LCDs and getting stuff done with Microchip PICs etc....then i would recommend the Matrixmultimedia.co.uk PIC products.....they are easy to get up and running....and you can do more difficult stuff with them if you wish....they have one called something like "C for PIC microcontrollers"....and also another (which uses the same development board, for assembler code.....you can also use inline assembler with the C one.......these offer all help you need , from simple C/assembler tutorial, to more complicated....also have functions to write to LCDs if you want to use them....and the dev board has LCDs etc....+terminals so yuo can connect the ports to external HW etc etc.

 

[logbook]

Hi Potcore,
thanks for the advice. I wasn't trying to make a career out of programming PIC chips however! It is just a distraction from my real work.

As itsmoked correctly (and satirically) observed, it was only the PIC chip problems that were solved. My car broke the next day and I spent several days playing "fault codes" and OBD games.

Regards
logbook
-----------------------------------------------
author of "ANALOG SEEKrets - DC to daylight"

http://www.logbook.freeserve.co.uk/seekrets/index.html

 

[itsmoked]

Okay Mr. OBD...

Why do I have to reset my "Check Engine" light every other day because of "Bank 1 Lean" on my multipoint fuel injected V8. It only comes on during #3(scale of 0-10)acceleration from a stop. Only complaint it ever has: P183([?]I stopped actually reading it - I leave it plugged in so I can turn off the blinding yellow light.) Always passes smog with <10% of allowed emissions.

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[MikeHalloran]

Leave the engine idling and open the hood. Listen for a hissing sound. Follow it to the rubber hose that's cracked (check the bottom, too), hardened and loose on its nipple, or just off its nipple.

It may actually be a vacuum leak that only opens at a particular torque level, so tug on the hoses, too. And get out your crowbar and check for a broken motor mount.





Mike Halloran
Pembroke Pines, FL, USA

 

[itsmoked]

Thanks,
I'll check that out!

Keith Cress
Flamin Systems, Inc.-

http://www.flaminsystems.com

 

[logbook]

P0183 Fuel Temperature Sensor A Circuit High Input

The fault code should be a letter and a four digit number.
There are several lists of fault codes on the web. This one was KBM systems ltd.