UTFT component? perfect for many graphic displays

[Benj]

Hi Rob,

Right I think I have just realised why everything is sooooooo slow. We need to go back to the PIC_CAL_I2C file and look at line 308.

Code: Select all

  delay_ms(10);	

This is right at the end of the I2C Stop command and fixes a problem with lockups using I2C hardware. We are using the I2C software so you should be able to comment out this line all together and it should significantly increase the speed.

Code: Select all

  //delay_ms(10);	

This combined with the last component optimisations should allow the display to run nice and quick

[RobH]

Way faster, but still not instantaneous:
http://youtu.be/zwS1ZbSJB14


I'll check the C file and change line 308 now.

*edit*

Ben, you're a long-haired genius! removing the 10ms delay fixed it. Now I'm going to go back and change the nop delay back to 1us and see if it works.

[Benj]

Hurrah, that's great thanks for letting me know.

I've now modded the CAL file here so the 10ms delay is always removed if your using the software I2C layer so this should work as is with no file changes for the next release.

The 1us delay will work in all cases and clock speeds. If you still find this a little slow you should be able to squeeze a bit more speed using the nop method but this needs to be balanced to work with the chips clock speed as well as things like the length of the wires to the display etc.

[RobH]

Before we put the last nail in the coffin, I'll run some more tests for writing, clearing, rewriting, etc. I'll get back with you promptly.

*edit*

I have limited equipment for testing here. I'll have to wait until I can get to my lab.

[RobH]

OK, after extensive testing of the latest C file with the delay change, I've made some observations. Summary - we're not quite there yet. It seems the issue here now is those changes worked perfectly, during programming only. After the programmer finished and you cycled power, nothing came on the screen. So, I did a few tests with the C file.

Since,ideally, you'd prefer not to overclock the i2c component, I left the original delay intact for tests 1-3:

Code: Select all

    #if (MX_I2C_SW_BAUD < 1)
        #define MX_I2C_DELAY    delay_us(1);
        

And here are the changes and outcomes of the i2c bus reuse delay.

Test1:

Code: Select all

//delay_ms(10);  //Wait before reusing the I2C BUS

This makes things the quickest (clears screen and writes "/■Hello World" in less than a second), but only works during programming/verifying. But, at this speed you can still notice the writing from left to right of the characters on the screen. After programming is complete and you cycle the external power source, nothing will write to the screen.



Test2:

Code: Select all

delay_ms(1);  //Wait before reusing the I2C BUS

This was an interesting one. Obviously,writing characters to the screen was about 3 times slower while programming/verifying. I did write them in the correct orientation on the screen. I say this because after programming and when you cycle power, it would write the characters to the screen at that same slower speed, but it would write them upside down on the bottom of the screen (screen rotate 180). Not consistently, though, as sometimes it would write them backwards on the top right (screen mirror).



Test3:

Code: Select all

delay_ms(2);  //Wait before reusing the I2C BUS

Now we're kind of getting back to normal, although slow. After programming, each time you cycle power the characters will write to the screen correctly. It takes between 4-5 seconds to clear screen and write the characters/text.




At this point I wanted to see if revisiting the nop cycles would remedy anything, so I ran a couple more tests.

Test4:

Code: Select all

    #if (MX_I2C_SW_BAUD < 1)
        //#define MX_I2C_DELAY    delay_us(1);
        #define MX_I2C_DELAY  nop();

Outcome: nothing works



Test5:

Code: Select all

    #if (MX_I2C_SW_BAUD < 1)
        //#define MX_I2C_DELAY    delay_us(1);
        #define MX_I2C_DELAY  nop();nop();

Outcome: works correctly but no noticeable speed increase over Test3.


I hope this helps!

[Benj]

Hi Rob,

What if you add a fairly large delay in to the program before you initialise the glcd component. 1 or 2 seconds should do and should allow the display to properly power up before we start throwing commands at it. Hopefully this will allow the delay in the I2C stop macro to be removed and allow the display to run reliably at full tilt.

[RobH]

Case closed. Adding a 1s delay before initializing did the trick. I thought I had done that in some previous tests, but I digress. Thanks for all your assistance, Ben. Now, back to overclocking with nop statements to speed up multi-line writing...

[Benj]

Hello Daniel,

As requested, here is a component driver for the SSD1322 type display with 6800 or 8080 type 8-bit parallel data interface. This should hopefully work with your OLED 5.6 Inch display.

The display type (6800 or 8080) is set via the component properties and controls how the pins are manipulated during operation.

Let me know how you get on.

[hyperion007]

Thanks Ben, I will have a look, but I think I have used 3 or 4 wire SPI for my SSD1322 displays but as I can use 8080 or 6800 (at least on the 5,6" one) I guess I can try it at least. Which is faster?

In the meantime I have tried the SSD1306 today.

Here is a small video: http://youtu.be/j3IWRx3rd80

It is about twice as fast if I use font "0" instead of "2" but it still isn't lightning fast by any means.I am using a PIC18F4550 running at 48Mhz with a 20Mhz X-tal.

Anyway to speed this up like you managed for the I2C one?

[hyperion007]

And here is another video of the SSD1306 with font "0" to demonstrate the speed difference:
http://youtu.be/g2KOfNUc72k

[Benj]

Here is the serial version for your 3.2" displays.

gLCD_SSD1322_buffered.fcpx

(7.23 KiB) Downloaded 477 times

Let me know how you get on.

[Benj]

Hi Daniel,

The 8080 and 6800 parallel interfaces will be much faster than the serial versions, mainly because you can clock in data 8-bits at a time.

I'll have a look at your vids and see if there is any optimisation I can do to the standard SSD1306 display to get it running a bit faster, from the top of my head there's potentially a couple of optimisations that could go in.

[Benj]

Here is the SSD1306 Buffered component with the speed optimisations to only write pixel values that have changed.

gLCD_SSD1306_buffered.fcpx

(7.26 KiB) Downloaded 484 times

[hyperion007]

YES!!!!

That's what I'm talking about!!!!

This is how all displays should look! It's like real time updates now, 2000 FPS at least!

Here's a video of this in action: http://youtu.be/DpOzX6RyuAk

So nice!

[hyperion007]

Btw, how would you suggest I go about printing the degree symbol on the display? I suspect that I cannot use an ASCII code since there are no ASCII tables in the display controller?

For now I just draw a small square 3x3 pixels but a circle macro would be nice

[hyperion007]

And you can keep the display I sent you. This works so well that I'm buying plenty more

[Benj]

how would you suggest I go about printing the degree symbol on the display?

The easiest way to do this is to override one of the fonts in the GLCD base font library. To do this click the View menu and bring up the component debugger window. Tick the Expose full component tree checkbox and this allows you to explore all of the components packaged inside the GLCD component.

On the properties window select the drop down list at the very top of the window and select the ASCII2 component located inside the GLCD component.

Change the integer properties from this

Code: Select all

0x36 , 0x49 , 0x49 , 0x49 , 0x36 ,0x06 , 0x49 , 0x49 , 0x29 , 0x1E ,0x00 , 0x6C , 0x6C , 0x00 , 0x00 ,0x00 , 0xEC , 0x6C , 0x00 , 0x00 ,0x08 , 0x14 , 0x22 , 0x41 , 0x00 ,0x24 , 0x24 , 0x24 , 0x24 , 0x24 ,0x00 , 0x41 , 0x22 , 0x14 , 0x08 ,0x02 , 0x01 , 0x59 , 0x09 , 0x06 ,0x3E , 0x41 , 0x5D , 0x55 , 0x1E ,0x7E , 0x09 , 0x09 , 0x09 , 0x7E ,0x7F , 0x49 , 0x49 , 0x49 , 0x36 ,0x3E , 0x41 , 0x41 , 0x41 , 0x22

To this

Code: Select all

0x36 , 0x49 , 0x49 , 0x49 , 0x36 ,0x06 , 0x49 , 0x49 , 0x29 , 0x1E ,0x00 , 0x6C , 0x6C , 0x00 , 0x00 ,0x00 , 0x02 , 0x05 , 0x02 , 0x00 ,0x08 , 0x14 , 0x22 , 0x41 , 0x00 ,0x24 , 0x24 , 0x24 , 0x24 , 0x24 ,0x00 , 0x41 , 0x22 , 0x14 , 0x08 ,0x02 , 0x01 , 0x59 , 0x09 , 0x06 ,0x3E , 0x41 , 0x5D , 0x55 , 0x1E ,0x7E , 0x09 , 0x09 , 0x09 , 0x7E ,0x7F , 0x49 , 0x49 , 0x49 , 0x36 ,0x3E , 0x41 , 0x41 , 0x41 , 0x22

The change is the 4th character in the ASCII LUT where each character consists of 5 bytes equating to the pixels in each column.

0x00 , 0xEC , 0x6C , 0x00 , 0x00 => ;

to this

0x00 , 0x02 , 0x05 , 0x02 , 0x00 => °

This then overrides the ';' character to the '°' character and should also work in simulation.

You can then use things like this in strings: "Temp = 23.4;C" to achieve the following on the display.

Temp = 23.4°C

And you can keep the display I sent you. This works so well that I'm buying plenty more

Thank you very much, much appreciated and should allow me to use it as a test bed to sanity check I don't break things in new releases.
I have just shown it to my MD and he is keen on using them for something

[hyperion007]

Thanks Ben!

I am actually ok with using a small square as degree symbol for now. Looks alright.

What do you think about the circle drawing macro? doable?

And yes, I thought it would be best if you had a display in case there are other issues down the line or new features to be added to the component. I absolutely love these small displays and the way it turned out with the component.

I made a small and simple test where I put a print number macro in a while 1 loop and incremented by 1 for each loop. It looks to be able to update 100 times per second.

http://youtu.be/8N6Cj0TE9L8

[Benj]

Hello Daniel,

No problems

What do you think about the circle drawing macro? doable?

The issue with drawing a circle is you have to do it using trig functions or using look up tables.

Trig functions are nice because they do the maths directly for any value, however the ROM hit will be large when dealing with 32-bit Float numbers on a 8-bit device. Plus the trig functions do not currently exist for the 8-bit PIC compiler so this can be ruled out for now as a viable option.

Look up tables could work well but you need different lookup tables for different circle sizes or things start to get a bit inefficient memory wise. Might be possible to do something simple here e.g. get a fairly high resolution 90 degree corner sample and then scale to the necessary size. This will likely not suit everyone as the circle will be aliased at high resolutions and consuming more memory than needed at lower resolutions. I will have a think on the best way to do this.

[hyperion007]

Ok, got it. 90 degree corners sounds interesting. Could be used to do nice rounded corners on boxes etc.

[Benj]

Here's a example 8 byte LUT for a circle.

8Byte LUT.jpg (110.89 KiB) Viewed 31035 times

[hyperion007]

If you have time I would love to see some smooth scrolling macro If possible, it would be great if one could specify which coordinates or at least which Y lines that should scroll, direction and speed. Scrolling text one pixel column at the time instead of a whole character per step is just so much nicer

Then there are a couple of commands in the datasheet that could be put to use via macros, like normal/inverse display, display on/off, fade out/in, blinking.

If you have the time etc

[Benj]

Hello,

I'll have a look and see how easy it would be to add macros for those functions, shouldn't be too hard.

Even at 16x16 pixels or 32 bytes in the LUT it still looks a bit sketchy.

32Byte LUT.jpg (106.56 KiB) Viewed 31034 times

[hyperion007]

Yes I agree, those corners look a bit wonky.

[Benj]

Ok here is a version of the buffered SSD1306 component with the additional macros to set the contrast, switch the display on and off and invert the display.

If these work ok then let me know and I will add them to the non buffered and I2C versions of the display component.

The scrolling commands look interesting so what I have done is made the SendCommand macro public so you can use this in your program to send any additional commands you want to have a play with.

gLCD_SSD1306_buffered.fcpx

(7.5 KiB) Downloaded 462 times