CFAF320240F-035T-TS-CB connected to a LeafLabs Maple Mini

[uberlinuxguy]

Hi Folks,

I am attempting to connect a CFAF320240F-035T-TS-CB to a LeafLabs Maple Mini. I've checked and double checked all my wire connections, but still cannot seem to figure out where the problem lies. It seems as though the LCD responds(ish) to the initialization routine, but when it gets to displaying color, it just doesn't do anything. I'm attaching the example code (I renamed the MapleIDE file from .pde to .c) I'm using which is a modified version of the 16bit code I downloaded from Crystalfontz. I've tried 8bit and 18bit (All 8080 parallel I believe) too and nothing seems to work. I'm attempting to avoid using SPI because it's just not going to be fast enough. Although, I tried that with an Arduino Uno and couldn't get that to reliably work either. I feel as though there's something small and simple I'm missing here but I can't figure out what. Any thoughts or suggestions from those who have used this LCD would be very helpful.

Note that I'm using a digitalWrite to flip the individual bits on the data bus on and off before I strobe the WR pin. I assume this should be ok since the Maple runs at 72Mhz and that should all happen pretty fast. Doing PORT I/O on the maple is a bit difficult, and I wanted to make sure I was flipping the right bits on and off, so...

Thanks
--
Jason

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[uberlinuxguy]

Thinking a bit more about this, I'm curious of two things:

1) what the wiring diagram for the example code on CF's website would look like (both in 8 and 16bit mode.) That might help me adapt things to the Maple Mini I'm using.

2) What exactly this snippet of code from the 8 and 16 bit examples does (since I didn't include it in my code):

int main()
{
        PORTD = 0xF8;	// pull-up on switches, all others off
        DDRD  = 0x0F;   	// VPP and led pins output

 

[cosmicvoid]

Hard to comment on your code since a lot of the functions used are not declared anywhere; and I'll assume that your wiring is correct and there are no timing problems, since you don't give any wiring info for your setup.

One thing I notice in your init list is that registers 0x44 through 0x46 are not being initialized. The data sheet shows that they are set to the default value at reset, but I've always explicitely set them in my init routine.

snip...
	0x0025, 0x8000,		// Frame Frequency Control Page 53 of SSD2119 datasheet
	0x0026, 0x7800,		// Analog setting Page 54 of SSD2119 datasheet
[B][SIZE=3]	0x0044, 0xEF00,		// Vertical RAM address position Page 57 of SSD2119 datasheet
	0x0045, 0x0000,		// Horizontal RAM address position	Page 57 of SSD2119 datasheet
	0x0046, 0x013F,		// Horizontal RAM address position Page 57 of SSD2119 datasheet
[/SIZE][/B]	0x004E, 0x0000,		// Ram Address Set Page 58 of SSD2119 datasheet
	0x004F, 0x0000,		// Ram Address Set Page 58 of SSD2119 datasheet
snip...

Can't hurt to try that, I suppose.

I'm a little puzzled about why you set all the data I/O pins to 0 before setting them to the bit value of the data/command. I guess it wouldn't make your code fail, but it seems peculiar.

If you want another example of working code for the 320240F, you could take a look at my version for the AVR cpu, here:
https://forum.crystalfontz.com/showthread.php?p=28164#post28164
cfaf320e_AVR.zip, in the GrLCD.c file. I have used both 8 bit and 16 bit versions of I/O with no problems.

 

[uberlinuxguy]

Hi cosmicvoid,

Thanks for the reply.

I've actually taken a look at your code a couple of times. It's quite nice code by the way, so thanks for posting it.

I can try to get a wiring diagram together and post one if that might help.

Good point about the registers. I'll try to give that a shot and see if it helps.

Yeah I just assumed that initializing the I/O pins to a "known quantity" might help, but I could see that looking a bit peculiar. I come from an old mindset of coding where you initialize things to known values before you try to use 'em. I'm also new to microcontroller/embedded coding though, so perhaps that's not as normal.

One other thing I found that was a bit odd was table 15.2 in the SSD2119 datasheet is titled "Mapping for Writing an Instruction" And it looked like the bits are left shifted in 16-bit mode. I assumed, possibly incorrectly, that "Instruction" in this case meant "Command" and changed that around to do what I thought was the right thing. It seemed to make matters worse because before I did that, the init routine would make the LCD flash and flicker as through the driver chip was initialized and is refreshing the screen. After I made the changes suggested in 15.2, it didn't do anything and just gave me the normal white background again. Just curious your thoughts on that.

Thanks again for your help man. I might grab my Arduino Mega and see if if I can do better with some AVR code and doing actual PORT operations.

--
Jason

 

[cosmicvoid]

snip...

One other thing I found that was a bit odd was table 15.2 in the SSD2119 datasheet is titled "Mapping for Writing an Instruction" And it looked like the bits are left shifted in 16-bit mode. I assumed, possibly incorrectly, that "Instruction" in this case meant "Command" and changed that around to do what I thought was the right thing. It seemed to make matters worse because before I did that, the init routine would make the LCD flash and flicker as through the driver chip was initialized and is refreshing the screen. After I made the changes suggested in 15.2, it didn't do anything and just gave me the normal white background again. Just curious your thoughts on that.

You can find a summary of the pin connection vs. mode here:
https://www.crystalfontz.com/products/document/2236/CFAF320240F_Interface_Table.pdf

I just hauled out my 320240F test jig, and I have it wired as shown in the 15.2 table (i.e. input bits 0 and 9 are NC in 16 bit mode). I also have the 4 mode select bits (PS0~PS3) wired to a port so I can play with different modes without rewiring. So let me know if you have any other questions. I didn't say anything about your earlier question regarding "PORTD" and "DDRD" in the CFA sample code because it seemed irrelevant to your situation.

After a successful initialization of the LCD, assuming you haven't cleared the display ram, you should have a screenfull of random pixels. Having the clear (white) screen implies that the SSD2119 is not "on" (display not enabled).

One other troubleshooting idea, if you have access to an oscilloscope, is to write a loop that puts data to the LCD continuously (for example, repeat the init routine). At the top of the loop, toggle an unused I/O pin to trigger the scope each time. Then you can see whether the signals to the LCD "look right", and check timing. Do your measurements at the LCD inputs, not the cpu outputs. BTW, a 50uS pulse width on the /WR signal is a bit much; even 1uS would be overkill.