electronews et meilleurs liens électroniques - Page 69

Mouarf

Faut pas mettre "four" et "Allemagne" dans la même phrase, ça tend vraiment de très mauvaises perches

Rôôôôh

J'en avais peut-être déjà parlé, mais pour dessouder les trucs "difficiles", j'ai entendu de bons échos de ça (pas testé personnellement, par contre) : http://www.chipquik.com/
Dave Jones en parle ici.

C'est un alliage qui abaisse le point de fusion de la soudure, ce qui permet de rallonger la durée pendant laquelle elle reste liquide : c'est pratique pour dessouder les composants qui ont beaucoup de pattes qu'on ne peut pas toutes chauffer en même temps. D'après le site, c'est dispo chez Farnell, Digikey, Mouser, etc.

Call : Godzil appelé(e) sur ce topic...
Ça pourrait te servir pour le connecteur de la Swan

C'est... cher

Oui.

D'un autre côté c'est pour un usage occasionnel, je pense qu'en acheter une fois permet d'être tranquille pendant un certain temps.

http://what.thedailywtf.com/t/the-wonderful-world-of-compilers/2169
(et non, ce n'est pas moi qui ai posté )

Ça me rappelle quand j'avais fait une analyse de deux RTOS en 2005, l'un d'eux créé et distribué avec son compilateur dédié par une marque connue (produisant également des calculatrices), l'une des conclusions après avoir vu la liste des bugs ouverts du compilateur était qu'il valait peut-être mieux rester sur l'ancienne solution

sérieux vous vous tapez des bugs comme ça ?
Ca sert à quoi ces fameux pics, ya d'autres composants analogues j'espère ?

Folco oui serieux, c'est pour ca qu'il y a plein d'autre CPU que les PIC qui eux marchent

(Zero va me tuer de mettre certaines refs, mais globalement ils sont quand meme moins problematiques que les PICs )
8bit: AVR/ATMega, STM8, 8051 based, 6502 based, MSP430, ...
32bit: ARM Cortex-Mx, ...

Aucun de ces CPUs n'atteins tout problèmes additionne la somme totale de problèmes que les PICs peuvent avoir..

Folco (./2049) :
sérieux vous vous tapez des bugs comme ça ?

Oui.
Rien que de voir le code assembleur généré : tu pleures (genre 20 lignes de codes alors que en 2 instructions ça fait pareil !). (GT en ferait une crise cardiaque)
De toute façon (si c'est toujours pareil depuis la dernière fois que je l'ai utilisé), rien que le fait que les accès aux fichiers (chemin+nom de fichiers) lors de la compilation est limité à 64 caractères en dit long sur la qualité de leurs outils

Et le hardware est pas mieux.
Pour avoir travaillé sur un projet basé sur différents modèles : 1 spécialisé USB, 1 spécialisé communications, 1 spécialisé conversion analogue->digital.
Au final :
- le USB avait des bugs dans la couche USB
- le spécialisé communications avait des bugs dans l'UART, l'I2C, le SPI et dans le gestionnaire du Bus mémoire externe
- le spécialisé ADC avait des bugs dans le numériseur...
A chaque mois d'avancement du projet, on vérifiait l'erratasheet, et à chaque fois la doc grossissait avec de nouveaux bugs découvert !

Du coup il a fallut faire des hacks partout pour que ça fonctionne (à peut prêt) comme voulu...

Ca sert à quoi ces fameux pics,

A faire des TPs dans les écoles

ya d'autres composants analogues j'espère ?

ya des µP bien mieux et bien moins buggé c'est sur

(au fait, Folco a ramassé un beau )

http://en.wikipedia.org/wiki/Drum_memory

Sympatique. Je veux même pas imaginer le bruit que ça devait faire

Zerosquare -> ah oui, merci
Au fait, pourquoi ils n'utilisent pas un compilo existant, ils n'auraient juste qu'à faire un backend, non ? D'ailleurs, ça se vend pas ça, des compilateurs tout nus, sans backend ? Pour les langages les plus courants, ça serait quand même plus simple que de recoder from sratch, non ?

Je ne connaissais pas les "Drum machine" decouvert ca dans ce texte:

http://www.pbm.com/~lindahl/mel.html

Folco > ben c'est ça le pire, ils se basent sur GCC, et ils arrivent à le faire déconner complètement
(enfin, pour XC8 je n'en suis pas sûr, mais pour XC32 c'est le cas et il y a pourtant plein de bugs...)

j'ai eu à bosser sur des CPU smartcard assez atypiques, avec des compilos maison, et des bugs de compil, on en mange à la pelle, parfois on doit faire des workarounds à base d'assembleur, c'est marrant.

quant aux PIC18, au taf on est resté sur mcc18 parce que XC8, et son super IDE MPLABX en JAVA (ouioui, basé sur netbeans!) suxduku tellement qu'on arrive plus à recompiler nos firmwares avec.

(pour que Squalyl en vienne à renier un truc en Java, vous imaginez ce que ça doit être )

Zero: en meme temps vu la gueule du code de GCC c'est pas etonant qu'il s'y mangent les pieds dedans...

SCPCD (./2051) :

Rien que de voir le code assembleur généré : tu pleures (genre 20 lignes de codes alors que en 2 instructions ça fait pareil !). (GT en ferait une crise cardiaque)

Au moins avec mes codes si bug il y a ça sera de ma faute

GT Pas aussi buggé que ces compilos !!

Heu non, ça peut être aussi un problème de l'assembleur

Godzil > c'est vrai que les sources de GCC sont loin d'être des exemples de code propre et lisible, mais pour arriver à créer des bugs pareils ils doivent faire n'importe quoi...

peut-être qu'ils font faire par des stagiaires

C'est sûrement ça. Quelle bande de connards, ces stagiaires !!!

#crayoui#

(mais moi je déconnais )

Pen² est tout-à-fait sérieux, lui.

Nan, il y a les bons stagiaires et les mauvais stagiaires

Oh, v'là une blague qui n'est pas inconnue

Oui il y a 10 types de stagiares, les bons, et les mauvais