Jump to content

STM32F4-CORE and LCD-Display


Recommended Posts

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) ??

 

mOnO

 

Link to post
Share on other sites

Yes, the app_lcd/universal driver is still under construction:

 

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

 

2) I've to test all LCD types and connection variants and tune the timings for best performance.

 

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

 

Best Regards, Thorsten.

Link to post
Share on other sites

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!

 

mOnO

Link to post
Share on other sites

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

 

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...

 

thx,

mOnO

 

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

Edited by mono
Link to post
Share on other sites
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...

 

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! 

 

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.

 

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! ;-)

 

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

 

Best Regards, Thorsten.

Link to post
Share on other sites
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! ;-)

 

So - please try it again with a fresh download.

 

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...;-)

 

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.

 

thanks,

mOnO

Link to post
Share on other sites

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

 

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...

 

have you tried a ks0108-display yet ??

 

regards,

mOnO

 

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)...

Edited by mono
Link to post
Share on other sites

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...

 

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...;-)

 

kind regards,

mOnO

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

 

Great!

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

 

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

 

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

 

Best Regards, Thorsten.

Link to post
Share on other sites

nice one! the comparison tool looks very useful...

 

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.

 

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 ??

 

kind regards,

mOnO

 

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

 

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

 

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.  :wink:

 

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.

 

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?

 

Best Regards, Thorsten.

Link to post
Share on other sites

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.

 

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 ?

 

have used this one: http://www.midibox.org/mios32_toolchain/

 

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

 

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

 

kind regards,

mOnO

 

 

 

 

 

-

Link to post
Share on other sites

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.

 

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

 

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...

 

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)

 

 

and its 18ms

 

And which time do you measure on a LPC1769?

 

Best Regards, Thorsten.

Link to post
Share on other sites

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

 

here is the result:

 

                 mios32_toolchain    gcc-arm 4.8_20131204

lpc17        28ms                        27ms

stm32f4    18ms                        17,8ms

 

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!

 

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...

 

kind regards,

mOnO

 

 

Link to post
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...
×
×
  • Create New...