Display drivers for '429-Discovery about ada_drivers_library HOT 6 CLOSED

Agreed, on both points.

The component driver is very low-level, and limited in scope. The LTDC interface does more, and will eventually be revised to be in terms of the component driver.

We considered "ancillary" instead of "utils" (among others) but have yet to find a good name. It may be that we need to break up the contents to find a good name.

Thanks for the comments!

from ada_drivers_library.

Probably I should move the STM32F4.* packages from utils/ to drivers/ and thereby simplify things a little. Originally the drivers/ dir was strictly for actual devices described by the RM, but that may be more narrow a definition than necessary.

from ada_drivers_library.

hi, from what I see and understood about LTDC, the driver should be indeed in drivers.
But not in this current form as it seems to be a mix between low-level driver and middleware.
I would see the peripheral driver layer in 'drivers' and the layer using SPI and GPIO in 'utils' folder.

by the way, 'utils' isn't so badly named and is often used to place utility services which act in the inter-layers, ie not ll driver, not middleware but useful to app developer. Middleware are usually services like an usb stack, a filesystem management, a graphic layer etc...

from ada_drivers_library.

Yes, the LTDC is a bit of a mixture at present. It was written prior to the ILI9341 component driver so we envision it being revised accordingly, at some point, and made more independent of the board.

I agree that utils is a good name as long as that's what is in there.

from ada_drivers_library.

The LTDC driver (and more generally framebuffer display) have been greatly refactored in the 'svd' branch. In particular:

• stm32-ltdc.ads now only configures the LTDC peripheral
• stm32-dma2d also only configures the peripheral
• a new HAL.Framebuffer interface has been introduce to handle framebuffer displays
• this interface is partially implemented in boards/common_stm32/ltdc/framebuffer_ltdc.ads.
• a new HAL.Bitmap type has also been introduced to perform operations on bitmap surfaces,
• a specialized version bitmap_dma2d allows hardware acceleration.
• all those interfaces are fully implemented at the board levels.

from ada_drivers_library.

This is now integrated into the master branch. So I'm closing this issue, feel free to open a new one if you see ways to improve the current architecture (even better if you can contribute changes: we're very open to your participation to this project)!

Best regards,

• Jerome

from ada_drivers_library.