cube48

[SOLVED] Can't make two OLED LCD's working together

23 posts in this topic

I have the MBHP_CORE_STM32F4 ready with the board, no MIDI_IO, no CS yet (Wilba's CS board is on the way).

 

Board is powered via USB, LCD power jumper is on 5V.

 

The LCD's I try to connect are Raystar 40x2 OLED LCD's, the same

 

When I connect them both, I get random characters/dots. If I connect only one of them, no matter which slot (J15A/B), they display the appropriate content (left/right display stuff). 

 

I tried swapping displays and cables, all is fine, it's just that they don't run/initialize? together.

 

When browsing the forum earlier, I have the vague feeling that somebody already had similar issue but I'm not able to find that thread again.

 

Can somebody please give me a hint what to check? Thanks in advance.

 

 

post-21295-0-24129100-1421020706_thumb.j

post-21295-0-49702700-1421020727_thumb.j

post-21295-0-22177000-1421020748_thumb.j

Edited by cube48

Share this post


Link to post
Share on other sites

Hola,

 

yes, had a similar problem, but with (nonstandard) VFDs:

 

it involved a bit of driver hacking (changed 8bit access mode to 4bit mode, which helped, and separated the control lines, which i nowadays think was not necessary, but you learn ;-))

 

Many greets,

Peter

Share this post


Link to post
Share on other sites

You might test it using a power adapter vs. usb. 

Share this post


Link to post
Share on other sites

Thanks for the tips. 

 

Tried the external power adapter but with the same result.

 

I wonder what can be different on LPC17 core which works fine with these OLED's as

 

LCD driver hacking is out of my league. It seems I'm stuck with expensive yet very nice displays.

 

My next step will be messing with bootloader params.

 

Perhaps I could also try 'one-ribbon' connection ...? 

Share this post


Link to post
Share on other sites

One ribbon connection is the same as two ribbons, just with fewer wires. :-)

Are you positive, that the OLEDs are exactly of the same brand and firmware revision as jbdivers?

 

Many greets,

Peter

Share this post


Link to post
Share on other sites

One ribbon solution was just desperate idea of desperate man who has no idea about LCD hacking :-D

 

I made a little progress ... sort of. I've changed the lcd_type to CLCD_DOG with bootloader update app and now the two displays show their content but only in first row. Content looks like smacked together, like two lines in one resulting in a bit chaotic stuff. Forcing the lcd_width/height has no effect doesn't help.

post-21295-0-13588400-1421151273_thumb.j

Edited by cube48

Share this post


Link to post
Share on other sites
Are you positive, that the OLEDs are exactly of the same brand and firmware revision as jbdivers?

 

I'm sure it's the same brand and model, Raystar doesn't have any other 40x2 OLED display. Bought it even from the same store (TME Poland). But I can't speak of the FW revision.

Share this post


Link to post
Share on other sites

if you´ll send me two for permanent testing, i could try to hack the driver! :smile:

 

.

.

.

 

...was just joking!

I´d love to build another SEQ with those displays later on that year, but it will take while - hope you manage to find the problem, if not, and no one else has ideas, i´d order two of them, too, to test. Later on :-).

 

edit:

it is probably timing related, as with many OLEDs, they could also have changed it from one firmware revision to the next - if you want to experiment, look into the mios32 repository /trunk/modules/app_lcd/universal/app_lcd.c and experiment with all timing specific code, e.g. look for delay_ctr and adjust the loop limits.

 

!!! There could be differences between LPC17 and STM32F4, as the latter board is faster, and this would explain why it works for jbdiver!

Some internal loops expect fixed runtime behaviour, like 4uS @ 72mHz - play around in app_lcd.c, line 474 and following. Good luck!

You could also test-swap the core for a LPC17 and see if that helps, if the theory is true, the displays are identical, only the timing code behaves differently on the different cores.

 

Peter

Edited by Hawkeye

Share this post


Link to post
Share on other sites

Although it doesn't make too much sense with what you describe, you could check the 74HC595 shift register and its resistor array.

 

Pins soldered correctly, right orientation (pin 1 dot etc.) or even a spare chip if you have one.

Share this post


Link to post
Share on other sites

If you send me the OLED displays, I can analyse the problem at my side and ensure future compatibility.

 

Of course, I will send them back after testing/troubleshooting.

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

Oh ... that's very generous! PM'd.

Share this post


Link to post
Share on other sites

Cool! :smile: TK., when you have them in hand, would you have a look at the timing? It might be, that because the STM32F4 is faster than the LPC17, the number of waitcycles is not sufficient anymore - and that causes the phenomenon, that it works for jbdiver (LPC17) and not for cube48 (STM32F4).

 

Many greets!

Peter

Edited by Hawkeye

Share this post


Link to post
Share on other sites

Just a small update ... displays went to TK yesterday.

Share this post


Link to post
Share on other sites

And I got the OLEDs today.

 

Observations:

- same behaviour at my side when OLEDs connected to a STM32F4 core

- OLED was working when I connected a common LCD to J15B instead of the second OLED

- both OLEDs are working together on a LPC17 core

 

In the app_lcd driver I found the difference between STM32F4 and LPC17: for LPC17 the pins which drive E/RW/RS are always configured in Push-Pull (PP) mode, for STM32F4 these pins are configured for Open-Drain mode (they are pulled to the LCD voltage with external pull-up resistors).

 

The LPC17 variant was actually a workaround for a weakness in the LPC17 microcontroller.

 

However, I added a new CLCD type "CLCD_PP" which will configure the pins in Push-Pull mode instead of Open Drain

 

Observations:

- OLEDs still failing at 5V LCD voltage

- but OLEDs are working at 3.3V LCD voltage!

 

-> solution found! :-)

 

And an explanation as well: the datasheet specifies an VIH (input high) level of 0.9 * VDD, which can't be achieved via the pull-up resistors when more than one OLED is connected to the same pin.

 

By reducing VDD to 3.3V, and setting the pins in the "stronger" push-pull mode, the spec isn't violated anymore accordingly displays are working properly.

 

 

@cube48: I will send back the OLEDs tomorrow, you may receive them saturday - be prepared for a nice weekend! :-)

The new CLCD_PP type has to be configured in the bootloader with "set lcd_type CLCD_PP".

As long as no new bootloader has been released, you can also set it with "set lcd_type 0x02", which has the same effect.

In addition, you will need a new MBSEQ V4 release which will be available saturday as well - maybe together with the screen saver ;-)

 

Best Regards, Thorsten.

Share this post


Link to post
Share on other sites

TK stands for The King. You are awesome. Thanks a lot!!!

Share this post


Link to post
Share on other sites

Incredible, how fast TK provide a solution for everything! Very nice to have these Raystar OLEDs as another option, thanks!

Share this post


Link to post
Share on other sites

Big thanks to TK again!

 

I've tried the latest MBSeq V4 release (4.088 pre5) and both displays work smoothly when following TK's instructions above.

 

This is how the new screensaver looks like:

 

https://vine.co/v/OjdHq3BznpJ

 

Attaching a picture of both OLEDs running along too.

 

Can mod's add [sOLVED] to the title of this thread please?

 

Thanks to everyone for ideas and support! This is really great community!

post-21295-0-81080200-1421572727_thumb.j

Share this post


Link to post
Share on other sites

I'm just reading this topic. I had the same issue in an earlier, not MB related project with Raystar OLED (4*20) and F4Discovery. The solution was to lower the 5V VDD of OLED by a diode. It could be an alternative solution if the 3.3V regulator on the core was overloaded. And this OLED is for 5V VDD according to the type number. Attached a part of my schematics.

Anyway these Raystars are really cool LCD alternatives. 

post-9695-0-99269900-1421848532_thumb.jp

Share this post


Link to post
Share on other sites
Can mod's add SOLVED to the title of this thread please?

You can do that yourself, just edit your initial post!

Share this post


Link to post
Share on other sites

Ahh ... I didn't see that option in basic editor when I searched for it before, not noticing I was in 'basic' edit mode. But it's possible in 'full' editor. Thanks for a hint.

Share this post


Link to post
Share on other sites

Sorry if this obvious and I am just dense: 

" The new CLCD_PP type has to be configured in the bootloader with "set lcd_type CLCD_PP". "

I assume this is done in the MIOS studio terminal? (on the STM32F4 core)

Got some green ones :)

Share this post


Link to post
Share on other sites

Just had to fiddle with this the other day :). Install the bootloader hex, that's where you store LCD settings. Note: if you've already bootstrapped your Core the normal MIDI-USB works fine. On Windows you have to restart MIOS Studio every time the F4 board resets. 

And don't forget to "store" the settings when done.

 

Edited by latigid on

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now