Jump to content

Joel Bodenmann

Administrators
  • Posts

    2,639
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Joel Bodenmann

  1. Multiple things need to be kept in mind when considering image caching. Whether it make sense to cache an image depends a lot on the user hardware/architecture as well as the application itself (how big the image is, what format/encoding the image is using, how often it needs to be drawn etc). As inmarket already said, caching an image means that a chunk of RAM will be allocated to store the entire decoded image. A decoded image is essentially a table of pixel values in the display controllers native color format. Working with an RGB565 format would mean that two bytes per pixel need to be allocated. A plain BMP file is already pretty much that. After a small header it's essentially a table of pixel values. This means that in terms of performance (as in saving CPU cycles for decoding) you won't gain anything when caching a plain BMP file. The next thing to consider is memory speed. This depends on the architecture of your device and the actual components used. In your case you're having both the ROM that stores the image as well as the RAM where you'd store the cached image on the same bus/peripheral (the FMC). Assuming that reading from your SDRAM is as fast as reading from the NOR would mean that the main gain would be that you don't need to spent time changing the peripheral configuration to switch between the two memories. Another important thing to keep in mind is hardware acceleration: In your case the DMA2D peripheral would allow to directly blit the entire image 1:1 without any CPU time involved at all. This is obviously a huge benefit and would save a lot of CPU time. In my opinion in your case it boils down to how often you need to draw the image, how big your RAM is and how fast you can access the NOR. I hope that helps... somehow. ~ Tectu
  2. Hi! Thank you very much for your feedback. We appreciate it a lot! We see what you mean and we will definitely do that. It sounds like a great idea! However, this might take some time as you said yourself that's quite a bit of work. We'll let you know once we're done! ~ Tectu
  3. Hello Sillvers and welcome to the community! The file/folder structure and the Makefiles provided with the library are very well tested and known to work without any issues. As inmarket already mentioned you're most likely pointing the GFXLIB variable to the wrong place. This variable should point to the top-level directory of the unmodified uGFX library directory. You can find some additional information about this here: http://wiki.ugfx.org/index.php/Getting_ ... grate_uGFX Let us know when you have any other questions. ~ Tectu
  4. Glad to hear that you got it working! We would love to include the corresponding drivers and board files into the repository Is that Linux driver now working nicely as a generic driver or what's the current state of that? ~ Tectu
  5. Sadly he's not able to help as he's currently on a trip (vacation). However, he sent me the files attached (GINPUT driver, board file, test project). He used this on a 3.2 Linux. The uGFX version he used this with was something between 2.3 and 2.4. I hope that helps you somehow... Please let us know how this turns out. ~ Tectu linux_ginput_event.zip
  6. Somebody I know has already written a generic event based touchscreen input driver for using touchscreens with uGFX on a linux system. I will ask him whether it would be possible to share that driver. That would save you some pain. ~ Tectu
  7. Hello sordfish and welcome to the community! It looks like we forgot to apply these changes. I put it on the ToDo list! Thank you for reminding us ~ Tectu
  8. You might want to store your calibration values once you performed the calibration. This way you can 'boot up' (starting uGFX by calling gfxInit()) without the need to calibrate again. Information on how to use the calibration interface can be found here: http://wiki.ugfx.org/index.php?title=To ... alibration ~ Tectu
  9. Just that we understand us correctly - you should be able to get this setup working without using pixmaps. For optimization that's definitely a good way to go but it should definitely also work without it. If you are having trouble getting the basic setup working without the pixmaps please do not hesitate to ask. We are happy to help where we can. You should be able to even use different bus speeds for the two by changing the SPI configuration in the acquire_bus() function so the board files. GDISPVMT_pixmap is line 33 of /src/gdisp/gdisp_pixmap.c. LLDSPEC is line 413 and 415 of /src/gdisp/gdisp_driver.h. All that does is either adding nothing or 'static' depending on whether you use just one or multiple displays. Judging from the compiler output you are lacking the inclusion of some files. Can you give some information about the build environment and the toolchain that you are using? Eg. are you using a makefile or the single-file inclusion etc. As this seems to be a bitbucket repository - is it possible that we get access to it so we can give the configuration a quick look? Please make sure that you use the latest master of the uGFX repository and that you integrated the uGFX library into your existing RPi project using either of these two methods: http://wiki.ugfx.org/index.php?title=Ge ... grate_uGFX ~ Tectu
  10. Hello and welcome to the community! Is it possible that you just forgot to enable pixmaps in your configuration file by setting GDISP_NEED_PIXMAP to TRUE? Otherwise, can you please show us the complete compiler output log? You definitely shouldn't get any error about LLDSPEC in any case. Just to be sure: Did you manage to draw to your display without using the pixmaps so far? Can you please also provide information about the IDE and the compiler that you are using along with the compiler output log? ~ Tectu
  11. Thanks, we will look into this. Might take a few days, tho. A few little side notes: The gradients on the F7 Discovery board look somewhat odd. You can set GWIN_FLAT_STYLING to TRUE in your configuration file to get rid of them. You can disable the µGFX start-up logo by setting GDISP_NEED_STARTUP_LOGO to FALSE you enabled an anti-aliased font but you haven't actually enabled font anti-aliasing. Set GDISP_NEED_ANTIALIAS to TRUE ~ Tectu
  12. Glad to hear that you got it working. I guess we'll make one or two short videos where we create a project from scratch to demonstrate the intended workflow as per your suggestion. ~ Tectu
  13. You want to change the 'Default Widget Style' of the GWIN Module. You can do that under Settings -> GWIN -> Default Style. The background property in the widget style only applies to the background of the display - not the widgets themselves. More information on widget styles can be found here: http://wiki.ugfx.org/index.php?title=Wi ... dget_Style I guess the uGFX-Studio seems to work reliably enough to start working on documentation now... what do you guys think? There's literally not a single line of documentation so far. ~ Tectu
  14. 1) How did you add the µGFX library to your project? Did you see this guide? ---> http://wiki.ugfx.org/index.php?title=Us ... _5_MDK-ARM 2) Can you describe what you mean by 'screen orientation is not working'? We fixed an issue in the STM32LTDC driver related to orientation a couple of weeks ago. Please make sure that you use the latest master branch of the µGFX repository. 3) Something is definitely very wrong in your project configuration. Can you please upload a ZIP archive containing the entire Keil µVision project and everything we need to compile? Otherwise it will be every hard for us to help. ~ Tectu
  15. I think we should set the default value of GFX_OS_HEAP_SIZE to a non-zero value to prevent confusion in the future... A couple of remarks: 1) Using a rectangle in the background designer to 'change the background color' is NOT recommended. This is what widget styles are there for. You can create as many widget styles as you like using the WidgetStyle-Manager that you can find in the 'Tools' menu. 2) The missing pixels you are experiencing with the rounder corner buttons are actually rounding issues that are not easy to handle. Inmarket and I have discussed that a couple of days ago and we didn't come to a definitive conclusion on how to fix that so far. 3) The top and left border of the square buttons are not over overwritten - they simply don't exist. The default render implementation of the buttons only draws two lines (you guessed it: at the right and the bottom edge) in hopes of making it look more appealing. Line 205 and 206: https://bitbucket.org/Tectu/ugfx/src/4b ... tton.c-168 4) Matching the fonts is currently one of the biggest issues we are experiencing with the Studio. We will try to improve that for the next release(s). Thank you for your feedback. ~ Tectu
  16. Hello Peter and welcome to the community! Thank you very much for sharing your experience. This will definitely be helpful to others. _sbrk_r() is a system call that's used for memory allocation/management. Usually this isn't something you would find on a microcontroller. It's either implemented in the underlying system that you're using or you simply shouldn't use it. I suspect that the µGFX-Studio project you are using generated a configuration file that enabled one of the file systems in the GFILE section. This has been an issue before but it was fixed a couple of updates before. Can you please let us know which version of the µGFX-Studio you are using and update to the most recent one? Version 0.12 was released two days ago and it contains many bug fixes. Now that I am writing this... is it possible that your configuration sets GFX_OS_HEAP_SIZE to 0? In that case the µGFX library would try to use malloc() and free() which would be supplied by your standard clib which call _sbrk_r(). More information on this can be found here: http://wiki.ugfx.org/index.php?title=Ba ... Management It would also be helpful if you could upload a ZIP archive of your µGFX-Studio project so we can look at both the configuration and the generated files. I'm pretty sure that something is enabled that shouldn't be. ~ Tectu
  17. We updated the online font converted. Can you please give it a try and let us know whether everything works now? ~ Tectu
  18. Thanks for sharing your experience with the ST7735, pigs. Is it possible that you upload a ZIP archive of the driver that you created so we can include it into the repository? ~ Tectu
  19. It's correct to use gdispXxx() instead of gdispGxxx() as mentioned in the documentation. You only need the one that takes the display parameter if you are working with multiple displays (if you have more than one display connected to your microcontroller). First of all I would like to point you to the documentation that explains the GDISP driver interface. It contains some valuable information that might be helpful to understand what happens: http://wiki.ugfx.org/index.php?title=Di ... iver_Model I assume that the reason that your gdisp_lld_draw_pixel() isn't getting called is because in your drivers configuration file you enabled some hardware accelerated drawing method. It's either possible that you set GDISP_HARDWARE_DRAWPIXEL to TRUE or that you enabled hardware accelerated area filling and you're trying to draw a rectangle in which case the GDISP code will use the hardware acceleration interface instead of gdisp_lld_draw_pixel(). When implementing it's a good idea to disable all hardware acceleration first. An additional comment: I'd strongly recommend you to stick with the current existing naming conventions that are also used by the other drivers. You can see that the SSD1289 driver's board file functions are called write_reg() and write_data(). I hope that helps. Let us know when you have any additional questions. ~ Tectu
  20. You can handle double buffering with uGFX but your hardware needs to support it too. For double buffering you actually need memory to store two entire frames - most microcontroller based systems don't offer this. If you can tell us which microcontroller and which display controller you are using we can give some more information. As you are only updating a small portion of the display area we would recommend using Pixmaps for this job. A pixmap is like a small virtual display to which you can draw. Then, you can just copy the contents of the pixmap to anywhere on your real display. The reason this increases performance is because the thing that's by far the slowest is writing pixels to the frame buffer in the display controller and especially if you don't write sequentially (continuous blocks of pixels) but single pixels at different locations instead. Rendering something like a font requires a lot of pixel i/o so this takes a lot of time. It's especially slow because many pixels get written twice (eg. cleared with a background color first, then the text on-top and maybe some third time for anti-aliasing). Doing the same in a pixmap is a lot faster because the pixmap is located in the microcontrollers RAM which is very fast to access. Further factors that will increase performance are the fact that each pixel gets just set once in the display controller (because we know what the end-result must look like) and also the fact that almost all external display controllers allow burst-writes where a continuous block of pixels can be transfered very quickly. There's an article on the wiki explaining pixmaps including a demo. You want to use the 'virtual display' method: http://wiki.ugfx.org/index.php?title=Pixmaps You could furthermore increase the performance by not re-writing the date each time as it won't change. If you really want to get everything out of your hardware then you could even split the time string into two piceses: one that contains the hours and minutes and once that only contains the seconds. This would further minimize the area that needs to be rerendered and redrawn. Hope that makes sense. ~ Tectu
  21. Hello and welcome to the community! You will definitely be able to run uGFX on that hardware and it also makes sense to do so What display are you using? If the display module uses a controller that's already supported by the uGFX library then you don't have to do anything but implementing the board file. The board file contains a few functions which you have to implement so they send and receive data through SPI in your case. You can find a list of all implemented drivers here: http://ugfx.org/platforms In case of your display controller is not yet supported you'll have to implement the driver yourself. We recommend having a look at some of the numerous existing drivers. Everything we have to offer in terms of documentation can be found here: http://wiki.ugfx.org If you have any questions do not hesitate to ask. We are happy to help where we can. ~ Tectu
  22. Is it possible for you to upload a *.zip of the entire project to this thread so we can give it a try over here? We will provide a working Keil project for the F7 discovery board eventually anyway, but we'd like to understand what's going wrong on your side. ~ Tectu
  23. So with the latest master branch from the repository you still get that error about the assembly code? Can you please post your entire gfxconf.h file? May I ask where you got your STM32F7-Discovery Keil project from? It seems like there are some things broken. I think the easiest is if we create a new BareMetal project from scratch ourselves to confirm that there's nothing wrong inside the uGFX library. We can then upload the project so everybody can download it. We want to create a page where people can download pre-configured projects anyway so this might be a good start. Is this a high priority task for you? ~ Tectu
  24. That's very odd. Can you please leave information about the compiler that you're using? We are using the STM32F7-Discovery board with Keil µVision 5 and Raw32 here every day and never had even the slightest problem. Is it possible that you're running an old uGFX version? We are constantly improving our software and there are nearly daily bugfixes. You might want check out the master branch of the repository to always be on the latest state. ~ Tectu
  25. Add this to your configuration file: #define GFX_CPU GFX_CPU_CORTEX_M7_FP Should work like expected then ~ Tectu
×
×
  • Create New...