LCD - Mission - Leka Image & Video Features

[ladislas]

Mission - Leka Image & Video Features

Introduction

Leka is an interactive educational toy. It has a screen to display images, animations, emotions, drawings.

While still images are easy to render and display, it's a different matter for animations. There are two ways of doing animations:

• programmatically using code
• or by playing video files

Using code is often more optimized and mcu power friendly. It is also interactive as you can change colors, speed, shapes on the fly. But it's a lot harder, takes more time, needs more people with very special skills and therefore is not financial ressource friendly.

On the other hand, playing video is easy conception wise: nowadays, even a non designer can create a simple video animations using Adobe or free tools, export it in mpeg to be played by the device.

The playing part is much trickier as it is resource intensive and can be programmatically complex to implement as it relies a lot on the hardware capabilities.

All capabilities (still images, videos & animations) are needed for Leka. We will start with displaying images before moving to "playing a video file". It completely separates the development process from the video creation process and allows both to work in parallel.

The Mission

Display images on the screen
Play a video from the SD card onto the LCD screen

Constraints

• image format must be jpeg with and without transparent background
• video format must be raw mpeg or avi
• video frame rate should be 24 images/s
• hardware JPEG Codec must be used to decode JPEG frames (YCbCr to RGB conversion will be done with software)
• the SD card must be formatted in FAT16 to allow PC users to add images and videos manually
• the final code will not include ST's BSP, but will rather repackage important pieces in our own (well tested) libraries if needed

Steps

1. TTHW (Time To Hello World) with images

This first step is to make sure the hardware is working using ST's provided software. We will start by displaying images from an SD card using only ST's examples and software.

• - read the documentation
• - follow an ST examples and tutorials using all their tools (on Windows or Linux) and software (BSP if needed here)
• - make sure everything works, that you understand every concepts and that the process has no secret for you

2. TTHW Images + Mbed OS

This second step is to take the working example and start incorporating Mbed OS into the final working code.

• - analyse the code provided by ST and make it C++ friendly
• - start integrating Mbed OS eventually removing all mentions to ST's BSP and/or auto-generated code
• - package ST's needed pieces into our own libraries
• - keep the SD card read separated and well packaged (it doesn't seem possible to use Mbed's version at the moment)
• - make sure everything still works properly and that images are read and displayed

3. Deep Dive Image Display

Now that we can display images using Mbed and our custom libraries well try different things.

• - display background image
• - display background image + 2 foreground images
• - display images with transparent background
• - move/animate images into position

4. TTHW (Time To Hello World) with videos

Taking a step back, we'll do the same as in step 1 and display videos from an SD card ST's examples and software.

• - read the documentation
• - follow an ST examples and tutorials using all their tools (on Windows or Linux) and software (BSP if needed here)
• - make sure everything works, that you understand every concepts and that the process has no secret for you

5. TTHW Videos + Mbed OS

This fifth step is to take the working example and start incorporating Mbed OS into the final working code. A lot of steps are the same as in step 2 and should be fairly straight forward. They are listed to make sure we don't forget anything.

• - analyse the code provided by ST and make it C++ friendly
• - start integrating Mbed OS eventually removing all mentions to ST's BSP and/or auto-generated code
• - package ST's needed pieces into our own libraries
• - keep the SD card read separated and well packaged (it doesn't seem possible to use Mbed's version at the moment)
• - make sure everything still works properly and that images are read and displayed

@YannLocatelli has already worked on this and gathered important resources and code examples. They are available here and must be read carefully:

Yann's Image & Video Features Mission resources

6. Deep Dive Videos

Now that we can display images using Mbed and our custom libraries well try different things.

• - play videos in loop (with optimizations)
• - play video backward
• - optimize as much as possible
• - make sure the hardware jpeg codec is used
• - make sure all the great things provided by ST are used (DMMA, Chrom-ART, etc.)

Resources

• TouchGFX - Documentation
• TouchGFX - Embedded Hardware Acceleration Features
• TouchGFX - Assets & .png
• STM32CubeF7 - Github Repository
• STM32CubeF7 - jpeg_utils.c
• STM32CubeF7 -STM32H747I-DISCO/JPEG MJPEG VideoDecoding
• ST Website - AN4996 - Hardware JPEG codec peripheral in STM32F76/77xxx
• ST Website - AN4861 - LCD-TFT display controller (LTDC) on STM32 MCUs

[Madour]

J'ai avancé un peu dans la configuration bas niveau du LCD en calquant sur le BSP.

Cependant je suis bloqué sur un comportement que je n'arrive pas à comprendre :

Pour pouvoir utiliser l'écran LCD, il faut passer par une initialisation de certains registres/variables en appelant des fonction du HAL avec les parametres voulus.

Dans cette initialisation est compris l'initialisation du composant OTM8009a (le nom du hardware de l'écran), or même en ayant copié exactement le code du BSP et après de nombreux essais et réécritures, cette initialisation semble ne pas aboutir correctement.

L'initialisation en question s'effectue dans la fonction uint8_t OTM8009A_Init(uint32_t ColorCoding, uint32_t orientation); qu'on peut trouver sous BSP/Components/otm8009a/otm8009.c.
C'est en fait une suite de commandes envoyées au DSI (fait le pont entre l'écran et le MCU).
Je n'arrive pas à comprendre pourquoi ça bloque à ce niveau.

---

Ce problème m'aura tout de meme permis de creuser en profondeur au niveau du fonctionnement interne et comprendre comment tout cela s'agence.

[ladislas]

@Madour tout le driver du otm8009 peut être utilisé en entier avec le .h et le .c.

Quelques pistes (que tu as peut être déjà faites):

• il faut implémenter le fonction void DSI_IO_WriteCmd(uint32_t NbrParams, uint8_t *pParams)https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/Components/otm8009a/otm8009a.c#L179 --> elle est implémentée ici https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery_lcd.c#L1615
• il y a la fonction void OTM8009A_IO_Delay(uint32_t Delay) qu'il ne faut pas oublier https://github.com/STMicroelectronics/STM32CubeF7/blob/master/Drivers/BSP/STM32F769I-Discovery/stm32f769i_discovery.c#L750 --> elle utilise HAL_Delay(Delay), il faudra tester avec un delay Mbed si ça marche (pas sûr)

L'ordre des implémentations est important.

De manière générale, toute cette partie initialisation de très bas niveau, elle doit être faite en HAL en gros.

Dans la phase d'initialisation du robot, ça se fera tranquillement au début pour avant de lancer le fonctionnement.

@YannLocatelli aura surement d'autres idées, il a plus creusé le sujet que moi.

[ladislas]

@Madour Mbed vient aussi de rajouter une weak function pour initialiser les choses avant le main de manière propre.

la PR est ici : https://github.com/ARMmbed/mbed-os/pull/13022/files

[Madour]

J'ai résolu le problème de l'initialisation, en fait ça ne venait pas directement du OTM8009a_Init, mais d'une instruction de configuration de la clock qui m'avait échappé.

J'ai corrigé cela dans le commit 082a7ac.

Edit: d'ailleurs au final j'ai fini par integrer le fichier otm8009a.c directement dans la classe LekaLCD car il se base sur des variable globales (hdsi_discovery par exemple), alors que j'ai integré ces handlers dans la classe en tant que membre. Je pense que c'est plus propre comme ça.

J'ai également commencé à essayer de remplir des surfaces avec le DMA2D (toujours en calquant le BSP).

Pour l'instant, les méthodes LekaLCD::clear et LekaLCD::fillRect, qui se basent sur LekaLCD::fillBuffer, ne fonctionnent pas vraiment; une commande de configuration a du m'échapper encore une fois ...

Une fois ce problème reglé, je tenterai de lire la carte SD depuis mbed os.

[Madour]

Pour l'instant, les méthodes LekaLCD::clear et LekaLCD::fillRect, qui se basent sur LekaLCD::fillBuffer, ne fonctionnent pas vraiment; une commande de configuration a du m'échapper encore une fois ...

Problème résolu, en fait l'initialisation de la SDRAM manquait (cf 1bf09ef).
L'affichage de couleurs sur l'écran fonctionne bien, j'ai créé une petite animation pour tester 5c20958

[ladislas]

bravo! 🎉

[Madour]

Avancement et recherches pour la lecture de fichiers vidéos mjpeg/avi :

• En explorant l'exemple Jpeg-Video-decoder fourni par ST (mais ciblé pour le F769NI-Eval), j'ai plus ou moins acquis une vision globale du fonctionnement (ouverture du fichier, récupérer les infos, récupérer les données d'une frame, les envoyer au JPEG decoder, transferer les données sur le frame buffer via le DMA puis afficher )
• Cependant, il y a des différences :
  • Jusqu'a maintenant, je configurais le DSI host en "Video mode" (comme le BSP). Cette configuration fait que l'affichage passe par l'écriture du frame buffer dans une SDRAM que le LTDC va aller chercher et passer au DSI host pour l'afficher sur l'écran OTM8009A. Il se trouve que c'est bien l'étape du "SDRAM fetching" qui limite les performances.
  • Il existe 2 autres façons de configurer le DSI host: "APB Command mode", pas très interessante dans notre cas, et le "Adapted Command mode". L'exemple Jpeg-Video-decoder configure en "Adapted Command mode".
    La principale différence de cette configuration est l'utilisation d'une "Graphical RAM" ou GRAM au lieu de la SDRAM pour stocker le frame buffer. La GRAM est intégrée à l'écran. (le OTM8009A en possède une de 1244 Ko, ce qui est largement suffisant pour notre frame buffer de 750 Ko). D'après la documentation, ce mode est le plus efficace pour le rafraichissement des écrans qui possèdent une GRAM car le LTDC n'a pas à envoyer tout le frame buffer, mais seulement des commandes d'écriture à l'écran. Cela permet d'avoir des performances correcte sans utiliser de double frame buffer.

Donc tout ça pour dire, que pour afficher une vidéo avec un rafraichissement rapide, je vais forcement devoir configurer le DSI host en Adapter Command mode, or j'y suis pas arrivé pour l'instant :( . Dans la documentation ils préviennent qu'il faut faire attention à la bande passante du LTDC, vérifier qu'il est capable d'envoyer la série de long write commands; j'ai regardé du coté de la doc du LCD-TFT, la gamme STM32F7x9 possède les meilleurs spec, donc à priori il ne devrait pas y avoir de soucis de ce côté.

Voila ce que j'ai compris globalement, y'a moyen qu'il y'ai des erreurs dans mon paragraphe, hésitez pas à corriger, ça sera bénéfique pour tous.

---

Par ailleurs, il se trouve que le F769NI-Disco a la possiblité d'utiliser un double frame buffer, j'ai testé avec les exemple de ST et l'affichages d'images une à la suite de l'autre se fait instantanément sans artefact visuel (tearing effect ou autre), ça serait intéressant d'essayer de mettre ça en place dans deux semaines ? (si l'affichage de vidéo fonctionne d'ici la)

[Madour]

Une petite remarque par rapport à la lecture vidéo, et plus précisemment par rapport à la compilation, j'ai remarqué que certaines options étaient nécessaires au bon fonctionnement du décodage :

1. -Os (optimize size)
2. -ffunction-sections (place functions in their own sections)

D'ailleurs, j'avais perdu du temps parce que le décodage bloquait au bout de quelques frames, et il se trouve que j'avais les mauvaises options (-O0 et -f-data-sections)! Je n'ai pas vraiment d'explications logique à ce comportement par contre.

Pour mbed os, j'ai vu qu'il y'avait possibilité de définire un compile profile via un fichier json , qu'on peut ensuite utiliser avec
mbed compile --profile build_profile.json par exemple, à tester.