Scrolling functions in 128x64 pixel graphics lcd.

Go To Last Post
73 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi der..
Can any1 suggest me some code for scrolling up,down left n rigt on 128x64 pixel graphics lcd.
:!:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

really depends on how your buffer is set up, but essentially it involves copying the data from line n+1 to line n for scrolling up, and line n-1 to n for scrolling down.

example:

scroll up:
before  after
0       1
1       2
2       3
3       4
4       5
5       6
6       7
7       new blank line

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Obviously you can move pixels about between a buffer in AVR memory.

Which graphics chip are you using ? For example a T6963C can just be given hardware commands.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

m using MS12864J LCD wit KS0108B CHIP. i guess it does not have any such commands.
wat is d whole concept of scrolling and adding a new line at d end????

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You do not have hardware commands with the KS0108 chip.

Are you using a publicly available library ? There may be existing functions.

Effectively you are doing a block move of pixel memory. Then you put white space in the gap that you have opened up.

You have to look carefully at your pixel addresses to see which way to move, and the appropriate limits. Are you scrolling a small window in the middle of your LCD ?

Try checking your spelling.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

check spelling?? m sry i didnt get u on tat one...
i plan to scroll the whole screen ... is tat possible??
i guess so..can u suggest me any site where i can find related codes....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you actually read the forum rules about what the acceptable form of communication here is? I doubt anyone is going to be willing to offer help to someone who can't even construct a sentence - what hope for a computer program?:

#nclude 

in man(vid) {
 whil(1) {
  of(PIB = 7) {
   PRTA = 3;
  }
 }
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since the ks0108 has pixels in memory in 8 bit vertical stripes, scrolling up 8 bits would be quicker and easier than 1 bit. the buffer requires 1k bytes... I draw into a 1k ram buffer in the 'normal' way across the top to the right, then copy the whole ram buffer to the ks0108 a byte at a time the way it likes. Good idea huh? A mega128 with 4k of ram would let you have a 4 screen bitmap in ram. If you keep the text in 22x8 char text screens, you could scroll one text line somewhat easier...

Imagecraft compiler user

Last Edited: Thu. Dec 6, 2007 - 04:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The most common scrolling method is to determine a virtual screen size that you want to write to. Just keep in mind how much ram your virtual screen buffer is going to require (This can add up fast).
Once you have a virtual screen setup it's just a matter of shifting the start origin of where you will copy the virtual screen to the physical screen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

When using KS0108 you can scroll up/down by changing the value in "Display Start Line Register".
You need to write LCD again after changing that value but you don't need to use a RAM buffer, just keep on sending same characters to same page and row. Changing "Line" is not useful if you only want to scroll parts of your screen, everything will move. Not sure if this changes both sides of your screen or just the one with active CS (my guess).
You need a delay in between to make the scrolling move in the speed you like.
Vertical scroll can be done in similar way, just change value of "Row" one step and write same sequence of bytes to LCD.
Be aware that you need some routine to take care of the changes needed to CS and Row when you get to the middle of screen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
The most common scrolling method is to determine a virtual screen size that you want to write to. Just keep in mind how much ram your virtual screen buffer is going to require (This can add up fast).
Once you have a virtual screen setup it's just a matter of shifting the start origin of where you will copy the virtual screen to the physical screen.

Not quite, as the pixels are oriented vertically in a byte, that is B0 is line 0, B1 is line 1, etc. Unless you are scrolling in multiples of 8, you will need to do a large bitwise shift to accomplish the goal. You cannot simply move the start index. The principles of the operation remain the same, no matter where your screenbuffer is located.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mount it portrait rather than landscape and use 64x128 rather than 128x64 perhaps? :lol:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

haha, true, if you only vertical scroll that might be an option. However then horizontal panning takes on the same issue. (the OP did say up, down left and right)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Not quite, as the pixels are oriented vertically in a byte, that is B0 is line 0, B1 is line 1, etc. Unless you are scrolling in multiples of 8, you will need to do a large bitwise shift to accomplish the goal. You cannot simply move the start index. The principles of the operation remain the same, no matter where your screenbuffer is located.

And this is where it's real useful to change "Line" as I described above.
Will do all the bitshifting for you, MCU only need to send one instruction to LCD and voilá.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Mount it portrait rather than landscape and use 64x128 rather than 128x64 perhaps? :lol:

Or tilt your head to one side...

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
And this is where it's real useful to change "Line" as I described above.
Will do all the bitshifting for you, MCU only need to send one instruction to LCD and voilá.

Actually it performs more of a rotate. When changing the line start value, all you say is what bit to start at. When it reaches bit63, it starts back at bit 0. So you still ahve to mask, and OR in the new data, but it certainly is faster than performing a bitwise shift in the AVR itself.

display         Output 
lines     Line=4      Line=60 
0           4           60
1           5           61
2           6           62
3           7           63
4           8           0
5           9           1
6           10          2
7           11          3
.           .           .
.           .           .
.           .           .
56          60          52
57          61          53
58          62          54
59          63          55
60          0           56
61          1           57
62          2           58
63          3           59

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Actually it performs more of a rotate

Yes, you're right.
Actually a bit annoying that the pixels that just disappeared from screen show up at the other end...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I didn't catch if the OP wants to scroll text or graphics. If text, the 128x64 will provide for a nice 8 line by 21 character display. I have done this with the GDM12864H graphics display - the one sold by Sparkfun and using the same chip set. I accomplished this in higher level programming - not at the lower display control functions.

If the OP wants to scroll graphs images, that will be a bit harder as, the GDM12864H and CFAG12864B (CrystalFontz) displays are laid out as a Left side and a Right side. Each side consists of columns of 8 vertical bits, 64 bytes wide, making up one page. There are then 8 vertical pages per side. So, the display has a Left hand side, consisting of 8 pages, each containing 64 bytes of vertical bits - each bit representing one pixel.

To move an image real time, you will have to keep tract of each pixel in each byte, in each page, in both sides of the display.

This is certainly not up for discussion in a forum as, the complexity is prohibitive.

Then again, you could do as I did... You could break out the STK500, wire up a GDM12864H graphics display (or something equivalent) and, start building the control functions that will enable you to place text and graphic images in the thing. From the beginning, it took about a week to get well formatted text control on my graphics display. Then it took about 3 weeks to get well behaved graphics control functions. At this point, I can place text, using direct addressing and scroll that text up and down. I can also draw lines, circles, set pixels, clear pixels using direct addressing, draw and clear boxes and, put text in a box, all using relative and/or direct addressing. In addition, I can plot waveforms based on ADC, frequency, time, etc..., as well as create sine, cosine, tangent, cotangent waveforms.

Now, how long will it take to communicate my effort to you. And if I did want to communicate (but I don't) the workings of my graphics display code to you, you'd have learned absolutely nothing about the graphics display and its inner workings.

So, the data-sheet is your friend, as is this forum. But we are not here to teach you how to program a graphics display. We are here to help you with difficulties that you might have along your journey to learning how to program your graphics display.

Does this all make sense???

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Not quite, as the pixels are oriented vertically in a byte, that is B0 is line 0, B1 is line 1, etc. Unless you are scrolling in multiples of 8, you will need to do a large bitwise shift to accomplish the goal. You cannot simply move the start index. The principles of the operation remain the same, no matter where your screenbuffer is located.

I think you missed the point. The method I'm describing is nothing more than double buffering. You write to virtual screen as though it were the physical screen then blit the physical screen with the updated contents. Using this method the physical orientation of the screen bytes makes no difference.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I completely understand the concept, and advantages, of double buffering. Even when you double buffer, the buffer is laid out in the same manner as the displays buffer, so the same problems exist, perhaps even magnignified by increased size. Double buffering does not insulate you from the physical arrangement of the buffer, it only insulates you from it's physical size constraints. (It may also insulate you from multiple 'tiles' such as the case here where you have 2 controllers... but the pixel arrangement, and consequent problems, remain the same). If you are also talking about re-mapping & expansion, which could insulate you from the physical buffer orientation. You suffer a huge penalty when you blit the buffer to the display, and possibly memory consumption.

In your initial statement you make it sound that all one needs to do is change the start index to scroll. My reply was simply saying that that is not correct, since the same physical problems exist, even in a double buffered system. Remember we are talking about a graphics system here, so we're talking about moving the image up, down, left, or right by 1 pixel (1 bit).

So given the vertical oriantation let's look at the two scenarios.

moving left or right (by one pixel)... simple, start the blit copying from the adjacent byte in memory.

Moving up or down (by one pixel)... now we have to shift ALL bytes that form a vertical column by one as one continuous unit, and thenn repeat this for all colums of the display. The AVR's memory is not bit addressable, so we cannot simply start copying at some odd bit address.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Thu. Dec 6, 2007 - 10:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Quote:

Not quite, as the pixels are oriented vertically in a byte, that is B0 is line 0, B1 is line 1, etc. Unless you are scrolling in multiples of 8, you will need to do a large bitwise shift to accomplish the goal. You cannot simply move the start index. The principles of the operation remain the same, no matter where your screenbuffer is located.

I think you missed the point. The method I'm describing is nothing more than double buffering. You write to virtual screen as though it were the physical screen then blit the physical screen with the updated contents. Using this method the physical orientation of the screen bytes makes no difference.


So Mike, what advantage does creating an image beforehand offer over directly writing the display?

The way I see it, by creating an image as you suggest, you are doing the work twice and, using unnecessary SRAM in the process.

The only advantage (or disadvantage) I see is that, with direct control (writing immediately) the display follows the events, such as plotting a wave form. This would retard (slow down) the real time display of incoming information. On the other hand, building an image will take time to actually build, and then more time to display. Also, building an image first could introduce flicker but, direct control will show a sweeping update of the display, likened to that of an oscilloscope trace.

So, depending on the particular requirements, each method could present advantages, and disadvantages. I think the final decision on the display control mechanism will be dictated by the particular application requirements.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually you're more likely to see flicker using the direct draw technique... especially if scrolling or panning. In direct draw, you have to do a read-modify-write operation. The actual time to 'modify' is insignificant to the rest of it, as the I/O with the display is so slow. Given that, using the double buffering approach you increase throughput by roughly 2. (possibly even more as you can often leverage auto-address increment in the blit)

[edit]
note that I am excluding the use of hardware features that assist in operations like scroll and pan, as they can be used in both models.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To do graphical gauges or anything that moves and redraws smoothly, the 'erase ram buffer, draw picture in ram, copy to lcd' gives good flicker free lcd image. It is possible to redraw faster than the lcd can respond. 5 to 10 redraws a sec looks good. Carl.. can you draw a box with a triangle on it (like a house) and rotate it?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Moving up or down (by one pixel)... now we have to shift ALL bytes that form a vertical column by one as one continuous unit, and thenn repeat this for all colums of the display. The AVR's memory is not bit addressable, so we cannot simply start copying at some odd bit address.

Yes, but even in the worse case scenario you should be able to update at least 30FPS. Once the low level layer is in place it certainly makes life a lot easier not having to deal with updating bits and pieces of the display on an individual basis all the time. I agree it is at the cost of sram usage, but if this functionality is needed (Panning basically) then I still think this is the way to go.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Copying a rectangular hunk from somewhere (offscreen?) to any x,y pixel address is a 'Bit Block Transfer' or bitblt. I dont think organiztion of avr ram has anything to do with it.... macs did pretty good graphics with 68000s with byte addressable ram... its a graphics libray primitive

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So Mike, what advantage does creating an image beforehand offer over directly writing the display?

Well, it looks like Glitch and Bob already answered this :)

One thing to remember with displaying "real time" data is that usually the update speed of the display is so slow that you've already lost the "real" before you started :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Carl.. can you draw a box with a triangle on it (like a house) and rotate it?

I can draw the box... I can draw the triangle... I can draw the triangle in the box... I can draw the box in the triangle...
But no, I can't do vector rotation yet! As soon as I'm done with the current contract project, I plan on implementing vector rotation. This is part of the reason I wanted direct pixel addressing.

I saw an example of vector rotation using a similar graphics display on U-TUBE. It was simply fascinating! I can't say that I have any particular application for its use, though. I'm sure that after I have something like vector rotation working, I'll have some project that I'll be wanting to use it with.

But, while I don't actually have vector rotation, I do have all (I think) of the functions in place to implement it. After all, vector rotation is just a bunch of trigonometry functions, correctly applied.

So Bob, the answer to your question is no, but getting very close...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Yes, but even in the worse case scenario you should be able to update at least 30FPS. Once the low level layer is in place it certainly makes life a lot easier not having to deal with updating bits and pieces of the display on an individual basis all the time. I agree it is at the cost of sram usage, but if this functionality is needed (Panning basically) then I still think this is the way to go.

Don't get me wrong... I'm all for double buffering, I believe it's the way to go. I was merely keying your, misleading, statements about it being simple as just changing the start address, or that it somehow isolates you from the physical arrangement of the buffer.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Glitch wrote:

Quote:
Even when you double buffer, the buffer is laid out in the same manner as the displays buffer,

That's not necessarily true - I've seen code where the buffer is mapped with horizontal bytes, and "rotated" on the fly when transferred to the display. In fact, the very first example I ever saw of an 8051 family chip talking to a graphics LCD did this.
CirMicro wrote:
Quote:
One thing to remember with displaying "real time" data is that usually the update speed of the display is so slow that you've already lost the "real" before you started Smile

What do you mean by update speed? I can re-write the entire display in well under one millisecond, the optical response is the big problem....

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Don't get me wrong... I'm all for double buffering, I believe it's the way to go. I was merely keying your, misleading, statements about it being simple as just changing the start address, or that it somehow isolates you from the physical arrangement of the buffer.

Not to beat a dead horse :) But you write one blit routine. Blit(x,y) This copies the buffer starting at x,y to 0,0 - 127,63. Decrement or Increment X and/or Y by as many pixels as you like and voila. Still seems as simple as changing the start address to me :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Copying a rectangular hunk from somewhere (offscreen?) to any x,y pixel address is a 'Bit Block Transfer' or bitblt. I dont think organiztion of avr ram has anything to do with it.... macs did pretty good graphics with 68000s with byte addressable ram... its a graphics libray primitive

The point is you can't bit align, the processor can only byte align. So for a one bit per pixel (8 pixels per byte) you cannot bitblt to any arbitrary x,y coordinate without some additional work. Although it's called a bitblt (bit block transfer) it's really a byte block transfer. As we are always aligned to a byte, and can only move multiples of a byte, and never less than a byte.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What do you mean by update speed? I can re-write the entire display in well under one millisecond, the optical response is the big problem....

Yes, that is what I am referring to as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John_A_Brown wrote:
Glitch wrote:
Quote:
Even when you double buffer, the buffer is laid out in the same manner as the displays buffer,

That's not necessarily true - I've seen code where the buffer is mapped with horizontal bytes, and "rotated" on the fly when transferred to the display. In fact, the very first example I ever saw of an 8051 family chip talking to a graphics LCD did this.

Note my "remapping" comment in that same posting. Yes you can remap it, but you pay for this in speed, and or memory. In your example the bitblt routine would have to read 8 bytes, sequentially shift bits out of them, and into a new byte and then write the new bite, repeating the shift and write for all 8 bits of the 8 'cached' bytes before moving onto the next 8. Ths is MUCH slower than simply copying the data from teh buffer to the display.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro wrote:
Quote:
Don't get me wrong... I'm all for double buffering, I believe it's the way to go. I was merely keying your, misleading, statements about it being simple as just changing the start address, or that it somehow isolates you from the physical arrangement of the buffer.

Not to beat a dead horse :) But you write one blit routine. Blit(x,y) This copies the buffer starting at x,y to 0,0 - 127,63. Decrement or Increment X and/or Y by as many pixels as you like and voila. Still seems as simple as changing the start address to me :)


ok from an outside view that's how it might appear... but the bitblt routine has to do a lot of work to make that happen. I'm talking implementation here, not some higher level library view.

consider this horse sufficiently dead! ;)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
Consider this horse sufficiently dead! ;)

And how dead is "Sufficiently Dead? "

Actually, I thought the whole thread was rather interesting!

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It has been an interesting thread, and fun to participate in... the dead horse is only about the potentially misleading comments made by CirMicro. Feel free to continue :)

How about a challenge? direct-draw vs double-buffering.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

glitch wrote:
It has been an interesting thread, and fun to participate in... the dead horse is only about the potentially misleading comments made by CirMicro. Feel free to continue :)

How about a challenge? direct-draw vs double-buffering.

So, are you saying create a working model and actually see which is faster/better?

Personally, I really believe the application will dictate. Though I don't know the actual criteria, I do have one further comment.

So, I'm plotting a sine wave using direct addressing.

And also, lets sat that I already have a plot of the sine-wave present on the screen.

So, in my direct addressing scheme, I want to put (basically over write) the new image of the sine-wave on the screen.

With my method, I use a scheme that I call "Clear Pixel Before Write. " In this scheme, I determine the "X,Y" location of the pixel to be set by determining the display side, page, byte and pixel. But before I actually write the pixel, I look at all 8 bytes within the 64 pixel column at location 'X' and determine if any other pixels are set along 'Y'. If any pixels are set along 'Y', I clear that pixel and then set the new pixel in that 64 (8 bytes at location 'X') pixel column. Then I simply move on to the next 'X' pixel location to be set, performing the same procedure.

So, to plot a sine wave, I read 8 bytes and check for the presence of pixels set, perform a write to clear the existing active pixel and then write the new pixel at location 'X'.

But with the virtual page method, you are doing 2 x 8 x 64 (1024) writes into an SRAM buffer, then, you are doing 2 x 8 x 64 (1024) reads from the SRAM buffer, and then you are doing another 2 x 8 x 64 (1024) writes to the display.

With the direct update method, I'm reading 2 x 8 x 64 (1024) display locations, writing 128 locations to clear any pixels and then writing another 128 locations to set the new pixel.

Virtual refresh = 1024 reads and 2048writes.
Real time update = 1024 reads and 256 writes.

The real time updates represent significantly less overhead, both in execution and data space, as opposed to the virtual screen update. And, as there are waits for the writes, I have to believe that the real time update scheme that I am using will be more efficient speed wise.

Am I missing something???

So, what numbers do you get???

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was thinking about a 128x64 graphics contest, where we send in performance benchmarks for our graphics package or multiframe videos where we brag 'top that!' and some 15 year old kid from Finland blows our doors off.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Who said you have to flush the entire buffer every time? Typically you only blit the area that changed. You don't have to erase/redraw the entire buffer every time. But for argument's sake, we'll stick with a whole screen refresh.

Also remember your direct method is reading from the LCD which is SLOW compared to that of SRAM. You can read/write several SRAM locations in the time you read a single LCD location. So it's not 2048 writes, and 1024 reads. It's 1024 SRAM writes, and 1024 SRAM reads, and then 1024 LCD writes.

Ok next up, is how you read/write the display. You also forget there are SRAM reads/writes to store your 8 bytes in each pass. (unless you unroll the loop, and store everything in registers)

In order to do the method you describe, you have to run the following cycle

update loop
  read loop
    set page (lcd cmd) [slow]
    set address (lcd cmd) [slow]
    read byte (lcd data) [slow]
    write byte (sram) [fast]
  repeat read loop 8 times

  process the 8 bytes (sram read/write) [fast]
  
  write loop
    read byte (sram) [fast]
    if update (max 2 times)
      set page (lcd cmd) [slow]
      set address (lcd cmd) [slow]
      write byte (lcd data) [slow]
  repeat write loop 8 times

repeat update loop 128 times

the way I see it, you have 1024 lcd reads, 2048 sram writes, 2048 sram reads, and 256 lcd writes

in contrast, the full screen refresh, we can stream the data, and take advantage of the auto increment.

draw loop
  inner loop 
    write byte (sram) [fast]
  repeat inner loop 8 times
repeat draw loop 128 times

update loop
  set page (lcd cmd) [slow]
  set address (lcd cmd) [slow]
  write loop
    read byte (sram) [fast]
    write byte (lcd data) [slow]
  repeat write loop 128 times
repeat update loop 8 times

which is, as you said, 1024 sram writes, 1024 sram reads, and 1024 lcd writes.

So yes, the double buffer method uses more resources in terms of memory... but it likely will not use more cycles if done properly.

Also note the same "optimization" you did in direct draw, can also be performed using double buffering.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Fri. Dec 7, 2007 - 02:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, point taken...

I guess the real question might be, is the OP actually learning anything from our discussion of managing and displaying graphics data?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

note I was editing when you posted, so you may want to review, in case I missed the mark somewhere. :)

I certainly hope the OP learned something... along with anyone else who reads this thread... it's been a good discussion.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have wondered why the awkward layout of this particular chip-set. Or, are they all this difficult to manage? It seems to me that, there is a better way to manage pixels in a graphics display. I suppose it has much to do with the fact that there are (in my displays anyway) two controllers, each managing one side of the display area.

I guess (I think) that if the graphics display was only 64 x 64 pixels, the format would reduce to pixel (bit), byte, page. But it's the pagination that throws everything off. I would think that it wouldn't be too terribly difficult to have laid out the display controller to simply accept an "X, Y" coordinate in the first place. As this (the GDM12864H/CFAG12864B) products are my first experience to the world of graphics displays, I don't really know what else is available and their method of pixel access.

One nice thing, though... I have noticed that the graphics display that I am currently using seems to be quite a bit faster then the HD44780 and compatibles. The graphics display that I am using is definitely harder to manage then the HD44780, as well.

A note to the OP, if he is still with us.

If you haven't actually broken out the STK500, attached one of these graphics displays to it, and tried to get some basic functionality working, getting to the level of display management that is being discussed in this thread will be difficult, if not impossible.

The fact that we brought the discussion to this point amazes me as, there isn't anything simple about learning to control and manage a graphics display. And, if you haven't yet conquered the HD44780 text based LCD display, you might make that a scheduled milestone, before you tackle the graphics LCD display. The similarities between the common text based LCD display and the LCD graphics display part company with the LCD, it self. But understanding the simpler issues of the HD44780 LCD display will set you up for success when moving to the graphics LCD display.

But, don't we just hate taking the "High Road??? " Do yourself a favor... Don't jump over the little steps as, they will lead directly to the end-goal. Jumping over the little steps, only leads to much frustration and brings the risk of failure in your end-goal.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They all get awkward when multiple controllers come into play... at least this one breaks at a power of 2 boundary, making partitioning relatively easy. I have a 240x64 display where the controllers switch at 132 or something like that... WHAT A PAIN!

The vertical pixel orientation is pretty common. It actually comes in handy for font rendering... a 5x8 font only needs 5 writes instead of 8, and no page changes. They all have byte access, as that's how CPU's work. I don't know of any that have bit level access, even if they did, it would be terribly slow, as now you'd be doing 128x64 (8192) writes to update the display, instead of 1024. This is a common ailment where there are more than one pixel to a byte. Live seems to get simpler when you get to bytes per pixel displays, but then the sheer amount of data pushes it out of the realm of your average AVR.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This was my thought too. 5*8 is a practical minimum font size and the vertical orientation of the bits simplifies writing the character no end... it's also compatible with other chip sets, for example a lot of the SED range.

As for two controllers, I think it's just a question of legs... having enough of them to drive the row and column outputs to the LCS. Having to select left or right half isn't a great problem.

The choice of memory double-buffering has to be decided on a case by case basis, I think. On many of the displays I've looked at, the read pin is not extended to the CPU, so you have no choice but to write only; if you need read-modify-write you have to do it in processor memory and blit it. But even so there are optimisations; you may have only part of the screen which requires live update with the remainder static text, for example; in such a case a smaller memory can be required.

I'm about to play with an OLED display with 256*64 pixels, each of 16 grey scales... each two pixels are addressed as the low and high nibble of a byte, so a memory map model would require 8k of memory to cover the whole screen. That's too big for the Mega32 I previously used for the app I'm redesigning. Unfortunately, there is no read control; the chipset is write only. Which has the potential to be a pain...

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:

As for two controllers, I think it's just a question of legs... having enough of them to drive the row and column outputs to the LCS. Having to select left or right half isn't a great problem.

Absolutely, there is no question a to why they double up controllers when they do. It's just annoying when the barrier falls at an oddball position.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First off nice thread, as I am working on the same display myself, and was struggling a bit at the beginning, first I thought the display was not working (checked the wiring a million times), but finally it was in the software (which I downloaded from here).
There where two hardware Init functions, one in the ks0108.c file and one in the glcd.c file. The one in the first file, which was used in the example, only did a hardware reset and Init, but it did not turn on the display :) , the function in the second file (which had only a slightly different name), used the Init from the ks0108.c file and then turned on the display.
When I was debugging the example, it stuck in the loop where it waits on a faling edge from the busy flag. That’s why I first thought of a hardware problem, took the data sheet and followed the steps to initialize the display and to turn it on, and then finally it worked.

microcarl wrote:
With my method, I use a scheme that I call "Clear Pixel Before Write. " In this scheme, I determine the "X,Y" location of the pixel to be set by determining the display side, page, byte and pixel. But before I actually write the pixel, I look at all 8 bytes within the 64 pixel column at location 'X' and determine if any other pixels are set along 'Y'. If any pixels are set along 'Y', I clear that pixel and then set the new pixel in that 64 (8 bytes at location 'X') pixel column. Then I simply move on to the next 'X' pixel location to be set, performing the same procedure.

With the direct update method, I'm reading 2 x 8 x 64 (1024) display locations, writing 128 locations to clear any pixels and then writing another 128 locations to set the new pixel.

Carl if I am following it right, don’t you update only one pixel with new data at a time, instead of waiting for all the 128 data ‘pixels’ and then update the whole screen, do you? Then you only have 16 byte reads and 8 byte writes, if I am not mistaken. If you would update the display with the double buffer method for only one pixel at a time, then it would take a lot longer, but sure, you can update only one vertical line at a time also with the double buffer method, but this needs a different function where you only update one vertical line and not the whole screen.

Another thing Carl, in your GLCD display library to draw a box and text in it at any x-y position, can you use different character sets with different sizes also? That also complicates things when using different character sets, not that difficult but it takes some time to make a good working function for that.

I also would like to make a library for a special character set, with variable character width, where for example the ‘I’ would only take a 3+1 (or even 1+1) bit wide space, whereas with a standard character set(5x7) it takes 5+1 bits total, a little like in ®Word from ®Windows :wink: .

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just out of interest, which AVRs are y'all hanging the 128x64 off? As it's a 1K screen, if you want to buffer and blit then you are presumably working with the big iron at the AVR end? (as most of the 16K AVRs have just 1K I'm guessing 32K devices or larger?)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This thread has become quite interesting.

As to answering the OP: he has a KS0108 type of controller with 128x64 LCD, and wants to do vertical scrolling, and possibly horizontal scrolling. He only wants to operate on the full screen.

Several approaches seem viable:
1. Maintaining a buffer in AVR SRAM, manipulating it and blitting the whole buffer in one go. The start address in SRAM circular buffer can be altered to easily horizontal scroll, or to vertical scroll on 8 scan line boundaries.
Personally I have never succeeded in writing 128x64 in less than 15mS.

2. Using the Offset register to alter the first displayed scan line. No good for horizontal scrolling. But smooth vertical scrolling is possible.

3. A combination of the two could work.

4. If there is no SRAM buffer, and any memory block moves are done within the KS0108 memory. This is very costly in read-modify-write especially over bit boundaries.

5. IMHO a library function would need to cope with a full range of start-address, window-width, window-height, horizontal-move, vertical-move. Depending on the size of the sub-window being scrolled, is it easier to block move some memory or in the case of full-window, alter registers ?

6. Is there an existing free library that already copes with scrolling windows ?

7. Handling the LCD as 21x8 text display is fairly trivial. Is this available in a library ?

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am using the AT90CAN128 and ATmega1281, probably a little overkill at this time, but didn't knew any better at the time, thinking bigger is better. Also switching DIL40 microcontrollers on the STK500, is a tricky job, so I bought the STK501 and are using TQFP64 only microcontrollers for now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just out of interest, which AVRs are y'all hanging the 128x64 off? As it's a 1K screen, if you want to buffer and blit then you are presumably working with the big iron at the AVR end? (as most of the 16K AVRs have just 1K I'm guessing 32K devices or larger?)

Yeah I used a mega64, but I also had a boatload of I/O in addition to the LCD's memory requirement.

You can use a small AVR, if you use the LCD's buffer memory, at the cost of speed. Or use a bigger AVR with enough memory for the buffer, at the cost of money ;)

I've also done a design using external SRAM, and then memory mapped the LCD. I wired it in such a way that I could do a virtual DMA from the SRAM to the LCD, simply by reading the memory in a loop. Esentially I added a control line to swap the read & write lines to the LCD, so that a read from SRAM, was a write to the LCD. Flipping the control line back, allowed me to talk to the LCD directly when necessary.

Another trick, was to set both chip selects active at a time. By doing this you can issue the same command to both controllers at the same time. It can also be used to clear the display (or set it to a common pattern/value) in half the time, as both are loaded simultaneously.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
On many of the displays I've looked at, the read pin is not extended to the CPU, so you have no choice but to write only;

Are you sure it wasn't brought out? It may be that Read & Write are the same pin. There are two common access methods.

One is to have a R/W pin and a strobe pin. The other is to have separate R and W pins, which are then strobed.

I have not seen a read-only display (which has memory). The only read-only ones I've seen, do not have their own buffer, so you must constantly refresh them to maintian an image.

I'm not saying they don't exist... only that I find it odd, and have never seen one configured that way myself.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Just out of interest, which AVRs are y'all hanging the 128x64 off? As it's a 1K screen, if you want to buffer and blit then you are presumably working with the big iron at the AVR end? (as most of the 16K AVRs have just 1K I'm guessing 32K devices or larger?)

I'm using a Mega644...

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

fleemy wrote:
Carl if I am following it right, don’t you update only one pixel with new data at a time, instead of waiting for all the 128 data ‘pixels’ and then update the whole screen, do you? Then you only have 16 byte reads and 8 byte writes, if I am not mistaken. If you would update the display with the double buffer method for only one pixel at a time, then it would take a lot longer, but sure, you can update only one vertical line at a time also with the double buffer method, but this needs a different function where you only update one vertical line and not the whole screen.

Well, I can update single pixels or byte-wise pixels, as well.

fleemy wrote:
Another thing Carl, in your GLCD display library to draw a box and text in it at any x-y position, can you use different character sets with different sizes also? That also complicates things when using different character sets, not that difficult but it takes some time to make a good working function for that.

Right now I'm only using 5x8 characters. I'd like to use other fonts and proportional spacing, as well. But I've still got to build those fonts and functions.

Also, I'm running the GLCD with a Mega644, clocked at 18.432MHz. I've been testing it by transmitting data via USART at 115.2K BAUD - one of the goals.

So far, what I do have working, works well. Once I have a good complement of usable GLCD functions, I'll not be using the HD44780 text based LCD any more. I can't see why I would have to! The GLCD will do graphics, provides 8 lines of 21 (5x8 font) characters each, the GDM12862H is only $19.95 at Sparkfun and, CrystalFontz makes a compatible GLCD in this class at $20.00 in quantities of 10.

One thing about the GDM12864H and the CrystalFontz CFAG12862B series displays. These two displays are directly compatible - well, mostly. The CS1 & CS1 lines on the GDM12864H are transposed to that of the CrystalFontz CFAG12864B display. The GDM12864H GLCD has "Split Pad " solder jumpers that allow the CS1 & CS2 control lines to be swapped.

I set all of the "Split Pad " jumpers on my GDM12864H display to match the CrystalFontz GLCDs as, the CFAG displays don't have any jumper options to change CS1 & CS2. Also, all of the code was written on the GDM12864H GLCD but testing has shown that the CrystalFontz GLCD seems to out perform the GDM12864H GLCD by a little bit.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Truly interesting thread...
I use mega16.
I've managed to survive without neither using buffers in SRAM or reading LCD.
The stuff displayed are 14 pixels high characters, 9 pixel high digits, a bar with "real-time" updated value 2 pages high and a scope-like squarewave also updated "nearly real-time. Much off this cross boundaries between CS1 and CS2
Occasionally screen content are scrolled both vertical and horizontal.
Only other task for m16 is to continously retrieve 20 bytes of serial data from I2C master, holding info on what to write to the screen. This might be the reason direct adressing without any buffering have worked for me.

Quote:
Another trick, was to set both chip selects active at a time. By doing this you can issue the same command to both controllers at the same time. It can also be used to clear the display (or set it to a common pattern/value) in half the time, as both are loaded simultaneously.

Very interesting piece of information. I have to blank the entire screen rather often to erase what was written to screen before. That's 1024 writes before any pixels are visible on screen. I been wondering myself if this trick would work but haven't had the guts. When I started to think about which chip would be read waiting for busy pin, and will there be a race and possibly even a conflict between chips.
So Glitch, may I ask how you handle busy pin? Were these chips KS0108?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
So Glitch, may I ask how you handle busy pin? Were these chips KS0108?

I would think that you would alternate between Left & Right side controller status checks. Which ever goes "Not Busy " first gets updated first.

As to the clearing of the entire display... Why can't you simply execute the built in "Clear " command, issuing it to both the Left & Right hand controller simultaneously?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops! It seems that I am clearing the GLCD the long way too!

void LCD_ClearScreen (void) {
     LCD_ClearPage (LCD_CS1); // Clear Left controller
     LCD_ClearPage (LCD_CS2); // Clear Right controller
}			   

void LCD_ClearPage (unsigned char chipselect) {
// The following defines are the logical or of the LCD address command & actual address to be read/written
#define PAGE_ADDRESS 0xB8
#define COLUMN_ADDRESS 0x40

     unsigned char X, Y;

     X = PAGE_ADDRESS;
     LCD_BusyWait(chipselect);
     do {
        LCD_WrtCmd (X, chipselect); // Set 'X' page address	
        LCD_WrtCmd (COLUMN_ADDRESS, chipselect); // Set 'Y' collunm address			
        for (Y = 0; (Y < 64); Y++) {
            LCD_PutData (0x00, chipselect); // Set data
        }
     } while (++X < PAGE_ADDRESS);	 		   		  
}

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah Carl got the Busy thing right. You can only write to both at the same time. When it comes to reading, you have to do it one at a time. Note that not all displays will allow you to access both controllers at the same time, it depends on how the manufacturer implemented them.

Certainly, if the display has a clear command, use it in favor of what I proposed above. I don't believe the KS0108 has it... I'd have to go back and look to be sure though.

I primarily used the dual write trick to issue any commands to the display. This way both were always in the same state (even if the command was never executed taken advantage of on the 2nd controller). It also came in handy in the full screen blit, since I could set the page address & address to 0 on both controllers in one step, this way only the CS line needed to be changed when I move across the 64 pixel boundary.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Carl, I use the same LCD from Crystalfontz as you do.
And no, as you seem to discovered there is unfortunately no "Clear" command.
I guess a question to the people at Crystalfontz whether both chips can be written at the same time is called for to prevent seeing any magic smoke...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
Carl, I use the same LCD from Crystalfontz as you do.
And no, as you seem to discovered there is unfortunately no "Clear" command.
I guess a question to the people at Crystalfontz whether both chips can be written at the same time is called for to prevent seeing any magic smoke...

I don't see any problem writing each half of the GLCD at the same time as, the Left & Right side controllers will be reading. As such, both controllers will be the equivalent of driving two or more logic inputs. "Fan-In " will dictate just how many inputs can be driven before a buffer/driver is required.

Reading from the both, the Left & Right side of the GLCD at the same time will create buss contention between the two GLCD controllers. The host won't know from which controller the data has come and, the output data from both GLCD controllers will more then likely have logic levels on the data lines that opposite that of the other GLCD controller, that is where the contention comes into play. In such a case, 1/2 the nominal logic level just won't make any sense to the host controller.

So, I think that for GLCD writes, sending common commands to both GLCD displays makes good sense. But, reading information out both GLCD controllers at the same time will never make sense.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But fast direct clearing of the lcd screen will never be necessary if you always draw into ram, then copy ram to the lcd. Since one can redraw screens too fast for the lcd to respond, speed of clearing doesnt gain anything in this block diagram.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Carl, I'm totally aware that reading both chips at the same time will lead to bus contention and most likely rise of the magic smoke.
It seems logical that you can write to both chips at the same time, still maybe there are some issues that I'm not aware of that prevent such actions.
"Oops, didn't think of that" have happened to me enough times to engrave a warning sign in my brain. If I had hundreds of LCD's I would try it out immediately. But I only have one and custom & shipping effectively doubled the price...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
But fast direct clearing of the lcd screen will never be necessary if you always draw into ram, then copy ram to the lcd. Since one can redraw screens too fast for the lcd to respond, speed of clearing doesnt gain anything in this block diagram.

But for now, I have no intention of using SRAM to build an image of the screen. Building a waveform using direct addressing and "Clear before Write " works quite well - without flicker. So, for now, I'm going to push forward with what I have as, I see other possible advantages in future functionality.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But fast direct clearing of the lcd screen will never be necessary if you always draw into ram, then copy ram to the lcd. Since one can redraw screens too fast for the lcd to respond, speed of clearing doesnt gain anything in this block diagram.

Just like Carl's program mine have no SRAM buffer and it does produce a working result.
My desire to get more knowledge drives me to want to explore if both chips can be written at same time. Even though it's not really needed to make this app work it might be useful if I start another project (with no SRAM buffer) where time used to clear LCD get more crucial.
When I wrote my app 5 years ago I was new to GLCD's and didn't even consider the possibilty of using an SRAM buffer as a virtual screen.
Right now I'm pondering over pros and cons if I were to rewrite my project and use SRAM buffer. Since it is working flawlessy as is I'm having a debate with myself whether fun or knowledge factor is high enough to do so anyway. I can definitely see that a buffer could have advantages in some situations if there is enough SRAM to implement it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you guys do the sort of graphics like a radar screen, where there is some fixed symbology like a grid and text labels, and some movable symbology like little ships and planes (sprites?) move around... sort of a battlefield plan view. How does one draw the grid, then smoothly move a square across the screen without erasing the grid? One way to do it with a color pallete is draw the sprites in color 1,2,4,8, but that obviously doesnt apply to a 1 color lcd. Clearing the whole screen, redrawing the fixed stuff, and drawing the movable stuff in the new location works if you draw in ram then copy to the lcd. Doesnt work so good if you erase the visible screen because you see it erase and draw again. ANy other trick to move stuff on the screen? Use xor mode?

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Clearing the whole screen, redrawing the fixed stuff, and drawing the movable stuff in the new location works if you draw in ram then copy to the lcd. Doesnt work so good if you erase the visible screen because you see it erase and draw again. ANy other trick to move stuff on the screen? Use xor mode?

Well, I don't have a grid yet, but tick marks to the left.

So, as long as the real-time image starts just to the Right of the tick-marks, there isn't a problem. As far as a base line, you'd need to check against that and if the current location to be written is the base line, then just don't write the pixel.

As far as an actual grid, I think that with a 128x64 GLCD, this isn't necessarily the best approach.

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
How does one draw the grid, then smoothly move a square across the screen without erasing the grid?

My method is to merge the grid and the moving information(a bar) into a byte that get written to LCD. This way the grid is never erased and no flickering occurs. Downside is that I consume time writing bytes to LCD that havent changed. An SRAM buffer would let me decide whether the byte to be written is already on screen. In my case the fast stuff I need to redraw is 256 bytes every 3 ms which is doable but I must admit that it does not present optimal programming practice...
So for now the debate between the lazy and the doer side of me has resulted in the compromise to make an SRAM buffer for that part of the screen so I don't need to rewrite the whole fucking program. Most of the screen is only changed once when a button get pressed. Clearing entire screen only occur if that button press takes program into another menu with completely different stuff on screen.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lennart wrote:
Quote:
so I don't need to rewrite the whole fucking program.

Quite a feat, this type of programming!!! But really totally needless here, don't you think?

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nevertheless, I knew exactly what level of frustration was expressed by that powerful adjective. I hate to have to rewrite the whole effin program too.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I apologize for the language. The lazy one can get terribly rude sometimes when threatened to do any type of work not needed for direct life-support. I've sent him to teraphy last year but it doesn't seem to have helped.

The Doer

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can confirm that writing to both sides works fine with CrystalFontz, Seiko and some no name I acquired. I do remember reading somewhere that not all support writing both at the same time, I just have not found one that doesn't yet :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CirMicro, the lazy one is grateful for not needing to send any question to CrystalFontz. Don't think he has realized yet that this will lead to more work updating code...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yes it'll depend on how the display manufacturer has set up the CS1-CS3 signals of each chip. If they simply bring out one of them, and tie the other two to their active state, then you can write both at once. If they use the CS1/CS3 or CS2/CS3 pair of both (one is active high, the other is active low) and then cross connect them, it is impossible to write both controllers at the same time (since one CS will need to be low, while the other is high to access one of the controllers, L-L or H-H would be inactive states). No damage will occur if you were to try. (as long as you are writing, attempting to read from both could result in damage)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks everybody.. m currently preoccupied with some other projets. i guess the suggestions will prove useful.