Ingénieur

Un peu Lapalissien, mais jusque là je suis d'accord.

J'ai dû louper un post, parce-que je n'ai pas lu l'affirmation qu'un "ingé qui utilise un mauvais outil est bon". Un outil est bon s'il est bien utilisé, et mauvais s'il est mal utilisé, donc un outil ne peut être intrinséquement qualifié de "bon" ou "mauvais". La qualité "bon" ou "mauvais" se rapporte à celui qui use de cet outil, et non à l'outil lui-même, qu'il s'agisse d'une règle à calcul ou d'un PC. Par suite, ce n'est pas l'outil en soi qui est en cause, mais celui qui l'utilise.

Valable pour génèrer des fermetures de sociétés et du chômage en masse. Un investisseur qui recherche de la plus-value peut aussi acheter du terrain pour y construire des logements qu'il louera ou vendra avec un gain à terme énorme, et foutre la paix à ceux qui pratiquent un *autre* métier. L'investissement qui ne cible que le gain d'argent ne génère rien d'autre que de l'argent, et accessoirement les crashes que l'on subit cycliquement. Aller prétendre qu'il y ait une "logique valable" là-dedans : non merci.

Tu es bien sûr libre de croire (ou pas) ce que tu veux, comme je suis libre de considérer que la "croyance" n'est pas l'approche optimale de ces situations.

Ces temps-ci, un employé est moins rétribué (en salaire et situation) en fonction de son savoir-faire et au mérite, qu'en fonction du nombre de boîtes de cirage qu'il peut fourrer dans ses poches. " C'est une logique d'investisseur " qui ne vaut pas un clou.

Reply to
Jean-Christophe
Loading thread data ...

C'est dommage, j'attends tes lumières avec une certaine impatience. Plus rien d'autre à dire ?

Pour ta gouverne, j'ai passé quelques années à ne faire que des régulateurs spéciaux, je sais à peu près de quoi je parle (et je n'ai toujours pas posé de question à ce sujet, tu remarqueras, je prétends simplement que recopier les schémas que l'on trouve sur le grand ternet sans les comprendre est dangereux).

Cherche un peu mieux. J'ai mis mes sages réflexions sur Internet. Info : mes réflexions sur ce sujet précis ont été publiées très récemment.

Ça change beaucoup de choses. D'un côté, on conçoit un circuit, de l'autre, on le repompe en le comprenant au mieux à moitié. D'un côté, on sait pourquoi ça marche. De l'autre, lorsque ça marche, c'est par hasard.

Ce n'est pas parce qu'ils n'ont pas eu le droit de publier qu'ils n'ont pas laissé des écrits et des preuves de leurs études. Il y a dix ans, j'ai eu l'occasion de bosser avec des bulgares dont le sujet était l'épitaxie. Ce n'est pas du tout ma spécialité, les types n'étaient pas présentables, habillés n'importe comment. Mais ils ont lancé des conférences sur la mer Noire dans lesquelles ils damaient le point aux spécialistes de LIP6. Tu peux chercher mon nom, il est dans les procedings. Et pourtant, jusqu'à la fin des années 1990, ils n'avaient pas publié beaucoup de papiers faute de moyen et d'autorisation de publication.

Je n'ai pas parlé de PDP11, mais de VAX11/750. Apprends à lire. L'OTAN utilisait des missiles (utilise peut-être toujours) dans les années 1990 qui étaient filoguidés (avec fibre optique) par un VAX dans un semi-remorque. Très pratique. La version russe était autonome avec un VAX embarqué. Tu peux dire ce que tu veux, les types qui ont fait ça ont peut-être copié, mais étaient excellents. Pour ta gouverne aussi, le clone russe était moins buggué que le 750 originel. Ça prouve que non seulement, les soviétiques ont copié, mais ont aussi corrigé le truc.

Et Hitachi s'est pris un procès de Motorola pour le 6309... Et les concepteurs du 6500 ont failli bouffer la moquette après avoir copié le 6800. Copier en améliorant nécessite un savoir-faire. Point-barre.

Pov'type.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très 
volontiers une réponse... 
 Click to see the full signature
Reply to
JKB

Le 27/09/2013 13:39, Volkin a écrit :

1°: il doit y avoir beaucoup de tapettes ici car programmer en assembleur il y en a beaucoup et moi le premier !!!! 2°: l'assembleur, pour quelqu'un qui sais programmer est beaucoup plus efficace qu'un langage de "haut niveau". un exemple simple, changer le niveau d'une sortie en assembleur et en C et comparer la difference de code, une seule instruction en assembleur par contre en C....

a te lire j'ai l'impression de voir quelqu'un avec une grosse voiture allemande pour faire 2Km tous les jour.

laurent.

Reply to
laurent

Corollaire du second cas : quand ca marche ils ne savent pas comment, et quand ca ne marche plus ils ne savent pas pourquoi. J'ai assisté à des démos faites par des mecs trés fiers d'eux qui blanchissaient dès que quelque chose allait de travers. (et appelaient à l'aide ceux qui n'avaient pas bossé dessus)

Un ingé électronicien (sic) concevait une carte dont un sous ensemble nécéssitait de désérialiser des données binaires : tout d'abord il n'a aucune idée de comment s'y prendre, ( sans doute qu'à son école "on a pas vu ça" ) une bonne âme lui suggère un registre à décalage, il bricole avec un jour ou deux ( ! ) mais patauge, et le 3e jour il s'exclame "ce qu'il me faut c'est un 4017" ! Au final on réalise qu'il est incapable de lire ni d'interpréter correctement un chronogramme. Il avait appris à reproduire des sous-ensembles déjà vus, mais pas à comprendre pour ensuite raisonner créativement.

Résumé (exemples un peu agés mais le fond reste vrai) powerdown.free.fr/rp.html

Reply to
Jean-Christophe

Personnellement, je ne réécrirai pas en ASM un gros programme qui a nécéssité en tout 5000 lignes de C.

A part la portabilité, une raison d'écrire en C est que le source nécéssite moins de code que si c'était en ASM,

- et on a toujours l'option d'y inclure de l'ASM pour les parties de code critique, par exemple en vitesse et taille de code (exemple, les ISR)

Certains compilos C bien écrits sont trés efficaces pour générer un code compact, mais cela n'assure pas d'être à l'abri de mauvaises surprises; par exemple pour une cible uC/16 bits les opérations C sur des entiers

32 bits sont implémentées (par certains compilos) de façon assez désastreuse en ce qui concerne la taille du code généré (même pour de simples décalages) et obligent à les écrire à la main en bon vieil ASM. Dans certains cas délicats il est prudent de jeter un oeil avisé sur le code généré par le compilo.

Pour certaines applications critiques il est imposé de dévalider toutes les options d'optimisation du compilo : l'objectif étant d'éviter à tout prix que le code ASM généré diverge de ce que le programmeur avait en tête.

Reply to
Jean-Christophe

du chômage en masse.

re* métier.

rien d'autre

ent.

non merci.

Pour réaliser un projet technique il faut d'abord investir en mar riel et en hommes. C'est comme ça et pas autrement.

Evidemment on peut aussi ne rien investir. Si vous pensez que c'est mieux - gardez votre conviction camarade, je ne peux rien pour vous.

Reply to
Volkin

ui

- rien.

e.

que des

e parle (et je

s, je

sur le

Des régulateurs spéciaux 3.3V 1.5A, oui vous avez passé de s années à ne faire que ça, je vous crois, oui bien sur. Bon, si vous faites ça dans une société privée qui vo us paye pour ça ou le soir chez vous, OK, ça ne ma pose pas de problèmes.

Tous les schémas trouvés sur google sont valables y compris dans Wikipédia.

La bonne démarche est :

- identifier le composant à l'aide d'une recherche parametrique

- utiliser le schéma d'application. ne pas chercher à comprendr e car le concepteur connait mieux les défauts et limitations de son produit.

- garder l'énergie pour la conception des choses que vous ne trouvez pas en tout fait.

Ceux qui ne travaillent pas comme ça ne sortent jamais rien et s'il sortent quelque chose ça ne tient pas la route comparé à la concurrence. Le monde est comme ça, je n'y peux rien.

oute la

re.

es

par un VAX

aient excellents.

e le 750

opié,

Ah oui ... Non, je ne connaissait pas ce processeur. Je suis parti avant. K1839. Apparemment il est toujours en production.

Formidable. Il y a 25 ans les russes on copié un jeu d'instructions et ils l'utilisent toujours. Super. Rien à dire. C'est des fous furi eux en math et en technique en général, c'est sur.

8080, 8086 ...)
s

pié

nt-barre.

Et vos russes avec leur regle en bois n'ont pas eu de process ?

MDR.

d

ntes,

Reply to
Volkin

J'ai écrit qque j'avais passé une partie de ma vie professionnel sur des problèmes de régulateur. Pas sur des régulateurs 3,3V 1,5A. Tu ferais bien d'apprendre à lire autrement qu'entre les lignes.

Ben non. Celui de wikipedia n'est _pas_ bon dans le cas général. Mais tu as le droit de prétendre le contraire. Entre nous, ça montre ton niveau de culture technique. Bon, deux types en moins d'une semaine dans ma boitakon, c'est un record.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très 
volontiers une réponse... 
 Click to see the full signature
Reply to
JKB

Je suis d'autant plus d'accord avec ça que je n'ai pas dit le contraire, par contre je critiquais une *certaine* finalité et les *moyens* d'y parvenir. ( en partie dans le texte que - oops - tu as supprimé )

Je n'ai pas affirmé qu'il ne fallait pas investir, mais ne vais pas non plus répéter ce que j'ai déjà dit dans mon post précédent. Que ce soit volontaire ou pas de ta part, si tu déformes ainsi le fond de ce qu'on te dit pour y répondre à côté, je vois mal où est l'intérêt.

Ca tombe bien, je n'ai pas besoin d'aide :o)

Reply to
Jean-Christophe

Effectivement.

Le dernier en date pour moi c'était de l'ISR en assembleur sur Blackfin pour traiter les lignes vidéo en temps réel.

Le compilateur C pour Blackfin était (à l'époque, je ne sa is pas si ça a changé) très orienté optimisation calcul parallèle et non latence de réponse.

)

te.

Oui.

Reply to
Volkin

Ca dépend du jeu d'instructions du uC, le compilo C faisant au mieux avec ce qui lui est disponible. Exemple avec du HC11/HC12/HC16 pour positionner à 1 le bit de poids faible de l'octet localisé à l'adresse 0x2000 :

BSET $2000,#$01

Même dans le cas le plus défavorable on reste quand même loin de 20 lignes ASM :

LDAA $2000 ORAA #$01 STAA $2000

Reply to
Jean-Christophe

Si maintenant on compare l'efficacité de coder dans un langage ou un autre, je trouve le C trés souple ( et moins restrictif que d'autres langages, ce qui permet d'être créatif, par exemple avec l'usage de pointeurs, de pointeurs sur des pointeurs, etc ) Mais en ce qui concerne la possibilité d'être sûr d'avoir atteint un algo qui ne puisse plus être optimisé, c'est bien l'ASM qui l'emporte, vu son immédiate proximité avec le hard.

Je pensais en particulier à de l'embarqué en Aéronautique & Spatial, mais il y a sans doute d'autres exemples ...

Reply to
Jean-Christophe

vous paye pour ça

ral.

Super, on revient au post initial quand vous avez affirmé que les

10 premières pages de google ne contenait pas le bon schéma de régulateur linéaire.

En apportant une argumentation technique de poids - diode zener n'a pas une courbe de réponse droite. Une découverte.

  1. Ce n'est qu'un question de précision, le principe est bon. Sans connaitre les contraintes de précision de votre design concret on ne peut pas dire que le schéma n'est pas bon.

C'est comme dire qu'aucun transistor n'est pas bon parce que aucun n'est idéal.

  1. Pour un régulateur que votre collégue recherchait à fai re plutot que fanfaronner devant le tableau noir avec une regle en bois vous aurait du lui conseiller un régulateur tout fait, précis et stable dans la plage d'utilisation qu'il lui fallait.

a montre

Oui, je le sais. Je suis le meilleur.

MDR

Reply to
Volkin

sais

ul parallèle

Et tableaux, et pointeurs sur les fonctions, et structures et preprocessor, et ...

Oui. Tout en restant très très très proche de l'assembleur .

r atteint

Je suis globalement d'accord. Sauf une chose : derrière les arbres on ne voit la foret.

Il vaut mieux travailler d'abord en C pour mettre au point l'algoritme le plus optimal. Et une fois que vous l'avez optimisé il peut être converti ou reecrit en assembleur.

En général je juste retouche un peu le code généré par le compilateur. Après ça il ne reste que c'est 20% du gain pour 80% du temps, c'est rarement rentable.

Je fais la même chose avec VHDL. Pour les algos trop complexes je travaille d'abord en C. Une fois que l'algo est au point je le reécris (là par contre entièrement, je n'ai pas trouvé de bon convertisseur) en VHDL

Reply to
Volkin

Ici je trouve enfin une raison d'intervenir (avec légèreté malgré la lourdeur des commentaires du/des fils):

Quelle est la différence entre une "grosse voiture allemande" (en tr ois lettres et les hémorroïdes ?

Reply to
jules

ter.

Ca fait des années que je n'ai programmé en assembleur car j'ai

de plus en plus de code écrit et pour une raison de portabilité

ça oblige d'utiliser un langage haut niveau.

De mémoire j'ai travaillé sur : 8080, NSC800, x86, Z80, x51, SH , PIC, MIPS, 80960, ARM, Blackfin, 6809, 68332, et j'en oublie sans doute trois ou quatre.

plus

Souvent une seule instruction.

En plus maintenent la puissance des CPU et la quantité de mémoi re disponible) est telle que c'est rarement un problème. Supposons que vous commencez un projet avec un 8 bit à 20 MHz. Ca ne passe pas ? Vous passez sur un 32 bits à 40 MHz. Toujours pas ? Vous passez sur un autre à 200 MHz. La différence est de 1 euro tout au plus.

Il y des exceptions sans doute, les projets avec de très très g ros volumes peut être.

:D Mais pas tous les jours.

Reply to
Volkin

Aaah, les tables de pointeurs sur des fonctions :o) Dans ma jeunesse j'avais implémenté pour une appli un interpréteur via une table de struct dont chaque élément contenait le hashcode d'un token et un pointeur sur la fonction correspondante ; l'ajout d'un nouveau token du langage consistait à coder la fonction voulue puis ajouter l'élément dans la table: puissant et simple : merci le C !

Et il faut aussi savoir goûter et apprécier la simplicité du codage en C, par exemple pour strcpy(dest,src) while( *dest++ = *src++ ); /* chapeau */ ce à quoi un débutant objectera que le '=' doit être remplacé par '=='

Mais portable. ( jusqu'à un certain point pour les I/O hard )

Il est vrai que, les yeux fermés, une fois qu'on a un algo en tête, on a immédiatement le code correspondant, qui est souvent plus direct à implémenter en C qu'en ASM. Mais personnellement, si ca *doit* être implémenté en ASM, alors je l'écris directement en ASM.

L'un de mes meilleurs souvenirs est d'avoir implémenté (vers les années 90) du code auto-modifiant ASM HC11 pour simplifier des manipulations de champs de bits de données. Au boot un bout de code machine en UVPROM terminé par un RTS était recopié vers une zone RAM réservée, et en runtime, suivant les besoins, ce code était modifié à la volée puis exécuté par un JSR en RAM. Un vrai plaisir.

Bien sûr cela peut aussi s'implémenter en C, mais un compilo C dédié uC *pourrait* refuser un appel de code en RAM (je l'ai déjà vu) ce qui complique, au lieu de simplifier comme en ASM.

J'ai déja eu aussi à utiliser un compilo C (imposé) qui refusait de compiler des fonctions récursives, ce qui m'a obligé à complexifier mon code - une aberration !

Je suis d'une époque ... ( que les moins de 0x14 ans ne peuvent pas connaître ) ... où le VHDL n'existait pas encore :oÞ

Pour finir sur un sourire (?) je me souviens d'un ancien article de Dr.Dobbs où l'auteur proposait d'implémenter du code objet directement en l'ASM.

Reply to
Jean-Christophe

Le Fri, 27 Sep 2013 21:35:16 +0200, Volkin a écrit :

Étonnant? Alors que ces grosses boites font justement, au dire des DRH, la chasse aux meilleurs.
--
http://www.youtube.com/watch?v=Mq-LpAKuhDs 
    Philippe Vessaire  ??
Reply to
Philippe

Le Fri, 27 Sep 2013 21:33:27 +0200, Volkin a écrit :

pas certain, il sont juste plus vifs donc moins de temps pour rattraper un mauvais coup.

en fait, les calculateurs lissent les variations de comportement, plus ou moins bien selon la qualité des programmes. Entre un MD80 extrêmement sensible et un A321 (je choisi les longs fuselages), le 2° a le même ressenti pour les deux extrêmes de centrage alors qu'il y a quasiment deux avions différents avec le 1°.

--
http://www.youtube.com/watch?v=Mq-LpAKuhDs 
    Philippe Vessaire  ??
Reply to
Philippe

Le Fri, 27 Sep 2013 03:37:05 -0700, ptilou a écrit :

spécialité haurtografe

Reply to
moi-meme

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.