Aller au contenu

electroremy

Membres
  • Compteur de contenus

    1 534
  • Inscrit(e) le

  • Dernière visite

  • Jours remportés

    20

Dernière journée remportée par electroremy le 7 Janvier

electroremy a le contenu le plus aimé!

1 abonné

Contact

Information

  • Genre
    Masculin
  • Lieu
    Besançon
  • Imprimantes
    PRUSA ORIGINAL I3 MK2S
    ANYCUBIC PHOTON S

Visiteurs récents du profil

3 695 visualisations du profil

Récompenses de electroremy

Veteran

Veteran (13/14)

  • Posting Machine Rare
  • Very Popular Rare
  • Dedicated
  • Reacting Well Rare
  • First Post

Badges récents

953

Réputation sur la communauté

3

Sujets solutionnés !

  1. Voici deux autres photos (cliquez dessus pour les voir en taille réelle) : J'ai aussi fait le test avec une pièce plus "massive", la réduction de la durée de la trempe (de 30 secondes à 15 secondes) a aussi nettement diminué les bulles (je ne peux pas encore mettre la photo car cela dépasse la taille maxi)
  2. S'il n'y avait que des radiateurs la vanne pourrait être laissée à une position fixe. La valeur exacte de la température de l'eau envoyée dans les radiateurs n'est pas très critique, ce sont les robinets thermostatiques des radiateurs qui vont réguler le chauffage dans la pièce. En revanche le pilotage de la vanne est utile voire nécessaire pour réguler précisément la température du plancher chauffant. Il faudrait remettre un moteur ; s'il a du mal à tenir sur la vanne, pourquoi ne pas faire une fixation complémentaire avec l'imprimante 3D ou autre moyen ?
  3. C'était donc une vanne 3 voies motorisée à la base Question à la con : quel est le rôle de cette vanne ? La commutation chauffage/production eau chaude et/ou la régulation ? Du coup il faut remettre la motorisation, ou sinon se contenter de laisser la vanne dans une position fixer et le chauffage sera régulé avec le thermostat et/ou des robinets thermostatiques
  4. On en a parlé il n'y a pas longtemps sur le forum Pour résumer, il faut installer un plug-in dans le slicer pour imprimer avec des "brick layers", qui permettent d'avoir des pièces plus solides et étanches Avec cette technique, en modélisant une manette assez "épaisse", et avec un peu de chance, tu pourrais imprimer une manette en 3D assez solide pour l'application sans devoir utiliser un filament technique cher et/ou compliqué à imprimer.
  5. Il y a une chose à tester : les "brick layers" - ou sinon augmenter le flow
  6. C'est le soucis avec ce genre de pièce, la vanne n'étant pas manoeuvrée souvent, au début de chaque manipulation les efforts seront importants. Si la pièce d'origine qui était moulée par injection s'est brisée, ce sera difficile d'avoir un meilleur résultat en impression 3D Il peut être possible de renforcer la pièce en y insérant une ou plusieurs tiges ou vis en métal, mais vu la forme de la pièce il restera des points faibles... Une solution serait de faire cette pièce en deux parties : - pour la partie "dentée", qui actionne la vanne : un morceau de tube en acier dans lequel on fait des encoches avec une lime - une manette imprimée en 3D qui sera fixée sur l'autre extrimité du tube avec une meilleure prise, et qui acceuillera la vis permettant de maintenir la pièce sur la vanne Pour fixer la manette sur le tube : - il faudrait modéliser deux ou trois trous diamètre 2,5mm, perpendiculaires à l'axe de rotation de la vanne dans la manette imprimée en 3D - on place le tube dans la manette - on perce le tube avec un foret de 2,5mm en utilisant les trous dans la pièce imprimée en 3D comme guide de perçage - ensuite on visse dans la manette des petites vis à bois diamètre 4mm, le filetage de la vis à bois va tarauder la manette, la pointe des vis à bois va entrer dans les trous percés dans le tube en acier, ce qui assurera la fixation
  7. Essayes de faire cette modification du moyeu (supprimer la partie qui dépasse) ; tu peux aussi augmenter la largeur des rayons vers le bas pour qu'ils soient en contact avec le bed. Ensuite, demande à Prusa Slicer de trancher la pièce sans support. Enfin, regardes si les surplombs ne sont pas trop prononcés, 45° ça peut le faire A bientôt
  8. Je n'ai jamais utilisé de supports... J'ai imprimé que des pièces qui n'en n'ont pas besoin La pièce doit avoir une face plus ou moins "complète" en contact avec le bed, et ensuite "grandir" selon l'axe Z d'une manière que les supports ne soient pas nécessaires, sachant que des surplombs et des ponts "raisonables" sont imprimables sans supports. Ta pièce est une roue ou une poulie... D'un point de vue fonctionnel, ta pièce n'a peut être pas besoin que le moyeu dépasse des deux côtés. Si tu modifies ta pièce pour que la face en contact avec le bed soit plane, pas besoin de supports. La pièce ne sera pas symétrique mais ce n'est peut être pas gênant. La face plane peut être du côté qui ne sera pas visible. En fait, il ne faut pas hésiter à concevoir et modéliser les pièces qu'on veut imprimer en 3D d'une façon différente des pièces qu'on fabriquerait par usinage ou fonderie. Chaque procédé de fabrication a ses avantages et ses contraintes, s'acharner à vouloir imprimer en 3D une pièce dessinée pour être fabriqué autrement c'est parfois se compliquer la vie, sans que cela soit utile au final. Autre astuce : l'orientation de la pièce que l'on imprime en 3D ne correspond pas forcément à l'orientation dans laquelle on l'a dessinée. Ici, c'est flagrant, la roue est couchée Mais parfois les utilisateurs se cassent la tête avec des supports difficiles à retirer alors que la pièce pourrait être imprimée plus facilement inclinée ou carrément à l'envers. La solution donnée par @Kachidoki est bien aussi : couper la pièce en deux pour la coller ensuite. Il faudra penser à ajouter aux deux moitiés de pièce des encoches males/femelles pour avoir un bon positionnement pendant le collage. Si tu imprimes en ABS, ce matériau se colle solidement et facilement avec de la colle PVC ou de l'acétone.
  9. Il y a Mouthe mais aussi quelques autres endroits dans le Jura et le Haut-Doubs. Je suis arrivé dans la région en 2004. On avait souvent des températures négatives de nombreux jours de suite et de la neige. C'est beaucoup plus rare aujourd'hui en effet.
  10. C'est exactement ça Avec l'Arduino on peut avoir des forks de lib qui fonctionnent très bien mais dès qu'on s'écarte un peu trop du cas d'usage classique ça ne fonctionne plus. C'est parfois cruel, l'Arduino permet à des non-spécialistes de réaliser facilement un circuit programmable embarqué, et paf, d'un seul coup ils se retrouvent bloqués par un problème ayant un niveau de complexité beaucoup plus élevé, qui demande de mettre les mains dans le cambouis et faire du reverse engineering quand la doc ne suffit pas. La courbe d'apprentissage est assez raide Cependant, certains sites sont très bien faits, comme https://www.locoduino.org/spip.php?rubrique14 qui aborde des notions assez pointue de façon plutôt accessible.
  11. Tu m'as grillé - j'avais trouvé l'explication mais tu as répondu avant que je le fasse Mais je suis content, j'avais peur que le sujet n'intéresse pas grand monde ! Je vais juste donner un peu plus détails - ça pourra être utile pour les autres "Arduinistes" du forum Alors, dans le code de la librairie URTouch, ces deux lignes modifient un bit du port de façon plus rapide que digitalWrite() *reg &= ~bitmask ou encore *reg |= bitmask On peut découvrir la complexité de digitalWrite() ici : https://garretlab.web.fc2.com/en/arduino/inside/hardware/arduino/avr/cores/arduino/wiring_digital.c/digitalWrite.html void digitalWrite(uint8_t pin, uint8_t val) { uint8_t timer = digitalPinToTimer(pin); uint8_t bit = digitalPinToBitMask(pin); uint8_t port = digitalPinToPort(pin); volatile uint8_t *out; if (port == NOT_A_PIN) return; // If the pin that support PWM output, we need to turn it off // before doing a digital write. if (timer != NOT_ON_TIMER) turnOffPWM(timer); out = portOutputRegister(port); uint8_t oldSREG = SREG; cli(); if (val == LOW) { *out &= ~bit; } else { *out |= bit; } SREG = oldSREG; } Chose intéressante, digitalWrite() fait la même chose que les macros de URTouch (voyez les lignes *out &= ~bit et *out |= bit) mais avec plus de précautions... ... en particulier, digitalWrite() désactive temporairement les interruptions avant d'exectuer les instructions qui modifient le registre de sortie Cette désactivation temporaire est réalisée par les lignes de code suivantes : uint8_t oldSREG = SREG; cli(); ... SREG = oldSREG; SREG est le registre dont un des bits autorise ou pas les interruptions ; il contient aussi d'autres bits ayant un rôle important cli(); désactive les interruptions En sauvegardant SREG, en désactivant les interruptions, puis en restaurant SREG, on peut travailler "proprement" avec le hardware car on remet le microcontrôleur de l'Arduino dans le même état qu'on l'a trouvé. En effet, si les lignes de code *reg &= ~bitmask et *reg |= bitmask ne font qu'une seule ligne de C++, elles sont compilées en assembleur par plusieurs instructions qui se suivent Comme l'a dit @Kachidoki : ce ne sont donc pas des fonctions "atomiques" qui s'execute d'un seul bloc. C'est le "piège" du C++ : sa syntaxe peut être très compacte mais une petite ligne de C++ peut correspondre à un nombre d'instructions assembleur plus ou moins nombreuses. Dans certains cas, le C++ peut donner l'impression à tord d'avoir optimisé un programme en écrivant un code C++ plus court... qui aboutira au final à un code assembleur de taille identique Là où c'est moins drôle, c'est que le C++ peut parfois faire passer pour atomique une instruction qui ne l'est pas. Il est donc possible qu'une interruption interviennent en plein milieu de la série d'instruction assembleur correspondant à *reg &= ~bitmask ou *reg |= bitmask ; si le code de cette interruption modifie aussi les registres utilisés par le code on se retrouve avec un bug assez difficile à trouver. Bref, l'optimisation faite par l'auteur de URTouch a été un peu trop loin Chose intétessante : la librairie que j'utilise pour l'afficheur ILI9341 utilise une autre librairie optimisée pour lire et écrire rapidement sur les broches : FastPin, qui est assez réputée. https://github.com/JakesMD/FastPin/blob/main/src/FastPin.cpp Voyons le code de FastPin : #include "FastPin.h" FastWritePin::FastWritePin(byte pin) { _pin = pin; } void FastWritePin::begin(bool initialVal) { pinMode(_pin, OUTPUT); digitalWrite(_pin, initialVal); // Turns off PWM timers. byte port = digitalPinToPort(_pin); _bitMask = digitalPinToBitMask(_pin); _outputRegister = port != NOT_A_PIN ? portOutputRegister(port) : NULL; } void FastWritePin::write(bool val) { if (_outputRegister == NULL) return; byte oldSREG = SREG; cli(); if (val == LOW) { *_outputRegister &= ~_bitMask; } else { *_outputRegister |= _bitMask; } SREG = oldSREG; } FastReadPin::FastReadPin(byte pin) { _pin = pin; } void FastReadPin::begin(bool pullup) { if (pullup) { pinMode(_pin, INPUT_PULLUP); } else { pinMode(_pin, INPUT); } digitalRead(_pin); // Turns off PWM timers. byte port = digitalPinToPort(_pin); _bitMask = digitalPinToBitMask(_pin); _inputRegister = port != NOT_A_PIN ? portInputRegister(port) : NULL; } bool FastReadPin::read() { return (_inputRegister != NULL && *_inputRegister & _bitMask) ? HIGH : LOW; } Même si FastPin est plus rapide que digitalWrite(), on voit bien que FastPin procéde prudemment en sauvegardant SREG, en désactivant les interruptions, et en restorant SREG. A bientôt
  12. Dans ma région il va falloir faire attention
  13. Bonjour, J'ai rencontré un problème qui m'a donné un peu de fil à retordre. J'avais adapté des librairies pour faire fonctionner ensemble, sur un Arduino UNO : - le shield Ethernet 2 avec une puce W5500 - un écran LCD graphique avec une puce ILI9341 - une dalle tactile avec une puce XPT2046 Voici le câblage : - Le shield Ethernet 2 utilise le bus SPI - L'écran LCD graphique utilise le bus SPI, la librairie est une version optimisée de celle d'Adafruit pour exploiter au mieux la vitesse du hardware SPI - La dalle tactile est en SPI mais gérée en bitbanging, avec une version optimisée de la librairie URTouch Un circuit convertisseur 3.3V/5V est intercalé entre l'Arduino et l'écran tactile Je ne suis pas arrivé à gérer la dalle tactile avec le hardware SPI mais l'ensemble fonctionne très bien J'ai voulu adapter mon projet pour le faire fonctionner sur un Arduino MEGA Le câblage et le code ont dû être modifiés car les broches SPI ne sont pas les mêmes sur l'UNO et le MEGA : #if defined(ARDUINO_AVR_UNO) #define ILI9341_CS_PIN 0 // (PD0) #define ILI9341_DC_PIN 9 // (PB1) #define ILI9341_RST_PIN 8 // (PB0) // ILI9341_MISO 12 (PB4) No choice, Mega Hardware SPI MISO - Also used by Ethernet Shield // ILI9341_MOSI 11 (PB3) No choice, Mega Hardware SPI MOSI - Also used by Ethernet Shield // ILI9341_CK 13 (PB5) No choice, Mega Hardware SPI CK - Also used by Ethernet Shield #else // ARDUINO MEGA #define ILI9341_CS_PIN 49 // (PL0) #define ILI9341_DC_PIN 48 // (PL1) #define ILI9341_RST_PIN 47 // (PL2) // ILI9341_MISO 50 (PB3) No choice, Mega Hardware SPI MISO - Also used by Ethernet Shield // ILI9341_MOSI 51 (PB2) No choice, Mega Hardware SPI MOSI - Also used by Ethernet Shield // ILI9341_CK 52 (PB1) No choice, Mega Hardware SPI CK - Also used by Ethernet Shield #endif Sur l'Arduino MEGA, j'ai voulu câbler les I/O de l'écran tactile sur les I/O qui étaient à proximité de celles utilisées par l'écran graphique LCD Et rien ne fonctionnait... Comme j'avais beaucoup optimisé les librairie pour l'Arduino UNO, je me suis dit que j'avais certainement rendu celles-ci incompatibles avec l'Arduino MEGA Après pas mal de tests, je me suis rendu compte que c'était juste le choix des broches d'I/O qui étaient en cause ; pour résumer : #if defined(ARDUINO_AVR_UNO) #define T_IRQ 5 // (PD5) #define T_CS 2 // (PD2) #define T_DOUT 7 // (PD7) MISO #define T_DIN 6 // (PD6) MOSI #define T_CLK 1 // (PD1) #else // ARDUINO MEGA // FONCTIONNE CORRECTEMENT : #define T_IRQ 33 // (PC4) #define T_CS 34 // (PC3) #define T_DOUT 35 // (PC2) #define T_DIN 36 // (PC1) #define T_CLK 37 // (PC0) // NE FONCTIONNE PAS : // #define T_IRQ 42 // (PL7) // #define T_CS 43 // (PL6) // #define T_DOUT 44 // (PL5) // #define T_DIN 45 // (PL4) // #define T_CLK 46 // (PL3) // AVEC L'ECRAN TFT BRANCHE AINSI SUR L'ARDUINO MEGA : // ILI9341_CS_PIN 49 (PL0) // ILI9341_DC_PIN 48 (PL1) // ILI9341_RST_PIN 47 (PL2) // ILI9341_MISO 50 (PB3) No choice, Mega Hardware SPI MISO // ILI9341_MOSI 51 (PB2) No choice, Mega Hardware SPI MOSI // ILI9341_CK 52 (PB1) No choice, Mega Hardware SPI CK #endif Ce qui pose problème, c'est d'utiliser des broches du même port (en l'occurrence, le port PL) pour : - les broches CS, DS et RST de l'écran tactile - les broches de la dalle tactile en SPI bitbanging Le code de la librairie URTouch utilise des macros assembleurs pour modifier un seul bit d'un port : #define cbi(reg, bitmask) *reg &= ~bitmask #define sbi(reg, bitmask) *reg |= bitmask #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask); #define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask); On a tendance à l'oublier avec les langages "user friendly" comme Arduino : sur un microcontrôleur 8 bits, on n'écrit pas directement sur une broche d'entrée/sortie, mais on écrit un octet dans un port. J'en suis arrivé à la conclusion que les instructions *reg &= ~bitmask et/ou *reg |= bitmask appliquées au registre d'un port pourraient engendrer des changements d'état parasites des bits qui ne sont pas modifiés, ce qui fait planter la puce ILI9341 de l'écran graphique. Mais je n'en suis pas sûr... Quel est votre avis ? J'ai d'abord pensé que la librairie qui gère l'ILI9341 avec le hardware SPI était aussi en cause... .. mais en faisant un test avec la librairie UTFT en bitbanging sur les mêmes broches le bug est aussi présent ! Voici le code complet de URTouch.h : // DEFINE HERE THE PIN USED -------------------------------------------------------------- #if defined(ARDUINO_AVR_UNO) #define T_IRQ 5 // (PD5) #define T_CS 2 // (PD2) #define T_DOUT 7 // (PD7) MISO #define T_DIN 6 // (PD6) MOSI #define T_CLK 1 // (PD1) #else // ARDUINO MEGA // FONCTIONNE CORRECTEMENT : #define T_IRQ 33 // (PC4) #define T_CS 34 // (PC3) #define T_DOUT 35 // (PC2) #define T_DIN 36 // (PC1) #define T_CLK 37 // (PC0) // NE FONCTIONNE PAS : // #define T_IRQ 42 // (PL7) // #define T_CS 43 // (PL6) // #define T_DOUT 44 // (PL5) // #define T_DIN 45 // (PL4) // #define T_CLK 46 // (PL3) // AVEC L'ECRAN TFT BRANCHE AINSI SUR L'ARDUINO MEGA : // ILI9341_CS_PIN 49 (PL0) // ILI9341_DC_PIN 48 (PL1) // ILI9341_RST_PIN 47 (PL2) // ILI9341_MISO 50 (PB3) No choice, Mega Hardware SPI MISO // ILI9341_MOSI 51 (PB2) No choice, Mega Hardware SPI MOSI // ILI9341_CK 52 (PB1) No choice, Mega Hardware SPI CK #endif // --------------------------------------------------------------------------------------- #if !defined(TFT_SIZE_WIDTH) #define TFT_SIZE_WIDTH 240 #endif #if !defined(TFT_SIZE_HEIGHT) #define TFT_SIZE_HEIGHT 320 #endif #define PORTRAIT 0 #define LANDSCAPE 1 // Now calibration data is saved on EEPROM, and calibration software is included in the "setup menu" of the interface :-) // So you don't have to burn a separate calibration sketch and include calibration data in the INO file for each bord and each screen int touch_x_left, touch_x_right, touch_y_top, touch_y_bottom; // Hardware specific defines #define cbi(reg, bitmask) *reg &= ~bitmask #define sbi(reg, bitmask) *reg |= bitmask #define rbi(reg, bitmask) ((*reg) & bitmask) #define pulse_high(reg, bitmask) sbi(reg, bitmask); cbi(reg, bitmask); #define pulse_low(reg, bitmask) cbi(reg, bitmask); sbi(reg, bitmask); #define regtype volatile uint8_t #define regsize uint8_t #define PREC_LOW 1 #define URTouch_Prec 102 class URTouch { public: int16_t TP_X ,TP_Y; void InitTouch(byte orientation); bool read(); bool dataAvailable(); int16_t getX(); int16_t getY(); void calibrateRead(); byte FutureOrientation; void UpdateOrientation(); private: regtype *P_CLK, *P_CS, *P_DIN, *P_DOUT, *P_IRQ; regsize B_CLK, B_CS, B_DIN, B_DOUT, B_IRQ; int disp_x_size, disp_y_size; void touch_WriteData(byte data); word touch_ReadData(); byte orient; }; void URTouch::touch_WriteData(byte data) { byte temp; temp=data; cbi(P_CLK, B_CLK); for(byte count=0; count<8; count++) { if(temp & 0x80) sbi(P_DIN, B_DIN); else cbi(P_DIN, B_DIN); temp = temp << 1; cbi(P_CLK, B_CLK); sbi(P_CLK, B_CLK); } } word URTouch::touch_ReadData() { word data = 0; for(byte count=0; count<12; count++) { data <<= 1; sbi(P_CLK, B_CLK); cbi(P_CLK, B_CLK); if (rbi(P_DOUT, B_DOUT)) data++; } return(data); } void URTouch::UpdateOrientation() { orient = FutureOrientation; } void URTouch::InitTouch(byte orientation) { FutureOrientation = orientation; orient = orientation; disp_x_size = TFT_SIZE_WIDTH-1; disp_y_size = TFT_SIZE_HEIGHT-1; P_CLK = portOutputRegister(digitalPinToPort(T_CLK)); B_CLK = digitalPinToBitMask(T_CLK); P_CS = portOutputRegister(digitalPinToPort(T_CS)); B_CS = digitalPinToBitMask(T_CS); P_DIN = portOutputRegister(digitalPinToPort(T_DIN)); B_DIN = digitalPinToBitMask(T_DIN); P_DOUT = portInputRegister(digitalPinToPort(T_DOUT)); B_DOUT = digitalPinToBitMask(T_DOUT); P_IRQ = portInputRegister(digitalPinToPort(T_IRQ)); B_IRQ = digitalPinToBitMask(T_IRQ); pinMode(T_CLK, OUTPUT); pinMode(T_CS, OUTPUT); pinMode(T_DIN, OUTPUT); pinMode(T_DOUT, INPUT); pinMode(T_IRQ, OUTPUT); sbi(P_CS, B_CS); sbi(P_CLK, B_CLK); sbi(P_DIN, B_DIN); sbi(P_IRQ, B_IRQ); } bool URTouch::read() { unsigned long tx=0, temp_x=0; unsigned long ty=0, temp_y=0; unsigned long minx=99999, maxx=0; unsigned long miny=99999, maxy=0; byte datacount=0; cbi(P_CS, B_CS); pinMode(T_IRQ, INPUT); for (byte i=0; i<URTouch_Prec; i++) { if (!rbi(P_IRQ, B_IRQ)) { touch_WriteData(0x90); pulse_high(P_CLK, B_CLK); temp_x = touch_ReadData(); if (!rbi(P_IRQ, B_IRQ)) { touch_WriteData(0xD0); pulse_high(P_CLK, B_CLK); temp_y = touch_ReadData(); if ((temp_x>0) and (temp_x<4096) and (temp_y>0) and (temp_y<4096)) { tx += temp_x; ty += temp_y; if (temp_x<minx) minx = temp_x; if (temp_x>maxx) maxx = temp_x; if (temp_y<miny) miny = temp_y; if (temp_y>maxy) maxy = temp_y; datacount++; } } } } pinMode(T_IRQ, OUTPUT); tx -= minx + maxx; ty -= miny + maxy; datacount -= 2; sbi(P_CS, B_CS); if ((datacount==(URTouch_Prec-2)) or (datacount==PREC_LOW)) { if (orient == PORTRAIT) { TP_X = ty/datacount; TP_Y = tx/datacount; } else { TP_X = tx/datacount; TP_Y = ty/datacount; } return true; } else { return false; } } bool URTouch::dataAvailable() { bool avail; pinMode(T_IRQ, INPUT); avail = !(rbi(P_IRQ, B_IRQ)); pinMode(T_IRQ, OUTPUT); return avail; } int16_t URTouch::getX() { int c; if (orient == PORTRAIT) { c = long(long(TP_X - touch_x_left) * (disp_x_size)) / long(touch_x_right - touch_x_left); } else { c = long(long(TP_X - touch_y_top) * (-disp_y_size)) / long(touch_y_bottom - touch_y_top) + long(disp_y_size); } return c; } int16_t URTouch::getY() { int c; if (orient == PORTRAIT) { c = long(long(TP_Y - touch_y_top) * (disp_y_size)) / long(touch_y_bottom - touch_y_top); } else { c = long(long(TP_Y - touch_x_left) * (disp_x_size)) / long(touch_x_right - touch_x_left); } return c; } void URTouch::calibrateRead() { unsigned long tx=0; unsigned long ty=0; cbi(P_CS, B_CS); touch_WriteData(0x90); pulse_high(P_CLK, B_CLK); tx=touch_ReadData(); touch_WriteData(0xD0); pulse_high(P_CLK, B_CLK); ty=touch_ReadData(); sbi(P_CS, B_CS); TP_X=ty; TP_Y=tx; } Voici comment le code est utilisé dans le projet : URTouch ts; void setup() { ... ts.InitTouch(PORTRAIT); ... } void loop() { if (ts.dataAvailable()) { if (ts.read()) { Touch_X = ts.getX(); Touch_Y = ts.getY(); ... } } ... }
  14. Quand j'ai renouvelé mon matériel, j'avais vu qu'ils vendaient des disques durs spécifiques pour NAS et vidéosurveillance - je trouvais ça bizarre mais ils doivent être conçus pour durer plus longtemps. Pour mes sauvegardes et archives, je suis resté sur des disques dur mécaniques. Les gros SDD sont très chers et j'ai vu pas mal de retours négatifs sur la durée de vie de la part de photographes et vidéastes... Un HDD mécanique en fin de vie donne des signes avant-coureurs et avec de la chance on a le temps de récupérer les données ou on peut même réparer le disque le temps de faire la sauvegarde. Avec un SDD quand une puce grille c'est mort.
  15. C'est bon à savoir Pour réduire le bruit, dans mes ordinateurs fixes, les HDD étaient "suspendus" Sur mon 2e PC construit en 2001, en plein dans la mode "jackyPC", j'avais bricolé des suspenssions avec des morceaux de chambre à air de vélo : C'était efficace, on n'entendait plus le disque dur "gratter". Admirez au passage la mousse anti bruit C'était l'époque des modems 56K ou il fallait dormir avec le PC dans la chambre allumé toute la nuit pour les téléchargements Sur le PC suivant, qui date de 2011, plus besoin de faire du "tunning", le fabriquant de la tour (ANTEC) avait prévu des fixations de disque dur en silicone, elles sont efficaces et ne prennent pas trop de place, peut-être une solution pour les NAS ? J'ai encore un HDD dans un boitier externe, ça vibre, je le pose sur un morceau de mousse. Ca évite aussi que le HDD prenne des coups quand je bricole sur le bureau (le PC portable et l'écran sont posés sur des supports fixés au mur, ça libère de l'espace sur le bureau)
×
×
  • Créer...