• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

cfag12864b in a microcomputer system

airswit

New member
hi, i have bought one of these displays in hopes to insert it into my microcomputer project. it is a 8 bit system built off of a motorola 68000 uP. i was wondering a few things. first, can anyone tell me exactly how data is to be sent to the device? also, is there any easy way to do 6x8 fonts on this display, or would it just be easier to do 8 dots wide? also, can anyone tell me an easy way to be able to turn the backlight on/off digitally? i am talking about the hardware of it. thanks in advance for any help! later

ps, i would also like to know if there are any timing conflicts w/ this processor running at 8MHz?
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
Last edited:
Using a 68000 microprocessor (or any microprocessor) will be a lot more troublesome than using a microcontroller. This is because you will have to create an I/O interface (microcontrollers already have I/O ports) by decoding a couple of memory addresses and using latches on the data bus. This is necessary because the cpu speed is too high for the timing of the display control signals. Do you understand what is involved in doing this? Is your project homebrew or based on a commercial product?

You can make fonts in any array size you want, but unless you have a font editor utility, it is a pain. Do you have one or can you write one? BTW, it is better to keep the font height in multiples of 8 pixels, to simplify the "paging" of the display.

The backlight can be controlled by using a transistor, typically a power FET, on one of the interface I/O pins. I can suggest part numbers if you indicate what kind of physical package you prefer.
 

CF Tech

Administrator
The software to drive a graphic display can be a major project.

You might take a look at these libraries to see if they support your micro and the LCD controller:

http://www.ramtex.dk
http://www.easygui.com

Along the lines of cosmic's comments, are you committed to the 68000? There are many flash based single chip micros that might significantly simplify your project if it would fit into one. Take a look at the Atmel Mega128 AVR for instance.
 

airswit

New member
well, the reason i am doing this is basically just to get experience in this sort of thing. i have already completed the design and construction of the system, for a college course, and just wanted to do this on my own. i havn't done any projects w/ microcontrollers, or pics, or anything, i just wanted to see if i could add this to my system. as for the backlight system, is there any easy way to do that w/ just a bjt, so i don't need a big fet? if not, any size fet would be fine, just an inexpensive one that can handle a source current of >100mA. thanks for replys, hope you can help further!
 
I think there are people here who will answer your questions and give advice, but I don't think anyone will lay out a complete design for you. So you need to ask more specific questions about details that you need.

You can use a bipolar transistor; I suggested a FET because there are types that can be driven directly from logic levels (5v), and I never use "big fets". There are fets in a SOT23 case (1mm x 3mm), IRLML2502, or TO92 case, BS170, that can switch several hundres mA, and have such low on-resistance that the power dissipation is nil, and they cost fifty cents.

You don't indicate your location, so I cannot refer you to a parts distributor.
 
Last edited:

airswit

New member
well, the hardware is the easy thing to design, its the software that will be troublesome. i basically want clarification on how data is to be sent to the display. is it correct that data is sent 8 horizontal bits at a time, then the next line down is sent? it says that with this display once data is written the Y address is increased by 1. if this is correct, what happens once the Y address gets to 63? i would assume it goes back to 0, but is the X address then incremented by 1, or does this have to be done manually?

i am not planning on doing anything too spectacular with this system, as this is just a side project to help me gain experience, and to see if i can do it, but i sure would like to get this thing up and running, at least in some form. i will be working with a pic based microcomputer system in a month or so here, so i am not tooattached with this system. thanks for your replys so far!
 
Yes, you're right, the hardware design is pretty trivial; it's the software that is the real work.

If you look on page 13 of the data sheet (I am referring to the CFAG12864B-TMI-V data), you will see that the X and Y designations are completely misleading. I have not used this particular display myself, but I have used the cfax12864ap, which has a different controller chip, but is very similar.

When a byte is written, it controls 8 pixels vertically, on one of the pages. The 128 pixel width is divided into two 64 column sections, which are chosen (separately or simultaneously, I believe) by the CS1 and CS2 inputs. The column within the section(s) is addressed with the "Y" address register. The 64 pixel height is divided into 8 pages, each with 8 rows of pixels.

To write a character to the display, one of the 8 pages is selected using the "X" address register, and the starting column using the "Y" address register and the CSn inputs. Each byte writes a column of 8 pixels within the page rows, and the "Y" address autoincrements to the next column. So your font bitmap should be arranged as a left-to-right array of bytes, with D0 as the top pixel.

I have written a font editor for this type of bitmap font, to run under windoze. If you can't find, or contrive, anything yourself, I might be persuaded to give you a copy.

What language are you writing in? I have a "display driver" file that does just what is described above, written in HC12 assembler. However, I think that you may derive more benefit from re-inventing that wheel yourself, as opposed to having it handed to you on a platter.
 

airswit

New member
wow, that's pretty crazy that x means the vertical and y means the horiz, i don't really like that! haha, anyway, thanks for the help, i can't really start on programming this project till i get back to school in about 3 weeks, but i was just looking for any info on this sort of thing.
thanks a bunch, and i'll see what i can do!

p.s. i will be doing all the coding in 68k assembly, as that is all the processor understands. if you have any code to just test to see if the display is working, or something, that would be great to have. i can always work on more complicated stuff by myself! thanks a bunch
 
Last edited:
Ha ha, you so funny :D . The code needed to "just test" the display is the same as what you need for the "more complicated stuff". You'll need to determine what the proper initialization sequence is, for an uninitialized display usually produces nada.

Good luck.
 

airswit

New member
ahh, man, don't leave me hanging!! how do i initialize the display, it doesn't say anything about that in the data sheet, does it?! any help would be great. and, as for the testing the display, i meant do you have any code that will just send a picture, or set a few pixels on, or something? just so i can brush over what order i need to send stuff in. thanks again...
 

airswit

New member
k, can you tell me if i am understanding this correctly, and feel free to call me retarded if i am not:

set enable to low
set d/i* to low (instruction)
set cs1 and 2 to low (select both halves)
send instruction to turn on display
enable display, set enable back to low
set starting line to zero
enable display, set enable back to low
start sending data

and do i have to wait 10ms in between each enable signal as it says in the code as well? another question i have is would it be alright to just wire the reset pin to high, or is it useful to have it software controllable?

please, let me know if this is right so i can start writing the code in assembly. if i have the time i might actually statically test this as well. thanks for all the help, again. talk to you soon!
 
Last edited:
Wiring the reset pin high is not a good idea, as asserting the reset input is the only way to guarantee that the internal state of the controller is known. Usually powering-up will reset it correctly, but not always. Better to use a 10 mS reset at the start of initialization, then you know that the state of the controller is correct.

The controller takes some time to execute each command, and the delay in the demo code allows for the longest command execution time. You can shorten that wait considerably if you have a bidirectional data bus, and test the "busy" status to know when the controller is ready for more input. It complicates the code to do this, but you will get maximum performance. If you are not concerned about fast updates, then the delay method is simpler. The data sheet for the display and the controller chip don't indicate the timing for the command execution (as I have seen in other controller data sheets), so you may want to experiment with delay times if you don't use the status read function.

P.S. I'm not trying to "leave you hangin", I'm giving you the oportunity to "gain experience":) .
 

airswit

New member
no, i see what you are saying, thank you.

man, you are complicating my hardware!! hehe, guess i'll have reset hooked to a latch.

thanks a lot for all your help, i think i have enough to start writing code now, and i think i will poll for the busy bit. one last question, is it necessary to set then

a couple last questions: is it necessary to set and clear the enable pin of the display where i said in my last post?
and was i correct when i said in my last post to select both chips, or do i deselect both halves of the display? cuz i was a little confused on the chip selects for the display in the C++ code.
 
Since I have not used this display, I can not answer with certainty, but I will take a stab at it.

Think of the enable input as a command/data strobe. You raise it then lower it for each "action". For writing, the action takes place on the falling edge of the strobe. For reading (status) the data is available while the strobe is high. Don't change any other control signals while the strobe is active.

As for selecting the halves, I'd say that you'd select them both for anything that is common to both, such as: display on/off, set page address, set start line, etc.

You'd select them separately for setting column addresses and writing data. (One exception: select both for clearing the display faster, by writing 0's to both simultaneously).

Here is your chance to experment and find out the results. By using a simple data pattern, such as alternating 0x55 and 0xAA, you can see the effects of addressing and chip selects.

Did I answer your question?
 
Last edited:

airswit

New member
ya, i think i am all good for now, like i said though, i can't start actually testing for a couple more weeks, till i get back to school. i will try and get some code worked out by then though
 
Top