gnx a écrit 420 commentaires

Bon, désolé pour la condescendance,

Pas la peine de t'excuser de quelque chose que tu n'as pas commis. Il n'a pas compris que tu signifiais juste que c'était à ton avis mieux de ne pas utiliser les spécificités d'un shell, et que tu ne le traitais pas de quoi que ce soit.

Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000e de seconde2, il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.

L'avantage d'aller plus vite que la mécanique est aussi de pouvoir faire du filtrage numérique. C'est bien plus simple à modifier.

Là aussi, c'est encore une solution de facilité (on acquiert les entrées aussi vite qu'on peut même si elles sont dégueulasses comme des bourrins et ensuite on verra bien comment on les filtre à l'intérieur) et on bouffe des ressources et ça explique qu'on ait besoin d'un gros CPU, de RAM, et de rentrer plus de données.

Et du coup, le temps de réactivité annoncé est à moitié bidon, puisque on ne réagit qu'après avoir pris en compte les 10/20/30 derniers échantillons (et donc 10/20/30 cycles) et viré/lissé/filtré les mauvais. Il est flottant, en fait.

Avoir des modules est généralement une bonne idée.

Oh non. C'est une très très mauvaise idée. Je suis d'accord pour la facilité de développement. Mais au niveau de la fiabilité, cela n'est plus la même chose. Moins il y a de connections mieux on se porte.
J'ai vu des archis de robot avec plein de µP chacun sur sa carte, c'est bien plus simple d'avoir une seul carte et tout dessus. Il y a bien moins de fils et bien moins de problèmes.

« Bien moins de fils » avec un fil pour chaque entrée venant de chaque capteur et un fil allant à chaque commande par rapport à une liaison série à 1/2/3 fils qui transporte l'ensemble des infos de 15 capteurs et 15 sorties ???
Bon, de toutes manières tu n'en démordras pas. Alors je te souhaite bien du plaisir à concevoir ta carte mère (utilise au moins un module CPU venant s'enficher dans la carte mère pour ton [(SoC/SoC+FPGA/Zynq)+RAM]) avec ses 200 ou 400 connections. Et le jour où tu auras besoin d'un de plus que ce que tu as prévu, ben tu refais toute une carte mère.

J'en ai pris un au hasard http://www.ti.com/lit/ds/symlink/tlc1518.pdf . J'ai vu qu'il y a un mode "repeat" qui peut être intéressant pour 8 voies, mais j'ai l'impression que l'envoie est contrôlé par 3 bits externe (INT, CSTART, FS). C'est autant de bit pris sur le SoC. Et j'ai peur que pour gérer l'entrée, il faut commander ses bits, ce qui prend tout le cpu, pendant ce temps là.

OK. Remarque : c'est un composant qui a plus de 15 ans. Il ne fait pas d'échantillonnage simultané (simultaneous sampling) et il ne sait pas enchaîner les différents canaux tout seul, donc il faut lui envoyer 1 coup de CS ou CSTART ou FS par canal en respectant des temps minimums (600ns/1,4µs). Ces temps d'attente sont perdus si tu ne sais pas faire autre chose en attendant. Par contre, le même signal peut servir à tous les TLC1518 présents sur la carte. Et la lecture, elle, ne pose pas ces problèmes d'attente (mais il faut des CS différents pour chaque TLC1518).

Sinon, si je prend aussi au hasard un composant plus récent comme le MAX11060 : 4 voies seulement, mais il fait le simultaneous sampling, il gère un peu tout tout seul et tu peux même en mettre plusieurs en cascade sans avoir besoin d'interface supplémentaire.

Note quand même qu'il va falloir une bonne quantité de ces CAN car il n'ont que 4 ou 8 entrées, alors qu'un µC peut gérer 16 voire 32 entrées et ce, en plus, pour un coût unitaire moindre. Faut les programmer, c'est sûr, mais si on ne leur fait faire que ça (lire leurs entrées analogiques, éventuellement signaler au SoC qu'elles sont prêtes, et envoyer les données quand le SoC leur demande), ce n'est pas bien compliqué.

Et un BGA tient les 500 broches, si le PCB est petit cela ne devrait pas être trop couteux.
Je veux surtout un truc pas trop chère

Euh, ouais, mais ce qui coûte, ça risque de ne pas trop être le PCB¹ et ses couches, mais d'une part (dans le cas de quelques protos) de faire souder la cochonnerie de BGA, et d'autre part dans tous les cas ce qu'il y a dans le composant et à combien d'exemplaire il est produit. Quand j'évoquais un gros Zynq à prix déraisonnable, c'est un composant qui va taper dans les 3000 à 5000€, pareil pour les FPGA les plus puissants ; quand aux processeurs/contrôleurs, s'ils sont vraiment spécialisés dans une petite niche, ils peuvent coûter plusieurs centaines d'€. Donc bon, si on devait être dans ce genre de cas, le prix des connecteurs serait accessoire :-)

si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.

J'entends bien qu'il faut « ajouter » des pattes mais ce n'est pas très grave dans la mesure où ce n'est pas trop difficile à router tant que c'est juste entre 2 composants. À partir de 3 ça serait plus pénible. Cependant, j'ai mis « ajouter » entre guillemets parce que les interfaces et les pattes sont de toutes manières généralement présentes sur les SoC, donc à moins de vouloir et pouvoir affecter les pattes correspondantes à une autre fonction, ça ne va rien changer (du moins, côté SoC).

C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle.

Ça me soucie un peu ça. OK, les signaux analogiques à mesurer sont quasi-statiques, donc on devrait pouvoir les filtrer à mort. Sauf qu'il y a cette histoire de réactivité qui m'ennuie à double titre. D'abord parce que du coup on n'a plus le droit de retarder des masses le signal, ni d'affecter sa valeur, ce qui limite la possibilité de filtrage. Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000^e de seconde², il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.
Et avec tout ça, on se trouver avec un filtre qui risque de ne pas filtrer la fréquence des PWM qui sont juste à côté, alors qu'on ne peut pas tolérer de bruit.

Au contraire il me semble qu'il faut réduire le nombre de fils en multiplexant les infos sur de simples lignes numériques.

Si tu as un robot de 50 cm, tu ne gagnes rien. Et tu as une pelleté de mini carte en plus, et de connecteurs (c'est chère les connecteurs).

Dans la mesure où le composant magique à 500 pattes n'existe pas, pour la carte de base il faut de toutes manières ajouter plusieurs µC ou CAN et même si l'on opte pour la solution FPGA, il faut quand même un étage pour l'adaptation des entrées analogique à la gamme demandée par les CAN et pour le filtrage.
Implanter ces composants sur la carte de base est plus coûteux que de les implanter sur plusieurs petites cartes séparées identiques. La surface prise sur la carte du SoC est du 6/8 couches, alors que la carte séparée est en 2/4 couches et on en fabrique plus d'exemplaires.
Avoir des modules est généralement une bonne idée. Déjà pour le développement, ça permet de tester séparément les fonctions, de ne pas les faire en même temps, etc. Ensuite, ça peut éviter, en cas de problème, de griller l'ensemble. Enfin, avoir de modules permet de s'adapter à différents projets, soit en changeant le nombre de modules connectés, soit en remplaçant les modules par d'autres ayant des fonctions variant en nombre ou en nature. Ça évite de devoir reconcevoir et refaire une carte à 800€…
De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.

Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives,

Tu peux préciser un exemple de composant problématique ?

En Allemagne, il y a le prélevement à la source et tu dois quand même remplir une déclaration

Ou pas.

Le prélévement à la source et le "absolument rien à faire" n'ont rien à voir…

Admettons que mon « prélèvement à la source » => « rien à faire » soit erroné. Ce n'est pas pour autant qu'il n'ont rien à voir, on peut supposer que « rien à faire » => « prélèvement à la source », au moins.

Tu es conscient que tu cherches la quadrature du cercle ?

Déjà, tu n'arrives pas à chiffrer combien d'E/S il te faut, on revient encore à « beaucoup », « plus », etc. Personne ne peut te trouver de solution ainsi.

Si on prend tes 25 moteurs, avec 3 capteurs analogiques et 3 sorties numériques chacun, ça fait déjà 75 entrées analogiques et 75
sorties numériques. + d'autres capteurs + d'autres sorties, donc au moins 100 entrées analogiques et 100 sorties numériques. Et tu voudrais que tout ça rentre directement dans un seul composant (200 pattes rien que pour ça, sans compter masses ou entrées différencielles) alors que tu voudrais un boîtier sans trop de pattes ? Et tu veux aussi que le composant soit fourni en RAM (donc large bus d'adresse), et très véloce (donc bus de données 32 ou 64 bits), alors que tu voudrais un boîtier sans trop de pattes ?

En plus tu ne veux pas optimiser en hiérarchisant les entrées/sorties ni en les multiplexant, du coup toutes au max de précision et il faut toutes les caser dans un bref laps de temps. => bouffage de ressources et restriction du choix.

Même en mettant de côté le coup du nombre de pattes, de tels composants n'existent pas. Les SoC n'ont pas d'E/S du type que tu veux, même en nombre insuffisant, ils ne sont pas fait pour ça. Les µC ne peuvent pas soutenir tout le bazar que tu veux faire tourner et de toutes manières, bien qu'ils soient fait pour ce type d'E/S, je n'en connais pas avec autant d'E/S (une trentaine de CAN n'est pas fréquent, alors 100…). Les FPGA, parfaits pour toutes tes E/S numériques par leur grand nombre d'E/S, comportent très rarement des parties analogiques ; on peut cependant faire des CAN avec du Sigma-Delta, mais ça doit bouffer des ressources.
Donc il te faudrait un composant spécialisé pour tes spécifications, autant dire un marché de niche et c'est là que ça va être « coûteux ». Autant dire que pour le beurre et l'argent du beurre, ce n'est pas possible, il faut supprimer une ou plusieurs exigences.

Donc pour réconcilier la plupart des fonctionnalités que tu demandes, il te faut tout ça : 1 SoC + 1 FPGA + n µC/CAN.

Enfin, tu parles de « compact ». Je ne suis pas sûr que relier 200 ou 400 fils à une unique carte centrale soit pratique, que ce soit à l'arrivée sur la carte ou pour les passer dans les structures, surtout des structures articulées/mobiles. Sans même parler de la tronche des signaux analogiques dans ce merdier. Au contraire il me semble qu'il faut réduire le nombre de fils an multiplexant les infos sur de simples lignes numériques.

Donc on revient aux solutions que tu n'aimes pas, du genre :
- une carte principale avec SoC + FPGA, et n CAN déportés reliés par SPI¹.
- une carte principale avec SoC, et n µC déportés reliés par SPI¹.
- une carte principale avec SoC + l'aide d'un µC ou FPGA pour libérer le SoC de toute la gestion des E/S, et n µC déportés reliés par SPI¹.

Sinon, la seule possibilité « simple » que je vois, en gardant la touffe de fils, c'est le combo [Soc+FPGA] ou [Zynq], en faisant du Sigma-Delta. Mais toujours le même problème : ça demande énormément d'E/S disponibles. 100 sorties + 3 x 100 entrées = 400 pattes dédiées ! Et ça, ça n'existe pas en Zynq à prix raisonnable. Donc [SoC+FPGA maousse²] ou [SoC+2xFPGA moyens] ou [SoC+3/4xFPGA petits] ou [Zynq+FPGA moyen] ou [Zynq+2/3 FPGA petits].

La déclaration des revenus s'est effectivement bien simplifiée, mais quand quand tu viens d'un pays où les impôts sont prélevés à la source et où tu n'as donc absolument rien à faire…

les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec

Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.

Ah oui, merde, là c'est moi qui n'avait pas vérifié, m'étant dit que puisqu'il avaient mis un cœur de µC, ils avaient assurément mis aussi des interfaces de type µC. Bah non :-/
À voir chez d'autres fabricants.

Sinon, dans un genre différent, quelque chose à base de Zynq ? Double cœur Cortex-A9 + une grosse partie FPGA + ce que j'avais oublié, c'est-à-dire une petite partie analogique. 2 ADC sur 17 lignes. Est-ce que ça suffirait ?
Si oui, il faut voir ensuite quelles cartes sortent les signaux en question.
- la Zybo de Digilent, c'est mort (ils servent à la sortie VGA) ;
- MicroZed ou Zedboard ça devrait aller (reste à vérifier combien des 17 entrées analogiques sont disponibles sur des connecteurs et s'il reste suffisament d'E/S numériques disponibles pour le reste).

Quand tu en a codé 1 (ou recopié le code dispo ailleurs), que tu en instancies 2 ou 100, c'est le même travail.

Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.

As-tu besoin d'une précision de 1/65536=0,0015% de période sur tes sorties ? et ce sur toutes tes sorties ?

De toutes façons, même si l'on compte pour être tranquille le double de ce qui doit être nécessaire, disons 32 bascules par compteur, ça rentre dans le plus petit des Spartan 6 qui en compte 4800, ou dans un Spartan 3A 200 qui en compte un peu moins.

De plus, utiliser n compteurs 16 bits pour n sorties, c'est la méthode bourrine calquée sur le fonctionnement des timers de µC. Pour obtenir la même précision, on peut par exemple utiliser 1 compteur principal (genre 8 ou 10 bits) et n compteurs plus petits (les bits qui manquent : 8 ou 6) ou n registres à décalages s'il manque peu de bits, en consommant de la RAM à côté (il y a plus de 200kb de RAM en blocs sur le plus petit des Spartan 6).

Il y a beaucoup de raisons à cela : lenteur des communications entre les 2. Mon but est de lire tous les capteurs puis tout écrire pendant un cycle. Un cycle dure entre 1 à 10 ms maximum (retroaction). Et pendant ce temps là le cpu doit être libre, ou presque pour faire des calculs (il existe des ADC sous I2C qui demande beaucoup de temps cpu pour du pulling).
Ensuite, si tu as un lien rapide entre les 2, cela sacrifie beaucoup d'IO, donc cela veut dire des gros package couteux. Lier un µP et µcontroller demande aussi de coder le µcontroller sans quasiement d'aide au debug, c'est bien plus long et complexe que sous un Linux, par exemple.

Cycle de 10ms dont 1ms consacrée aux E/S, donc ?
Si on prend une liaison SPI à 40 MHz et qu'on suppose arbitrairement qu'une lecture/écriture de message comporte 8 octets et qu'on doit attendre l'équivalent de 4 octets entre 2 messages ; ça nous fait un message toutes les (12x8=64)/40.10^6=2,4µs. On peut utiliser plusieurs bus SPI (un avec le SoC maître et l'autre avec le µC maître, par exemple).
Si on prend un bus // arthritique entre SoC et µC : 8 bits de données, quelques bits d'adresse, 10 MHz ; disons qu'un mot 32 bits est transféré en moyenne en 6 coups d'horloge; ça nous fait un message tous les 6/10.10^6=0,6µs.
Dans les 2 cas ça doit être suffisant pour lire 100 entrées et mettre à jour 100 sorties en utilisant un maximum de 0,5ms.

Si c'est un cycle de 1ms dont 100µs consacrée aux E/S, c'est plus tendu, mais s'il y a moins d'E/S que 100 et 100, ça peut rentrer.

Après si le boulot difficile est fait par le producteur de la carte pourquoi pas. Mais il faudra montrer que le driver Linux qui permet d’accéder au ADC ou au PWM d'un µcontrolleur à bien 1 ms de latence max, ou plus exactement que toutes les IO peuvent être lu/écrite en moins de 10 ms, sans prendre plus de 10% de cpu.

S'il faut tout tout fait, ça réduit encore les possibilités de solution :-)

Tu as listé combien d'entrées et de sorties il te faut, avec leur type, leur précision et leur vitesse/latence ? Ça sera plus pratique pour essayer de déterminer une solution que beaucoup/plein de/le plus possible :-) Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.

Les cortexM tourne à 70-100Mhz, j'ai commencé la robotique sous linux avec des Pentium 75. Il faudrait juste utiliser une plateforme de µC et y mettre un Cortex A7 ou lieu d'un M.

Ben j'ai l'impression (juste avec ce que tu as dit) que tu t'embarrasses d'un OS de type mammouth alors que ce que tu fais tourner dessus a le fonctionnement d'un automate et se contenterait d'un mini-micro-nano OS ou de pas d'OS du tout. Alors du coup t'as besoin d'une fréquence 10 fois supérieure.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).

les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec

Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.

Ah oui, merde, là c'est moi qui n'avait pas vérifié, m'étant dit que puisqu'il avaient mis un cœur de µC, ils avaient assurément mis aussi des interfaces de type µC. Bah non :-/
À voir chez d'autres fabricants.

Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.

T'es gentil… Si j'ai répondu à ce message dans lequel tu racontes des âneries, c'est pour corriger ces âneries. Si j'avais voulu répondre à ta « demande », je l'aurais fait en répondant à un message dans lequel tu l'aurais exprimée.

Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok.

Non, pas 100, moins. Comme je l'ai écrit. Comme c'est écrit sur le site du module que tu « avais déjà regardé à l'époque et rien n'a changé ».

Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !

Quand tu en a codé 1 (ou recopié le code dispo ailleurs), que tu en instancies 2 ou 100, c'est le même travail.

Par contre, attention, ça reste un module (auquel tu peux ajouter une carte de dév), pas quelque chose d'immédiatement prêt à l'emploi comme un SBC ou beaucoup de cartes µC.

Tu remarques enfin ce que je cherche vraiment ?

Tu cherches quelque chose qui (pour ce que j'en connais) n'existe pas ou presque :

• puissant comme un SoC pour faire tourner un Linux ;
• des E/S analogiques d'un µC ;
• un grand nombre d'E/S ;
• monolythique.

Les SoC sont conçus pour les tablettes, ils n'ont donc pas besoin d'entrées analogiques.
Les µC sont conçus pour faire le boulot qu'on leur demande, pas vraiment pour faire tourner des scripts Python sur un Linux.
À partir de là, la solution est d'associer les 2, mais tu n'aimes pas.

Il reste à explorer les composants où sont associés un cœur de SoC et un cœur de µC, comme les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec. Mais je ne sais pas quelle mesure leur complexité est moindre que d'avoir le SoC et le µC séparés sur une carte.

Moui, à première vue, ça peut paraître comme ça. Mais ça a surtout un côté « l'herbe est plus verte ailleurs ». Parce que le hockey, c'est aussi :

• une grosse part des buts qui relève d'une tactique très élaborée : taper à peu près en direction du tas devant la cage en espérant qu'un partenaire ou un adversaire la dévie ailleurs que sur le gardien ;
• de toutes manières, on peut faire les tactiques qu'on veut, à la fin on est devant un gardien qui couvre 80% de la surface de la cage et vu la précision de la visée avec une crosse dans les conditions d'un match… en plus le gardien a le droit d'avoir des réflexes :-) ;
• donc faut arroser, arroser, arroser et de temps en temps ça peut rentrer, ou avoir du bol ;
• des coups vicieux et de l'anti-jeu en permanence ;
• un arbitrage qui peut virer à la mascarade, puisque toutes les 5 secondes, il y a une situation qui peut valoir faute ou non, suivant l'interprétation ;
• prévoir une bonne mutuelle pour le dentiste ;
• pour un (télé)spectateur, ça dure des plombes (compter dans les 2h30) ; 2h30 à se peler les miches si on est sur place, et dans les 2 cas 60 minutes à chercher où est passé le putain le palet. La moitié des buts, tu te demandes s'il est rentré ou pas, s'il est rentré puis ressorti, etc. puisque ça va trop vite.

Voilà, bon, j'ai regardé des dizaines et des dizaines (peut-être des centaines plutôt) de matchs de tous niveaux, à la télé et en vrai. Plus ça allait, moins ça m'intéressait. Maintenant je regarde à l'occasion quelques bouts de matchs mais ça doit faire un bail que je n'en ai pas vu un en entier.
J'ai aussi joué 3 ans à un vague parent du hockey, et c'était à peu près les mêmes problèmes. J'ai atteint mon niveau d'incompétence maximale au bout d'à peine 3 ou 6 mois et je n'ai jamais vu quelqu'un avec un niveau nettement supérieur qui m'aurait indiqué qu'il y avait encore des progrès à faire. On peut toujours éliminer / se démarquer mieux, mais vu qu'au final ça revient de toutes façons dans l'immense majorité des cas à bombarder l'autre gros dans le but… :-)

Bref, les conclusions sont personnelles, mais les éléments cités au départ sont à prendre en compte.

Sérieux, ça serait bien de consacrer 3 minutes à s'informer avant de poster ; 3 minutes, avec le lien donné dans le message auquel tu réponds, ça suffit pour trouver :

• qu'il y a (au max) plus de 100 GPIO de l'ARM ;
• qu'il y a plus de 60 GPIO du FPGA ;
• que le FPGA est relié à l'ARM par le bus parallèle de ce dernier.

Bon, je pense qu'il n'y a pas de CAN, car les CAN, généralement, ça se trouve sur des µC, pas des SoC.

Par contre, attention, ça reste un module (auquel tu peux ajouter une carte de dév), pas quelque chose d'immédiatement prêt à l'emploi comme un SBC ou beaucoup de cartes µC. Et c'est pas mal plus cher aussi.

Je vois souvent ce genre de remarques et je ne les comprends toujours pas. C'est généralement le jour où l'on veut poster pour la première fois qu'on crée un compte puisqu'il est nécessaire de s'inscrire pour écrire…

Je vois que j'ai affaire à un bon.

Le prix de l'abonnement au téléphone fixe a doublé avec l'ouverture à la concurrence

Non ils n'ont pas doublés, le forfait fixe RTC à 16 euro existe encore chez Orange et SFR. Le forfait à 30 euro ne correspond pas au même service.

Je parle de 30 € ? Non. Alors maintenant figure-toi que ce dont je parle, « l'ouverture à la concurrence » comme je l'ai bel et bien écrit, date non pas des dernières années mais de l'époque où tu étais à la maternelle. Tu as peut-être lu dans un livre d'histoire qu'au siècle passé, notre peuple archaïque utilisait une monnaie appelée le franc (ça vient juste après la sesterce). Eh bien figure-toi que rien qu'entre 1995 et 2000, l'abonnement est passé de 45 à 82 F.

Les communications mobiles coûtent encore environ 5 fois plus cher que les communications fixes les moins chères avant la concurrence et le développement du mobile (l'inflation ne compte que pour un facteur 1,4 dans le même temps).

Encore une fois, ne pas comparer les carottes et les bananes.

Il y a bien sûr des carottes et des bananes puisque si on considère purement sur le fixe, il n'y a pas grand chose à comparer, vue l'augmentation de l'abonnement de base. Par contre l'usage du téléphone fixe a été en grande partie supplanté par celui du mobile, d'où l'intérêt non nul de la comparaison.

Si on tient à comparer les communications fixes les moins chères dont je parlais, on (des passéistes croulants, pas toi, rassure-toi) se souviendra avec émotion de la suppression du tarif bleu nuit, puis du tarif bleu, puis de l'extension du tarif rouge à des périodes auparavant blanches, de l'arnaque du passage à la tarification à la minute… accompagné de l'apparition d'un coût fixe incompressible par communication.

De plus c'est faux. Le mobile le moins cher est à 0 par mois, soit littéralement infiniment moins cher que le fixe le moins cher.
Sinon, il est à deux euro, et c'est moins cher que le prix du fixe de l'époque.

Cher ânon, j'ai pourtant bien écrit « les communications » et non pas les abonnements. Il arrive que les mots aient un sens. Le truc que l'on paye si l'on n'a pas un forfait illimité.

et maintenant ils vont lâcher 50 à 90 € pour internet, TV, un ou deux mobiles liés, etc.

Les forfaits internet commencent à 12 euro et la moyenne est autour de 35 euro, je te signale…

Et moi, je te signale que tu as, par malhonnêteté ou incapacité de comprendre un texte même en y passant 3 jours, extrait ce passage d'un paragraphe qui concernait explicitement le fait que l'enveloppe consacrée globalement aux télécommunications augmentait malgré le fait que les forfaits ADSL baissaient, ce dernier fait n'étant donc pas nié. Il menait à pointer le fait que les opérateurs avaient intérêt à te fourguer le plus de produits possibles, d'autant plus qu'il s'agit d'une concurrence d'entreprises privées dont l'intérêt unique est de rentrer de l'argent et non pas l'intérêt général (auquel elles sont uniquement partiellement contraintes par les autorités).

Le fait est que la concurrence, d'abord à 3, puis à 4, a dynamisé les acteurs et les a poussé à se réformer et s'améliorer pour être plus efficace.

Oui, quand OVH fait de la collecte SFR sur des installations Orange qui finissent sur une ligne France Telecom qui sous-traite les travaux à une entreprise privée locale, c'est rationnel ; quand plusieurs de ces gars interviennent sur les mêmes installations, ce n'est pas du tout source d'anicroches ; quand tout ce petit monde se renvoie à la balle à chaque problème c'est efficace et rapide. D'accord, d'accord.

La concurrence est bénéfique. C'est elle qui nous fait progresser.

Merci de ton attention, tu peux maintenant reprendre le cours normal de tes activités de jeune libéral dynamique. Il n'y aura pas de prochaine leçon.

Quand on tape « buy le truc », le premier résultat est surprenant aussi : « Buy a Truck, Get a Free AK-47 ».

Rien à ajouter : tout pareil.

Déjà, sur Aliexpress, je ne le trouve pas (aujourd'hui) au prix indiqué plus haut mais minimum à 46 €.
Bizarre, je le trouve à 35-37€ chez moi.

À l'unité, fpdin ?

Après, faut se décider : on compare à un produit concurrent de Raspberry Pi ou Cubieboard? On s'y perd… L'auteur de la dépèche compare à un Raspberry Pi, donc on imagine pouvoir l'avoir autour de 30€ TTC… Sinon, ben euh…

Ben c'est les tripes d'une Cubieboard, avec les connecteurs d'un Raspberry. Et pour les quantités produites, ça doit taper dans les mêmes catégories qu'une Cubieboard, le Raspberry étant probablement hors-concours. Donc le prix (enfin, plutôt le coût de revient) me semble devoir être dans les mêmes eaux qu'une Cubieboard, oui.

Sur www.cpubenchmark.net, tu as des listes des résultats Passmark des CPU et GPU. La liste n'est probablement pas exhaustive mais elle ne doit pas en être loin.

Je ne pense pas qu'ils fournissent ces listes directement comme tu le voudrais, mais en récupérant les pages comme Common CPUs, en éditant le HTML pour ne garder que la partie intéressante, et en écrivant un one-liner de Perl ou autre pour récupérer le contenu des champs <a>xxx</a>, ça ne devrait prendre que quelques minutes pour avoir une liste comme tu la souhaites.

<tr>  <td id="rk2023" class="chart">    <a href="cpu.php?cpu=Intel+Core+i7-4930K+%40+3.40GHz&amp;id=2023">Intel Core i7-4930K @ 3.40GHz</a>  </td><td id="rt2023" class="value">  <div class="meter pink">    <span style="width: 86%" onMouseOut="HTAD()" onMouseOver="STAD(event,1,667,6,2)"></span>13,223  </div></td>
<td class="chart"><a href="cpu.php?cpu=Intel+Core+i7-4930K+%40+3.40GHz&amp;id=2023#price">$579.99</a></td></tr>
<tr>  <td id="rk902" class="chart">    <a href="cpu.php?cpu=Intel+Core+i7-3930K+%40+3.20GHz&amp;id=902">Intel Core i7-3930K @ 3.20GHz</a>  </td><td id="rt902" class="value">  <div class="meter yellow">    <span style="width: 79%" onMouseOut="HTAD()" onMouseOver="STAD(event,2,1417,6,2)"></span>12,146  </div></td>
<td class="chart"><a href="cpu.php?cpu=Intel+Core+i7-3930K+%40+3.20GHz&amp;id=902#price">$569.99</a></td></tr>

Et en bonus tu peux aussi récupérer les valeurs Passmark si tu en as envie.

Auparavant, ARM était plutôt opposé à toute version libre de leur pilote, craignant, comme beaucoup de concepteurs de circuits, que cela donne trop d'informations sur le fonctionnement interne de leur architecture, donc ce changement de vision est au contraire un progrès.

Je crois qu'il y a méprise. Ce qu'ils ont dit c'est plutôt « Non, on ne vous aidera pas. Si on voulait un pilote libre, on aurait libéré le nôtre, mais on n'en veut pas. ». Donc pas de changement de vision mais au contraire toujours campés sur cette position crétine.

Déjà, sur Aliexpress, je ne le trouve pas (aujourd'hui) au prix indiqué plus haut mais minimum à 46 €. Ensuite vous comparez un prix HT et un prix TTC ! Vous êtes censé rajouter 20% de TVA à l'importation (OK, par la poste classique, ça passe en général à l'as mais sinon en plus des 20%, on se fait estamper avec des frais à la con, des minimums à percevoir, etc.). Et hop, ça fait 55€.
Du coup le revendeur français est au même prix et (pour une fois !) ne s'est pas trop sucré au passage, même sur les frais de port.

Euh, c'est quand même moi qui l'ai invoqué. Bon, d'accord, il greppe sur son pseudo :-) mais ce n'est pas la peine de l'attaquer les rares fois où il n'y est pour rien.

Ça faisait longtemps qu'il n'y avait pas eu de troll féministe/sexiste/anti-sexiste. Ça ne m'avait pas manqué.

Zénitram devait attendre impatiemment : il va pouvoir recharger son karma ! :-)

Donc je cherche un mini PC de bureau qui soit le plus silencieux, le moins cher possible, avec minimum 4Go de RAM et un connecteur VGA (ou alors, un bon connecteur HDMI -> VGA mais toutes les critiques sur Amazon pour ce genre de produit sont affolantes).

Alors, mini PC, donc dans la gamme {Gigabyte Brix, Zotac Zbox, Intel NUC}. Les moins chers que j'aie répertoriés (je ne dis pas que c'est exhaustif) :

• Gigabyte Brix GB-BXBT-2807 : Celeron N2807 (passmark 903)
• Zbox ID18 : Celeron 1007U (passmark 1454)
• Intel NUC DE3815TYKE : Atom E3815 (passmark 356), pas d'emplacement HD ?
• Intel DN2820FYKH : Celeron N2820 (passmark 1052)

Donc Zbox ID18. C'est ce sur quoi je tape ce message et bien que ce ne soit évidemment pas un foudre de guerre, ça me suffit très bien (et je suis avec une Gentoo donc je supporte le temps de compilation de chaque programme) avec 2 Go . Ça supporte jusqu'à 16 Go donc OK pour tes 4 Go. RAM DDR3 SO-DIMM (classique pour portable, pas besoin de DDR3L au contraire des autres modèles cités). HD 2,5". Une sortie DVI (qui me sort aussi l'analogique pour le VGA avec un classique adaptateur à 3 sous) et une HDMI pour mon second écran.
Aucune idée du silence par rapport aux autres.

Voilà, au final (RAM+HD) c'est le même prix qu'un ordi de bureau premier prix mais ce dernier ne remplirait pas la condition "mini PC".

Merci pour les tests !

Je me réponds sur un point :

• Ça couine si deux champs ont des range qui se chevauchent ?

On dirait que non car dans l'exemple que tu as mis en lien, il y a des sortes d'alias sur certains champs :

Write_Enable at 4 range 9 .. 9;
Read_Enable at 4 range 9 .. 9;
Expansion_Direction at 4 range 10 .. 10;
Conforming at 4 range 10 .. 10;

Dommage, parce qu'avec toutes les bornes à taper, c'est facile de se planter par ci par là.

Merci.

Mais pour l'ordre des champs, c'est déjà précisé dans l'exemple précédent qui spécifie les tailles ET les emplacements.

Et le sens de la numérotation des bits (0<=>LSB ou 0<=>MSB) est fixé par la norme ?

Par contre, quand tu as besoin d'un champ inutilisé, tu es obligé de le spécifier aussi.

Heu, dans ton exemple plus haut, justement, tu ne spécifies par les bits 8 et 9.

Pour parfaire mon information :-) :
- Ça couine si on dépasse l'attribut 'Size avec les range des champs ?
- Ça couine si deux champs ont des range qui se chevauchent ?
- Ça couine si deux champs ont des range qui se recouvrent alors que leurs offsets (le at) sont différents ?

Bon, c'est lourd

C'est bien de l'Ada, alors :->