Jump to content

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


cube48
 Share

Recommended Posts

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
Link to comment
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

Link to comment
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 ...? 

Link to comment
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
Link to comment
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.

Link to comment
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
Link to comment
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
Link to comment
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.

Link to comment
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

Link to comment
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

Link to comment
Share on other sites

  • 1 year later...

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
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...