Jump to content

inmarket

Moderators
  • Posts

    1,295
  • Joined

  • Last visited

  • Days Won

    4

Recent Profile Visitors

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

  1. It all depends on the display controller. Some display controllers - that is just how they operate. In terms of speed, they can be just as fast as any other mechanism. It really all comes down to bus speed and the type of bus. For some bus types and speeds streaming controllers can be faster than any other type. Try doing framebuffer pixels writes over a slow I2C bus would be terribly slow, a streaming controller and driver can however perform really well. uGFX is pretty unique amongst graphics libraries because it doesn't require direct access to the framebuffer in RAM. It was with this basic tenant that the first version of uGFX was written, and its first hardware controller was a streaming driver.
  2. Thank-you. Nice work. We will add to the standard driver collection as soon as possible.
  3. It sounds like you got the panel working for you in 18bit mode. I am currently using the original code on a Ili9488 in RGB565 mode (16bit) without change. Looking at your photo the board even looks the same! This is a common problem with the Ili series of controllers. Often chips with the same part numbers behave quite differently depending on the source of the chip. Add to that different ways the panel can be attached to the controller, and then the pixel format you want to use for the application, all mean that the initial sequence often needs to be customised. Seemingly identical boards can sometimes behave differently. I even heard of one case of this happening from a single supplier. With regard to the reset function, the gTrue was supposed to mean the reset was asserted (i.e active low for most boards). As there were a number of different programmers who wrote the different drivers, for some drivers that meaning got transposed and the gTrue was taken to mean pin high instead. It looks like the ili9488 driver is one of those. It is something we are fixing for uGFX v3 but can't change for v2 without breaking someone's already working code. Nice job on working it out!
  4. Check your gfxconf.h file. Make sure it is not defining GDISP_PIXELFORMAT
  5. It is more likely it is caused by the sequence of Alloc's and Free's. Another possibility is that there is a buffer overrun problem in the uGFX image code. This is also possible but unlikely as the uGFX image code is very well tested. What strikes me as unusual here is an Alloc of just 2 bytes.
  6. Looks like you might have found a bug with the FreeRTOS memory allocator.
  7. In this case it is the LTDC peripheral that is doing the pixel conversion and layer mixing I talked about in my earlier post. While the LTDC does not support RGB666 DPI it does support RGB888. You can connect that to a RGB666 panel by simply not connecting the two lowest bits of each colour byte. So, You can use RGB565 as the CPU and framebuffer pixel format for a layer, and then you program the LTDC to take that RGB565 pixel data and convert it to the RGB888 output DPI bus. That RGB888 DPI bus you then connect to RGB666 panel by ignoring the bottom 2 bits of each colour on the DPI bus. So, uGFX works and is programmed around the chosen framebuffer pixel format - not the DPI bus format. The LTDC converts that framebuffer pixel format on the fly to your RGB888 DPI bus. Note: when you have 2 layers they can be in different framebuffer formats. uGFX then may have a "system" pixel format and two different display/layer pixel formats. uGFX drivers convert from the system format (which all drawing operations occur in) to each display/layers internal format in the driver. That conversion is obviously trivial when the system and all drivers agree.
  8. There seems to be a confusion here between the display DPI interface and the framebuffer format. They usually do not need to be the same. For most controllers, they will do the conversion on the fly between the frame buffer RAM interface and the DPI lcd interface. E.g. if you are using an 8 bit palette framebuffer format the display controller will do the palette lookup to create the 18/24 bit wide DPI data. Similarly, the framebuffer can be in RGB565 format which is efficient for the CPU, RAM and memory usage, and convert it on the fly to the 18bit DPI interface (by bit shifting the red and blue values). Layering also occurs at this level. Layers involves taking 2 framebuffers in potentially different pixel formats and "mixing" them to produce a single 18/24 bit hardware DPI value for the LCD. That is the other thing about layers, you need a full size framebuffer for each layer. They can usually be in different pixel formats. In fact, they may have to be in different pixel formats in order to not exceed the total RAM bandwidth limitations. E.g. an STM4 chip using LTDC with external RAM can only support 1 x 320x240 framebuffer at RGB565 unless frame rates are quote low. If you want the 2nd layer it needs to run at RGB232 or an 8 bit palette mode to meet RAM and LTDC bandwidth requirements. As implied there are things that can be done to help here, 2 x RGB565 are available at low frame rates. It may help to split the RAM interface, it may be possible to use higher speed static RAM, a different CPU may also help etc. I will leave the bandwidth calculations to be part of your hardware design.
  9. Looking at the symptoms and your description it is obvious that you are still not talking SPI correctly to the display. Unfortunately you can't use SPI in 16 bit mode to emulate SPI in 9 bit mode. Unfortunately many micros are not able to talk 9 bit SPI, only 8 or 16. So, 1. Check carefully the data sheets of your micro to see if you can put the SPI port in true 9 bit mode 2. If it can't, see if the display has an 8 bit mode with a separate D/C line (most do). Note this requires an extra pin on your micro for the D/C line, or 3. Use bit banging instead of the micro UART. While this is a pain there is plenty of example code on the internet. At least this method can prove the working of the display and you can investigate a less CPU intensive solution later.
  10. To also add some more detail... Most small display controllers use a pixel framebuffer that is outside the CPU address space. This is because the CPU is talking to them over a very slow bus like SPI or even 8 bit parallel. These buses are far too slow to be feeding display data directly to the display. Instead graphic commands are sent to the display controller which then renders into the off-CPU framebuffer. This covers most of the GDISP drivers. The few CPU's that have the display controller built in (or are on a very high speed bus) will typically map the pixel framebuffer directly into the CPU address space. The framebuffer and fb24 drivers are for these displays. The only odd one out is the LTSC driver for STM32 CPU'S. While this is theoretically a framebuffer driver situation, it has very complicated initialisation and eccentricities due to its support of DMA operations thus warranting a specialised driver for it.
  11. The divide by 2 when calling xyaddr() is incorrect. It is the xyaddr() macro itself that needs the divide by 2. As indicated by the macro name, it is supposed to take (x,y) as it's parameters.
  12. inmarket

    LT7381 driver

    Those routines are typical of routines you would see at the board file level. They describe how to convert a logical operation into a physical one. For example, the logical operation is writePixel, the physical requires the details inside SPI_DataWrite_Pixel. Your driver will call those routines. Those routines will be in the board file of the driver. Note: This actually looks like 16 bit SPI with the top bits indicating data/cmd and read/write. You might rearrange the board interface like follows... write_cmd8(g, c) = SPI_CmdWrite(c) write_data8(g, d) = SPI_DataWrite(d) write_data16(g, w) = { write_data8(g, (gU8)w) write_data8(g, w >> 8 ) } Read instructions are similar. If you compare this to other driver board interfaces you will see this is very similar. You then just need to write the driver itself. Note: By doing this board level extraction the same driver could be used with the display controller in 8080 bus mode simply by changing the implementation of the board routines above. For the driver, having had a quick look at the data sheet, it is basically a "window" model driver that effectively uses the "MCU write with ROP" controller instruction. When you have that working you can then add an accelerated block fill routine using the controller "rectangle fill" instruction. There is another controller that is similar in that it is a window driver and has a accelerated block fill routine. From memory (I am currently away from my computer) it might be the SSD1331 driver or one of the RA drivers. Hope this helps.
  13. inmarket

    LT7381 driver

    Also have a look at the code for an Olimex board. It is lying around somewhere probably in the boards directory in the source code. It also uses a 9th bit instead of a D/C line and was one of the first boards used when developing the uGFX project. Of note: This means of communication requires a CPU capable of 9 bit SPI. The standard ST processors don't but SAM processors do. Look at your CPU hardware specs to see if it is supported. Also, sometimes the display controller can operate in either 8 bit mode with D/C or in 9 bit mode. This is usually pin configurable. If your CPU doesn't support 9 bit SPI then you will need to modify the display board, use bit banging SPI (not simple), or find another display.
  14. The problem here is a physical one that can't be overcome in software. There are 2 fundamental issues: SPI flash is SLOW SPI flash is not memory addressable by the CPU Yes, I know that some CPU's support memory addressing of SPI flash and in those the uGFX code works unchanged however the speed considerations are still a problem for practical use. So, how to make SPI work for storage of fonts... Treat the SPI flash as a disk and connect it with the GFILE module Use the dynamic loading font mechanism to load the font you want into memory. Whilst this still uses RAM for the font you have loaded, the advantage here is that it can be unloaded when not needed and potentially a different font can then be loaded from your SPI flash. So, not a full solution but instead a work around. Unfortunately it is the only way to get around what is a physical hardware limitation.
  15. The function might be called sprintg or something like that (I am off-computer presently so can't see the proper function name). It is the ugfx equivalent of sprintf. Note: sprintf from the c library won't work as it is also not utf8 aware at all. Sprintg (the ugfx equivalent) may work when you use %s to include the character (obviously as part of a string). I don't expect it to work with %c or as part of the format string itself. Note: this is a work around that should work but there are no guarantees. To be fixed properly this requires substantial changes to the printf engine in ugfx. The extra complexity is the whole reason very few sprintf implementations support it except on desktop systems like Windows or Linux.
×
×
  • Create New...