Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2399 connectés 

 
 


 Mot :   Pseudo :  
  Aller à la page :
 
 Page :   1  2  3  4  5  ..  169  170  171  ..  264  265  266  267  268  269
Page Suivante
Page Précédente
Bas de page 
Auteur Sujet :

[arduino] Topic Unique blabla @ Arduino

n°245952
calagan57
BF3 : calagan57
Posté le 08-02-2019 à 07:36:58  profilanswer
 

Reprise du message précédent :
Hello!!
 
Question NOOB de chez NOOB je préviens  :o  
 
quand on importe/charge une bibliothèque dans arduino IDE, comment on sait/trouve les variables et la synthaxe à faire avec cette bibliothèque dans le sketch?  :pt1cable:  
 
je charge la bibliothèque emonlib.h (monitoring d'énergie superbe  :love: ) mais comment je peux savoir les variables que je dois mettre  :pt1cable:  
 
il y a bien un exemple mais mais ça ne donne pas toute les possibilités...
 
merci à vous  :hello:  
 

Message cité 1 fois

---------------
Waterbox
mood
Publicité
Posté le 08-02-2019 à 07:36:58  profilanswer
 

n°245956
tomsoft
Posté le 08-02-2019 à 08:19:50  profilanswer
 

calagan57 a écrit :

Hello!!
 
Question NOOB de chez NOOB je préviens  :o  
 
quand on importe/charge une bibliothèque dans arduino IDE, comment on sait/trouve les variables et la synthaxe à faire avec cette bibliothèque dans le sketch?  :pt1cable:  
 
je charge la bibliothèque emonlib.h (monitoring d'énergie superbe  :love: ) mais comment je peux savoir les variables que je dois mettre  :pt1cable:  
 
il y a bien un exemple mais mais ça ne donne pas toute les possibilités...
 
merci à vous  :hello:  
 


 
T’ouvre le .h et tu regarde les prototypes des fonctions / classes, ou la doc quand y’en a une

Message cité 1 fois
n°245957
calagan57
BF3 : calagan57
Posté le 08-02-2019 à 08:22:01  profilanswer
 

tomsoft a écrit :


 
T’ouvre le .h et tu regarde les prototypes des fonctions / classes, ou la doc quand y’en a une


 
merci je vais check ça  :jap:
 
Edit :
 

Citation :

/*
  Emon.h - Library for openenergymonitor
  Created by Trystan Lea, April 27 2010
  GNU GPL
  modified to use up to 12 bits ADC resolution (ex. Arduino Due)
  by boredman@boredomprojects.net 26.12.2013
  Low Pass filter for offset removal replaces HP filter 1/1/2015 - RW
*/
 
#ifndef EmonLib_h
#define EmonLib_h
 
#if defined(ARDUINO) && ARDUINO >= 100
 
#include "Arduino.h"
 
#else
 
#include "WProgram.h"
 
#endif
 
// define theoretical vref calibration constant for use in readvcc()
// 1100mV*1024 ADC steps http://openenergymonitor.org/emon/node/1186
// override in your code with value for your specific AVR chip
// determined by procedure described under "Calibrating the internal reference voltage" at
// http://openenergymonitor.org/emon/ [...] alibration
#ifndef READVCC_CALIBRATION_CONST
#define READVCC_CALIBRATION_CONST 1126400L
#endif
 
// to enable 12-bit ADC resolution on Arduino Due,
// include the following line in main sketch inside setup() function:
//  analogReadResolution(ADC_BITS);
// otherwise will default to 10 bits, as in regular Arduino-based boards.
#if defined(__arm__)
#define ADC_BITS    12
#else
#define ADC_BITS    10
#endif
 
#define ADC_COUNTS  (1<<ADC_BITS)
 

class EnergyMonitor
{
  public:
 
    void voltage(unsigned int _inPinV, double _VCAL, double _PHASECAL);
    void current(unsigned int _inPinI, double _ICAL);
 
    void voltageTX(double _VCAL, double _PHASECAL);
    void currentTX(unsigned int _channel, double _ICAL);
 
    void calcVI(unsigned int crossings, unsigned int timeout);
    double calcIrms(unsigned int NUMBER_OF_SAMPLES);
    void serialprint();
 
    long readVcc();
    //Useful value variables
    double realPower,
      apparentPower,
      powerFactor,
      Vrms,
      Irms;
 
  private:
 
    //Set Voltage and current input pins
    unsigned int inPinV;
    unsigned int inPinI;
    //Calibration coefficients
    //These need to be set in order to obtain accurate results
    double VCAL;
    double ICAL;
    double PHASECAL;
 
    //--------------------------------------------------------------------------------------
    // Variable declaration for emon_calc procedure
    //--------------------------------------------------------------------------------------
    int sampleV;                        //sample_ holds the raw analog read value
    int sampleI;
 
    double lastFilteredV,filteredV;          //Filtered_ is the raw analog value minus the DC offset
    double filteredI;
    double offsetV;                          //Low-pass filter output
    double offsetI;                          //Low-pass filter output
 
    double phaseShiftedV;                             //Holds the calibrated phase shifted voltage.
 
    double sqV,sumV,sqI,sumI,instP,sumP;              //sq = squared, sum = Sum, inst = instantaneous
 
    int startV;                                       //Instantaneous voltage at start of sample window.
 
    boolean lastVCross, checkVCross;                  //Used to measure number of times threshold is crossed.
 
 
};
 
#endif


 
Donc dans emonlib.h il a bien une class qui s'appelle "energymonitor"
 
Ensuite dans l'exemple d'utilisation on a ça :
 

Citation :

// EmonLibrary examples openenergymonitor.org, Licence GNU GPL V3
 
#include "EmonLib.h"             // Include Emon Library
EnergyMonitor emon1;             // Create an instance
 
void setup()
{  
  Serial.begin(9600);
   
  emon1.voltage(2, 234.26, 1.7);  // Voltage: input pin, calibration, phase_shift
  emon1.current(1, 111.1);       // Current: input pin, calibration.
}
 
void loop()
{
  emon1.calcVI(20,2000);         // Calculate all. No.of half wavelengths (crossings), time-out
  emon1.serialprint();           // Print out all variables (realpower, apparent power, Vrms, Irms, power factor)
   
  float realPower       = emon1.realPower;        //extract Real Power into variable
  float apparentPower   = emon1.apparentPower;    //extract Apparent Power into variable
  float powerFActor     = emon1.powerFactor;      //extract Power Factor into Variable
  float supplyVoltage   = emon1.Vrms;             //extract Vrms into Variable
  float Irms            = emon1.Irms;             //extract Irms into Variable
}


 
Donc ici on crée une instance appelée "emon1" c'est bien ça? Rien n’empêche d'en créer d'autres genre emon2 etc...?
Le but c'est de brancher plusieurs capteur de courant.
 
merci à vous!

Message cité 1 fois
Message édité par calagan57 le 08-02-2019 à 11:11:12

---------------
Waterbox
n°246013
_pollux_
Pan ! t'es mort
Posté le 08-02-2019 à 14:21:33  profilanswer
 

Salut,  
 
je pose ça comme ça, on sait jamais mais ça peut faire gagner du temps :o
 
Ne comptez pas utiliser Software.Serial à 115200 bauds, ça passe pas  [:icon4]  
Le pire, c'est que dans mon cas, ça reproduisait la même erreur de lecture à chaque fois...
 
- En passant à 9600bauds, aucun soucis.
- En restant à 115200 sur du serial hardware, aucun soucis.
 
 


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246024
rat de com​bat
attention rongeur méchant!
Posté le 08-02-2019 à 15:24:37  profilanswer
 

calagan57 a écrit :

Donc ici on crée une instance appelée "emon1" c'est bien ça?

oui.

Citation :

Rien n’empêche d'en créer d'autres genre emon2 etc...?

à priori pas de soucis.

n°246045
_pollux_
Pan ! t'es mort
Posté le 08-02-2019 à 16:53:26  profilanswer
 

Salut, je souhaite communiquer avec un appareil qui attend des commandes telles que :
0x81 0x17 0x68
 
Le seul moyen que j'ai trouvé de communiquer est d'utiliser la touche Send Numbers avec le terminal realterm. Voir l'image suivante:  
 
https://reho.st/self/2dd392de5f6e471ac87b5d9e764cdac9123d4767.png
 
 
 
On peut voir en bas l'explication de la méthode :

Citation :

Char values as decimal or Hex with blank and commas eg 77 254,x6F, 0x1F,$5A


 
Mon problème est que je dois recréer cette façon sur Arduino, mais mes tentatives d'envoi de type  :

Code :
  1. Serial1.print("0x81 0x17 0x68" );
  2. Serial1.write("0x81 0x17 0x68" );


 
ne mènent à rien... vous avez une idée ?


Message édité par _pollux_ le 08-02-2019 à 16:55:15

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246049
rat de com​bat
attention rongeur méchant!
Posté le 08-02-2019 à 17:01:59  profilanswer
 

Non, ça c'est les valeurs en ASCII.

 

Essaye

Code :
  1. Serial1.write(0x81);
  2. Serial1.write(0x17);
  3. Serial1.write(0x68);
 

ou plus court

Code :
  1. const uint8_t data[3]={0x81, 0x17, 0x68};
  2. Serial1.write(data, sizeof(data)/sizeof(uint8_t)); //oui on peut virer le sizeof(uint8_t)...
 

selon la doc sans garantie. :o


Message édité par rat de combat le 08-02-2019 à 17:02:23
n°246052
_pollux_
Pan ! t'es mort
Posté le 08-02-2019 à 17:20:42  profilanswer
 

pas mieux :/


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246053
rat de com​bat
attention rongeur méchant!
Posté le 08-02-2019 à 17:22:06  profilanswer
 

Pourtant ça devrait le faire... Tu peux brancher un petit module USB-série sur la liaison pour voir ce qui s'y passe? Le baudrate et les autres paramètres sont bons?

n°246072
_pollux_
Pan ! t'es mort
Posté le 08-02-2019 à 18:20:21  profilanswer
 

J'ai plus le matos sous la main jusqu'à lundi :D
 
Mais oui, je peux brancher un FTDI, c'est d'ailleurs ce que j'ai fait dans un premier temps pour communiquer dans les 2 sens avec RealTerm.
J'ai ensuite effectué la programmation côté arduino pour récupérer les données (j'envoyais les commandes avec le FTDI).
 
Il ne me reste plus qu'à envoyer les commandes avec l'arduino et c'est là que je bloque un peu :D
 
(J'aurais aussi pu développer directement un prog sur pc mais je connais quand même mieux l'environnement arduino et le problème serait le même)


---------------
Le topic du sport électronique@hfr : watch the l33t !
mood
Publicité
Posté le 08-02-2019 à 18:20:21  profilanswer
 

n°246103
Nitescent
Posté le 08-02-2019 à 21:36:33  profilanswer
 

Natopsi a écrit :

Oui c'est je ne sais plus quel signal de contrôle du port série qui sert à ça.


Bizarre, je sais plus pourquoi j'avais pas gardé cette solution  [:transparency]  
 
Peut être que ça faisait un bricolage trop dégueulasse avec un cable ouvert en deux :o
Mais maintenant que je fais que des PCBs bien propres je pourrais l'intégrer.
 
 
Mon montage est alimenté en 12V pour la partie puissance,  
il y a un convertisseur 12V -> 5V pour la partie commande,
l'arduino est branché en USB donc normalement il est tout le temps alimenté quand je m'en sers.
 
Mais je voulais avoir la possibilité de m'en servir sans ordinateur, donc j'ai utilisé le convertisseur 12V -> 7,5V disponible pour alimenter l'arduino sur Vin.
Sauf que encore et toujours, une alimentation sur Vin + le cable USB, ça pose des problèmes sur mon ordinateur...
 
Donc il suffit que je ne câble pas le 5V de l'USB sur mon PCB et que j'injecte l'autre 5V à la place [:canaille]


Message édité par Nitescent le 08-02-2019 à 21:36:52
n°246382
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 13:17:37  profilanswer
 

Salut,

 

Je reviens à mon problème d'envoi de données sur UART.
Ne trouvant pas simplement en codant, j'ai branché mon oscillo num sur la sortie du FTDI et de l'arduino.
On voit que l'oscillo reçoit de jolies données correspondant à ce que je veux envoyer quand j'utilise le FTDI, mais c'est pas tout à fait le cas avec l'arduino :D (en outre, faudra peut-être aussi que je réduise la tension à 3.3V)

 

FTDI

 

https://reho.st/self/286e94bbaadd3e9ac812537a1d17495e9f9ac948.png

 

ARDUINO

 

https://reho.st/self/43e5f9ebe0ae368ca6216e42bdd780b4be2f1826.png

Message cité 1 fois
Message édité par _pollux_ le 11-02-2019 à 13:23:54

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246392
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 14:34:27  profilanswer
 

Bon, problème partiellement compris... ça passe sans problème à 9600 bauds...


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246401
Natopsi
☄️Just end it already!☄️
Posté le 11-02-2019 à 15:15:33  profilanswer
 

SoftwareSerial a des limites, et en hardware t'as vite fait de saturer le buffer si le CPU ne tiens pas la charge.

Message cité 1 fois

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡
n°246404
rat de com​bat
attention rongeur méchant!
Posté le 11-02-2019 à 15:26:23  profilanswer
 

_pollux_ a écrit :

en outre, faudra peut-être aussi que je réduise la tension à 3.3V

Si ton bidule n'est pas tolérant 5V il faut faire ça toute de suite au risque de le griller!! :o


Message édité par rat de combat le 11-02-2019 à 15:36:12
n°246406
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 15:35:31  profilanswer
 

Natopsi a écrit :

SoftwareSerial a des limites, et en hardware t'as vite fait de saturer le buffer si le CPU ne tiens pas la charge.


justement, j'suis plus en software.serial... qui me posait déjà des soucis à la lecture...

 

Là, c'est sur le serial1 d'un arduino mega.

 

Le truc bizarre aussi, c'est que c'est pas x% d'erreur sur un gros débit mais une erreur systématique sur 3 octets envoyés...

 
Code :
  1. void setup() {
  2.  
  3.   // Set serial port
  4.   Serial.begin(115200);
  5.   while (!Serial) {
  6.     ; // wait for serial port to connect. Needed for native USB port only
  7.   }
  9.   // set SoftwareSerial port
  10.   Serial1.begin(9600,SERIAL_8E1);
  11.   while (!Serial1){
  12.   }
  13. }
  15. void loop() { // run over and over
  16.   ecriture();
  17. //  lecture();
  18. //  affichage();
  19.   delay (5000);
  20.  
  21. }
  23. ////////////////////////////////
  24. ////////// Fonctions ///////////
  25. ////////////////////////////////
  27. void ecriture(){
  28. //       Serial.println(commande_firmware);
  29.      
  30.         Serial1.write(0x81);
  31.         Serial1.write(0x17);
  32.         Serial1.write(0x68);
  34.        
  35. }
 

Dès que je passe de 9600 à 115200, je ne reçois plus les bonnes valeurs... franchement, j'aurais le choix, je changerais le débit du module avec lequel je dois communiquer, mais il est fixé :/


Message édité par _pollux_ le 11-02-2019 à 15:39:25

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246408
Turkleton
I don't quite understand you
Posté le 11-02-2019 à 15:42:46  profilanswer
 

Et pas moyen d'utiliser SPI ou I2C j'imagine ?

Message cité 1 fois

---------------
If you think it could look good, then I guess it should
n°246412
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 16:06:09  profilanswer
 

Turkleton a écrit :

Et pas moyen d'utiliser SPI ou I2C j'imagine ?


non, bien sûr :D
 
Il doit y avoir un truc qui chie dans mon code.... depuis quand l'arduino serait incapable d'envoyer correctement 3 octets à 115200 bauds ?


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246413
rat de com​bat
attention rongeur méchant!
Posté le 11-02-2019 à 16:15:27  profilanswer
 

Je connais pas bien les Arduino, vous me pardonnerez si je raconte des conneries. :o
-Tu es sûr que serial1 c'est bien le module hardware?
-C'est quoi qui cadence l'AVR, il y a bien un quartz sur ton Arduino?

Message cité 1 fois
n°246416
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 16:23:36  profilanswer
 

rat de combat a écrit :

Je connais pas bien les Arduino, vous me pardonnerez si je raconte des conneries. :o
-Tu es sûr que serial1 c'est bien le module hardware?
-C'est quoi qui cadence l'AVR, il y a bien un quartz sur ton Arduino?

 

Sur le mega, il y a 4 lignes série hardware (voir ici : https://www.arduino.cc/reference/en [...] on/serial/ )
L'AVR est cadencé par un quartz à 16MHz


Message édité par _pollux_ le 11-02-2019 à 16:37:21

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246422
WipEout 20​97
Do you think we can fly
Posté le 11-02-2019 à 16:41:26  profilanswer
 

Sur un Mega c'est un peu dommage de passer en SoftWare Serial, vu le nombre de lignes hardware dispos...

Message cité 1 fois
n°246425
M4vrick
Mad user
Posté le 11-02-2019 à 16:44:48  profilanswer
 

Tu as essayé sur un autre serial hardware ou sur un autre mega?
Le fait que tu ai systématiquement une erreur sur 3 octets (si c'est bien avéré) me fait plus penser à un soucis hardware interne que de code ou de cablage.

Message cité 1 fois
Message édité par M4vrick le 11-02-2019 à 16:44:58

---------------
--== M4vr|ck ==--
n°246426
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 16:45:16  profilanswer
 

WipEout 2097 a écrit :

Sur un Mega c'est un peu dommage de passer en SoftWare Serial, vu le nombre de lignes hardware dispos...


C'est bien vrai, raison pour laquelle je les utilise :D


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246427
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 16:46:06  profilanswer
 

M4vrick a écrit :

Tu as essayé sur un autre serial hardware ou sur un autre mega?
Le fait que tu ai systématiquement une erreur sur 3 octets (si c'est bien avéré) me fait plus penser à un soucis hardware interne que de code ou de cablage.


je viens d'essayer 2 lignes différentes, même erreur...
 
je peux essayer sur un arduino uno sinon... avec la seule ligne hardware dispo.


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246429
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 16:52:50  profilanswer
 

Exactement les mêmes symptômes sur le UNO.
 
Aucun soucis à 9600 baud et toujours la même trame, fausse, à 115200...


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246430
Natopsi
☄️Just end it already!☄️
Posté le 11-02-2019 à 16:56:53  profilanswer
 

Ton consommateur est bien configuré sur 115200?


---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡
n°246432
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:01:17  profilanswer
 

à 9600 baud, on a bien les 3 hex : 0x81 0x17 0x68

 

https://reho.st/self/448083bdcafbe0a99909af90084a99c59b293ef4.png

 

à 115200, on a 3 octets mais pas les bons...

 

https://reho.st/self/b35c8bcca1e9c2554e7e839849c83ae0142443bd.png

 

et ça, c'est ma configuration côté oscillo pour l'interprétation des trames  (je change entre 9600 et 115200 en fonction).

 

https://reho.st/self/68f155f0028a9aba473b092addca670424c84823.png

 

Message cité 1 fois
Message édité par _pollux_ le 11-02-2019 à 17:01:56

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246433
jimbofarra​r
Poreux de la cafetière
Posté le 11-02-2019 à 17:05:05  profilanswer
 

_pollux_ a écrit :

à 9600 baud, on a bien les 3 hex : 0x81 0x17 0x68
 
https://reho.st/self/448083bdcafbe0 [...] 293ef4.png
 
à 115200, on a 3 octets mais pas les bons...  
 
https://reho.st/self/b35c8bcca1e9c2 [...] 2443bd.png
 
et ça, c'est ma configuration côté oscillo pour l'interprétation des trames  (je change entre 9600 et 115200 en fonction).
 
https://reho.st/self/68f155f0028a9a [...] c84823.png
 


Tu déclares une parité paire dans ton serial1.begin (8E1) c’est vraiment nécessaire ? (D’autant que tu es sans parité dans ton troisième screenshot)

Message cité 1 fois

---------------
Bien des Shubs et des Zouls furent calcinés dans les profondeurs de l'énorme Sloar, en vérité, je vous le dis !
n°246434
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:10:05  profilanswer
 

jimbofarrar a écrit :


Tu déclares une parité paire dans ton serial1.begin (8E1) c’est vraiment nécessaire ? (D’autant que tu es sans parité dans ton troisième screenshot)


oui, désolé, c'est à force de modifications... :/

even ou pas de parité, ça change rien à mon problème, j'ai testé.
 
Merci Merci Merci ... il semblerait que ce soit un problème de parité...


Message édité par _pollux_ le 11-02-2019 à 17:19:37

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246438
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:22:26  profilanswer
 

C'est bizarre en fait ... ça marche si ...

 

Je mets la parité côté arduino et que je ne la mets pas côté oscillo  [:hide]  (mais pas l'inverse)

 

J'suis loin d'être un pro mais la parité est pas sensée être réglée pareil des deux côtés ? :??:
Si il faut aussi que je débugue les softs de mon picoscope, je vais pas m'en sortir... :o


Message édité par _pollux_ le 11-02-2019 à 17:28:13

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246440
Natopsi
☄️Just end it already!☄️
Posté le 11-02-2019 à 17:26:32  profilanswer
 

T'as essayé avec 2 bits d'arrêt?

Message cité 1 fois

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡
n°246443
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:30:28  profilanswer
 

Natopsi a écrit :

T'as essayé avec 2 bits d'arrêt?


non, parce que de toute façon, le module que je dois utiliser au final est en 115200, Even, 1 bit de stop.
C'est pour ça que de base, j'ai utilisé ces paramètres sur l'arduino... j'avais juste pas présumé qu'il semblerait que le logiciel de l'oscillo se comporte étrangement à 115200, parce qu'à 9600 baud, ça marche dans toutes les configurations ...


Message édité par _pollux_ le 11-02-2019 à 17:32:08

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246444
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:39:41  profilanswer
 

En gros, pour résumer


arduino <---> oscillo

 

9600 baud,   N, 1 bit <----> 9600 baud,   N, 1 bit   --> OK
9600 baud,   E, 1 bit <----> 9600 baud,   N, 1 bit   --> OK
9600 baud,   E, 1 bit <----> 9600 baud,   E, 1 bit   --> OK
115200 baud, N, 1 bit <----> 115200 baud, N, 1 bit   --> NO
115200 baud, E, 1 bit <----> 115200 baud, N, 1 bit   --> OK
115200 baud, E, 1 bit <----> 115200 baud, E, 1 bit   --> NO

 

Il y a vraiment un problème avec l'interpréteur de décodage série de l'oscillo... ou avec l'arduino...


Message édité par _pollux_ le 11-02-2019 à 17:46:12

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246445
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 17:53:57  profilanswer
 

Quand je regarde mieux l'oscillo, il semblerait que le signal est quand même bien dégradé à 115200 bauds.
En ne cherchant pas le bit de parité, le programme identifie mieux les bit de départ... et lis donc la suite des octets sans trop de difficulté.

 

Aperçu du traitement sur la même acquisition... on voit que s'il cherche à détecter les bit de parité, il ne trouve plus les bits de départ :/ ... enfin, pas au bon endroit...

 

https://reho.st/self/1508f98b94d7ca8127df04baf451fe5622910757.png

 

https://reho.st/self/5bbcde5b174f3bdcfc37250ee0af8d7e0d682abc.png


Message édité par _pollux_ le 11-02-2019 à 18:07:16

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246450
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 18:12:57  profilanswer
 

En gros, c'est comme si le rythme de l'arduino (plus de chance) ou de l'oscillo (peu de chance) n'était pas correct, parce que ok, les fronts sont pas particulièrement verticaux, mais ça justifie quand même pas les décalages, si ?
Et si c'est le cas, ya moyen d'améliorer la qualité du signal ?


Message édité par _pollux_ le 11-02-2019 à 18:16:17

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246457
jimbofarra​r
Poreux de la cafetière
Posté le 11-02-2019 à 18:57:23  profilanswer
 

Essaye de mettre une pause de 1ms entre chaque octet envoyé.


---------------
Bien des Shubs et des Zouls furent calcinés dans les profondeurs de l'énorme Sloar, en vérité, je vous le dis !
n°246464
Natopsi
☄️Just end it already!☄️
Posté le 11-02-2019 à 19:35:11  profilanswer
 

On dirait que l'horloge de oscilloscope dérive. Vu que l'on a l'air d'être dans les 1Mech/seconde c'est peut être un arrondi à la con dans l'interpréteur. En tout cas le signal est bon, c'est l'oscillo ou son soft qui déraille. Surtout que tes fronts sont très très nets.  :jap:


Message édité par Natopsi le 11-02-2019 à 19:35:41

---------------
⚡ACH/VDS⚡HFRCoin◈1435mm⚡
n°246468
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 19:44:56  profilanswer
 

merci de vos conseils :jap: j'essaye tout ça demain :)


---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246497
Manisque
Posté le 11-02-2019 à 22:25:03  profilanswer
 

Est-ce que ton FTDI et ton Arduino sont des Chinoiseries?
 
Tu peux vérifier leurs horloges pour être sûr que tout est bien à la bonne fréquence (si tu envoie des 'U' en 8N1, ça te fait un signal carré de rapport cyclique 1/2 :o).
 
Si le MCU dérive, tu peux regarder le quartz (par contre si tu probe, tu charges le quartz et tu vas dévier la fréquence, ça peut s'équilibrer salement avec une probe 10:1 de chaque côté du quartz :o).

Message cité 1 fois

---------------
Si tu bois froid juste après le potage chaud, ça va faire sauter l'émail de tes dents - Monorailcat iz ohverin
n°246504
_pollux_
Pan ! t'es mort
Posté le 11-02-2019 à 23:18:59  profilanswer
 

Manisque a écrit :

Est-ce que ton FTDI et ton Arduino sont des Chinoiseries?

 

Tu peux vérifier leurs horloges pour être sûr que tout est bien à la bonne fréquence (si tu envoie des 'U' en 8N1, ça te fait un signal carré de rapport cyclique 1/2 :o).

 

Si le MCU dérive, tu peux regarder le quartz (par contre si tu probe, tu charges le quartz et tu vas dévier la fréquence, ça peut s'équilibrer salement avec une probe 10:1 de chaque côté du quartz :o).


le mega est une chinoiserie, pas l'arduino, et le ftdi vient de chez farnell :o
et le ftdi fonctionne très bien, merci pour lui :o

 

Et si le merdier vient de l'oscillo, c'est du picoscope ... ça dépanne bien, sauf des fois :D


Message édité par _pollux_ le 11-02-2019 à 23:23:57

---------------
Le topic du sport électronique@hfr : watch the l33t !
n°246532
_pollux_
Pan ! t'es mort
Posté le 12-02-2019 à 09:54:08  profilanswer
 

Bon, je confirme qu'en rajoutant un délai de 10 µsecondes, l'oscillo interprète bien les octets.
 
Je confirme aussi que le module interprète bien le message sans ces délais...
 
En conclusion, j'ai perdu pas mal de temps, mais j'ai aussi appris des trucs, notamment à ne pas faire confiance aveuglément à un oscillo  :o


---------------
Le topic du sport électronique@hfr : watch the l33t !
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  ..  169  170  171  ..  264  265  266  267  268  269
Page Suivante
Page Précédente
Haut de page 

Aller à :
Ajouter une réponse
 

Sujets relatifs
* Réparations de vos appareils électroniques & electromenager * 
Plus de sujets relatifs à : [arduino] Topic Unique blabla @ Arduino

Forum MesDiscussions.Net, Version 2010.2
(c) 2000-2011 Doctissimo
Page générée en 0.114 secondes

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR