Jump to content

Fleck

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by Fleck

  1. I cannot make photo of this, you should try it out, but there are sync problems, how can we fix this? Download; unpack; make flash and see for your self http://fleck.rullz.lv/uGFX/f7_HAL_uGFX_test.zip Expected: nice, clean, solid white line bouncing
  2. Version 1.0.0

    1,506 downloads

    This is a ready-to-run demo for the STM32F746G-Discovery board containing everything required to compile & run: µGFX library CMSIS STM32CubeF7 (ST HAL) This demo was created by our community member @Fleck. It's an implementation of the game "Sokoban". Although this download is a demo project for the STM32F746G-Discovery it can be adopted easily to run on any other µGFX compatible platform. Please note that this demo has not been optimized for speed, size or any particular platform.
  3. OK, found it, problem is in the board file: boards/base/STM32F746-Discovery/board_STM32LTDC.h 1) Line 139 for PK0 MODER used is GPIO_MODER_MODER0_0 but should be GPIO_MODER_MODER0_1 2) Line 184 for PG12 AFRH is set to 14 (LCD_B1), but needs to be 9 (LCD_B4), LCD_B1 we have on PJ13! Now there is only one thing left, HardFault when enabling RGB888 mode in drivers config file, I overcome this by setting LTDC_PIXELFORMAT to LTDC_FMT_ARGB8888, LTDC_PIXELBYTES to 4 and LTDC_PIXELBITS to 32, also, in DMA2D init if RGB888 is selected, I set DMA2D to ARGB8888. Yes I know, this is not the right way, but, at least, it doesn't HardFault, HardFault error was unaligned memory access, 24 bits on 32bit cpu?!? Dunno why, I am not so smart in all this, and last line in gdisp_lld_STM32LTDC.c executed before HardFault is 277: PIXEL_ADDR(g, pos)[0] = gdispColor2Native(g->p.color); Anyways, now I can continue do what I wanted to do on F7-Disco heh and you have all the info needed to fix all those problems, case closed!
  4. OK, I have tried STM32CubeF7 demo/example code, there is a picture frame demo code, I uploaded my BMP to sdcard and checked it out, it's definitely not a property of a display, looks great! Next, I will try to find where the problem lies! Here's the image running STM32CubeF7 demo/example code: http://imgur.com/1e3PwtV as you can see, nice and smooth! Will let you know if I find something more on this problem!
  5. You know me, it will take me whole day to get something running on F429i... answer is still the same!
  6. Nope, F429i uses chibios, no CubeHAL example there!
  7. Don't know, ST demo images in alarm app looks OK, there are gradients, shadows, also ST logo on startup looks OK to me. Can't believe ST used so bad display in 2015. Can't believe SSD1289 performs better. Just can't!
  8. Hi, as Tectu is busy those days, I decided to post my question here. No matter what pixel format I use (RGB565 or RGB888) I get low quality image on screen, I use 24bit bmp, here's image of F7 on the left and F4 with SSD1289 on the right, you can see the quality difference: http://imgur.com/rR5K1i2 and bigger image of F7: http://imgur.com/VPzZ5GD, as you can see, colors are not smooth, like 256 color mode on old PCs Ideas?
  9. A simple tetris game using ChibiOS and uGFX Screenshot: Edit: This demo has been added to the official uGFX library. It can be found under /demos/applications/tetris. For source and better screenshots check git: https://bitbucket.org/Fleckz/ugfx-tetris/ Comments/suggestions, bad/good are welcome! Big thanks goes to Tectu!
×
×
  • Create New...