# STM32F4-CORE and LCD-Display

**URL:** <https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083>\
**Category:** Testing/Troubleshooting\
**Tags:** ks0108, stm32f4, lcd\
**Created:** [January 14, 2014, 3:57pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083 "2014-01-14T15:57:16Z")\
**Posts on this page:** 17\
**Page:** 1

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 14, 2014, 3:57pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/1 "2014-01-14T15:57:16Z")

</div>

Im planning a prototype of the stm32f4-core using the stm32f4discovery. unfortunately i cant find any notes on J28. nothing in the diagram and nothing in the mios32-include-files either…

basically i want to connect two ks0108 lcd-displays, which will need 4 cs-signals. on the lpc17-core they are provided via J28, but theres nothing like that on the stm32f4-core. am i missing something or is this just not implemented (yet) ??

&nbsp;

mOnO

&nbsp;

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 14, 2014, 10:17pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/2 "2014-01-14T22:17:05Z")

</div>

Yes, the app\_lcd/universal driver is still under construction:

&nbsp;

1. I’ve to change the way how the extra pins are accessed for different boards, because all the #if/#elif options look like a big mess

&nbsp;

1. I’ve to test all LCD types and connection variants and tune the timings for best performance.

&nbsp;

However, I’ve added a temporary solution for you so that you can try out a KS0108 based GLCD - I haven’t tested it at my side (crossing fingers!)

The CS pins should be available at J10B:D8 .. J10B:D11 now

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 15, 2014, 6:10am UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/3 "2014-01-15T06:10:16Z")

</div>

excellent! looks like its time to start building up a prototype for the stm32f4discovery. i will do that asap and let you know how it goes. the solution with the general purpose i/os is quite neat and there are still 12 lines of them available to control even more displays…😉

thx tk!

&nbsp;

mOnO

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 18, 2014, 11:22am UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/4 "2014-01-18T11:22:53Z")

</div>

im still working on my prototype for the stm32disovery and im hoping to get this done today/tomorrow.

&nbsp;

in the meantime ive updated the mios32\_toolchain for the stm32f4 and compiled the ks0108-demo-app, which compiles just fine. obviously the lcd-parameters for the ks0108 are not set yet on my board. so i wanted to set them, but compiling the bootloader-updater-application fails, because of the app\_lcd/universal-driver. whenever you have chance, can you try to compile the updater for the stm32f4 ? there are too many errors and i agree that all these compiler-options are really a mess…

&nbsp;

thx,

mOnO

&nbsp;

ps. ive compiled the ks0108-demo-app using the old universal-driver. with the updated version compiling fails as well…

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 18, 2014, 12:47pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/5 "2014-01-18T12:47:55Z")

</div>

> but compiling the bootloader-updater-application fails, because of the app\_lcd/universal-driver. whenever you have chance, can you try to compile the updater for the stm32f4 ? there are too many errors and i agree that all these compiler-options are really a mess…

&nbsp;

I’m always doing this whenever I update central code.

It’s completely automated at my side for all derivatives - therefore I’m surprised that it fails at your side!&nbsp;

&nbsp;

Maybe you’ve changed a file locally which is not in sync with the repository anymore?

I would propose that you download the complete repository again (e.g. into a separate folder) and try it from there.

&nbsp;

However, I just have finalized the new universal LCD driver, again many changes in the MIOS32 base, and again the danger that you miss an update if you are doing local changes in MIOS32 sources! 😉

&nbsp;

So - please try it again with a fresh download.

And for the case that you are still not able to compile, here are the prebuilt binaries of the new bootloader:

[http://www.ucapps.de/mios32/mios32\_bootloader\_v1\_014.zip](http://www.ucapps.de/mios32/mios32_bootloader_v1_014.zip)

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 18, 2014, 6:30pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/6 "2014-01-18T18:30:02Z")

</div>

> However, I just have finalized the new universal LCD driver, again many changes in the MIOS32 base, and again the danger that you miss an update if you are doing local changes in MIOS32 sources! 😉
> 
> &nbsp;
> 
> So - please try it again with a fresh download.

&nbsp;

alright. have updated my folder and finally i can compile the ks0108-demo-app & the updater with no errors. i suppose, i need to find a better way of organizing my files within the mios32-folder…😉

&nbsp;

unfortunately i havent finished my board yet, but it will be finished tomorrow and i will test it straightaway. i let you know here, how it works anyway.

&nbsp;

thanks,

mOnO

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 19, 2014, 5:19pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/7 "2014-01-19T17:19:24Z")

</div>

Please note that I just had to change the schematic.

J10B.D11 is now connected to PE2, and not to PE3 anymore to solve a conflict with the onboard MEMs chip.

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 19, 2014, 5:29pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/8 "2014-01-19T17:29:33Z")

</div>

board is finished so far, but the ks0108-display doesnt work. there is only crap on the screen. sometimes you can see parts of the letters, but that was it. have tested all the pins on the board and even on the display with the testlcdpin-command and it looks fine! i noticed just one problem. the 3.3v voltage is slightly below 3v. the datasheet of my display is here: [http://www.topwaydisplay.com/Pub/Manual/LM12864MBC-Manual-Rev0.1.pdf](http://www.topwaydisplay.com/Pub/Manual/LM12864MBC-Manual-Rev0.1.pdf)

&nbsp;

it wants a minimum of 3.5v on the pins, but works fine with 3.3v on my lpc17-board. so i decided to short the diode d3 on the discovery-board to get a bit more voltage out, but with the same result on the screen. my next attempt is to use an external 3.3v-regulator, if i can find one, but the problem is surely not on your (software)-side…

&nbsp;

have you tried a ks0108-display yet ??

&nbsp;

regards,

mOnO

&nbsp;

ps. just seen your latest change to the diagram. thx for letting me know, but the problem is the same with only one display (cs1 & cs2 connected)…

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 19, 2014, 5:53pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/9 "2014-01-19T17:53:51Z")

</div>

KS0108 works at my side (I can only check the non-inverted type, 0x80)

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 19, 2014, 6:05pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/10 "2014-01-19T18:05:19Z")

</div>

lucky you are! i think you mean 0x81 (GLCD\_KS0108). im still looking for the voltage-regulator…

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 19, 2014, 7:42pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/11 "2014-01-19T19:42:09Z")

</div>

ok ive tried a 3.3v voltage-regulator connected to the 3v-pin of the discovery-board and you really get 3.3volts on the lcd-pins, but it still doesnt work. so ive thought, i update the sources (again) to see what happens and voila it works with one display ! dont know what the difference between 1.014 and 1.015 is, but something magically changed…

&nbsp;

the second display still doesnt work. cs3 is connected to pc15 and cs4 is connected to pe2. have tried different parameters for lcd\_num\_x and lcd\_width, but nothing changes.

thx so far anyway…😉

&nbsp;

kind regards,

mOnO

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 19, 2014, 7:55pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/12 "2014-01-19T19:55:11Z")

</div>

> so ive thought, i update the sources (again) to see what happens and voila it works with one display ! dont know what the difference between 1.014 and 1.015 is, but something magically changed…

&nbsp;

Great!

Seems that the immense effort that I spent yesterday to qualify various displays at various cable lengths on the STM32F4 was worthwhile 🙂

&nbsp;

You can retrieve the differences with the comparison tool of the svnmios page:&nbsp;[http://svnmios.midibox.org/log.php?repname=svn.mios32&path=%2F&isdir=1&](http://svnmios.midibox.org/log.php?repname=svn.mios32&path=%2F&isdir=1&)

&nbsp;

Select revision 1938 and 1936, and then click on the compare button.

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 20, 2014, 5:36am UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/13 "2014-01-20T05:36:34Z")

</div>

nice one! the comparison tool looks very useful…

&nbsp;

got the second display to work! the enable-signal of the second display needs to be the same as for the first one. lcd\_num\_x is set to 1 and lcd\_width is 255, which gives me a width of 256 with 2 128-pixel-width displays.

&nbsp;

the only drawback seems to be the MIOS32\_LCD\_PrintString-Function. if you print the static screen in the while-loop (KS0108-Test), as it is, both displays and the four leds on the board flicker. whereas if you print the static screen before the while-loop it runs perfect without any flickering. i cant believe, that the printstring-function works slower on the stm32f4 than on the lpc17, where the ks0108-test runs without flickering out of the box. do you see any reason for that ??

&nbsp;

kind regards,

mOnO

&nbsp;

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 20, 2014, 5:47pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/14 "2014-01-20T17:47:47Z")

</div>

> the only drawback seems to be the MIOS32\_LCD\_PrintString-Function. if you print the static screen in the while-loop (KS0108-Test), as it is, both displays and the four leds on the board flicker. whereas if you print the static screen before the while-loop it runs perfect without any flickering. i cant believe, that the printstring-function works slower on the stm32f4 than on the lpc17, where the ks0108-test runs without flickering out of the box. do you see any reason for that ??

&nbsp;

It’s either related to a wrong configuration or to a misinterpretation of the LED at your side.

&nbsp;

I tested the execution time of the while() loop in apps/mios32\_test/app\_lcd/ks0108.

On a LPC1769 one iteration takes ca. 10 mS, whereas on a STM32F4 it takes ca. 5 mS - so, definitely faster.&nbsp; 😉

&nbsp;

Possible wrong configuration: check the LCD parameters in the bootloader.

For KS0108 you’ve to specify lcd\_num\_x 1 and lcd\_num\_y 1, because the two GLCDs are handled like a big display with 4 segments (this is the way how the driver is implemented)

If you’ve specified lcd\_num\_x 2, the driver would try to access a non-existing GLCD, and this slows down the execution.

&nbsp;

Possible misinterpretation: are you testing from a background task, or from a main task (e.g. APP\_Tick())?

What else is running in your application?

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 20, 2014, 6:40pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/15 "2014-01-20T18:40:27Z")

</div>

my configuration is exactly, as it should be: lcd\_num\_x = 1 & lcd\_num\_y = 1. have used the original unmodified (!) file from apps/mios32\_test/app\_lcd/ks0108. in this file the while() loop is executed in the background task. as far as i am concerned there are no other tasks running anyway.

&nbsp;

however i have measured the execution time of the while() loop and its 18ms on my board. maybe there is a problem with the compiler ?

&nbsp;

have used this one: [http://www.midibox.org/mios32\_toolchain/](http://www.midibox.org/mios32_toolchain/)

&nbsp;

and i am just downloading this one to see, if it makes a difference: [https://launchpad.net/gcc-arm-embedded](https://launchpad.net/gcc-arm-embedded)

&nbsp;

unfortunately the download is really slow (about 1 hour). i will re-compile the source again, once ive updated the compiler…

&nbsp;

kind regards,

mOnO

&nbsp;

&nbsp;

&nbsp;

&nbsp;

&nbsp;

-

---

<div class="post-metadata">

**Author:** ![T.K](https://forum.midibox.org/user_avatar/forum.midibox.org/t.k/32/7_2.png) [@T.K](https://forum.midibox.org/u/T.K)\
**Post date:** [January 20, 2014, 7:07pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/16 "2014-01-20T19:07:27Z")

</div>

The compiler can’t cause such a difference, and as long as you are using the recommended one (mios32\_toolchain), it’s ensured that you’ve exactly the same setup like me.

I wouldn’t use other compiler versions, especially since they could generate code with a different timing behaviour which could cause failures.

&nbsp;

> however i have measured the execution time of the while() loop and its 18ms on my board.

&nbsp;

The access time mainly depends on the performance of your display, and KS0108 are known for their bad timings (therefore these displays are also not supported so well from my side anymore…).

E.g. whenever a data byte is written into display RAM, the driver has to poll a busy flag, and the time it takes for your display to get unbusy depends on the KS0108 clock (which is generated internally), and also on the temperature, etc…

&nbsp;

GLCDs with modern controllers (such as DOGM, but also SSD1306 and SED1520) can take over the data immediately, so that no busy polling is required, and deterministic access times can be expected (which leads to a much better performance of course)

&nbsp;

&nbsp;

> and its 18ms

&nbsp;

And which time do you measure on a LPC1769?

&nbsp;

Best Regards, Thorsten.

---

<div class="post-metadata">

**Author:** ![mono](https://forum.midibox.org/user_avatar/forum.midibox.org/mono/32/464_2.png) [@mono](https://forum.midibox.org/u/mono)\
**Post date:** [January 20, 2014, 8:11pm UTC](https://forum.midibox.org/t/stm32f4-core-and-lcd-display/18083/17 "2014-01-20T20:11:05Z")

</div>

well, that was a bit of excitement! had to swap boards, toolchains & enviroment-variables…,-)

&nbsp;

here is the result:

&nbsp;

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; mios32\_toolchain&nbsp;&nbsp;&nbsp; gcc-arm 4.8\_20131204

lpc17&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 28ms&nbsp;&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 27ms

stm32f4&nbsp;&nbsp;&nbsp; 18ms&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 17,8ms

&nbsp;

AND i noticed, that you are right! the trouble is, that you cant see the flickering on the lpc17, because its far too slow! i wouldnt even say, that the led on the lpc17 “flickers”. its more like a “blinking”. didnt realize that about 2 month ago, when i built up my lpc17-board. also the “knobs” are not rotating as smooth as on the stm32f4. so it was a misinterpretation on my side, sry, and probably the reason, why my lcd-displays are quite cheap (around 7 pounds each). dont get me wrong, i still like them, but i will look out for a replacement type with a modern controller, when i get chance. i bought them from china and would rather go for rs/farnell as a supplier, just because they are more reliable and can deliver next day (for free) as well!

&nbsp;

so i would say: problem solved! ks0108 works just fine on the stm32f4. will add some more components to my stm32f4-board in the next days. mainly sd-card, i2c and midi. we shall see…

&nbsp;

kind regards,

mOnO

&nbsp;

&nbsp;
