Bonjour à tous,

C’est une question très courante quand veut débuter en Arduino (et donc en générale quand on veut aborder le monde des microcontrôleurs) : quelle carte choir ? UNO, MEGA, DUE, Nano ??!

Comprendre

Très souvent le débutant fait les mêmes erreurs qui le guide vers un mauvais choix de première carte :

- il a déjà un projet en tête : et oui mais l’Arduino, même si ça se veut être la plateforme de développement la plus simple à mon sens, ça reste de la programmation et de l’électronique. Et avant de vouloir courir il faut savoir marcher ! Très souvent sur le forum Arduino on croise des choses du genre "je voudrais faire un quadricoptère, mais je comprends pas ce que c’est que le PWM". Bah oui mais ça peut peut-être sembler barbant mais commencer à jouer avec des led, des boutons, des photorésistance … Permet d’apprendre les bases indispensables et ça prend pas forcement plus de temps au final parce que ça va peut-être prendre du temps au départ mais qui sera vite rattrapé. Ne pensez pas que vous serez plus malin que les autres.

- "Je vais prendre celle qui en a le plus dans le slip au cas où" : perso, j’ai une MEGA, et elle ne m’a jamais servi … A moins d’avoir des projets bien particuliers, on peut faire énormément de choses avec une Nano ou une Micro, il existe des tas d’extensions possibles pour parer à toutes les situations. On croit bien souvent que le système est lent : croyez moi, le jour où vous amènerez votre UNO à ces limites, c’est soit que vous aurez atteint un certain niveau, soit que vous avez un code foireux ;)

Les fonctions de l’Arduino

Je pense qu’il est bien important de comprendre les fonctions de l’Arduino pour comprendre ce que l’on achète.

Tout d’abord il faut comprendre ce qu’est exactement Arduino : ce n’est pas juste un ensemble de carte, c’est un environnement : des cartes ET une interface de programmation. Ces cartes (puisque que c’est le sujet qui nous interesse ici), il y en a plusieurs mais le principe est toujours le même : on trouve un microcontrôleur (= le cerveau) et une série de composants nécessaires à son fonctionnement, le tout monté sur un circuit imprimé qui facilite le développement : bornier, possibilité d’empiler des "shields" pour ajouter des fonctions, entrées pour différentes alimentations … Donc une carte, c’est un ensemble de choses qui vont lui donner ces caractéristiques finales, mais le principal dans l’histoire reste évidemment le microcontrôleur : c’est lui qu’on va programmer et qui définit le plus les possibilités données à la carte.

Voyons maintenant ce que peut faire un microcontrôleur …

Les entrées/sorties digitales

C’est LA fonction première d’un microcontrôleur : avec une simple ligne de code, on peut passer une sortie du µC (microcontrôleur) à 5V ou à zéro volt. Quelle intérêt ? Alimenter une led au travers d’une résistance, faire sonner un buzzer, commander une électrovanne  un moteur … En gros c’est une sorte "d’interrupteur" : lumière allumée ou éteinte.

Maintenant on peut faire l’inverse : lire une entrée de l’Atmega. Est-elle l’état haut (=5V) ? Ou à l’état bas (=0V) ? Quelle utilité ? Détecter l’appuie sur un bouton, un son, un signal d’un détecteur infrarouge … Bref tout ce qui prend fourni des signaux tout ou rien (= "ma lumière est allumée ou bien éteinte ?")

Les entrées analogiques

Une fonction également très importante d’un µC (s’il en est capable, ce qui est le cas de toutes les arduinos) est la mesure analogique : c’est très simple à expliquer, c’est comme si vous aviez un voltmètre. Une ligne de code et hop vous connaissez la tension sur tel ou tel pin analogique. Quelle utilité ? Lire tout un tas de capteurs : mesurer la luminosité, la température, l’humidité, la tension d’une batterie …

Les sortie PWM

La on va pouvoir générer une tension "pseudo variable" : en gros il s’agit de faire passer un pin de 0V à 5V puis de 5V à 0V très rapidement(tellement que c’est imperceptible pour l’être humain), et ce, avec une répartition du temps passé à 5V et à 0V variable mais bien évidemment commandée dans le code :

C’est comme un variateur de lumière : la luminosité varie simplement pour nous, mais si on dilatait le temps, on verrait des variations dans la luminosité car en réalité le courant circule un temps puis s’arrête. L’oeil humain n’étant pas assez rapide pour distinguer ces variations, l’illusion fonctionne. Le PWM c’est un peut pareil : un voltmètre lira effectivement une tension variable car la plupart sont équipés de filtre en entrée qui lissent les créneaux de tension. Mais il faut garder à l’esprit que ce n’est pas une réelle tension fixe : si le système sur lequelle on le branche est assez rapide, il ne verra que du 0V ou du 5V. Par exemple si je branche une sortie PWM sur une entrée analogique de l’Arduino, et bien vous aurez un coup une mesure à 0V et un autre à 5V.

Les ports de communication

Il existe trois principaux mode de communication : la liaison série, le SPI et l’i2c. Elles servent principalement à communiquer avec l’ordi (ça c’est pour la liaison série) et à communiquer avec d’autres composants (SPI et i2c). En fait derrière ces noms un peu barbares c’est toujours le même but : échanger des données (et qui sont toujours des 0 et des 1), il n’y a que la manière qui change. Je ne vais pas trop développer ce sujet, mais ce qu’il faut retenir :

- SPI ou i2c : ces deux modes permettent de communiquer avec presque autant de "clients" que vous voulez avec un seul port. Quelque part, deux i2c c’est inutiles, c’est comme avoir deux bouteilles de whisky qui ne se vide jamais.

- Série : deux points à retenir. Le premier, c’est que la plupart des Arduino n’ont qu’un seul port série et qu’il sert à la liaison avec le PC. A ce moment la, un composant (un Atmega32u4 pour les carte récentes, un FT-232 sur les anciennes) fait l’intermédiaire pour que le branchement se fasse en USB (mais sur le PC la carte apparaît bien comme un port série). C’est par ce biais que s’effectue la programmation, et éventuellement le dialogue avec la carte. On peut alors lui transmettre des commandes et elle peut nous envoyer des infos. On peut cependant exploiter ce port série pour communiquer avec d’autres clients, mais en liaison série il n’y a que deux dialogueurs (enfin en réalité on peut faire des dialogues à plusieurs, mais c’est assez complexe). Donc utiliser le port série pour communiquer avec une autre carte par exemple, c’est perdre la liaison avec le PC. Le second point c’est qu’il s’agit de série TTL à différencier du série RS-232 qu’on trouve sur les anciens PC maintenant (le fameux port COM). C’est presque la même chose mais les tensions n’ont rien à voir (0-5V pour le TTL et -12/+12V pour le RS-232) donc brancher du RS-232 sur une Arduino ça va la griller, et les polarités ne sont pas les mêmes (un 0 en TTL est un 1 en RS-232 et vice-versa). C’est pas forcement hyper important comme remarque mais c’est un point qui n’est pas forcement clair et le terme "série" est en générale utilisé à tord et à travers sans distinction.

A noter : dans toutes les fonctions que je viens d’évoquer, chacune n’est pas forcement disponible sur tous les pins du µC. Si je prends la UNO par exemple, j’ai 6 pins analogiques (qui sont aussi digitaux) : sur les autres pins de la carte je ne pourrais pas faire de mesures analogiques.

"Ouais mais tu nous emmerdes on sait toujours pas quoi choisir !"

Tout ce blabla pour qu’on arrive à mon conseil : prenez une UNO (et pas une UNO cms). Pourquoi :

- elle a toutes les fonctions nécessaires et largement assez dans le slip pour faire tous ce que vous voulez.

- vous pouvez changer l’atmega : si un truc doit griller (et bien évidemment un débutant est le meilleur candidat à ce que ça arrive) c’est l’Atmega. Si vous prenez une Léonardo et que vous flinguez l’Atmega32u4, vous avez intérêt à avoir un pote bien équippé pour qu’il vous dessoude ça et en remonte un neuf … Donc si ça vous arrive toute la carte est bonne pour la poubelle. Alors qu’une UNO classique l’Atmega328P est monté sur un support et qu’ont peut l’enlever à la main. Donc en cas de mauvaise manip, il n’y a que ça à changer.

- ça vous servira toujours : il vaut mieux racheter plus tard une MEGA ou autre, une UNO on s’en sert toujours pour faire des test, programmer des Atmega pour les monter sur ses propres montages en standalone (comprenez qu’on peut juste prendre l’Atmega et le monter sur ses propres circuit intégré, ce que j’ai fait ici par exemple mais avec un Atmega328 en version cms = monté en surface)

Fortement déconseillée : la DUE. Ce n’est pas la même architecture au niveau du µC (c’est un ARM), pour faire simple : si sur la programmation ça ressemble à la même chose que sur une Arduino "normale", derrière ça n’a rien à voir. Donc bon nombre de librairies sont incompatibles, et pas grand monde (même la team Arduino) ne bosse dessus donc pas grand espoir que ça change. En plus elle est en 3,3V : envoyer 5V sur une entrée et bye bye le ARM … Même si le 3,3v est voué à se démocratiser (on voit même apparaître de plus en plus de 1,8V !) ça le rend plus vulnérables aux erreurs de débutants. En plus elle est chère (+ de 35€) … Si vous tenez à faire du ARM tout en gardant la simplicité de la programmation Arduino, prenez la Stellaris Lauchpad de Texas instrument : 9,9$ et compatible avec Energia, un logiciel de programmation basé sur Arduino.

Arduino UNO (Atmega328P au format DIP) => c’est elle qu’il vous faut !

Arduino UNO CMS ==> Pas bbbiiieeennnn

Où acheter ?

Alors je suis un grand acheteur sur ebay et dx.com. J’ai acheté énormément de matériel en provenance de Chine sur ces deux plateformes, jamais déçu. Alors oui je sais c’est pas cool pour les petits français. Mais bon regardez sous tous les appareils électroniques chez vous et ça sera marqué made in China …

Je vous recommande plutôt DX car sur ebay, on trouve un peu plus de choses "exotiques". Car ce que vous achèterez si vous commandez en Chine, ce sont bien évidemment des clones (pas des copies puisque Arduino est OpenSource, comprenez que rien n’es breveté donc chacun peut dupliquer des cartes Arduino et les vendre) et les fabricants sont multiples et peuvent essayer de grappiller sur les composants : un régulateur moins costaud, un convertisseur USB-Serie moins performant … Et sur Ebay, on peut trouver plein de vendeurs différents avec pas forcement un bon suivi. Sur DX, il y a des commentaires sur tous les articles et ils n’ont pas 10 000 ref différentes pour la UNO. Ils ont bien plusieurs modèles de UNO, mais elle seront surement toutes fiables car ils ne s’amuseraient pas à en mettre des mauvaises car la note du produit serait fortement entachée. Après évidemment il faudra se montrer patient (2-3 semaines en moyenne).

Si vous êtes pressé ou que la Chine vous fait peur, bien sûr il y a des bonnes crèmerie en France : Semageek, Farnell, Snootlab … Et la vous aurait la vrai board officiel. Mais pour au moins 2 fois plus cher. A vous de voir !

Bonjour à tous,

Bon je suis pas encore sûr du nom (du tout même) mais je vais vous présenter un projet qui m’a vraiment pas mal occupé, même si on dirait pas forcement !

Principe

La philosophie de ce projet est très simple : je me suis rendu compte dans mon travail qu’on en revenait très souvent aux mêmes fondamentaux, et que même si idéalement il faudrait créer une ou plusieurs boards par projet, au final 90% du temps on fait toujours appel aux mêmes "briques" électroniques : un microcontrôleur en liaison avec des capteurs et des actionneurs.

J’ai donc entrepris de créer un ensemble de développement, capable de satisfaire un maximum de besoin et ayant une apparence professionnelle. Et c’est ce dernier point que j’ai particulièrement recherché car bien souvent dans le DIY on voit des projets avec des fils partout, des empilements de shield  … Bref pas propre !!

Pour ce faire, le cahier des charges s’est établi comme suit :

- l’ensemble doit pouvoir s’intégrer dans un boitier type DIN (j’en parle plus tard),

- une carte mère rassemblant µC + bouton + écran + buzzer + connecteur pour les autres board + protection/filtrage d’entrées analogiques + autre si la place,

- un prix abordable : et oui si c’est pour sortir l’ensemble à 150€ ça vaudra moins le coup …

- possibilité de brancher des shields pour étendre les fonctionnalités,

- de la place en façade et à l’arrière pour arranger les connecteurs et/ou les potars et/ou autre (led, boutons "cachés", photo résistance, récepteur IR …) comme on veux,

- open source et facile d’utilisation : je veux rester dans un environnement type Arduino.

Le choix du boitier

Je voulais un boitier de ce type :

C’est couramment sous cette forme qu’on trouve les contrôleurs du marché (temperature, vitesse moteur, humidité …). C’est facile à mettre en place et ça fait propre.

Alors j’en ai testé une palanquée … Car si ça peut paraître mineur, et bien ça ne l’est pas … Pourquoi ? Et bien essayez de prendre un boitier vide commercial et d’assembler différente carte dedans, tout en prenant en compte le fait que justement la configuration de vos carte à l’intérieur va changer, et qu’il faut également que vous preniez en compte le fait qu’il y a des connecteurs à installer …

Et puis surtout, trouver des boitiers de ce type, c’est pas une synécure …

Bref c’est un beau mic-mac et j’ai fini par en trouver un, et pas cher en plus (je ne l’avais pas mentionné mais évidemment le tarif est entré en ligne de compte) :

http://www.tme.eu/fr/details/op48x96l057/boitiers-de-panneaux/#

Vous pouvez y aller, c’est en Pologne mais je n’ai eu aucun problème et le matos est de qualité.

La carte mère

WP_20140128_002

Après moulte questionnement, j’en suis arriver à travailler avec un écran de Nokia5110 (PCD8544). Ce choix s’est fait par ses dimensions, sa résolution et son prix. Je ne voulais pas de 7-segment car trop gros, trop gourmand … Pas de caracterères LCD, pour quasiment les mêmes raisons. De plus le PCD8544 est bien documenté et plusieurs librairies existent.

Le micro est évidemment un Atmega328p :)

Pour l’instant on peut y souder 4 boutons. J’y ai ajouté une mémoire FM24C04B, pilotée en i2c. Pour résumer c’est une mémoire non volatile (comme l’EEPROM ou la flash) de 4kb qui peut supporter 10 puissance 12 écritures. Grosso-modo, même si vous écrivez sur le même segment toutes les ms, elle durera plus de 30 ans … Le rétroéclairage est piloté en PWM via un mosfet. Je n’ai pas intégrer de FT232RL surtout parce la place me manquait, et aussi parce qu’on en a pas forcement besoin en dehors de la programmation (qui peut se faire via le port ISP présent en plus).

Les entrées analogiques sont protégées et filtrées via un simple circuit RC + zener 5,1V.  Au passage il est possible de faire un diviseur de tension (pour interfacer avec une entrée 0-10V par exemple) en changeant la résistance de pull-down de 100k.

WP_20140128_003

WP_20140128_001

WP_20140307_001 WP_20140307_003 WP_20140307_004

 

WP_20140307_00'

Voici les fichiers eagle (pas forcement complet au niveau noms et valeurs des composants).

A noter également que je n’ai pas terminé les façades avant et arrière ce qui explique l’aspect

Carte alimentation

WP_20140128_004

Alors je vais être honnête, pour cette première version je visais un certain projet et je n’ai pas pu atteindre le degrés de "modularité pour tous" suffisant. Mais j’ai quand même créer une carte d’alimentation capable de prendre en charge suivant les composants soudés sur le PCB : 230VAC, 12VDC ou 36-15VAC/VDC. Elle comporte le FT232RL et un connecteur sur l’arrière pour envoyer i2c, 5V et 12V. Enfin il y a une entrée analogique vers A0.

L’avenir

Alors je compte pas m’arrêter la : je travaille déjà sur d’autres shields pour cette version 1.0 mais j’ai déjà la 2.0 dans la tête. Où j’en suis dans mon raisonnement :

- Microcontrôleur ARM M4 Tiva C TM4C123 le même que celui du launchpad Tiva C :

http://www.ti.com/ww/en/launchpad/launchpads-tivac.html

Pourquoi ? La puissance (je vous laisse regarder la fiche technique mais c’est une tuerie (80 mhz, 256k de flash 32 kb de RAM, 4x SPI, 4x i2c, port USB Host/Device/OTG …) et surtout, le point qui me fait faire vraiment ce choix, compatible avec l’IDE Energia, le Arduino-like pour les launchpad. Bon il ne prend pas tout en charge encore (notamment l’USB sous exploité), mais j’ai trouvé quelques "subterfuges" pour passer outre, j’en parlerai bientôt dans un autre article. Et TI est particulièrement actif dans le monde du DIY et collabore notamment beaucoup avec les developpeurs : les projets Energia par exemple vont pouvoir être importer dans Code Composer Studio v6. Avec les Stellaris et les Tiva C ils fournissent quantités de librairie, notamment en USB ce qui simplifie énormément le travail des codeurs. Le prix des launchpad est ridicule. Bref Texas Instrument semble une "bonne voie" dans laquelle s’engager :)

- ce choix me permet d’intégrer une horloge en temps réel puisque intégrée dans le Tiva C ;)

- possibilité d’utiliser d’autres écrans, d’autres configuration de clavier : besoin de plus de bouton ? un joystick ? d’un écran plus petit ? bref un petit coup de fer à souder et hop ;)

- ajout d’un ADC 24-bits, de la prise en charge Ethernet via ENC28j60 et d’un DAC : la nouvelle organisation que je prévois devrait me laisser plus d’espace, donc je vais pouvoir "gaver" l’ensemble pour accumuler un max de fonctionnalités, en tout cas il y aura la place sur le PCB.

Pour le reste comment je vois les choses : fourniture de cartes personnalisées : j’aimerais pouvoir proposer le concept à la vente, avec à la commande pouvoir décider de ce dont vous avez besoin. Pas besoin de l’ethernet ? Bin jle soude pas et le prix est déduit … Et vous recevez un "kit" qu’il ne reste plus qu’à programmer et qui fait pro. Et bien sûr le tout à un prix raisonnable évidemment ;)

Pour les intéressés il me reste pas mal de cartes (seeedstudio oblige) que je peux revendre ;)

Bonjour à tous,

Alors en ce moment je joue pas mal avec mon Stellaris Launchpad et je vous propose aujourd’hui une méthode pour se passer du programmateur. L’intérêt ? Et bien on peut imaginer des montages avec un ARM en standalone sans avoir besoin d’y intégrer un programmateur. Au passage, Texas Instrument propose directement des bootloaders pour flasher via USB, Série, SPI et même i2c. Sur les Tiva C série 129 il y en a même équipés de l’ethernet et on peut flasher par ce biais. La doc de TI sur le sujet 

Ce billet va traiter d’une autre méthode, même si elle utilise l’USB. Au hasard du net j’ai trouvé le boulot d’un type  et j’ai décidé de tester et d’adapter la méthode pour Energia.

Par ailleurs, n’ayant qu’un Stellaris Launchpad sous la main, mon tuto a été réalisé sur cette carte mais normalement ça marche aussi pour les Tiva C Launchpad, moyennant peut-être juste quelques adaptations. Enfin il se destine pour les mêmes raisons aux Windows-iens ;)

1ère étape

Dans le github de l’auteur, dossier prebuilt, récupérer boot_msc_usb.bin

Si vous ne l’avez pas, récupérez LMFlashProgrammer ici. C’est un outil de programmation très simple mais très efficace fourni par TI pour ses ARM. Au passage si vous jouez avec les différents types de bootloader, ce programme permet d’uploader un programme par n’importe quelle voie, même l’ethernet !

On va maintenant flasher le Launchpad avec le booloader. Branchez votre Launchpad par l’USB Debug et lancer  LMFlashProgrammer :

Dans "quick set", selectionnez "LM4F120 Launchpad" si vous avez un Stellaris LaunchPad et "TM4C123G Launchpad" si vous avez un Tiva C launchpad, puis dans l’onglet "Program" allez chercher le fichier boot_msc_usb.bin préalablement téléchargé. Si vous n’avez touché à rien d’autre alors tout est bien configuré.

Cliquer sur Program, et voila ;)

2ème étape

Vérification : brancher votre launchpad via USB Device cette fois et n’oubliez pas de basculer l’interrupteur de sélection d’alim sur Device. Presser le bouton SW2 et tout en le maintenant enfoncé appuyez puis relâchez le bouton reset. Normalement la led rouge se met à clignoter, signe que le bootloader s’est lancé et votre launchpad apparaît sur votre PC comme une clé USB.

3ème étape

"Ah bin t’es marrant toi je mets quoi dessus maintenant ?"

J’y viens j’y viens …

Il faut copier votre program au format .bin. En réalité, quelque soit votre environnement de développement (Energia, CCS, IAR …) votre programme est toujours transformé en fichier binaire, compréhensible par le µC (peut-être que vous avez déjà croisé des histoires de .bin et des .hex). C’est fruit d’une série d’étapes dont on a pas toujours connaissance. Exemple sur Arduino, on clique sur upload et hop "comme par magie" il se retrouve sur la carte. Vous vous doutez bien que c’est pas aussi simple que ça derrière le rideau …

Bref, après une modification mineure, on va pouvoir récupérer le .bin de votre programme codé sous Energia, pour le copier sur le Launchpad comme si on copiait une musique sur son lecteur mp3.

Donc aller dans votre dossier Energia\hardware\lm4f\cores\lm4f et ouvrer dans notepad ou notepad++ le fichier lm4fcpp.ld

Il faut modifier la partie concernée du fichier comme suit :

MEMORY
{
// flash (rx) : ORIGIN = 0×00000000, LENGTH = 0×00040000 // ligne d’origine
flash (rx) : ORIGIN = 0×00004000, LENGTH = 0x0003c000 // ligne pour upload via USB Storage mass
ram (rwx) : ORIGIN = 0×20000000, LENGTH = 0×00008000
}

Le bootloader étant installé sur la flash il faut "décaler" la plage de programmation allouée au programme, sans ça il ne démarrera jamais. Attention : si vous essayer de repasser par le port debug pour uploader votre programme via Energia, ça ne marchera plus, il faut remettre la ligne d’origine, c’est pour ça que je commente/décommente les lignes concernées dans ce fichier, au moins pour passer d’une méthode à l’autre j’ai juste à faire ça. Par ailleurs, écrire un programme avec la configuration d’origine va effacer le bootloader et il faudra recommencer depuis l’étape précédente.

Maintenant sur Energia, ouvrez votre programme, cliquer sur Vérifier pour lancer la programmation. Dans l’espace en bas apparaît une série de lignes. Regardez à la fin, il apparaît un certain fichier …

energia bin

Et oui c’est notre .bin ! Récupérer le et copier le sur votre Launchpad. Appuyer sur Reset et normalement il se lancera ;)

Par ailleurs je ne l’ai pas précisé mais ce .bin est tout à fait uploadable via LM Flash Programmer avec le Launchpad branché sur la prise USB Debug (ou par les autres voies citées en intro si vous avez mis un autre bootloader), à condition cette fois d’utiliser la config d’origine du fichier lm4fcpp.ld

Optimisations

Alors j’avoue que pour l’instant mes connaissances sur tout ce qui touche à la compilation, au linker, au makefile … est très limitée. Il y aurait surement une méthode plus simple pour spécifier à la compilation qu’on veut le .bin, donc modifier le fichier .ld automatiquement et mettre le .bin sur le bureau par exemple.

Sur CCS

Sur CCS la méthode est quasiment la même, il suffit de modifier le fichier nom_de_votre_projet.cmd  comme ceci :

//#define APP_BASE 0×00000000 // originale
#define APP_BASE 0×00004000
#define RAM_BASE 0×20000000

/* System memory map */

MEMORY
{
/* Application stored in and executes from internal flash */
//FLASH (RX) : origin = APP_BASE, length = 0×00040000  // originale
FLASH (RX) : origin = APP_BASE, length = 0x0003c000
/* Application uses internal RAM for data */
SRAM (RWX) : origin = 0×20000000, length = 0×00008000
}

/* Section allocation in memory */

SECTIONS
{
.intvecs: > APP_BASE
.text : > FLASH
.const : > FLASH
.cinit : > FLASH
.pinit : > FLASH
.init_array : > FLASH

.vtable : > RAM_BASE
.data : > SRAM
.bss : > SRAM
.sysmem : > SRAM
.stack : > SRAM
}

__STACK_TOP = __stack + 1024;

Faites ensuite clique droit sur votre projet > properties puis dans  la colonne de gauche "Build" puis onglet "Steps" et enfin au champs "Command" dans Post-Build steps  ajoutez ces lignes :

"${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin.bat" "${BuildArtifactFileName}" "${BuildArtifactFileBaseName}.bin" "${CG_TOOL_ROOT}/bin/armofd.exe" "${CG_TOOL_ROOT}/bin/armhex.exe" "${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin.exe"

Lancez le build et dans votre dossier de projet se trouvera le .bin ;)

Si vous avez des questions n’hésitez pas les commentaires sont la pour ça ;)

[Tutorial] Réparer sa TV Samsung

Publié: 15 janvier 2014 dans Non classé

Bonjour à tous amis bricoleurs :)

Alors un court article pour raconter une mésaventure qui n’a pas durer bien longtemps.

Alors il y a très longtemps mon frère m’avait parler de ce problème, et dès que ma TV s’est mise à déconner, ni une ni deux je n’ai pas hésiter. Le problème est assez connu, on trouve pas mal d’info sur le net, autant faut-il déjà en avoir eu vent.

Les symptômes : votre TV ne s’allume plus ou a du mal (mon cas) , l’écran scintille … Bref en réalité pour une même cause les conséquences peuvent prendre bien des formes.

La cause : des condensateurs au niveau de l’étage d’alimentation rendent l’âme. Et une alimentation qui pare en vrille peut avoir des répercutions sur n’importe lequel des sous-systèmes qu’elle alimente, d’où la variété de problèmes constatés.

Donc hop je démonte et bingo :

WP_20140113_002

WP_20140113_003

WP_20140113_010

On voit assez nettement que 3 condos on fait de la "gonflette", signe typique de leur décès. A la rubrique nécrologique on trouve donc  trois 820 µF 25V.

Quel condensateur prendre pour le remplacement ?

Alors tant qu’à faire on va pas refaire la même erreur que le fabricant : si ces condensateurs rendent l’âme c’est qu’ils ont été mal dimensionnés. Donc plutôt que des 25V j’ai mis des 35V et 40V (j’ai fait de la récup). La règle absolu dans tous les cas c’est de prendre un voltage au moins équivalent. Mettez en un plus faible et votre condensateur va très certainement exploser ! Après pour la capacité il faut prendre idéalement la même, perso je n’en avais pas donc j’ai mis des 470µF pour deux des trois (le troisième a eu droit au 820 µF) et ça marche très bien. Et dernier point, bien évidemment faîtes attention à la taille du condensateur qu’elle soit à la fois compatible par rapport aux autres composants, et également qu’il ne soit pas trop grand auquel cas vous ne pourriez  plus remonter le panneau arrière de votre TV …

La réparation est donc enfantine : on démonte le panneau derrière la TV, on débranche les quelques nappes, on dévisse la fameuse carte, on joue du fer à souder pour changer les condos et on reprend les étapes en sens inverse.

Note importante : faîtes bien évidemment attention aux polarités des condensateurs ! Inversion = explosion directe

Une fois réparé :

WP_20140114_011

Pourquoi foutre des condensateurs sous/mal dimensionnés ?

Et oué on est quand en droit de se dire qu’ils abusent chez Samsung, c’est quand même leur boulot ! Pour moi trois explications possibles et cumulables :

- Obsolescence programmée : c’est à la mode, fini les produits qui durent 20 ans. Société de consommation quand tu nous tiens … Et insérer volontairement des "points faibles" dans les appareils qui lâchent quelques temps après la garantie c’est devenu malheureusement monnaie courante …

- Limiter les coûts : plus la capacité ou le voltage est élevé, plus le condensateur coûte cher. Vous allez me dire "pour 20 centimes ?! Sérieusement ??" Et oui, 20 centimes multiplié par des centaines de milliers de produits (en plus que ça permet de limiter le nombre de composants utilisés et donc d’en commander plus à la fois et donc de réduire encore plus le prix à l’unité) ça commence à faire des sommes non négligeables (faut bien payer les amendes à Apple :p )

- Les spécifications des fabricants de condensateur se réduisent de plus en plus. En effet alors qu’avant un fabricant donnait son condo à 25V, il pouvait en réalité en supporter plus. Maintenant on est vraiment proche des 25V …

Bref vous le saurez si ça vous arrive : inutile de jeter votre TV à la benne !

Quelques liens utiles :

http://www.conseil-creation.com/electronique/tv_samsung_panne_alimentation.php

http://tendactu.fr/votre-tv-samsung-en-panne-normal-cetait-prevu/867/

http://forum.ubuntu-fr.org/viewtopic.php?id=736861

Bonjour à tous,

Pour commencer : non je ne suis pas mort mais très occupé :)

Je bosse sur pas mal de sujet, y’en a un qui devrait vous intéresser et que je vous présenterai à la fin du mois si tout va bien (en attente des PCB de Chine). Pour l’instant suspens :p

Alors qu’est-ce qui nous amène aujourd’hui : n’avait vous jamais rêvé d’une lumière qui s’allume et s’éteint en tapant dans vos mains ? Et bien ce doux rêve est à portée de bras :)

Matériel

- Une arduino (ici j’ai pris une pro mini) + 1 bouton

WP_20140114_001

- Au besoin comme moi, un convertisseur USB <-> Serie :

WP_20140114_005

- Un module chinois de détection sonore :

WP_20140114_004

- Un module  relais chinois :

WP_20140114_003

- Des bras et un cerveau.

Bon vous l’aurez noter peut-être, mis à part les bras et le cerveau tout est en provenance direct de Hongkong, histoire de tester ces modules au passage ;)

Montage

Rien de complexe du tout. Pour le module sonore : deux pins pour l’alimentation, et un pin OUT à brancher sur une entrée digitale de l’Arduino. Ce pin est HIGH lorsqu’il n’y a aucun son et passe à LOW lorsqu’il en détecte un, le seuil se réglant avec le petit potentiomètre dessus. Une LED permet de visualiser la détection.

Pour le module relais rien de fantastique non plus : deux fils pour l’alim et un pour la commande. Ici attention, suivant les modules, le relais ne s’active pas sur le même état. Sur le mien justement HIGH = relais ouvert et LOW = relais fermé

Le bouton la c’est du classico-clasique : une borne au GND, l’autre à un pin digital configuré en INPUT_PULLUP.

Enfin si comme moi vous avez une pro mini, il vous faut raccorder le convertisseur USB<->Série : RX à TX, TX à RX, DTR à DTR, GND à GND et au besoin 5V à VCC.

Programmation

La ça se corse … En fait le codage ne fait pas appel à des notions complexes, mais ça demande une certaine gymnastique mentale pour transcrire le problème réel en code. Le principe de base et le suivant :

Quand je tape dans mes mains, un signal est détecté par l’Arduino. millis() est alors mis en mémoire (si vous êtes déjà perdu cet article devrait vous aider), c’est le point de départ.  Lorsque je retape, l’Arduino détecte le signal et fait la différence entre millis() et le point de départ précédemment enregistré. Cet écart est mis en mémoire dans un tableau. On remet à zéro le point de départ et on recommence. On se retrouve ainsi avec un tableau rempli d’écart entre deux frappes : ça y est, on a sauvegarder notre rythme !

Comme un schéma vaut parfois mieux qu’un long discours :

WP_20140114_010

Alors ça c’est pour le principe de base. Maintenant on veut également ne pas avoir a enregistrer la rythmique à chaque démarrage, donc on va faire appel à l’EEPROM. Pour ceux qui l’ignore, l’EEPROM est une mémoire morte. On en retrouve dans la quasi totalité des microcontrôleurs. Alors qu’est-ce qu’elle a de spécial cette mémoire ? Et bien c’est assez simple : on va pouvoir y stocker des variables et pour toujours (en tout cas, tant qu’on ne réécrit pas dessus) et ce, en passant par un programme ! Typiquement, cette mémoire sert à stocker des variables de configuration amenées à être modifiées durant la vie du système, par exemple le contraste d’un écran : on va pas s’amuser à chaque démarrage à aller dans les menus pour remettre un contraste qui nous semble correct. On stocke en mémoire ce contraste et au redémarrage on recharge cette variable. Dans le montage qui nous intéresse ici, on va donc se servir de cette mémoire pour enregistrer notre rythmique. Attention cependant, le point faible de cette mémoire est qu’elle a un nombre d’écriture limité : 100 000 écritures d’après la datasheet. En réalité c’est une durée de vie minimum, mais si ça se trouve elle peut durer 10 fois plus. En tout cas ce qu’il faut retenir c’est que ce n’est pas une mémoire où il faut écrire régulièrement, sinon on la flingue assez vite. A noter qu’en revanche il n’y a aucune limite en lecture.

Il y aura donc deux modes de fonctionnement : un mode écoute (le fonctionnement "normal" quoi) et un mode enregistrement, qui sera déclenché par l’appui sur le bouton.

Alors on va commencer par l’enregistrement car ça me semble plus facile pour comprendre l’écoute ensuite.

Brute de fonderie, le code :

void Enregistrement(){

Blink(); // fonction qui fait clignoter la LED signifiant le passage en mode enregistrement
 Depart=millis(); // la sortie de Blink() se fait sur la détection du premier clap, donc on prend le point de départ

Stab();

int j=0;

while(millis()-Depart<TIMEOUT && i<50){ // on boucle tant que le timeout n'est pas dépassé on qu'on enregistre pas plus que ce qu'on peut

if(digitalRead(INMIC)==LOW){ // son détecté

Sequence[j++]=millis()-Depart; // on enregistre le temps écoulé
 Depart=millis(); // remise à zéro du point de départ

Stab();

}

}

NombreDeClap=j+1;

SauvegardeEEPROM();

Play();

Mode=ECOUTE;

}

Alors avant toute chose, vous noterez les appels à certaines fonctions. Ne vous inquiétez pas on va les voir. Donc on commence par la fonction Blink() :

void Blink() {

Depart=millis();

byte State_LED=HIGH;

while(digitalRead(INMIC)==HIGH) {

digitalWrite(LED,State_LED);

if(millis()>=(Depart+500)) {
 Depart=millis();
 State_LED = !State_LED;
 }

}

digitalWrite(LED,LOW);

}

Son principe est simple : faire clignoter la LED mais de manière non bloquante : dès qu’il y a un signal sonore, hop on sort. Si vous êtes perdu je vous renvoi vers le même article.

Ensuite on tombe sur Stab(). Vous allez me dire que faire une fonction pour 2 lignes c’est pas forcement utile. Oui mais on y fait appel plusieurs fois dans le programme, donc bon …

void Stab(){

while(digitalRead(INMIC)==LOW); // tant que le détecteur n'est pas revenu à l'état normal on boucle
 delay(REBOND); // anti-rebond

}

Sa fonction est simple : un signal sonore n’est jamais un pic parfait ce qui fait que le signal dure plusieurs millisecondes, donc si on ne veut pas avoir de problème, il faut attendre que le signal "retombe". Pour ce faire on se mets dans une boucle while() tant que le signal est LOW (=son détecté) et en plus derrière on place en plus un delay() par sécurité (on attend que les choses "se tassent" ;) ). REBOND est défini en en-tête, on le verra plus tard.

Donc la ça y est le top départ est donné : Depart = millis() ==> mis en mémoire du "Top depart" du chrono.

On rentre alors dans une boucle while() dont on ne sortira qu’à deux conditions : si on dépasse un certain temps (timeout) ou si on arrive à la limite de notre tableau Sequence[] qui permet de sauvegarder notre rythmique.

Alors dès qu’un signal est détecté, on mesure le temps écoulé par rapport au premier "clap", on remet à zéro Depart, on attend le retour à la normale du capteur (Stab()), et on repart pour un tour. Dès qu’on sort de la boucle (trop de clap ou bien on a arrêté de taper et on a dépassé le timeout) on lance la sauvegarde en EEPROM :

void SauvegardeEEPROM(){

EEPROM.write(0,NombreDeClap); // adresse zéro on stocke le nombre de clap

int y=1;

for(i=0;i<NombreDeClap-1;i++) {

EEPROM.writeLong(y+=4,Sequence[i]); // long = 4 bytes

}

}

Alors ici si vous n’avez jamais jouer avec l’EEPROM forcément ça risque de vous parlez un peu chinois (en même temps vu d’où viennent les modules xD)

L’EEPROM est diviser en byte, soit 8 bits. Chaque byte porte une adresse. Pour un atmega 328 qui a 1024byte de mémoire, les adresses vont donc de 0 à 1023. Mais comme ce sont des bytes, on ne peut stocker de base que des nombre entre 0 et 255. Donc pour stocker un "long" qui fait 4 bytes, il faudra donc utiliser les adresses en 4 par 4. Alors écrire une routine pour le faire n’est pas compliqué, mais il y a une librairie qui le fait directement, elle s’appelle EEPROMex.h

Donc je m’en sers ici mais il faut quand même tenir compte du fait qu’elle ne prend pas en compte le type de variable écrit par rapport à l’adresse (je sais c’est pas clair). Par exemple : si j’utilise EEPROM.writeLong(0,MaVariable1) puis  EEPROM.writeLong(1,MaVariable2), je vais écraser 3 blocs sur 4 de MaVariable1 ! Il faut écrire   EEPROM.writeLong(4,MaVariable2). Ainsi aux byte d’adresse 0, 1,2 et 3 j’aurai stocké  MaVariable1 et à ceux dont l’adresse est 4,5,6 et 7 MaVariable2.

Pour en revenir à nos moutons, il me suffit donc de faire une simple boucle for pour recopier les différents index de Sequence[] dans l’EEPROM. Sequence[0] à l’adresse 1, Sequence[1] à l’adresse 5, Sequence[2] à l’adresse 9 etc …

Au chargement du programme on fera donc simplement la manip inverse :

void ChargementEEPROM(){

if(EEPROM.read(0)<=50){

NombreDeClap=EEPROM.read(0);

int w=1;

for(int e=0;e<NombreDeClap-1;e++) {
 Sequence[e]=EEPROM.readLong(w+=4);
 }

}
 else {
 Mode=ENREGISTREMENT; // si nombre de clap invalide on passe en mode enregistrement
 }
 }

Une fois la sauvegarde effectuée on passe à Play() qui va jouer l’enregistrement qu’on vient de record, et ce, sur la LED 13 de la carte :

void Play() {

Pulse();

for(int u=0;u<NombreDeClap-1;u++){

delay(Sequence[u]);

Pulse();

}

Serial.println("");

}

void Pulse(){

digitalWrite(LED,HIGH);
 delay(50);
 digitalWrite(LED,LOW);

}

Donc la je pense que si vous avez compris le principe de base, vous comprendrez ce passage de vous même.

Maintenant passons à la partie un peu plus velue (et oui ça c’était la partie facile, en tout cas pour moi je trouve ça bien plus facile à appréhender que l’écoute) :

void Ecoute(){

if(digitalRead(INMIC)==LOW){ // son détecté ?

Time = millis()-Depart; // Temps écoulé depuis le précédent clap
 Ecart = float(Sequence[i])-float(Time); // Ecart entre le temps "attendu" et celui réalisé

if(abs(Ecart) <=TIME_ERROR){ // si l'écart constaté est dans l'erreur tolérée

i++; // le compteur de "bonne réponse" est incrémenté

Depart=millis(); // RAZ du chrono

if(i>=NombreDeClap-1){ // si le nombre de bonne réponse est atteint

State= !State; // si le relais était allumé on l'éteint et vice-versa
 digitalWrite(RELAY,State);
 New(); // on repart à zéro

}

} else { // si mauvaise réponse

New(); // on repart à zéro

}

Stab();

}
 }

void New(){

Depart=millis();
 i=0;

}

La je pense avoir commenté au maximum le code, si jamais vous ne pigez pas y’a les commentaires ;)

Bon si maintenant on rassemble tout, qu’on rajoute la prise en charge de la liaison série, le setup() et tout, ça nous donne :

#include <EEPROMex.h>
 #include <EEPROMVar.h>

//configuration des pins
 #define INMIC 2 // entrée détecteur de son
 #define RELAY 5
 #define BOUTON 10
 #define LED 13

// constantes pour rendre le code plus lisible
 #define ECOUTE 4
 #define ENREGISTREMENT 5

//constantes de réglage
 #define TIMEOUT 3000
 #define TIME_ERROR 200
 #define REBOND 100

unsigned long Sequence[50]={0}; // sers à stocker l'air
 unsigned long Depart,Time;
 float Ecart;
 int NombreDeClap,i;
 byte Mode,State; // Mode permet de définir le comportement et State est la variable de commande du relais
 char buffer [100]; // Tampon pour les sprintf
 void setup(){

Serial.begin(9600);

// Configuration des variables

Mode=ECOUTE; // par défaut on écoute
 State=HIGH; // sur mon module relais, à LOW le relais est fermé et inversement
 i=0;

// Configuration des pins

pinMode(BOUTON,INPUT_PULLUP);
 pinMode(INMIC,INPUT);
 pinMode(RELAY,OUTPUT);

digitalWrite(RELAY,State);

ChargementEEPROM(); // Chargement de Sequence[]

Play(); // la séquence est jouée sur la LED 13
 }

void loop() {

// si appui bouton, on passe en mode enregistrement
 if(digitalRead(BOUTON)==LOW) {
 Mode=ENREGISTREMENT;
 while(digitalRead(BOUTON)==LOW); // tant que le bouton est appuyé on boucle
 delay(50); //anti-rebond
 }

switch(Mode) {

case ECOUTE:

Ecoute();

break;

case ENREGISTREMENT :

Enregistrement();

break;

}

}

void Ecoute(){

if(digitalRead(INMIC)==LOW){

Time = millis()-Depart; // Temps écoulé depuis le précédent clap
 Ecart = float(Sequence[i])-float(Time); // Ecart entre le temps "attendu" et celui réalisé

if(abs(Ecart) <=TIME_ERROR){ // si l'écart constaté est dans l'erreur tolérée

Serial.println("OK");

i++; // le compteur de "bonne réponse" est incrémenté

Depart=millis(); // RAZ du chrono
 Serial.println(i);

if(i>=NombreDeClap-1){ // si le nombre de bonne réponse est atteint

Serial.println("Sequence validee");
 State= !State; // si le relais était allumé on l'éteint et vice-versa
 digitalWrite(RELAY,State);
 New(); // on repart à zéro

}

} else { // si mauvaise réponse

sprintf (buffer, "Realise = %d ms Attendu = %d ms Ecart = %d ms ", Time, Sequence[i], Ecart);
 Serial.println(buffer);
 Serial.println(Ecart<0?"Pas OK Trop lent":"Pas OK Trop rapide"); // <=> if(Ecart<O) Serial.println("Trop lent"); else Serial.println("Trop rapide");

New(); // on repart à zéro

}

Stab();

}
 }

void Enregistrement(){

Serial.println("Enregistrement");

Blink(); // fonction qui fait clignoter la LED signifiant le passage en mode enregistrement
 Depart=millis(); // la sortie de Blink() se fait sur la détection du premier clap, donc on prend le point de départ

Serial.println("Debut enregistrement");

Stab();
 int j=0;

while(millis()-Depart<TIMEOUT && i<50){ // on boucle tant que le timeout n'est pas dépassé on qu'on enregistre pas plus que ce qu'on peut

if(digitalRead(INMIC)==LOW){ // son détecté

Sequence[j++]=millis()-Depart; // on enregistre le temps écoulé
 Depart=millis(); // remise à zéro du point de départ

Stab();

}

}

Serial.println("Fin enregistrement");

NombreDeClap=j+1;

SauvegardeEEPROM();
 Play();

Mode=ECOUTE;

}

void New(){

Serial.println("New");
 Depart=millis();
 i=0;

}

void ChargementEEPROM(){

if(EEPROM.read(0)<=50){

NombreDeClap=EEPROM.read(0);

Serial.print(NombreDeClap);
 Serial.println(" claps ");

int w=1;

for(int e=0;e<NombreDeClap-1;e++) {
 Sequence[e]=EEPROM.readLong(w+=4);
 sprintf(buffer,"Adresse %d Sequence[%d] = %d",w-4,e,Sequence[e]);
 Serial.println(buffer);
 }

}
 else {
 Serial.println("Le chargement a echoue");
 Mode=ENREGISTREMENT;
 }
 }

void SauvegardeEEPROM(){

Serial.println("Sauvegarde EEPROM");

EEPROM.write(0,NombreDeClap);

Serial.print(NombreDeClap);
 Serial.println(" claps ");

int y=1;

for(i=0;i<NombreDeClap-1;i++) {

EEPROM.writeLong(y+=4,Sequence[i]);
 sprintf(buffer,"Adresse %d Sequence[%d] = %d",y-4,i,Sequence[i]);
 Serial.println(buffer);

}

}

void Stab(){

while(digitalRead(INMIC)==LOW); // tant que le détecteur n'est pas revenu à l'état normal on boucle
 delay(REBOND); // anti-rebond

}

void Play() {

Pulse();

for(int u=0;u<NombreDeClap-1;u++){

delay(Sequence[u]);

Pulse();

Serial.print(Sequence[u]);
 Serial.print(" ");
 }

Serial.println("");

}

void Pulse(){

digitalWrite(LED,HIGH);
 delay(50);
 digitalWrite(LED,LOW);

}

void Blink() {

Depart=millis();

byte State_LED=HIGH;

while(digitalRead(INMIC)==HIGH) {

digitalWrite(LED,State_LED);

if(millis()>=(Depart+500)) {
 Depart=millis();
 State_LED = !State_LED;
 }

}

digitalWrite(LED,LOW);

}

Une fois écrit c’est sûr que ça parait facile (pour ceux qui trouve ça facile). Mais faîtes comme si vous n’aviez rien vu et partez d’une page blanche ;)

En vidéo :

Application sorti du labo

Si maintenant on installait ça pour commander la lumière du salon :)

Bilan : on se rend compte que le module micro est très limite. Ça marche très bien à 50 cm et au-delà ça devient assez bof. Mais bon en même temps pour 2€ fallait pas s’attendre à grand chose. Mais je n’ai pas encore dit mon dernier mot ;)

Amelioration

La clairement je ne vois qu’une seule amélioration : la partie détection sonore dont les faiblesses deviennent assez gênantes une fois qu’on applique le montage en situation réelle. Concrètement ça consisterait en quoi ? D’une part mise en place d’un filtre (passe bande surement) pour affiner la détection et limiter les perturbations, ainsi il n’y a que le "type" de son qui nous intéresse qui déclencherait un signal. Je pense que déjà la on y gagnerait beaucoup car derrière on peut mettre en place une amplification plus importante et plus fine.

Autre piste qui ne changerai pas grand chose : utiliser un capteur piezzo pour par exemple taper sur n’importe quelle partie du sol ou du mur pour allumer la lumière. La aussi un petit circuit filtre+amplificateur et ça pourrait donner quelque chose du tonnerre ;)

Bonjour à tous,

Aujourd’hui je vous propose un petit test/tutorial sur la soudure CMS à l’air chaud.

CMS, késako ? Pourquoi faire ?

CMS = Composant Monté en Surface (SMD dans la langue de Shakespeare)

Le CMS vous savez ce sont tout ces petits composants montés sans trou sur les circuits imprimés. C’est un format très utilisé dans les produits commerciaux pour plusieurs raisons :

- moins cher : regarder par cous même sur des crèmerie comme farnell, y’a pas photo …

- plus compact. Démonstration :

WP_20130924_002 (2)

A gauche des MSP430G2553 et à droite des Atmega 328P. Au bas mot 4x plus petit et 4 x moins épais.

- pas de trou à faire : moins de main d’oeuvre, encore des économies.

- montage à la chaîne robotisé possible, très difficile en traversant.

- On soude tout d’un coup.

- possibilité de faire du double face : doublement plus compact ! On peux poser des composants des deux côtés d’un PCB.

Maintenant qu’en est-il pour nous DIYers : et bien si vous relisez cette liste, vous trouverez plusieurs arguments intéressants, surtout si vous avez déjà monté des PCB un poil complexes. En plus, pas mal de composants n’existent tout simplement pas en traversant, obligation d’utiliser un adaptateur.

Alors pourquoi on en voit pas souvent ? Je pense qu’il y a surtout deux gros points qui font barrage :

- d’une part les gens en on peur : c’est tout petit, on en voit pas souvent, il doit falloir un matos hyper complexe et cher …

- c’est beaucoup plus difficile de bidouiller après coup. On va plutôt réserver ce type de placement pour des prototypes dont on est quasiment sûr de la fiabilité.

Et pourtant vous allez voir souder du CMS c’est pas si compliqué, et une fois qu’on y a gouté c’est comme beaucoup de choses, c’est dur de s’en passer xD

Le matos nécessaire et le principe

- Une source de chaleur (je développerai ensuite).

- Un PCB + les composants (sans déconner ??!).

- De la pâte à souder.

- Deux mains, un cerveau.

Le principe est très simple : on place un peu de pâte à souder sur les pads, on pose ses composants dessus, on chauffe et la pâte se transforme en étain. Au refroidissement tout est prêt, il ne reste plus qu’à faire les éventuels composants traversants.

Alors cette source de chaleur peut prendre plusieurs formes : four principalement, ou avec une buse à air chaud comme je vais vous le montrer. Les fours permettent du travail de gros alors que la buse à air chaud convient bien pour du "à la main".

La station

WP_20130809_008

Alors c’est une station achetée sur ebay pour 80€ environ. Elle fait buse à air chaud et fer à souder. Il y a deux boutons pour allumer ou éteindre la buse ou le fer et il y a 3 potard de réglage : un pour la température du fer à souder, un pour celle de l’air chaud et le troisième pour le débit d’air. Il y a deux afficheurs 7-segments qui affiche les températures de consigne du fer et de l’air. Deux led indiquent si on est à la bonne température ou pas. Donc on ne peut pas savoir quelle est la température, mais si la led s’éteint c’est que la consigne est atteinte.

Au niveau de l’usage rien à redire : le fer comme la buse chauffe très vite, on peut facilement changer la pane (je n’ai pas cherché les disponibilité pour une de rechange mais ça doit se trouver), et la buse se coupe quand on la repose sur son support. Le ventilateur tourne un certain temps sans chauffage pour éviter une surchauffe à cause de l’élan thermique, donc pensez à ne pas débrancher tant que le ventilo tourne ;)

Alors vous pouvez trouver sur ebay plusieurs modèles, il se ressemblent beaucoup au niveau de la buse à air chaud donc je pense qu’elles ont à peu prêt toute le même fournisseur. Ce qui n’est pas plus mal si un jour elle tombe en panne ;)

Au niveau des accessoires sont fournies plusieurs buses, pour l’instant j’ai pas exploré plus que ça, j’ai mis la plus fine et ça fonctionne très bien donc bon …

Bref je ne regrette absolument pas mon achat, rien à redire pour le moment.

Choix de la pâte

Et oui on a pas parler de ça ! Alors grosso modo on trouve 3 famille de pâte : avec plomb (Sn/Pb) , sans plomb, bismuth/étain. Comme pour la soudure en fil, avec plomb c’est beaucoup mieux que sans … Surtout qu’ici la sans plomb fond bien plus haut que  celle avec. Et la Bi/Sn elle a ma préférence car fond à 140°C (230°C pour la Sn/Pb). En effet à 230°C l’epoxy et le vernis apprécient moyen …

Ou en trouver ?

En effet j’ai lu à plusieurs endroit qu’il était difficile de s’en procurer. Y’en a qui ne doivent pas connaitre Farnell … Attention les pâtes à souder n’ont pas une durée vie très longue (quelques moi). Pour ma part j’opte pour celle la : Sn/Bi, pas cher, fourni avec les embouts de seringue, petit volume donc évite le gâchis.

Souder le CMS

Allez on y va, vous allez voir, mis à part la mise en place des composants, ça va très vite ! A ce propos : vous n’avez même pas à mettre parfaitement les composants, comme toute les pattes de votre composant baigne dans de l’étain liquide, la capillarité place le composant tout seul (sisi !). Alors ça marche pas tout le temps à 100%, vous pouvez avoir à faire une petite reprise.

Le PCB :

pcb

On met un peu de pâte de partout :

pate

A noter que si vous disposer d’une découpeuse laser, vous pouvez faire des masques en vinyl, il n’y a alors qu’à étaler la pâte. Exemple :

On place les composants à la pince brucelles :

Et on chauffe !

et voila le résultat !

finie

Alors pas mal hein ;)

Petite astuce en passant fournie par BossOfScandalz  du forum Arduino pour les réparations : utiliser des blindages CEM pour protéger ce qu’on ne veut pas dessouder. Les blindage ressemble à ça.

A bientôt !

[Tutorial] Jouer avec les ATtiny

Publié: 4 octobre 2013 dans Non classé

Salut à tous amis DIYers :)

Alors je sais j’invente pas le fil à couper l’eau chaude mais comme j’ai dû expliquer la marche à suivre à un ami pour programmer un ATtiny depuis le début, je me suis dit pourquoi pas en faire profiter les autres !

A noter que j’utilise ici un programmateur type USBTinyISP (environ 6€ sur ebay) qui permet de programmer les bootloaders de toutes les cartes Arduino ou de les programmer sans bootloader (c’est le cas des Attiny ici). Pour ceux qui ne le savent pas, le bootloader c’est le ptit bout de programme qui fait que sur Arduino on programme directement par liaison USB (en réalité sur les UNO par exemple il y a un chip qui fait la conversion USB<->Série, les cartes Leonardo elles n’en ont pas mais il faut quand même un bootloader). Donc si on prend un Atmega328p par exemple sans bootloader (chez farnell.com par exemple), ça ne marchera pas directement si on le mets sur une platine UNO, il faut préalablement programmer le fameux bootloader.

Il existe un autre type de programmateur low-cost qui fonctionne très aussi, les USBasp, 3€ sur ebay …

Aller c’est parti :

1) Installation du programmateur

Téléchargement du pilote W7 et XP 32-bits ici :

http://learn.adafruit.com/system/assets/assets/000/010/319/original/usbtinyisp_w32_driver_v1.12.zip

Installez-le et ensuite brancher le programmateur qui doit être reconnu. Si ça fonctionne bien débranchez-le.

2) Installation du logiciel de programmation Arduino

Téléchargez-le ici :

http://arduino.googlecode.com/files/arduino-1.0.5-windows.exe

Installez-le et notez bien dans quel dossier vous l’installez.

3) Patch logiciel Arduino

Il faut ajouter des fichiers pour que les attiny soient reconnus.

Go sur ce site et cliquez sur "Download ZIP" à droite de la page : https://github.com/damellis/attiny/

Extraire le dossier attiny dans  le répertoire  xxx/Arduino 1.05/hardware    xxx étant l’endroit où vous avez installé le logiciel Arduino lors de la précédente étape.

4) Programmation

On y arrive enfin !

Allez dans Outils>Programmateur et sélectionnez USBtinyISP. Toujours dans « Outils » allez dans "type de carte" et sélectionnez l’Attiny qui vous correspond, par exemple "ATtiny44(internal 1Mhz clock)".

Branchez le programmateur à la carte puis au PC. Dans "Outils" cliquez sur "Graver la séquence d’initialisation" ("burn bootloader" pour les anglophone).

Si tout va bien, une led rouge s’allume sur le programmateur et s’éteint une fois la tâche accomplie (très bref). A noter que ici il n’y a pas de programmation de bootloader à proprement parler, mais qu’il y a programmation des fuses qui sont des registres mémoire importants. On y définit entre autre la fréquence de fonctionnement.

Charger maintenant votre programme ou un programme exemple.

Il ne vous reste plus qu’à cliquer en haut sur le bouton du programme Arduino avec une flèche tournée vers la droite. La led rouge s’allume à nouveau puis s’éteint quelques instants plus tard et normalement en bas du logiciel Arduino est écrit « Téléversement terminé».

D’autres infos ici.

A bientôt :)