Forums

interfacing 4x20 lcd using c/c++

Started by AyeashaB April 13, 2005

any suggestions?




In a message dated 4/13/05 9:41:47 A.M. Eastern Daylight Time,
ayeashab@ayea... writes:

any suggestions?

=================
lots of c example code on avrfreaks.net



C++ produces too much code to leave much space on the 64K of a
68HC11. Even C functions such as printf(), scanf() and floating
point libraries are consider to big and slow to use on a 68HC11.

Dave Dunfieils C complier is about as simple as they get at
http://www.dunfield.com/ if your are know with gcc from Linux it
has been ported to a 68HC11 and will let you do terrible things
on it. If you are at a university there should be a lab that use
the 68HC11 and someone that supports it and that is the best one
to get.

If you look at c a scaffold for 5% assembly language to make the
really tight spots in you program and with some functions
putint(int a) and putlong(long a) and char *atos(int a, char *s)
and ltos() and use these puts() incited of printf you can get
lots of program in a 68HC11. If you treat in like a Windows box
with floating point and high level function calls you will be
disappointed.

Gordon Couger
Stillwater, OK
www.couger.com/gcouger

AyeashaB wrote:
>
> any suggestions? >
> Yahoo! Groups Links





On Apr 13, 2005, at 8:39 AM, AyeashaB wrote:

> any suggestions?

Sure. Read the data sheets for the LCD you select. The text LCD modules
are very easy to use. There are much harder challenges in embedded
programming than coding for a text LCD so if a text LCD is a challenge
for you then its just right as something to dig into and learn with.

The standard Hitachi LCD controller wakes with its parallel interface
configured in 4 bit mode. Or at least its supposed to. Observe the
command to put it into 8 bit mode is designed so that it can be written
about 4 times on an 8 bit interface (if memory serves) so that no
matter what state the hardware was in it will end up in 8 bit mode. Of
course, that is assuming you would like the display interface to be in
8 bit mode.

Some do not connect the Ready line, rather they pace the rate of
commands written to the controller. I suggest you go ahead and connect
it.

Others have already addressed the issue of code bloat using C++. I
suggest avoiding any standard f-functions which may come in your C
library. Such as printf(), fputc(), etc.

--
David Kelly N4HHE, dkelly@dkel...
========================================================================
Whom computers would destroy, they must first drive mad.


AyeashaB wrote:

>any suggestions? >
>
First, since the MC68HC11 uses memory-mapped I/O, there should be
no problem doing whatever you want from C or C++. Note that there
is no such language as C/C++.

Second, 64K is a *lot* of room. But, you may not have that much RAM
installed. And even if you do, it probably has holes in the memory area.
This is always a consideration when using a high-level language. You may
need to study your tool set to see how to manage memory. Assembly is
often much easier in this respect. I'm presuming that you are using an
expanded mode.

Third, you need to decide how the hardware hookup is going to work. Are
you going to use direct connect to the expansion bus, or are you going to
use I/O ports? This will affect how you do your control

Next, consider the architecture of your code. I suggest writing it in
layers.

NB: None of the code snippets has been compiled nor is any of it expected
to run on any system. Each is supplied as an example of programming style...

At the bottom, I suggest having a logical/physical interface layer. This
layer
knows how to write (and possibly read back) a byte. It knows about any
delays or checks for ready line state. It knows whether the hardware is
in 4 bit or 8 bit I/O mode. But it knows nothing about the hardware beyond
how to talk. The services provided by this layer might include such things
as LCDputByte(unsigned char Byte), LCDgetByte(),
LCDsetIoMode(IoMode) where IoMode is one of LCD_NIBBLE_MODE,
LCD_BYTE_MODE, etc. I prefer enumerated types to defines. As an example:

unsigned char * const Lcd = 0xABCD; /* an address goes here */

void LCDputByte(unsigned char Byte) {
LCDwaitReady();
if (IoMode == LCD_BYTE_MODE)
Lcd[DATA] = Byte;
else {
Lcd[DATA] = Byte >> 4;
LCDwaitReady();
Lcd[DATA] = Byte & 0xF;
}
}

Timeouts would be a nice feature, with put/get etc. returning -1 for
failure,
and perhaps setting errno to some hopefully informative value.

One layer up, I suggest a logical layer. This layer knows each of the
commands the LCD is capable of performing. It calls upon the lower layer
to do its actual I/O. The services provided by this layer would be
things like
LCDpositionCursor(int Row,int Col), LCDcursorMode(CursorMode) where
CursorMode is one of LCD_BLINK_CURSOR and LCD_NOBLINK_CURSOR
etc. An example of the type of code in this layer would be

int LCDpositionCursor(int Row,int Col) {
int Result;

if (Row < MIN_ROW || Row > MAX_ROW || Col < MIN_COL || Col <= MAX_COL) {
Result = -1;
errno = E_LCD_BAD_CUP;
} else {
LCDputByte(LCD_CUP);
LCDputByte(Row);
LCDputByte(Col);
Result = 0;
}
return 0;
}

Routines like this then would be a portable library which you could use
in other projects, and perhaps even with other processors. The only
routines which would need rewriting would hopefully be the
logical/physical layer, only a few. Like set io mode, put byte, get byte,
and wait for ready. If your application only relies on the high
level routines, then it is completely insulated. In fact, you could
write and
test your main application without even having an MC68HC11 at all.
Simply write the low-level routines to do some simple screen displays
and your app could be written and completely tested (except for the
logical/physical layer) on your PC.

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
I speak only for myself, and I am unanimous in that!


Mike McCarty wrote:

>[snip]
>
>int LCDpositionCursor(int Row,int Col) {
> int Result;
>
> if (Row < MIN_ROW || Row > MAX_ROW || Col < MIN_COL || Col <= MAX_COL) {
> Result = -1;
> errno = E_LCD_BAD_CUP;
> } else {
> LCDputByte(LCD_CUP);
> LCDputByte(Row);
> LCDputByte(Col);
> Result = 0;
> }
> return 0;
>} >
Warned you! Of course this should have been
return Result;

[but you knew that!]

Mike

--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
I speak only for myself, and I am unanimous in that!