Jump to content

cpu20

Members
  • Content Count

    122
  • Joined

  • Last visited

1 Follower

About cpu20

  • Rank
    IDE Specialist

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. cpu20

    STM32F401RE+CubeMX+Eclipse+ILI9341

    In the last image you sent inidcates that you haven't correctly included the gdisp configuration file. Adding files to be included in the build is done in the Properties window of your project. Go to: C/C++ General > Paths and Symbols > Includes In that window you need to add all the folders that contain .h files that need to be included in your project for example the folder containing the "gdisp_lld_config.h". Sorry for my late reply. If you have any questions don't hesitate to ask.
  2. cpu20

    STM32F746-Disco & Eclipse - Makefile approach

    With Makefile approach do you mean using the Makefile system provided by uGFX? Because then you need to make a Makefile project in Eclipse. When you create a C project in Eclipse, it will create a Makefile for you depending on how you configured the project. When you create a Makefile project, Eclipse will not generate any makefiles and use the Makefile you provide. What you are currently doing is manually configuring the whole Eclipse project to compile correctly. That is a very difficult process, but I think it is possible.
  3. cpu20

    Getting started with E-paper displays

    uGFX is a graphics library that makes abstraction from the hardware that you use. So you can write a prom that uses the uGFX library to draw things on the screen, reads user input etc.. without knowing what hardware you are using (in theorie). To make the program work with your specific hardware setup, a gdisp driver must be written for your hardware setup. All existing drivers can be found in drivers/gdisp (take a look there to get an idea). The display driver file is called gdisp_lld_xxx.c So in order to make uGFX work with your EPaper display you need to write a driver for it. An example of a driver for an EPaper display can be seen here: After writing the display driver, there is also a file needed that implements the interface between your specific MCU and the display. This file is called board_xxx.h The board file includes functions that send data to the display over a certain interface (depending on the display used). In your case the display uses SPI so the board file will contain functions that use SPI to send data to the display. For an example see the post above. To summarize, you will have to write a driver (gdisp_lld_xxx.c) for your EPaper display and a board file (board_xxx.h) that implements the SPI interface between your MCU and the display. If you have any questions don't hesitate to ask. EDIT: I did a quick google and it seems that the 2.9inch and 2.13inch EPapers are quite the same. It might be possible to copy the driver in the post above and just change the resolutions of the display in gdisp_lld_xxx.c
  4. From your screenshots it seems that you included all the sources correctly. Not only the uGFX folder has to be included under "Paths and Sybmols", but also your gdisp driver folder. In your case you need to add the drivers/gdisp/ILI9341 folder to your "Paths and Symbols". This should fix the error.
  5. cpu20

    FreeRTOS Semaphore Create Mutex

    I would start by increasing the stack size of your intialization thread: osThreadDef(defaultTask, StartDefaultTask, osPriorityNormal, 0, 128); 128bytes might not be enough to initialize everything.
  6. cpu20

    The compiled newspaper is wrong on eclipse

    This is most likely caused because you don't have any file that implements the memory system calls. These calls are system dependent and normally the manufacturer of your platform provides these functions. You can also let µGFX handle memory management by setting GFX_OS_HEAP_SIZE to a non zero value.
  7. cpu20

    Completely stuck

    In your board file, you drive the chip select pin of your display. You should not keep that line constantly low or anything because that can lead to unwanted situations. The chip select line should be lowered and raised in the acquire and release bus functions. Other than that I have no idea if the ST7735 driver is functional. Last time it came up there were some issues with it.
  8. cpu20

    The compiled newspaper is wrong on eclipse

    That board file uses the Chibios HAL to drive the display. Make sure you have Chibios set up correctly first.
  9. cpu20

    Write_data

    According to the datasheet of the ST7586 the controller has a built in GRAM. So in theory you should not need a full framebuffer on the MCU. Reading from the displays GRAM is according to the datasheet only possible when using the parallel interface. So when using SPI it won't be possible to do this. Otherwise this would probably be the best solution to use the least resources. Some designers make some very weird decisions... When not using the parallel interface, I don't think it will be possible to omit the framebuffer. I think the easiest approach is to keep the framebuffer but only do partial flushing. The controller supports setting a window for the GRAM. So set the window and only write the data that changed.
  10. cpu20

    Problem with passing a reference of an Object to the GUI

    Just to be sure: When using the gfxInit routine, does the object still get altered in your main? Maybe the problem is not your GuiLoop.
  11. cpu20

    uGFX stops at xQueueGenereicReceive [STM32F103]

    At first sight it seems that the xQueue you give to the xQueueGenericReceive function is not intialized correctly. Maybe something is going wrong with the heap manager when using µGFX? Could you show us the code where you initialize FreeRTOS and µGFX?
  12. That is normal behaviour as you ask to wait indefinitly for an event that never comes. Biggest chance is that the failure is somwhere in the STMPE811 driver. I will look at your code tomorrow to see if I can catch something.
  13. cpu20

    Which big display is better?

    On embedded systems the increased resolution isn't always a benefit as it will increase your required RAM-size significantly and also the data throughput to your display. Be sure to consider those drawbacks also especially when dealing with animations. As the drivers for both displays are already included in µGFX they are both fully supported. As for the speed, my guess would be that the MCU will be the deciding factor. If you are just starting to experiment which these things and want to experiment more I would recommend the STM32F746G-Discovery board. This board is fully supported by µGFX, is very popular and already has alot of peripherals on board. Also the display is already reasonably large.
  14. Version 1.0.0

    470 downloads

    This is an example project for the STM32F746-discovery board running µGFX and FreeRTOS. For the application the demo project from /demos/modules/gwin/button is used. The IDE used for the project is AC6 SW4STM32.
  15. cpu20

    uGFX + FreeRTOS (on STM32F746-Disco)

    After creating a program in SW4STM32 and experimenting a bit, it is clear that the method using the uGFXMain() will never work. As stated here no delays are possible before the scheduler is started. The Init function you were using in your first post and starting the scheduler yourself will be the way to go. While trying to get a project up and running it took me quite some tries to get everything right to work together and I bounced into a problem in the board_stm32ltdc.h The stm32f7xx_hal_rcc.h and stm32f7xx_gpio.h need to be replaced with stm32f7xx_hal.h to work properly with the latest HAL libraries. Anyway here is the result if anyone would be interested. STM32F746-Disco-FreeRTOS.zip
×