Real time measurements on graphical lcd using AVR

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

Hello !

I've used alphanumerical lcds in the past but recently i've developed the need for a graphical interface.
What I need is a way to be able to plot graphs real time/post process on the lcd and measure things like accelerometers etc in real time.

The lcd i'm planning to get is :

http://www.gme.cz/lcd-graficky-d...

It's a 128x64 graphical display. I'm having trouble understanding all these types of drivers for them.
This one says it has a "NT 7108 or Equivalent"
I'm guessing the NT7108 is the driver , and i don't understand what the "or equivalent" means there.

Can someone advise where I can start with using that lcd or a similar one with an AVR?
I'm guessing that writing the code by myself is out of the question and that I would have to use a library and some sort of graphics engine.
Once again , I actually need graphics , not just letters and circles/squares etc..

I found a site https://code.google.com/p/u8glib/
Does anyone know it?

I'd appreciate any help on this and I apologise if there has been a similar thread in the past on this topic

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

nt7108 seems, according to http://serdisplib.sourceforge.ne... -which drives a GLCD from a PC- , compliant (equivalent) with the popular ks0108;
u8glib has support for it: it has been verified on arduino https://code.google.com/p/u8glib... and implemented (without verification : but it is a classical circuit) for avrs.

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

Thanks dbrion for the info , but I still have no clue where/how to start.

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

Well, I tested, four years ago, ..on a PC how to draw real times lines (kind of oscilloscope): one had to wipe off the previous ones (much more RAM consuming than wiping a full image). Going less superficially depends on the way pixels are adressed (here, they are 0 and 1 )which is display specific...

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

Well, let's see:

Step 1: Figure out how to wire it up. Compare datasheets and draw a schematic.

Step 2: Get one wired up.

Step 3: Make a program to try and have some effect on the display. Like maybe set a pixel "on."

Step 4: Make a more complex program to have some effect on the display. Like maybe set 2 pixels "on."

Step 5: Figure out how to set enough pixels on the display to draw a line or something.

Step 6: ...

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut. 

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

128x64 'monochrome' (one bit per pixel) has 16 bytes across x 64 lines ->1024 bytes. If you use an avr with 4k or 8k or 16k of ram, you can have 2 screens in ram. I betcha you can get 5 or 10 redraws a sec with this system... glitch free double buffered animations.

Imagecraft compiler user

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

What do you mean by 2 screens in ram?
5 or 10 redraws? You mean an update rate of 5 or 10 hz?

Isn't the lcd module supposed to have some 'buffering memory' to which I can send all the data and latch it so I don't have to burned the micro too much?

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

He's talking about a technique called double buffering. If you just draw direct into the display memory its sometimes possible to actually see the updates in progress on the display itself so things like video games do thir drawing into another buffer and when the complete frame is ready you switch it into display. On PCs and other advanced devices this final switch can often be done in one instruction that just switches the base address in RAM where the display electronics are looking. But with this kind of AVR setup you still have to copy the entire 1K (or whatever) from its location in AVR RAM to the RAM of the display controller but that's still quicker than doing the picture assembly with a lot of drawing operations. Also LCDs like this show the display by scanning across the lines and from top to bottom of the screen. The moment the scan goes back to the top of the screen is called "frame flyback". Often it's possible to find out when this is happening. If you then time your display RAM writing so it's "behind" the current scan update you can update all the RAM without the updating being seen. If you miss time it or you cannot tell when FF is happening you can get a "tearing" effect on the display where the boundary between one frame and the next is seen. However it's only really a problem if you are making large updates (like showing frames of video), if you are just drawing a few lines or characters it won't matter too much.

Oh and this kind of display uses a technology called Super Twist Nematic. That describes the kind of liquid crystal used and the technique used to energise it. With STN it takes about 200ms (1/5th of a second) to switch a pixel from black to white (or vv) so it is pointless trying to update more often than this and if you do the display may look "blurry" so you have about 200ms (5Hz) to prepare a frame and memcpy it to the display.

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

What Cliff said. I can reload the entire screen in under a millisecond, but the optical resonse is between 100 and 200 mS. On the plus side, the mono displays tend to be transreflective, meaning that you can read them with either incident light(daylight/sunlight) or a backlight. This is not an option with colour displays(yet), unless you have very deep pockets. Full of money, obviously. Deep pockets by themselves are not much use unless you have very long arms, or want to carry lengths of copper pipe around with you.

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

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

Well there you go. Three avrfreaks seem to agree. I'm going to go get my lotto ticket.

Imagecraft compiler user

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

Thanks alot for your input clawson , John_A and bobgardner.

Yes the 200ms update rate is pretty crap. I knew that this was the case with alphanumeric lcd but was hoping the the graphical ones were faster.

In any case I decided to go with monochrome OLED displays. I found a few good ones for about 16 bucks.

http://www.exp-tech.de/Displays/...

or this
http://www.exp-tech.de/Displays/...

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

Quote:

I decided to go with monochrome OLED displays.

As you'll have noticed they have update rates more like 10ms but that then raises another potential issue which is exactly how fast can the AVR go and how quick can it generate/update a frame. Say you have 128x64 mono pixels and you want to update 100 times a second. That means writing 800,000+ pixels per second. If the AVR runs at 8MHz that would be just 10 cycles per pixel and where is all this pixel data coming from anyway?

On the other hand film uses 24fps and TV uses 25 or 30fps. Human eyes don't need updates faster than that because of "persistence of vision" so you probably have 40ms to make a display update.

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

Well , for starters I think i'll be satisfied with an update rate of 15 hz or so , doesn't have to be completely fluent. I could use an atmega664 running at 20MHz so that would give me a decent frame rate.
Granted there would be some cycles spent on processing the data before it being sent.

I was thinking that maybe I could have one avr process the data and 'animate it' and send it to another avr which would push the data onto the display.
Is that a reasonable system?

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

Quote:

Is that a reasonable system?

Single CPU is almost always the "better" solution. I'd only be looking at two CPU if your time budget really dictates it.

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

Shagas

Keep in mind that the prices are in euros not $.
€16 = $21.68

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

I know the price is in euros , 16 Eu for an Oled display for educational purposes is well within reasonable boundaries for me.

Quote:
I'd only be looking at two CPU if your time budget really dictates it.

Please explain in which direction do you mean that?
Are you saying that a dual micro would be an easier but less effective solution?

Well My time budget isn't excessively abundant so I think that it would be reasonable to cut some corners here.

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

I like the little adafruit 128x32 and 128x64 white or blue oleds. They are about the size of a 3 digit 7seg display.

Imagecraft compiler user

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

Quote:

Please explain in which direction do you mean that?
Are you saying that a dual micro would be an easier but less effective solution?

Two (or more) CPU solutions are a nightmare for all kinds of reasons like communication, synchronization, matching firmware updates, how do you even program both etc.

So one CPU is always preferable. However if your time budget says that you require 150% of the CPU power you actually have and the micro is not going to be able to keep up with the job in hand (perhaps because it spends all its time updating LCD and there's no time for anything else) then you might give in and look at implementing a two+ solution.

In no sense would a dual solution be "easier" (except that it might lift the workload from one CPU).

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

I would say , that normally I would go for 1 CPU as well.
But in one project I had two one for 1/4 VGA touch screen (mega1284) that did all the mmi etc, and then an other for realtime stuff (mega16), that could send high print packets to the VGA.

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

Well thanks a lot for the advice guys . It definitely helped alot

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

I am getting about 60-90 fps with text (and some bitmap graphics) on this NewHaven OLED but from a 32mhz XMEGA:
https://www.youtube.com/watch?v=...

I think the NewHaven has multiple screens worth of buffer memory inside it that you can preload and instantly switch between. I haven't figured out how to do that. I am getting 60-90 screen redraws just writing to the actively displayed region.

That is their model with no character generator, its all bitmapped.

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

No, I have not used this display. But it looks as if it is monochrome 128x64. i.e. 8192 bits or 1024 bytes.

Most displays have an auto-increment mode so you are talking about 1024 SPI or 1024 parallel with appropriate strobes. Your Xmega should be able to manage 16MHz SPI (512us per frame). Parallel will be faster if you use a VPORT.

So I reckon you have a theoretical 1900 fps. Parallel will be even faster.

Untested. Pure speculation. You have chosen not to reveal the OLED model#.

Post your code.

David.

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

> You have chosen not to reveal the OLED model#.

NHD-2.7-12864UCY3
from
http://www.newhavendisplay.com/o...

My code is based on their example code you can download from their site. My entire menu system code is big.

I run it in parallel. The display is pretty simple, this is what the data routine looks like:

void oled_Data(unsigned char Data)
{
	PORTD.OUT = Data;
	PORTC.OUTSET = PIN3_bm;		// DATA ~CMD LOW
	PORTC.OUTCLR = PIN4_bm;		// RD ~WR LOW 
	PORTC.OUTSET = PIN5_bm;		// ~EN HIGH 

	PORTF.OUTCLR = PIN3_bm;		// ~CS LOW

	_delay_us(0.3);

	PORTF.OUTSET = PIN3_bm;		// ~CS HIGH

	_delay_us(0.3);

	PORTC.OUTCLR = PIN5_bm;		// ~EN LOW
	PORTC.OUTSET = PIN4_bm;		// RD ~WR HIGH 
	PORTC.OUTSET = PIN3_bm;		// DATA ~CMD HIGH
	
}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see the demo code at http://www.newhavendisplay.com/app_notes/OLED_2_7_12864.txt

Your Xmega is going to be pretty efficient at handling the GPIO. All the same, I am sure that you can speed up that demo code. For example, I suspect that you can strobe the parallel data with less wiggles on the DC, CS, RD, EN lines.

You can also make the primitive functions 'inline'.

No, I don't own any of these displays. So I have no great inclination to do anything. $35 is a lot to pay for 128x64 monochrome.

This is relatively cheap but does not look very nice http://www.ebay.co.uk/itm/Serial-UART-I2C-SPI-128x64-12864-OLED-LED-Module-Blue-for-Arduino-PIC-AVR-Proj-/370779189389?pt=LH_DefaultDomain_0&hash=item565429708d
And it seems to use a M*crochip MCU rather than a SSD1325 controller.

Where are you?

David.

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

> Where are you?
I am in Wasilla, Alaska.

> All the same, I am sure that you can speed up
> that demo code.
I have found the display still works with variation from the demo code. Its been so long since I looked at the demo I am not sure if I am following it any more.

Mike

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

Say Hi to Todd and Sarah.

Imagecraft compiler user

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

> Say Hi to Todd and Sarah.

Did see 'em once at the local mexican restaurant. I think you have better chance of running into them down there now that they are living large.

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

Hi Mr. deathcow,

I'm going to go parrallel to try to set up the SSD1325(NHD-2.7-12864UCY3) on a xmega 256A3BU

is there any words of wizdom you can pass along?

Do I just setup the GPIO s than initialize the display as per their example?

 Then use the DATA function you created (Data(char) is declared global and passed?)

Where will the char be displayed?

 

oh and is this 6800 mode?

thanks in advance

/Dave

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

Dave,

 

Two thoughts:

As you are using an Xmega, I'd have thought you would post your question / Thread in the Xmega Forum.

Also, I think you would get a better response by starting your own, new Thread.

I'm not sure why you tacked your question on to a two year old Thread, you are using a different display and a different uC.

 

Unfortunately, with the recent update to the Forum software, splitting Threads is difficult for the Moderators.

So your Thread will likely stay here.

 

You can use any of the three supported interfaces.

If you use the parallel data interfaces, you will write the low level (bit-banged) interface to send the data to the LCD.

If you use the serial interface, you can often use the SPI hardware module in the uC to do the actual sending of the data to the LCD, you just stuff a register with the data values you want to send.

 

Note, however, that there are 4 ( ? ) SPI "modes", so it can take a little careful data sheet reading, or simply trying all four modes, to get the SPI setup correct in the uC.

The purist would read the data sheets for the LCD and the uC's SPI module and select the correct mode.

If you are in a hurry, one can change the mode in software, download it, and test it in a fraction of the time.

 

The only "downside" to the serial interface is that one can't read data back from the LCD.

It is, in this mode, an output only device.

 

One therefore often maintains an image of the LCD display in the uC's memory.

One updates the uC's memory data array for the LCD as needed, and has a separate routine that copies the uC's memory data to the LCD.

This does a full re-write of the LCD every time it is called.

The advantage here is that one can read the memory array stored in the uC to assist in writing the new screen data.

 

Another item to be aware of is that some of these OLED GLCD's have a register to adjust the contrast, not the classic 10K pot so often used in Character LCDs.

The value you see in the LCD data sheet, or in other people's code found on-line, may not be even close to what your particular LCD requires.

This is one more variable that one sometimes has to test a bunch of vales until one gets it right.

 

Hence, the initial steps to turn on the LCD and display it's first pixel can be a bit time consuming and frustrating.

But once you have the initialization code working (SPI mode and contrast setting, etc.), you are home free.

 

JC

 

 

 

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

Thanks JC,

I'll get the hang of the Forums soon.

 

I think I may go with the SPI mode and keep in mind your advise...regarding (SPI mode and contrast setting, etc.),

 

I might try out the u8g library as well...looks like a bit of work to get installed into ASF!

 

From New Havens https://www.newhavendisplay.com/app_notes/OLED_2_7_12864.txt code which uses parallel (6800) mode

the first two functions "Command" and "Data" if I rewrite them to be SPI functions "drivers" the rest of the code under instruction setting etc should work?

 

and the OLED_12864_INIT(); function should too or am I way off base? I think I have to first put the chip into "RESET" then send reset info

Thanks

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

Look at the example, and look carefully at the data sheet for the display.

 

You will still need to write a low level driver to send data and commands to the display, even using the hardware SPI module.

You would typically have an additional I/O pin for use as the D/C control signal, (Data/Command).

You set this signal, then send the data with the SPI hardware.

 

The Chip Select\ can be always be done in software, again using your own dedicated I/O pin.

Sometimes it can be done with the hardware module's own CS\ signal.

 

Once you have SPI working, it works great.

Sometimes, however, it is easiest for me at least to manually control the CS\ signal, and then once I have it working I can see if I can coax the hardware into controlling it for me, if the added speed is important, (and it usually isn't).

 

Good luck, it is great to see that first controlled pixel light up on the display!

 

JC