Jump to content

Joel Bodenmann

  • Content Count

  • Joined

  • Last visited

  • Days Won


About Joel Bodenmann

  • Rank
    µGFX Developer

Recent Profile Visitors

9,594 profile views
  1. Thank you for bringing this to our attention. We've added looking into this to our ToDo list.
  2. The µGFX-Studio is currently not available for any kind of use in a production environment and/or commercial use. This is indicated on the µGFX-Studio download page.
  3. There's a list of all supported controllers on the website/homepage. You can also have a look at the /drivers directory. And as @inmarket said: Adding a new driver is very easy. There's documentation and plenty of existing samples including drivers for very similar display controllers.
  4. There's currently no driver for the ST7920 display controller that comes with the µGFX library but µGFX is very agnostic: It will work with virtually anything. There are plenty of existing GDISP drivers (also for monochrome displays) that you can use as examples to implement your ST7920 driver.
  5. The STM32F103 is quite an outdated microcontroller. Any particular reason why you'd be using this model? µGFX will definitely work in all of those configurations. How much RAM you want to have to work with is of course another discussion (and your personal decision). µGFX can work with very little resources. Having more resources available just enables you to do fancier stuff.
  6. Happy to hear that you got it working! The issue with the chip select sounds like the GDISP driver is not properly calling those functions.
  7. Hi, We appreciate your motivation to donate. Once we started selling commercial licenses we decided to take down the donation option. Money is clearly the main hold-back issue here as we can't afford more man-power but donations usually don't result in an amount and steady supply of money that would allow to improve this. We're close to release µGFX v2.9. It's already ready - we just need to do the actual release. µGFX v3.0 is also making progress
  8. Hello & Welcome to the µGFX community! There are many factors to consider such as the resolution and color space you want. The more pixels you have to control the more resources you'll need (memory, CPU, bandwidth, ...). For something of this size the newer STM32F4 families or the STM32F7/STM32H7 microcontrollers are extremely popular. If you're not very experienced I'd stay away from the STM32H7 for the moment as support for it seems to be quite scarce on all levels (including debugger support). The STM32F7 is by now pretty well established but tends to be a lot harder to work with compared to an "old school" STM32F4 due to newly introduced technologies such as the memory cache which can lead to many sleepless nights: http://www.chibios.org/dokuwiki/doku.php?id=chibios:articles:cortexm7_dma_guide The STM32F429/STM32F439/STM32F469 are extremely well supported and will most likely provide enough resources for what you're after. Also, you can get various development boards for those with displays so you can get yourself familiar with all the software components before you have to mess with custom hardware.
  9. The ILIxxxx display controllers are known to suffer from differences across series and revisions. Also, some (chinese) sources love to sell you an ILI9225 as an ILI9220 and so on. Therefore, once you confirmed that the SPI is working correctly, try to grab the initialization code (sequence) from your supplied and plug it into the init() function of the corresponding µGFX driver. Another thing you might want to do is trying to read out the display controllers version register / chip ID. This will tell you exactly what display controller you have and will also confirm that the communication is working well.
  10. You should definitely work against the latest master branch of the official git repository (https://git.ugfx.io/ugfx/ugfx).
  11. Instructions are given in the red box at the top of the µGFX-Studio download page.
  12. > I am working with a recent git version of ugfx and Chibios 18.2. How recent is recent? There has been a text edit fix two months ago: https://git.ugfx.io/uGFX/uGFX/commit/509fc7501e7bd30b1b314fc0d4838d7cdf6ac621 I'm currently on the road so I can't dive into this right now. But can you reproduce it with the most minimal test case? Eg. using gwinSetText() with a simple string parameter (no runtime buffer stuff) and setting the last argument to TRUE? So I guess the response to your "I suppose using dynamic text could provide a workaround, but I thought I would ask before trying too many things." statement is pretty much: That's exactly what I'd recommend you to try to track down the problem.
  13. Hmm... the board file template is definitely missing. Thank you for bringing this to our attention. Many of the drivers are community driven and do not originate from the official µGFX developers. We're definitely going to take better care of this in µGFX 3.0. We're thankful for any kind of bug reports and/or patches. Usually a forum post will do - if possible with a patch that we can just apply. Alternatively you can make a pull request on the µGFX git server. It's correct that those functions will actually write data to your display controller (in your case) through your SPI peripheral. Most displays that are in the style of the ILI9225 have a pin called D/C or similar - sometimes it's an additional bit in the SPI frame. That bit will tell the display controller whether the data it's receiving is actual pixel data (write_data()) or commands such as changing the viewport, changing rotation or setting any other kind of register value (write_index()).
  14. I'm currently on the road so I can't easily check, but I'd say it's rather likely that the board file can be found in the /boards directory of the library or in the downloads section of this forum.
  • Create New...