Show Posts
Pages: 1 ... 31 32 [33] 34 35 ... 102
481  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: December 17, 2013, 04:01:01 pm
It is long time back that i worked with the Nokia displays. At least my own display has 96x65. I applied 5V to my Noika display without further voltage reduction. At least it still works, but I do not know if this is just luck.

Oliver
482  Using Arduino / Displays / Re: openGLCD running on my test board on: December 17, 2013, 12:34:32 am
Quote
I wouldn't think that the glue will change much.
Ok, then i can start updating M2tklib at any time.

BTW, if you have any issues or suggestions that would help make it easier for M2tklib to integrate with openGLCD
let me know and I'll see if I can get them integrated.
As far as i remember, i had to hardcode ascent and descent values of a font into the M2tklib code GLCD code.  Having procedures to return these values, would be great.

Oliver
483  Using Arduino / Displays / Re: openGLCD running on my test board on: December 16, 2013, 05:08:41 pm
Hi Bill

Yes, I have used Arduino IDE 1.0.5 and I just followed your instructions. The M2tklib port was more like a quick and dirty modification. I just wanted to see how openGLCD behaves under more heavy conditions. Your preliminary release indeed behaves very stable.
I hope to find some time to migrate the existing GLCD glue code for M2tklib to the new openGLCD API, but maybe i should wait for some first official release. Do you expect larger changes to the openGLCD API?

Also thanks for your comments on "bitbucket.org".

Oliver
484  Using Arduino / Displays / openGLCD running on my test board on: December 16, 2013, 03:48:39 pm
Quote
To read more about or even try the openGLCD library, it can be found on bitbucket:
https://bitbucket.org/bperrybap/openglcd
Please post any questions or support issues for this library in new threads.

Very good. After reading your comment, i just went to my lab, pulled out my GLCD test board and did some testing with openGLCD. Works without any problems.  Real plug and play. I would call this already very stable.

Also M2tklib works after one minute in compatibility mode without any visual issues. I just replaced all
Code:
#include <glcd.h>

lines with
Code:
#include <openGLCD.h>
#include <include/openGLCD_GLCDv3.h>

In the documentation i have seen that API calls will be more consistent. I guess that implements some of my suggestions long time back smiley

Unfortunately font data is still located in the header files.

Also bitbucket.org seems to be a nice replacement for google code. I wonder what is the difference to google code (except for the disabled download feature for google code in the next year).

All in all: Looks very promising.

Oliver

485  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: December 16, 2013, 03:04:05 pm
Hi

U8GLIB_ST7920_128X64_1X(sck, mosi, cs [, reset])
  --> single buffer software SPI variant (slowest)

U8GLIB_ST7920_128X64_1X(cs [, reset])
  --> single buffer hardware SPI variant

U8GLIB_ST7920_128X64_4X(sck, mosi, cs [, reset])
  --> quad buffer software SPI variant

U8GLIB_ST7920_128X64_4X(cs [, reset])
  --> quad buffer hardware SPI variant (fastest)

For hardware SPI is only available on pins 13 and 11. So by using
U8GLIB_ST7920_128X64_4X(6)
you have to connect clock to pin 13, serial data to pin 11 and chip select to pin 8.

I think, clock and serial data pins can be shared by two displays if the cs line is different (I have never tried this). For example:
U8GLIB_ST7920_128X64_4X(6)
U8GLIB_ST7920_128X64_4X(7)
Note that this will require 1K RAM.

Here are some FPS numbers, which i measured 9 months back (not directly comparable, because i only have a 192x32 display):
  ST7920_192X32_1X, SPI:    FPS: Clip=10.3 Box=5.5  @=7.2 Pix=3.9
  ST7920_192X32_4X, SPI:    FPS: Clip=10.9 Box=6.7  @=8.8 Pix=7.4
  ST7920_192X32_1X, HW SPI:    FPS: Clip=14.2 Box=6.3  @=8.7 Pix=4.3
  ST7920_192X32_4X, HW SPI:    FPS: Clip=15.3 Box=8.0  @=11.2 Pix=9.0

Hope this helps...

Oliver
486  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: December 15, 2013, 05:19:36 pm
Excellent.   smiley-grin

Oliver
487  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: December 15, 2013, 05:12:39 pm
Hi

Thanks for the feedback. Unfortunately i can not access the google+ pictures. Let me know if there are further problems.

Oliver
488  Using Arduino / Displays / Re: U8glib: Graphics Lib for LCDs and OLEDs on: December 15, 2013, 04:35:45 pm
Hi

What is your version of u8glib? Maybe you can also link to the datasheet of your display.

In principle it is better to start with the constructor which has the better layout, so I think the
U8GLIB_NHD_C12864 u8g(SCK, MOSI, CS, A0, RST)
should be the best starting point (assuming a correct layout).

By comparing the init sequences, the only difference with respect to the contrast is the contrast value itself. So it should be possible to get the same contrast as the DOGM128 constructor with he NHD constructor. How did you set the contrast?

Code:
u8g.setContrast(0x018*4);
should give the same contrast as for the DOGM128 init code.

Oliver
489  Using Arduino / Displays / Re: T6963C error on: December 15, 2013, 01:03:42 pm
Quote
  Notes:
    The font selection pins should generate the 8x8 font.
    For the MGLS240128TZ only FS1 is available on pin 18.
    FS1 must be low to generate the 8x8 font.

This is also described at the end of this page (before the comments):
http://code.google.com/p/u8glib/wiki/device

All in all i see this as a valuable contribution to u8glib. Let me pay the beer...

Oliver
490  Using Arduino / Displays / Re: T6963C error on: December 15, 2013, 11:02:18 am
Amazing work. Thanks a lot.
As a conclution, U8glib will work correctly if FS1 is set to GND, correct?
In fact, U8glib has been written by assuming that FS1 is set to GND. From my perspective i do not see a need to support the 6x8 mode for the T6963 controller. All graphics output can be done in 8x8 mode, correct?

All in all good pictures and nice summery so far. I will try to send the beer via paypal  smiley-wink
Please send me a PM with your e-mail for this...

Oliver
491  Using Arduino / Displays / Re: T6963C error on: December 14, 2013, 03:53:32 pm
Are you able to fix U8glib also? I guess the setup in http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_t6963_240x64.c is wrong. For fixing U8glib, i will, for sure, pay a beer...

Oliver
492  Using Arduino / Displays / Re: T6963C error on: December 10, 2013, 06:24:43 pm

It is there. Quote from the refered manual:
Quote
Befehlssatz des T6963C
Interne Beschaltung:
MD0, MD1, MD2, FS0: GND
MDS, MD3: VDD
FS1: GND (LB3 offen, 8x8)
FS1:VDD (LB3 zu, 6x8)
Where I personal would guess that "LB" means "Lötbrücke" (=solder bridge). I bet its closed... According to that statement it should be open (connected to GND). The remaining question is: Where to find this LB3. The manual is not that clear about this.

Oliver
493  Using Arduino / Displays / Re: T6963C error on: December 09, 2013, 03:03:24 pm
Hi DEAFBOY

Good work so far. I never managed to make these old TS6963 libs to display something (but it might be due to my wrong hardware setup).
The remaining vertical lines might be there because of a wrong level at the FS (or FS1/FS2) input pins of your display: The one FS or both FS1 and FS2 *must* be connected to GND (0V). These pins do not only change the font, but also the memory layout.

Oliver

494  Using Arduino / Displays / Re: T6963C error on: December 08, 2013, 03:02:30 pm
Hi

Some time back i tried the existing T6963 librarys. As far as i remember, none of them had been ported to Arduino 1.0 (this is also true for your attempt).  But also using Arduino 0022 had failed to work.  Finally i decided to add support for the T6963 displays to U8glib (http://code.google.com/p/u8glib/): U8glib will work with Arduino 1.0.5 and usually all new releases of U8glib and Arduino are tested with my T6963 display.

Grüße aus Böblingen,
Oliver




 
495  Using Arduino / Programming Questions / Re: Sleep mode & u8glib & ST7920 on: December 04, 2013, 12:33:40 am
Hi

The line
if ( draw_state >= 9*9)
has been modified by you. The original number was 8*8 which is the state value to restart the sequence again.
The graphics test sequence has 8 pages with are divided into 8 sub steps. These 8 sub steps are extracted and used here:
Code:
  switch(draw_state >> 3) {
    case 0: u8g_box_frame(draw_state&7); break;
    case 1: u8g_disc_circle(draw_state&7); break;
    case 2: u8g_r_frame(draw_state&7); break;
    case 3: u8g_string(draw_state&7); break;
    case 4: u8g_line(draw_state&7); break;
    case 5: u8g_ascii_1(); break;
    case 6: u8g_ascii_2(); break;
    case 7: u8g_extra_page(draw_state&7); break;
  }
If you add a new page, then the values will be 9*8. If you add two new pages, then this will be 10*8.

My suggestion was to place the sleep command outside the picture loop. That means: Place it in the loop() procedure:
Code:
void loop(void) { 
  // picture loop 
  u8g.firstPage(); 
  do {
    draw();
  } while( u8g.nextPage() );
 
  // increase the state
  draw_state++;
  if ( draw_state >= 9*8 )
  {
    draw_state = 0;
    sleepNow()         // here we put the arduino to sleep
  }
 
  // rebuild the picture after some delay
  delay(150);
}

Please note that i have never used the wake up procedures. I can not tell if these procedures are correct or not.

Oliver
Pages: 1 ... 31 32 [33] 34 35 ... 102