MIOS32 LCD driver: does one exist for ST7565P

[Duggle]

Hi TK and All,

well Im back after some years! (Very excited regarding the amazing state of mbhp development, congratulations!)

I have my core32’s pcb,parts,JTAGtiny on order and have installed and tested the build tools.

I’m interested in developing a driver for a ST7565P based graphic LCD display. First of all is there an equivalent driver already?

I want a starting exercise (on mios32) with a clear goal, and I have access to many of these displays.

It would seem that following the pattern of the existing drivers is a fairly straight forward process for writing support for a new one. I guess the only thing that complicates it slightly is that the

variant display device I have (CV9007, based on ST7565) has SPI interface only (2 wire plus 3 control lines).

Is it possible to easily support connection to any of the available SPI ports (of the 3 available)?

Ive been pouring over the docs and getting familiar, I guess I’m fishing for any advice you guys may have for me at this point.

Thx,Cheers.

[philetaylor]

Hi.

The ST7565 is pretty well supported by MIOS32 (and MIOS) as it is the controller used by the EA DOGM and DOGL displays!

The driver is: http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fmodules%2Fapp_lcd%2Fdog_g%2F

The only thing you might need to change is the initialization as your display may be different to the “DOG”.

The driver uses software SPI (bit-banged) on the standard LCD port. This also allows up to 8 displays to be connected on the same port

Cheers

Phil

[Duggle]

Awesome, thanks.

I have good reference code for the display I’m using so I’ll look at the initialization.

If I find differences I’ll eventually commit the modified version of the driver to the repo.

thx again.

[Duggle]

OK (looking at the examples I have) Ive convinced myself they use the same instruction set, I’ll wire one up and try the existing DOG code.

For convenience, is there a wiring diagram like for the other displays documented uCapps/LCD Module?

thx

[philetaylor]

Here is a quick circuit that I “knocked-up” for Ultra some time ago.

Please note that the connections to the backlight are backwards… B+ should go to A1,2,3 and B- to C1,2,3. (I never got round to fixing the diagram!)

Also for the CORE32, the 220ohm resistors on the inputs aren’t required (as the CORE32 operates at 3.3v). The voltage divider circuit is there to provide 3.3v to the display from Vd (which is 5v on both CORE8 and CORE32) so if your display can take a 5v supply this may not be required either.

Cheers

Phil

[Duggle]

Thanks so much!

It seems all very straight forward.

Looks like smash’s shop is backed up a little, so I wont be able to report success until I get my cores.

[T.K]

Welcome back, Doug!

Best Regards, Thorsten.

[pcbatterij]

Here is a quick circuit that I “knocked-up” for Ultra some time ago.

Please note that the connections to the backlight are backwards… B+ should go to A1,2,3 and B- to C1,2,3. (I never got round to fixing the diagram!)

Also for the CORE32, the 220ohm resistors on the inputs aren’t required (as the CORE32 operates at 3.3v). The voltage divider circuit is there to provide 3.3v to the display from Vd (which is 5v on both CORE8 and CORE32) so if your display can take a 5v supply this may not be required either.

Cheers

Phil

Phil,

does this also apply for the dogm128 display?

cheers

Jef

[philetaylor]

Hi Jef.

Sorry I have been away for a few days… Yes the DOGM-128 display should work fine.

Phil

[pcbatterij]

Hey,

Could anybody let me know if the ST7565 display is working with mios32?

I have made a PCB with the toner transfer method using the schematic of PhileTaylor…but I got nothing on my screen.

After looking through the wiki and the forum, I then put a new bootloader on my LPC17 board and changed the lcd_type to GLCD_DOG, with 128, Height 64, num_x 1, num_y 1. put SeqV4 back on the LPC17, but…nothing on the screen.

I even compiled the tutorial 021_GLCD to test my display: nothing on the screen

I don’t know what I can do to make the ea dogm to work, it might be the display itself that is broken as there is a few diagonal lines of dark pixels on the screen?!

cheers Jef

[T.K]

It works with my STM32 core (where I’ve soldered the display cables directly on the PCB).

I will desolder the display and check it with the LPC17 core later today.

Best Regards, Thorsten.

[T.K]

I checked the DOGM128 driver on the LPC17 based core, and it works (basically) - there was a bug which caused that only the left half of the display was written, but the initialization was already working correctly.

Here the schematic: http://www.ucapps.de/mbhp/mbhp_lcd_dogm128_mios32.pdf

And here the picture which you should see with the apps/mios32_test/app_lcd/dog_g application:

Best Regards, Thorsten.

[pcbatterij]

Thx Tk,

The display works fine, I kept the 10K resistor and only used the 1uF Caps though.

But now I am a bit stuck by the following bit from the seq_lcd.c file:

/////////////////////////////////////////////////////////////////////////////

// Local definitions

/////////////////////////////////////////////////////////////////////////////

// can be overruled in mios32_config.h

#ifndef LCD_NUM_DEVICES

define LCD_NUM_DEVICES 2

#endif

#ifndef LCD_COLUMNS_PER_DEVICE

define LCD_COLUMNS_PER_DEVICE 40

#endif

// shouldn’t be overruled

#define LCD_MAX_LINES 2

#define LCD_MAX_COLUMNS (LCD_NUM_DEVICES*LCD_COLUMNS_PER_DEVICE)

When I change the LCD_MAX_LINES, I get an error when compiling the SeqV4 project.

Could you point me in the good direction to be able to use the 8 lines of the 1 display instead of the 2 lines from several displays?

Do I need to rewrite everything that’s related to LCD or is there a way a round?

cheers,

Jef

[T.K]

Well, you are hitting the RAM limitations again - the MBSEQV4 firmware allocates almost the complete 64k range, if you want to stay compatible with future extensions, you have to search for other ways.

I should also prewarn you that changing such a global setting would result into a lot of adaption work in all the seq_ui_*.c files!

In general you’ve two possibilities:

1. branch the user interface like I did in midibox_seq_v4_lite - this allows you to create a dedicated UI from scratch. This will probably the most simple solution as everything is under your control.

When you look into midibox_seq_v4_lite/core, you will notice that the number of files is very reduced in this variant -> better oversight.

2. alternatively, re-use the existing UI and just change the display position of the second LCD device in seq_lcd.c, SEQ_LCD_Update() function

You would also have to find a way to adapt SEQ_LCD_InitSpecialChars() for graphical LCDs - I don’t have an automated solution for this yet… it’s something what you would have to develop by yourself.

This approach is pragmatic, but the display output will look ugly in comparison to a fully customized adaption.

If you are asking me: creating a new UI from scratch (solution 1) is the best way to utilize this GLCD, because the original user interface hasn’t been created for this.

Since you are using different buttons/encoders as well, sooner or later you would have to do a lot of changes in different files anyhow, with the disadvantage that you won’t get the changes that I’m doing in future.

Best Regards, Thorsten.

[pcbatterij]

Thx Tk,

I found a solution for the screen, for now.

What I will do is: during the my PCB testing I will try to keep the SeqV4 UI as much as possible the same.

Once I now that my PC design is OK, then I’ll start to make a new UI (using a lot of your code )

so far so good with my DIY project

Cheers,

Jef