framboise314.fr

Bonjour à tous,

j'ai constaté apres mise à jour de raspbian par:

sudo aptitude update
sudo aptitude upgrade

qu'au reboot le petit ecran LCD de 3.5 pouces etait "oublié", plus d'affichage.
Je n'ai pas verifié si l'affichage revenait sur le port hdmi, je suppose que oui.

L'image raspbian que j'utilise est fournie avec l'ecran LCD par Eckstein en allemagne, si bien que je n'ai pas eu à l'installer ni à le parametrer.
J'imagine que la mise à jour ecrase la config, mais je ne trouve pas les fichiers concernés

Si vous avez une idée ...

Merci !

iota a écrit :Bonjour à tous,

j'ai constaté apres mise à jour de raspbian par:

sudo aptitude update
sudo aptitude upgrade

qu'au reboot le petit ecran LCD de 3.5 pouces etait "oublié", plus d'affichage.
Je n'ai pas verifié si l'affichage revenait sur le port hdmi, je suppose que oui.

L'image raspbian que j'utilise est fournie avec l'ecran LCD par Eckstein en allemagne, si bien que je n'ai pas eu à l'installer ni à le parametrer.
J'imagine que la mise à jour ecrase la config, mais je ne trouve pas les fichiers concernés

Si vous avez une idée ...

Merci !

Bonsoir,

Le site du vendeur est très clair (il redirige vers un autre site mais c'est normal, tous ces écrans se ressemblent comme des jumeaux et seule l'étiquette change) :
http://www.waveshare.com/wiki/3.2inch_R ... stallation

Cet écran peut être activé de 2 façons différentes:

1) La + standard:
En installant le "driver" sur une distribution normale.
2) La + simple et la + rapide:
En chargeant la version "adaptée" de Raspbian. Ça permet un fonctionnement rapide et sans prise de tête.

Le problème de la solution 1, ce qui semble bien être le cas, c'est qu'une mise à jour lourde (le kernel par exemple) conduit pratiquement systématiquement à un blocage.

Il y a donc au moins 2 solutions:

1) Suivre le tutoriel de l'installation du driver
2) Réinstaller, sur une autre carte, la version adaptée de Eckstein. Ça devrait fonctionner mais dépendre d'une version spécifique n'est pas recommandé (problème des mises à jour de sécurité) et ça ne fait pas progresser dans la maîtrise de son matériel.

Comme l'OS est déjà à jour, il y a une forte probabilité de pouvoir sauter des étapes et de passer directement à la configuration (activation du SPI, utilisation du frame buffer ...).

Bon courage.

Sylvain

En effet la réinstallation du driver résoudra le pb mais à chaque update c'est un peu ...

Je pense soit ne plus effectuer de mise à jour (du noyau tout du moins) soit me passer de l'ecran.

iota a écrit :En effet la réinstallation du driver résoudra le pb mais à chaque update c'est un peu ...

Je pense soit ne plus effectuer de mise à jour (du noyau tout du moins) soit me passer de l'ecran.

Chacun voit midi à sa porte
Le risque de ne plus mettre sa distrib à jour est de laisser des failles de sécurité. Si la machine n'est pas connectée à Internet, ça se discute.
Se passer de l'écran serait dommage en utilisation avec une IHM simplifiée (contrôle de processus, domotique .

Pour ma part, j'ai un petit écran du même style, offert par un de mes fils, et je galère car je dois réaliser l'interface (tel que, il n'est pas compatible Raspberry).
Ça m'a obligé à creuser le fonctionnement (j'ai pas encore terminé). Comme déjà dit, tout ces écrans se ressemblent et sont gérés à peu de choses près de la même manière.

Le Raspberry n'a pas assez de ports GPIO pour les gérer en parallèle. Il faut donc attaquer par une liaison série (port SPI) et transformer de série vers parallèle et gérer quelques signaux. C'est le rôle de la carte qui est soit livrée soit à faire (mon cas).

La bibliothèque wiringPI qui gère le SPI est désormais incluse d'office dans Raspbian (Jessie à ce jour).
La bibliothéque qui gère les écrans TFT est FBTFT, accessible ici:
https://github.com/notro/fbtft/wiki/FBTFT-on-Raspian

Après, c'est une question de paramétrage (activation du SPI, X11 sur framebuffer ...).
Le site est bien fait et intègre un wiki. Il faut bien identifier le matériel sans se laisser abuser par l'étiquette du vendeur (bien observer le circuit imprimé, le chip ...).

On est à la limite du monde de l'embarqué (GPIO, SOC, pas de HD ..) même si certains le vendent comme un mini PC (c'est limite pub mensongère).
Cela veut dire que tout n'est pas "plug and pray" mais qu'il faut mettre les mains dans le cambouis.

Bon courage

Sylvain

Merci pour toutes ces infos qui du coup me donnent une idée :

Faire un script réinstallant l'ecran, à lancer apres les mises à jour.
J'ai remarqué que la mise à jour supprimait mes modifications au demarrage (j'avais ajouté qqs lignes à bashrc pour avoir l'ip au login at sur l'ecran), donc un script de verification que l'ecran est installé ne survivrait pas mais je vais me debrouiller

Quelque chose du genre (d'apres la doc):

avec LCD-show-160520.tar.gz dans /home qui à priori n'est pas impacté par une mise à jour.

run raspi-config --expand-rootfs
tar xvf LCD-show-160520.tar.gz
cd LCD-show/
sudo ./LCD35-show


Le seul soucis pour l'instant est d'activer "Desktop Autologin" dans le Boot Option de raspi config avec le script

L'idée de base est bonne mais il faut procéder par étapes:
1) Rétablir le fonctionnement en notant TOUTES les actions réalisées.
2) Identifier les fichiers de paramétrage impactés par ces actions ET en faire une copie lorsque tout est fonctionnel.

en effet, certaines commandes inter-actives comme raspi-config seront peut-être difficile à scripter.

Nota: Je ne vois pas pourquoi il faudrait refaire un expand rootfs après une mise à jour par dist-upgrade.
Nota 2: Pour une utilisation aussi peu fréquente (1 fois par grosse mise à jour) il n'est peut-être pas nécessaire de vouloir un lancement automatique.
Une sauvegarde sur clef USB (avec les fichiers patchés) et un lancement manuel devrait être envisageable.

Sylvain

Oui, je ne sais pas trop pourquoi ils demandent d'effectuer un expand, peut être vis à vis de la decompression du driver ?!

Le raspi config semble être un script, il va falloir decortiquer.

J'ai songé mettre les fichiers modifiés dans le /home (une clef usb ça disparait )

C'est loin tout ça, dur dur

iota a écrit :Oui, je ne sais pas trop pourquoi ils demandent d'effectuer un expand, peut être vis à vis de la decompression du driver ?!

L'expand est nécessaire pour utiliser toute la capacité de la carte SD.
Sous Linux, la copie de l'image de Raspbian se fait par un dd qui est une copie "bit à, bit" qui ne tient pas compte de la taille de la partition ni du système de fichiers; Il suffit que la destination soit assez grande pour recevoir la copie de l'image. Il reste donc une grande partie de la carte "en friche".

Sylvain