Comme il est difficile de trouver les détails sur les circuits qui la composent (hormis cette ébauche de doc), voici quelques informations trouvées ici ou là.

En italique, ceux dont je ne suis pas sûr.

LittlevGL est une bibliothèque graphique open-source et gratuite qui permet de bâtir des interfaces graphiques de hauts niveau à la click-o-drome (contrairement à Cairo ou DirectFB qui s'occupent elles du bas niveau sous Linux).

Je ne vais évidemment pas refaire la doc : il n'y aura ici que les choses qui me paraissent importantes et/ou les pièges dans lesquels je suis tombé.

Pas besoin de l'installer, elle est directement incluse avec la bibliothèque TTGO.

Les styles sont définis dans des structures lv_style_t qui DOIVENT RESTER ACCESSIBLES AUSSI LONGTEMPS QUE L'OBJET QUI LES UTILISE EXISTE. Si cette règle de base n'est pas respectée, plantage assuré.

Ca ne signifie pas non plus qu'il faille modifier la structure directement ni surtout qu'elles soient prises en compte directement. Non, il faut

1- modifier l'attribue par la fonction idoine, par exemple

lv_style_set_bg_color( &style, LV_OBJ_PART_MAIN, LV_COLOR_GRAY );

2- appliquer les modifications

lv_obj_add_style( &objet, LV_OBJ_PART_MAIN, &style );

Quasiment tous les widgets dépendent de lv_obj dont le constructeur est

lv_obj_t *lv_obj_create(lv_obj_t *parent, const lv_obj_t *copy);

le nouvel objet récupérera les attributs de copy s'il n'est pas nul ... y compris ceux de position. Sauf que ses derniers ne sont pas absolus mais relatif à leurs parents respectifs. Ainsi, si on a fait un

...
lv_obj_set_y( parent, 10 );
fils = lv_obj_create( parent, parent );

le fils sera décalé de 20 pixels par rapport à l'origine : 10 du parent + 10 encore hérité par le fils.

Mais où peuvent bien être cachés tous les types d'alignement d'un objet ??? Et bien, sur cette page.

Il est possible de demander un ré-alignement automatique dans son container lorsque la taille d'un objet change, typiquement lorsqu'on met à jour la taille d'un objet.

lv_obj_set_auto_realign( true );

Cependant, j'ai fait face à pas mal de crashs avec cette fonction. Bref, en cas de guru, un premier test est de désactiver cette possibilité.

Les labels sont des conteneurs dans lequel on peut afficher un texte ou une icône. Si le texte est trop long, le label s'agrandira ou le texte sera tronqué en fonction du mode "long text" activé par la fonction lv_label_set_long_mode().

Le mode par défaut est LV_LABEL_LONG_EXPAND où le label s'agrandit horizontalement si nécessaire : dans ce mode, lv_obj_set_width() est inactif. J'imagine que c'est là même chose avec lv_obj_set_height() en mode LV_LABEL_LONG_BREAK. Bref, si l'on veut fixer une taille il faut

1. activer un mode compatible
2. puis changer la taille

Ce qui donne

lv_label_set_long_mode( label, LV_LABEL_LONG_SROLL_CIRC );
lv_obj_set_width( label, 150 ):

Les mosaïque sont typiquement le type d'interface que l'on trouve sur une montre intelligente, où l'on passe par balayage d'une page à une autre. L'implémentassion dans lvgl est un peu déconcertante : en fait, on se retrouve avec une sorte de grand écran virtuel contenant toutes les tuiles mises les unes à côté des autres et l'écran physique s'y balade en fonction des gestes de l'utilisateur.

Le créateur est un classique

lv_obj_t *tileview = lv_tileview_create(lv_obj_t *parent, const lv_obj_t *copy);

mais lui indiquer le tableau des mouvements autorisés.

static lv_point_t valid_pos[] = { {0,0}, {1,0} };

que l'on associe à la mosaïque par un

lv_tileview_set_valid_positions( tileview, valid_pos, nbre_entrees_valid_pos );

Les tuiles en elles-mêmes sont de classiques conteneurs qu'il faut donc déplacer par un

lv_obj_set_pos( tuile, x, y );

Ce n'est généralement pas nécessaire pour la 1ere car en position {0,0}.

Dans notre exemple, la seconde se trouve en {1,0} (donc à droite de la première), il faut donc la déplacer par un

lv_obj_set_pos( tuile, LV_HOR_RES, 0 );

Enfin, on l'ajoute à la mosaïque grâce à la fonction

lv_tileview_add_element( tileview, tile);

Si l'on place un label au milieu d'une tuile, on s'apercevra qu'il n'est plus possible de la déplacer par effleurements si notre doigt atterrie sur le dit label. Il en va de même si une image est placée dans un bouton : il devient inopérant si on clique sur la zone de l'image. Dans les 2 cas, la cause est la même : l'objet du dessus à intercepté notre action.

La ligne suivante va lui indiquer de devenir "transparent" aux messages d'évènements qui sont donc propagés à la couche du dessous.

lv_obj_set_click( this->getMyself(), en );

avec en valant true ou false en fonction que l'on souhaite (true) ou non (false) que l'objet interprète les évènements.

Les fonds d'écran suivants sont fournis avec la librairie ... mais ne sont décrits nulle part : voilà qui est réparé.

• bg - mauve djhazebg1 - ciel et aurore
• bg2 - métal
• bg3 - mauve avec des messages
• WALLPAPER_1_IMG - Camouflage
• WALLPAPER_2_IMG - Camouflage grand
• WALLPAPER_3_IMG - Ananas en bas a gauche

Un jour, je prendrai mon courrage à 2 mains pour faire des captures d'écran ... un jour.

Gestion de l'alimentation (PMU) ... à l'instar de l'AXP209 du BananaPI.

Canaux :

• AXP202_EXTEN
• AXP202_DCDC2 - Not used 0.7V to 2.275V, 1.6A
• AXP202_LDO1 - Always on 30mA
• AXP202_LDO2 - Display backlight 1.8V to 3.3V, 200mA
• AXP202_LDO3 - Audio power 0.7V to 3.5V, 200mA
• AXP202_LDO4 - Not used 1.8V to 3.3V, 200mA
• AXP202_LDO5 - Not used 1.8V to 3.3V, 50mA

IRQ :

• AXP202_VBUS_REMOVED_IRQ, AXP202_VBUS_CONNECT_IRQ : câble d'alimentation
  
• AXP202_CHARGING_FINISHED_IRQ
• AXP202_ON : bouton power

Code :

• ttgo->power->isVbusPlugInIRQ() - câble USB connecté
  
• ttgo->power->isVbusRemoveIRQ() - câble USB retiré
• ttgo->power->isChargeing() - est-ce que la montre est en charge ?
• ttgo->power->isPEKShortPressIRQ() - appuis rapide sur le bouton

Accéléromètre, incluant un compteur de pas.

Code :

• ttgo->bma->isStepCounter() : compteur de pas à mettre à jour.