La gestion des cantons par Arduino !!

Merci pour vos réponses, je mettrai donc ce paramètre dans le programme !

A propos de la PWM, j'ai réfléchi en essayant de m'endormir, et j'ai eu une idée. Je vous l'expose, c'est un peu technique, mais j'aimerais avoir vos avis avant de tenter...

Admettons que nous voulions une fréquence de 32kHz pour nos PWM... (plus précisement 31373 Hz comme calculé sur Locoduino : Lien)
Ceci implique d'avoir une période T de 32µs.
Si on veut avoir une plage d'au moins 80 valeurs de consignes, cela nous donne une variation de 390 nanosecondes environ.
Il va donc falloir utiliser un Timer qui va compter à la même vitesse que le processeur, c'est à dire 16MHz, un tic étant de 62.5 nanosecondes.
1 point de consigne correspondra donc à 6 tics de processeur. Les 80 points donneront 480 tics. Pour bien faire, et coller aux puissances binaires, il faudrait arriver à 512. En prenant 85 points de consignes, cela me donne 85x6=510. Je pars donc sur l'idée de donner une plage 85 points pour les valeurs de consignes.
Je pense utiliser les interruptions possibles d'un timer en utilisant la valeur OCR, qui permet de déclencher une interruption pour une valeur donnée du timer.

Imaginons 2 trains simultanés sur le circuit, le N°1 ayant une consigne de 35, le N°2, une consigne de 50.
Je range ces consignes par ordre décroissant dans un tableau, en gardant leur N° de canton sur lequel ils se trouvent.
La plus grande valeur sera la première à traiter puisque la durée du créneau "haut" de sa PWM sera plus longue.

J'ai donc le tableau suivant :  50 ->2 / 35 ->1
J'applique donc à la variable OCR la valeur 210 (=510 - (6x50) ). Lorsque le timer va atteindre la valeur 210, l'interruption est appelée. Le rôle de celle-ci va être de placer la sortie correspondante à 1. Pour ce faire, il suffit d'écrire l'adresse du canton correspondant et de valider : on lit le N° du canton correspondant à 50 (c'est le canton où se trouve le train N°2), on envoie l'adresse vers le 74HC259, puis on valide par son entrée LE. Ces actions se font rapidement puisqu'on écrit directement les bits.
Dernière chose à faire dans l'interruption, affecter la nouvelle valeur à OCR, qui sera 300 (=510 - (6x35) ). L'interruption est finie, on attend maintenant que le timer atteigne 300 pour relancer l'interruption.
On répètera cela pour toutes les consignes se trouvant dans le fameux tableau.

Pour la remise à zéro des signaux, on reste sur le reset mémoire du 74HC259, celui-ci sera exécuté quand le timer atteindra 510, valeur qui déclenchera une autre interruption, qui elle remettra le timer à 0.

Sur l'arduino Mega, chaque timer peut avoir 3 valeurs différentes OCR et 3 interruptions correspondantes (si j'ai bien compris la doc !), donc j'utiliserai la première pour passer les signaux à 1, et la seconde pour le reset mémoire (cette valeur d'OCR sera de 510 et ne changera pas.)

Le seul point noir dans l'histoire est de savoir si, ce que je demande dans l'interruption se fera assez rapidement pour ne pas bloquer l'interruption suivante dans le cas où 2 trains auraient des consignes proches, voire égales... Là, je ne sais pas trop comment faire...

Les experts en Arduino peuvent-ils me donner leur avis ??

nicozea57 a écrit:

Merci pour vos réponses, je mettrai donc ce paramètre dans le programme !
.........
Le seul point noir dans l'histoire est de savoir si, ce que je demande dans l'interruption se fera assez rapidement pour ne pas bloquer l'interruption suivante dans le cas où 2 trains auraient des consignes proches, voire égales... Là, je ne sais pas trop comment faire...

Les experts en Arduino peuvent-ils me donner leur avis ??

En microélectronique programmable, c'est là toute la difficulté des interruptions. La routine d'interruption doit être la plus courte possible. En général, elle agit sur des variables et c'est le programme normal qui exécute ce qu'il y a à faire en fonction de ces variables.

Consulte l'article de Jean-Luc sur Locoduino : Les interruptions (1). Ou encore ce lien du forum Arduino : http://forum.arduino.cc/index.php?topic=45239.0

A force de rajouter des fonctionnalités à un montage, le processeur est vite employé à fond, voire saturé. Aussi l'idée de sierramike de délocaliser la génération de la PWM à une autre unité n'est peut-être pas à écarter. Dans l'industrie, les µC ont un code optimisé, souvent proche de l'assembleur. Ils traitent donc des programmes complexes plus rapidement. En utilisant les fonctions d'Arduino, on perd de la place en mémoire et du temps d'exécution. Par exemple, un programme utilisant les fonctions digitalWrite prend plus d'octets qu'un programme qui adresse directement les registres des PORT. Toutes ces petites optimisations que tu peux faire sur un programme lui donnent de la fluidité. Par contre, l'utilisation des fonctions d'Arduino permet de programmer facilement sans se préoccuper de ce qu'il y a sous le capot du µC. Simple revers de la médaille : facilité de programmation versus rapidité du code.

Arduino a écrit:

...
Simple revers de la médaille : facilité de programmation versus rapidité du code.

On a la même chose en informatique, avec les L4G. Simplement on a atteint une puissance de traitement dans les PC qui permet d'accepter la lourdeur complémentaire des L4G qui permettent un meilleur rendement aux éditeurs de logiciel.

C'est pareil pour l'Arduino !

Question subsidiaire : quel transistor pour la haute fréquence ?? J'ai vu des MJE181, je ne sais pas, ça a l'air assez rapide 50MHz (fréquence de transitions) ?

J'ai entendu parler de MOSFET pour la haute fréquence, des IRLZ44N ou IRFZ44N (vérifier les caractéristiques dans les datasheet)

Oui MOSFET également

Mosfet IRF xxx

Serie N commute le - charge sur le + ( pour le PWM de nicozea57 )
Serie P commute le + charge sur le -

Dispo chez Gotronic

A+ JL

Mais pourquoi vouloir passer à 32KHz ????
Les essais que j'ai pu faire sur le comportement des locos montrent que le ralenti avec une tension PWM de 300 Hz sans asservissement n'est pas meilleur qu'avec du continu lisse.

A 300 Hz, on ne peut mettre en cause le choix des transistors : on est très très loin des limites HF des transistors même pas spécialement rapides !

C'est juste un effet mécanique. Les petits chocs sont plus efficaces pour "décoller" la mécanique lorsqu'ils se produisent à très basse fréquence. D'ailleurs, à 50 Hz le ralenti est encore meilleur qu'à 100 Hz, mais là il faut vraiment faire attention avec les moteurs à rotor sans fer. La fréquence de 100 Hz semble être un bon compromis.


Concernant l'utilité de déclarer "essieux graphités ou non", je pense que c'est inutile et que ça va embrouiller l'utilisateur lambda plus qu'autre chose. Le système fonctionne que les essieux soient graphités ou non, que demander de plus ? Le mieux est parfois l'ennemi du bien...

Dominique : si le paramètre est par défaut à "non" le fonctionnement est comme aujourd'hui, et si l'utilisateur lambda ne touche rien, ça fonctionne comme aujourd'hui. La présence du paramètre permet simplement à celui qui veut utiliser le système de manière plus avancée de le faire, pourquoi s'en priver ?

De plus, concernant la PWM, j'ai deux réflexions :
1) Pourquoi passer de 100Hz à 32000Hz ? Il y a un monde entre les deux ! La vérité est rarement dans les extrêmes
2) En partant du principe que la génération de la PWM soit déportée dans une unité indépendante, pourquoi ne pas laisser l'utilisateur avancé choisir la fréquence qui lui convient le mieux via un menu de paramétrage ?

Encore une fois, on peut avoir un menu de paramètres pour les utilisateurs avancés, que les utilisateurs "lambda" peuvent simplement ignorer et laisser aux valeurs par défaut !

Pour ma part, concernant la fréquence, je ne regarde pas que le ralenti, mais aussi ce sifflement du moteur qui, pour moi, est franchement désagréable.

Et je donne tous mes avis simplement comme une réflexion universelle, je ne suis pas un client potentiel car mon souhait pour mon futur grand réseau est de fonctionner en DCC !

Tu m'as devancé Sierramike !!

Concernant les cantons, j'allais répondre quelque chose d'assez proche.
Par défaut, le système fonctionne et fonctionnera comme il est actuellement, c'est à dire avec un canton "tampon".
Ajouter un paramètre n'est pas bien compliqué dans le programme, il demande un tout petit peu de mémoire en plus.
Ce dernier, pour les amateurs, pourra permettre par exemple, de ne pas attendre qu'un autorail arrive à la fin d'un canton pour libérer le précédent. Si on passe le paramètre au niveau supérieur, le système libérera le canton dès que l'autorail aura quitté ce dernier, c'est plus logique, et ce sera plus joli aussi je pense.
Quand il s'agira d'un convoi contenant des voitures ou des wagons non graphités (ou non consommateur de courant), on laissera le paramètre au niveau inférieur (valeur par défaut) et le système utilisera un canton tampon pour éviter les rattrapages intempestifs.

Je pense, que ça ne coute pas grand chose (un peu de temps) mais ça peut amener une plus value au système.

Concernant la PWM, pour l'instant, je suis dans la phase étude et faisabilité !
Je ne suis pas le plus expérimenté en matière de matériel roulant, mon expérience se limite à ce que j'ai sous la main.
J'essaye de faire confiance à ceux qui ont déjà vécu d'autres choses.
Si les moteurs "sans fer" posent effectivement problème, et que le 32kHz est une solution, pourquoi ne pas le faire...
Par contre, effectivement, il y a un sacré fossé entre faire du 100Hz et faire du 32kHz !!
Pour le moment, je n'ai pas encore trouvé LA méthode qui me permettrait de faire du 32kHz sans problème...
Pour la gérer dans la MEGA, il faut s'assurer qu'elle soit assez rapide, il faut trouver comment traiter cette rapidité, il faut modifier certains composants, etc...
Pour la délocaliser, il faut réussir à transmettre toutes les informations entre les cartes (consignes, position, vitesse, etc...) et surtout synchroniser les signaux entre les différentes cartes s'il en faut plusieurs...

La question est de savoir si l'utilisation de ces moteurs "sans fer" va se généraliser ou non...!  

Comme je l'ai déjà dit, et je le redis, mon système me donne entière satisfaction avec le 100Hz pour le moment, mais j'étudie toutes les possibilités et surtout toutes les remarques qui me viennent d'éminents modélistes, comme tous ceux qui participent à ce fil !

@Sierramike et Nicozea57 :
Vous êtes encore assez jeunes et les outils offrants plein de possibilités ne vous rebutent pas, mais je ne suis pas certain que c'est que tout le monde, et surtout les moins jeunes, souhaite (je ne connais pas l'âge moyen de la population des modélistes, mais j'ai dans l'idée qu'elle est plus proche de la soixantaine que de la quarantaine).

Personnellement, j'aime les choses simples et claires pour n'importe quel type d'équipement, et j'évite (quand on a encore le choix) les appareils qui offrent pléthore de possibilités qui ne m'intéressent pas. Par exemple, j'ai toujours mon vieux téléphone portable Nokia qui fait juste téléphone, et je ne veux pas en changer surtout quand je vois l'ergonomie bien trop compliquée à mon gout des smartphones et autres bouffeurs de batteries.

Après, je donne simplement mon avis comme demandé par Michaël, je ne suis pas partie prenante.

@Sierramike :
Tu auras davantage de sifflement en utilisant une fréquence bien centrée dans la bande audible (crois en mon expérience de sonorisateur).
Bien que le signal PWM contienne beaucoup d'harmoniques dont les fréquences sont des multiples de celle de base (chaque fois que l'on double la fréquence, on monte d'une octave), avec 100 Hz on est plus proche d'un bourdonnement (moins perceptible et désagréable) que d'un sifflement,

En revanche, avec une PWM de 400Hz par exemple, on entendra bien ce 400Hz (déjà bien médium, c'est presque le LA du diapason), mais aussi les harmoniques à 800Hz, à 1200Hz, à 1600Hz, etc. Toutes ces fréquences sont situées là où l'oreille humaine est la plus sensible, et sont donc bien audibles même à faible niveau.
Quand aux fréquences supérieures à 1 KHz, elles commencent à être vraiment pénibles à entendre (sensation de "vriller les oreilles") et leurs harmoniques encore bien plus.
Pour être tranquille du point de vue son, il faudrait choisir une fréquence au delà de la bande audio (d'où le 32 KHz), mais à coup sûr on est en mode conduction continue et on perd la supériorité du ralenti (sans asservissement, bien sûr).

Quelques réflexions pour faire avancer le bourrin......

- La plupart des décodeurs DCC utilisent une fréquence de 20KHz à 25KHz pour activer le moteur, donc juste au dessus de la bande audible, pas de raison de grimper aussi haut que 32KHz.
- Essayes de ne pas forcément penser "tout numérique", il y a des mariages numérique - analogique très performants. Je pense en particulier à des montages générant un PWM à partir d'un signal en triangle  diffusé à tous les cantons et d'une tension de consigne propre à chaque canton qui génère le PWM grâce à un comparateur. J'avais fait un montage dans ce genre dans la version précédente de mon système et cela marchait plutôt bien avant mon passage au DCC, et cela avait l'avantage de résoudre les problèmes de synchronisation entre cantons.
- Une autre idée qui vaut peut être la peine d’être explorée: Travailler à fréquence constante n'est pas la seule manière de générer un PWM. Tu pourrais définir une durée fixe d'activation du moteur, par exemple 5ms; suivi d'une durée de repos de 5ms également, cela génère un signal à 100Hz et permet d'assurer un démarrage fiable de la loco. Pour accélérer il suffit de raccourcir le temps de repos entre deux activations de 5ms, jusqu'à activer toutes les 5ms.
Évidemment  le bruit dont parlait ci-dessus DMARRION va balayer la bande audible entre 100Hz et 200Hz et je ne sais pas si cela sera acceptable.
Le système numérique peut ne générer qu'une impulsion à la bonne fréquence, de l'électronique analogique se chargeant de créer l'impulsion de 5ms.(monostable réarmable)
Libre à toi évidemment d'essayer d'autres bandes de fréquence et d'autres durée d'impulsion.

Bonjour à tous,

La proposition de CleoN de garder des impulsions de longueur fixe tout en changeant leur espacement est parfois connue sous l'acronyme PFM "Pulse Frequency Modulation".

Cette méthode est avantageuse pour les moteurs peu performants à bas régime ainsi que décrit par exemple dans ce document: http://www.didel.com/kidules/PwmPfm.pdf.

L'analyse conduction continue / discontinue disponible sur le site de JLB devrait être refaite pour la PFM. Il faudrait que je m'y colle !

Bonne suite et bonnes réflexions.

SavignyExpress a écrit:

.....
Cette méthode est avantageuse pour les moteurs peu performants à bas régime ainsi que décrit par exemple dans ce document: http://www.didel.com/kidules/PwmPfm.pdf.

Il me semble que nous avons fréquenté les mêmes bancs (virtuels) d'école...

En attendant que je mûrisse ma réflexion sur la PWM, petite vidéo pour le paramètre sécurité :

Arduino a écrit:

Il me semble que nous avons fréquenté les mêmes bancs (virtuels) d'école...

Et en ce qui me concerne, ce n'était pas que du virtuel, durant la 1ère moitié des années 80, alors étudiant à l'EPFL, j'ai suivi les excellents cours sur les microprocesseurs et leurs interfaces donnés par le Prof. Nicoud et P.Y. Rochat, les 2 animateurs du MOOC sur les microcontrôleurs.

La PFM me paraît une alternative à creuser. Je n'ai pas investigué sur la génération de PFM à partir des timers des AVR qui sont capables de produire de la PWM nativement. Il faudrait peut-être une approche 100% soft par interruption, auquel cas déléguer la PFM à un Attiny aurait tout son sens.

Toujours en attendant, j'ai reçu hier ma mini-caméra, achetée à 6€ sur la baie.
Je l'ai installée sur un wagon graphité, posé en tête de convoi (loco en pousse).
Voici le premier essai de vidéo :

Suite à ma petite visite à l'expo de Metz-Magny, j'ai remarqué sur le réseau du Club de Montigny-les-Metz (en N !!!) une chose qui m'a donné l'idée d'améliorer (encore un peu) mon système !
Leur réseau est une double boucle, c'est à dire une double voie qui fait un rond (ou un parallélépipède rectangle à coins arrondis si vous préférez...)
J'ai constaté, sur les 5 minutes où je les ai regardé, qu'ils ne géraient pas les cantons et qu'ils ralentissaient les trains à la main (il faudra que je les contacte !) alors je me suis dit, tiens, si je leur propose mon système, il leur en faudrait 2, puisqu'il y a 2 circuits différents, en fait.

Donc, je pense, que je vais apporter les modifications et améliorations suivantes :

1- possibilité de définir un nombre de circuits de 1 à 4. Il suffira de donner, pour chaque circuit, le numéro du dernier canton le constituant.
2- possibilité de définir, pour chaque circuit, s'il est en boucle ou linéaire.
3- possibilité de brancher une consigne extérieure pour les circuits linéaires (car cela veut dire que les cantons gérés par le système sont raccordés à un autre morceau alimenté par une autre alimentation). Cette consigne sera la consigne par défaut du premier canton du circuit concerné.

Ces modifications vont permettre par exemple, de gérer 2 double-voies différentes sur un même réseau, ou 4 circuits en os de chien (en limitant le nombre total de cantons à 64)
Je me lance dès que possible, par contre, il va falloir que je fasse un autre petit circuit de test....

Qu'en pensez-vous ?

Salut,

voila, tu as bientôt réalisé le pilotage pour mon club. On a 2 boucles en sens inverse qui matérialisent une double voie. Elles sont reliées par deux bretelles sur la même gare terminus...
Si tu veux qu'on fasse des tests???

Je suis en train de préparer un re-câblage pour découper les cantons.
A+
Yves

SUPERN a écrit:

Si tu veux qu'on fasse des tests???

Oui, mais il faudrait que je finalise un peu mes cartes avant !! Et puis, la charente n'est pas la porte à côté !!

Pourrais-tu me donner un schéma du réseau, que je me fasse une idée un peu plus précise de la question ?
Merci

Ca y est ! J'ai mis la possibilité d'avoir 4 circuits distincts, c'était chaud... Reste à tester

En parlant de tests, si je veux présenter le fonctionnement du multi-circuits, il me faudrait peut-être un plateau comprenant au moins 2 circuits...

Donc, il faut que je ré-étudie mon schéma... Heureusement que je n'ai pas commencé !

Cahier des charges du plateau de test :

- 2 circuits minimum;
- 9 cantons minimum par circuit (3 trains simultanés);
- longueur des cantons minimum 1,50 m;
- 1 gare automatique minimum par circuit;
- 1 gare manuelle minimum par circuit;
- dimensions fixes du plateau 1,90 x 2,00 m;

Si certains aiment faire des plans !  

J'en ai profité aussi pour ajouter une petite fonctionnalité : arrêt automatique d'un train si le système détecte des wagons perdus (pour éviter de les trimbaler à la main sur tout le circuit).
De cette manière, si des wagons sont perdus, la loco sera arrêtée au plus, à un canton devant lui (voire 1 et demi)    

Pour 1 réseau de test, l'important est de montrer toutes les possibilités.

A partir du moment où tu fais 2 circuits distincts, pourquoi mettre une gare automatique et une gare manuelle sur chaque circuit ? En équipant un circuit de la gare manuelle, et l'autre de la gare automatique, les 2 dispositifs seront montrés, rien ne sert de les réaliser en double sur la maquette. Ce sera toujours ça de moins à réaliser.

C'est comme pour l'aiguillage multiple de ta conception que tu voulais intégrer en 4 exemplaires à ton réseau de démo : 1 seul suffirait pour en montrer les avantages, et tu gagnerais un temps précieux pour boucler ta maquette. De plus, en laissant des aiguillages "normaux" du commerce sur le réseau, tu démontrerais que ton système les gère aussi bien que les aiguillages multiples.

J'en reviens à un principe auquel Sierramike et toi aimez bien vous référer et qu'on pourrait résumer par "Pourquoi ne pas le faire puisque le système le permet ?" Et je réponds à cela : le fait que ce soit possible n'est pas une justification en soi, il faut avant tout que ce soit utile.

Merci Dominique,

je te rejoins sur tous les points. Et rassure-toi, je ne ferai rien d'inutile ! (j'ai pas envie de perdre du temps)

Pour la gare automatique, j'en mettrai une seule, effectivement.
Pour la gare manuelle, je dois quand même prévoir la possibilité d'arrêter mes trains. Si je veux faire circuler 3 trains, à un moment donné, je dois pouvoir les stocker. La gare automatique n'aura pas cette fonction puisqu'elle ne permettra que d'"échanger" des trains. Il faut donc que je puisse garer les trains manuellement quelque part. Donc, il me faut une gare manuelle sur chaque circuit. Je pense que ce sera plus facile à mettre en service que d'enlever les convois à la main.

Pour mon aiguille, je ne sais pas si j'aurai le temps d'en mettre. Mais effectivement, une seule suffira !

J'aimerais bien avoir des différences de niveaux également, afin de pouvoir tester mes coefficients de manière plus précise...

J'essaye de faire une nouveau plan...

Voilà ma nouvelle idée : 2 circuits, une gare manuelle de 3 voies sur chacun (dont un aiguillage perso), une gare automatique 2 voies sur la partie haute (couleur orange), 10 cantons sur chaque circuit.
La partie orange est surélevée de 5 cm afin d'avoir des cantons en montée et d'autres en descente...
Les numéros rouge (ex: C12) sont les numéros des cantons

DMARRION a écrit:

J'en reviens à un principe auquel Sierramike et toi aimez bien vous référer et qu'on pourrait résumer par "Pourquoi ne pas le faire puisque le système le permet ?" Et je réponds à cela : le fait que ce soit possible n'est pas une justification en soi, il faut avant tout que ce soit utile.

Salut Dominique,

Je veux tout de même corriger ça (en toute gentillesse bien sûr !), je n'ai jamais dit qu'il fallait faire tout ce qui est possible juste parce que c'est possible. D'ailleurs bien au contraire, avec mon expérience professionnelle je dis plutôt qu'il faut commencer par sortir quelque chose, quitte à ce que toutes les fonctionnalités n'y soient pas, mais au moins sortir quelque chose, quitte à faire des versions ultérieures ensuite.

En effet, des nouvelles fonctionnalités, des nouvelles idées, on en a tout le temps. Si on attend d'être exhaustif, le système sera ultra complet, et parfait, mais n'existerai jamais ...

En revanche, lorsqu'une fonctionnalité est utile et coûte peu, comme le paramétrage des essieux graphités, je le ferais. D'une part, parce que tout le monde ne veut pas graphiter ses essieux, d'autre part parce que ceux qui le font n'ont pas envie de "subir" le canton tampon. Et aussi parce que si on a des essieux non graphités, et aussi des autorails qui eux n'ont pas une ribambelle de voitures derrière, le paramétrage rame par rame est tout à fait utile.

Et je le ferais d'autant plus que pour les gens qui ont peur des nombreux paramètres, il suffit de déclarer par défaut les essieux graphités, et de cacher le paramétrage dans un sous-menu, que seuls ceux qui en ont envie iront chercher, les autres se contentant d'utiliser le système comme si l'option n'existait pas.

DMARRION a écrit:

@Sierramike et Nicozea57 :
Vous êtes encore assez jeunes et les outils offrants plein de possibilités ne vous rebutent pas, mais je ne suis pas certain que c'est que tout le monde, et surtout les moins jeunes, souhaite (je ne connais pas l'âge moyen de la population des modélistes, mais j'ai dans l'idée qu'elle est plus proche de la soixantaine que de la quarantaine).

Personnellement, j'aime les choses simples et claires pour n'importe quel type d'équipement, et j'évite (quand on a encore le choix) les appareils qui offrent pléthore de possibilités qui ne m'intéressent pas. Par exemple, j'ai toujours mon vieux téléphone portable Nokia qui fait juste téléphone, et je ne veux pas en changer surtout quand je vois l'ergonomie bien trop compliquée à mon gout des smartphones et autres bouffeurs de batteries.

Là encore, j'ai envie de dire, la moyenne d'âge des modélistes est peut-être plutôt autour de la 60aine, mais si tu écartes d'office les possibilités intéressant les plus jeunes, comment veux-tu intéresser les plus jeunes ? Quand on a un système qui fonctionne de manière basique, mais permet, via un menu, à ceux qui le souhaitent, d'aller plus loin dans le paramétrage, je ne peux pas comprendre ce qui pourrait rebuter l'utilisateur de 60 ans qui a peur des paramétrages, puisqu'il ne les verra de toute manière pas s'il ne touche pas aux menus ?

Enfin, et là je sais qu'on est un peu HS, mais parce que je lis trop souvent ces critiques envers les smartphones, je voudrais préciser une chose. Si tu veux juste un téléphone, pour téléphoner, bien sûr, tu as un vieux Nokia, et tu pourrais en avoir un neuf si tu voulais, ce n'est en rien critiquable. Personnellement, j'ai un smartphone qui fut relativement onéreux, mais j'ai acheté un ordinateur de poche, avec un grand écran lisible, qui me sert autant à travailler qu'à me divertir (même plus à travailler qu'au reste...), qui est "connecté" justement pour travailler, avec un des meilleurs capteurs photos du moment de l'achat, parce que je n'ai pas envie de trimbaler un appareil photo en plus dans mes poches, et qui accessoirement fait téléphone, parce que c'est plus pratique que d'avoir un téléphone séparé dans l'autre poche. Alors non, on n'achète pas forcément un "téléphone qui ruine le portefeuille", parce qu'on est jeune (d'ailleurs suis plus si jeune que ça )

Fin du HS, et je me répète, tout ce que j'écris n'est qu'une discussion de comptoir, sur un ton tout à fait cordial et juste pour donner moi aussi mon point de vue qui fait avancer le schmilbick (J'ai par ailleurs beaucoup de respect et d'amitié pour toi Dominique, avec la mine d'informations que tu partages !)