Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - simontpellier

Pages: 1 2 3 [4] 5 6 ... 8
46
Merci M Jean-Luc pour l'info ACAN pour Teensy. Je regrette d'avoir raté votre post mais pas grave puisque j'ai découvert cette librairie par ailleurs il y a ... deux heures !
Et je me suis permis de faire dans la foulée un mail à Pierre Molinaro (pour autant que l'adresse soit active) car je rencontre avec sa librairie exactement le même souci qu'avec "flexCAN", à savoir un Teensy qui lit sur le bus sans problème, et acquitte, mais ne sait pas écrite... j'ai mis tous mes moyens intellectuels sur le coup, ils n'y ont pas suffi et je n'ai plus de cartouche à tirer sauf d'acheter une autre carte "pour voir" !

Une petite question si je peux à propos de ACAN (celle des Arduino) ? J'y vais régulièrement voir sur site s'il y a des nouvelles de la note de renvoi 4: [4] Nous verrons les messages remote dans un prochain article aussi comme j'imagine que vous en serez l'auteur, eh bien je languis de cette publication à venir !



47
@trimarco232 :
Bon plan merci ! (Pour pas trop cher!)
(le mega CORE était également une bonne suggestion, je ne connaissais pas non plus)

L'objectif en cours est néanmoins basé sur le Teensy 3.5 qui repousse très loin toutes les limites. Les librairies Arduino passent comme qui rigole, le code "shift-register-PWM" transféré sur Teensy tourne à une vitesse faramineuse... mais reste le problème du bus CAN. La librairie n'a rien en commun avec ACAN, les exemples sont peu nombreux, et abcons, et il y a 4 "variants" (tous anglais) de ladite librairie... j'ai eu beau labourer le web, pas moyen de se faire parler la teensy (via son CAN intégré) avec un Arduino, je suis au bord de l'appel au secours.

48
Vos projets / Re : Taille caractères sur afficheur "Arrivée Départ"
« le: février 16, 2021, 12:28:38 pm »
Bonjour,
ça semble être quatre lignes en 2X... paramètre par défaut ? Je n'ai pas vérifié. En tous cas la taille de caractère n'est pas paramétrée dans le .ino.

Vous aurez probablement vos huit lignes en y ajoutant :
    display.set1X();

Mais ça fera tout petit !!

49
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: février 09, 2021, 08:32:32 pm »
A signaler à toutes fins utiles... il semblerait qu'on puisse même se passer tout simplement de transceiver !

https://forum.pjrc.com/threads/43684-CAN-bus-Teensy-Teensy-communication-without-transceiver
https://www.mikrocontroller.net/attachment/28831/siemens_AP2921.pdf

50
Vos projets / Re : projet centrale "LaBox" wifi DCC++ Can
« le: février 06, 2021, 04:47:15 pm »
Bonjour Dominique (c'est presque un message privé...)

Cette semaine, je cherchai un transceiver CAN pour interfacer non un ESP32 mais un TEENSY, ce qui ne change rien sur le fond.
Le souci que tu rencontres avec les CJMCU-230 n'est pas isolé, il y a des cas sur d'autres forum (mais tout de même, 1/5 c'est pas banal !)
(D'après ce que j'ai lu, le problème serait fonction du débit : https://esp32.com/viewtopic.php?t=380&start=170 )

Parce que j'étais impatient et avec le sentiment probablement illusoire d'un risque moindre, j'en ai trouvé UN (le dernier !) chez un vendeur France, relativement pas cher, toujours très rapide : commandé jeudi reçu ce midi : https://www.ebay.fr/itm/CJMCU-230-module-communication-%C3%A9metteur-r%C3%A9cepteur-bus-CAN-SN65HVD230-1345Z/293132899616?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2648

Pas de DCC ni donc de LaBox dans mon cas, je ne pourrai donc pas apporter de réponse à ta question.
Mais c'est moi qui en ai une ! Je ne peux pas utiliser ton code pour tester mon module. Mais y aurait-il un test tout simple, un test "de paillasse", qui distingue celui qui marche des 4 autres ? Car il serait trop beau que l'adaptation du code ne réserve pas aussi des surprises et alors comment savoir !
Si tu as une idée, merci d'avance !


51
Composants / Re : Décodeur sonore Hornby pour locomotives vapeur
« le: janvier 31, 2021, 09:17:29 pm »
Bonsoir,

Ben non, pas d'expérience approchante.
Mais faute d'autre réponse et parce que ça pourra quand même p'être servir (et plaire au petit fils ?), personnellement j'utilise la possibilité offerte par processing de jouer des sons.
Il faut donc un TCO sous processing, quelques conditions dans le code (quel son, quel loco, quelle moment) et les sons qui vont avec. Deux exemples en PJ (pour les voix, j'utilise google translate : il suffit d'écrire le texte voulu et d'enregistrer la lecture vocale)
C'est pas localisé dans la loco mais les possibilités sont infinies et tout ça c'est aussi gratuit que si c'était le père Noël

52

quoique...
un certain "milwind" fait remarquer que la pin XCK qui est en 48  est tout près de la pin de la pin 50 qui, elle, sort sur une broche et qu'il suffit juste d'un petit pont de soudure. Faut oser ! Il a osé.
https://forum.arduino.cc/index.php?topic=257506.0

(Mais pourquoi une PWM de pourrait-elle pas plutôt être utilisée comme signal d'horloge ?)

(et OK j'ai corrigé : je fais confiance à l'analyseur logique à 10 balles de Trimarco)

53
...while/if... le problème ne s'est finalement pas posé. Je pense que ça s'explique par la gamme de (basse) fréquence qui m'intéresse.

Je reviens donc pour déposer le code final : ça va décidément très très vite : avec une fréquence bridée par interruptions à 60Hz vérifiés/oscillo et pour 40PWM, la loop tourne elle à ...160 kHz! (perso, avec un petit réseau école c'est vrai mais toutes les fonctions d'un grand, ma loop prend 6ms... 6 comparé à 160, y'a de la marge ! et je suis d'ailleurs de plus en plus étonné par ce qu'un Arduino Mega a dans le ventre).
D'autres paramètres (prescaler etc) permettraient une plage de fréquence bien plus haute sans étouffer le CPU ; je fais confiance à l'estimation l'analyseur logique à 10balles de Trimarco.
 
Le SPI étant largement susceptible d'avoir d'autres usages que de la PWM logicielle, pour l'exemple le code pilote en parallèle des registres indépendants de ceux de la PWM, par exemple pour les pins de polarisation des boosters, pour des signaux etc.

Juste dommage que tout ça ne puisse marcher qu'à condition de ne pas avoir besoin du (seul) SPI harware pour un bus CAN (et très dommage qu'il manque juste une broche au Mega pour pouvoir en créer un second). Mais un SPI logiciel, même moins véloce, pourra quand même abattre du boulot.

Le code en pièce jointe (encore merci à Trimarco)

Bien cordialement


54
les "while" en effet mais le code ne tourne pas sans. On peut les enlever mais il faut alors ajouter un petit delay avant le latch, 10us au moins. En principe c'est pas très bon mais dans ce cas il y a un petit gain et le résultat égale quasiment des "SPI.transfer". Ce qui offre un choix

Là bien sûr c'est une performance brute avec une loop qui ne fait que ça (même pas vrai car j'ai testé l'ajout d'un second esclave, en prévision d'un "general purpose", rafraîchi toutes les 10ms, et c'est quasiment sans incidence).
Au final, le réglage de la fréquence PMW effective se fera par le timer2 et interruptions, ce qui a marché va resservir !

(Et comment on fait pour vérifier que les transferts sont effectués ?)

55
Bonjour,
moyennant beaucoup-beaucoup d'essais... ayé tout marche !

Je rapporte auparavant quelques grosses surprises notées en cours de route.

- le SPI logiciel... en réalité il est déjà bien rapide !
     en effet, remplacer la boucle :   for (uint8_t cran(0) ; cran<crans ; cran++)
     par   cran=0; //................// if (cran == 127) cran = 0;
     multiplie la vitesse par 10 ! de 130 à 1200 Hz !

- mais bien loin c'est vrai du SPI Harware : 20kHz
     avec la aussi une surprise (c'est confirmé) : chain = chain<<1;   chain = (cran<PWM5[section]) + chain; tourne à 20Mhz
     tandis que  (PWMx[section] >= cran) bitSet(byte_to_spi, section);     n'atteint pas 9Mz  (mais un poil plus haut que bitWrite)

Voici le code, de plus en plus concis, avec ton code exemple à la base. Et avec comme dernière surprise qu'un code plus "Arduino-rustique" et qui utilise SPI.transfer fait légèrement mieux !

/* ARDUINO MEGA */
#include <SPI.h>

#define crans 128

#define SpiControl 0b01110000   //  sur bits: SPIE SPE DORD MSTR CPOL CPHA SPR1 SPR0
#define bDa  2   // MOSI 51
#define bCk  1   // CLK pin 52
#define bLd  0   // SS pin 53


 // pseudos PWM à émuler - pour chaque PWM, le tableau donne le cran entre de 0 à 127
uint8_t PWM1[] = { 0, 0, 0, 0, 0, 100, 0, 00 };
uint8_t PWM2[] = { 0, 0, 0, 0, 0, 0, 10, 0 };
uint8_t PWM3[] = { 54, 26, 107, 96, 111, 82, 125, 2 };
uint8_t PWM4[] = { 54, 27, 108, 97, 112, 83, 126, 3 };
uint8_t PWM5[] = { 54, 28, 109, 98, 113, 84, 127, 4 };

uint8_t cran = 0;
uint32_t count;
uint8_t chain;

void setup() {
  Serial.begin(115200);
  DDRB |= 1<<bLd | 1<<bCk | 1<<bDa ;
  SPCR = SpiControl ;
}

void setSlaveRegisters() {       //Place les pins des 74HC595 à l'état HAUT ou BAS
  cran++;
  bitClear (PORTB,bLd);

  chain = 0 ;
    for (int8_t section(0); section<8; section++) {
      chain = chain<<1;
      chain = (cran<PWM5[section]) + chain;   /* pour mémoire : pin74HC[section]=cran<PWM[section]; */
    }
    SPDR = chain;
    while (!(SPSR & 1<<SPIF)) {}

        chain = 0 ;
          for (int8_t section(0); section<8; section++) {
            chain = chain<<1;
            chain = (cran<PWM4[section]) + chain;
          }
          SPDR = chain;
          while (!(SPSR & 1<<SPIF)) {}

  (...)
 
  chain = 0 ;
    for (int8_t section(0); section<8; section++) {
      chain = chain<<1;
      chain = (cran<PWM1[section]) + chain;
    }
    SPDR = chain;
    while (!(SPSR & 1<<SPIF)) {}

  bitSet (PORTB,bLd);   
  if (cran == crans-1) cran = 0;   
}

void loop() {
    setSlaveRegisters();   
}

20kHz... de quoi faire tourner même les moteurs qui aiment les hautes fréquences ! (avec mes 40Hz optimum constaté,  je reste sur ma faim d'une explication!)

Beau travail non ? Un TRES GRAND MERCI.
Me reste juste à bagoter le latch avec un timer (je reviendrai) et j'aurai plus qu'à dessiner un réseau avec 40 sections !



56
Débuter / Re : Avant de commencer...
« le: janvier 18, 2021, 03:25:01 pm »
Bonjour,

et pour ce qui est de l'alimentation, bien heureusement l'Arduino peut s'alimenter autrement que par l'USB :
à nouveau Locoduino et à nouveau Jean-luc : https://www.locoduino.org/spip.php?article16

Ensuite, l'Arduino ne fournira jamais la puissance au rail.
En analogique (apparemment c'est le cas ?) il modulera un signal, envoyé à un "booster" qui, lui, alimentera les rails.
explication : https://howtomechatronics.com/tutorials/arduino/arduino-dc-motor-control-tutorial-l298n-pwm-h-bridge/

bons amusements

57
Ah oui ! l'essayer c'est l'adopter !
je viens de lancer, ça sort du 10kHz !

J'ai fait des essais de mon côté sur le SPI hardware et je suis très très loin de ça ! (Avec un code qui je dois dire ne ressemble en rien)
Évidemment je vais étudier ça de très près. A première vue, je suis juste surpris de voir un seul SPI.beginTransaction dans le setup (et jamais de endTransaction... qui laisserait la main pour autre chose ?)
Mais en tous cas le résultat brut est là, à moi de l'intégrer (dans tous les sens du terme).

________________   APRES PRISE EN MAIN _______________________

J'ai en effet bien besoin d'aide, merci pour la proposition et c'est fort agréable de savoir qu'il y a une hot-line dédiée!

Après étude de ton code et différents essais, voici ce que je comprends (mais peut-être pas) et ce que je ne comprends pas (et ça c'est certain) :

1 - comprends :
- le code en l'état ne fonctionne pas, c'est un bout de code qui pourrait aider
- sa structure permet de faire du daisy-chainning très simplement (si c'est bien ça, c'est très astucieux)

2 - comprends pas :
- SPI.beginTransaction   dans le setup
- ligne 6 : #define spi_latch_pin 19 // pin19 // PORTB permet l'instruction bitSet
       choisir une autre broche semble tout aussi possible
- ligne 32 : bitClear(PORTB, 0); // pin19 // prépare le latch
             La broche 19 n'est pas sur le port B mais D et il faudrait écrire sur le bit 2 et non 0

- if (PWMx[bit0to7] >= cran) bitSet(byte_to_spi, bit0to7);
   pas plutôt : if (PWMx[bit0to7] < cran) bitSet(byte_to_spi, bit0to7);
   car si le cran dépasse la consigne PWM "bit0to7", ça doit provoquer le falling, non ? C'est en tous cas comme ça que ça fonctionne avec mon code.
   (détail, à propos de "bit0to7" : il me semble que "byte0to7" serait plus exact et facile à comprendre. De plus, pour normaliser et comme en réalité ces datas représentent la PWM
   à appliquer à une section donnée, ça pourrait donc encore plus clairement s'écrire :    if (PWMx[section] < cran) bitSet(byte_to_spi, section);)

3 - comprends pas bien : le choix de bitSet pour construire la trame (voir mes essais)

Pour ma part, voici mes maigres avancées :
- le passage au SPI hardware a un effet très modeste, le gain n'est que d'une 20aine de %
- devant me plier au protocole SPI, j'ai des difficultés à construire la trame. Elle est limitée par le protocole à 32bits ce qui fait que je ne peux pas atteindre les 40PWM "imposées" sans devoir faire du daisy-chainning (ou définir deux esclaves). Mais donc ça se solutionne
Le plus ennuyeux est que la construction de la trame est semble-il ce qui ralentit le code à tel point que le bénéfice du SPI rapide disparaît presque complètement
Voici le nouveau code, avec une syntaxe quasiment normalisé pour que les échanges soient plus faciles.
Dans lequel j'ai essayé deux méthodes pour construire la trame : utiliser des bitWrite est TROIS FOIS moins rapide que l'autre, d'où mon interrogation, plus haut, sur bitSet (que j'ai donc eu l'idée d'essayer, mais il nécessite un "if" et le résultat est encore plus dégradé qu'avec bitWrite)

/* ARDUINO MEGA */
#include <SPI.h>
//#include "SPIDaisyChain.h"

#define crans 128

const int8_t howmany_74HC = 4;
boolean pin74HC[howmany_74HC*8] = { 0 };      // data-table, matching with the state of the 74HC595 ouputs

 // 40 pseudos PWM à émuler - pour chaque PWM, la valeur donne le cran de consigne
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 80, 130, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };   
uint32_t count;
uint32_t chain;

void setup() {
  Serial.begin(115200);

  DDRF |= B00001010;           // A1 & A3 = output
  SPI.begin();
}

void writeSlave1() {        // https://www.arduino.cc/en/Hacking/PinMapping2560
  PORTF &= B11111101;          // PIN A1 (latch) = LOW
  SPI.beginTransaction(SPISettings(16000000, MSBFIRST, SPI_MODE0));
  SPI.transfer(chain);
  SPI.endTransaction();
  PORTF |= B00000010;          // => HIGH
}

void setRegistersSlave1() {       // Place les pins des 74HC595 à l'état HAUT ou BAS
  for (uint8_t cran(0) ; cran<crans ; cran++) {
    chain = 0;
    for(uint8_t section(0) ; section<howmany_74HC*8 ; section++) {
      chain = chain<<1;
      pin74HC[section]=cran<PWM[section];
//      bitWrite(chain, section, pin74HC[section]);
      chain = pin74HC[section] + chain;
    }
  writeSlave1();
  }
}

void loop() {
    setRegistersSlave1();

    count++;
    if (millis() > 3000) {
      Serial.print(count/3);Serial.println("Hz");
      Serial.end();
    }   
}

58
wouah cette fois j'ai compris... le principe !
D'un côté le CPU dont le boulot est d'exécuter le code
de l'autre le hard qui offre des services gratuits... très improductif en effet de s'embêter à les reproduire dans du code !

le timer qui se charge de faire "bagoter" (chez moi ça "commute"... pas la même promo on dirait) plutôt qu'une instruction ça c'est grandiose ! (pas encore mis en œuvre mais va falloir !)
Et pour me documenter sur le SPI "harware" ?  pas besoin de Google... à priori tout est dans la datasheet.

Un grand merci pour cette explication, pour le temps que ça demande obligatoirement. Avec un schéma de plus ! (*)
Pour l'instant, en l'état, ça fonctionne déjà à merveille... au départ c'était "pour voir" mais l'élimination des PCA9685 semble en prime solutionner des problèmes de plantages du bus I2C, c'est bon à signaler au passage puisqu'il y a maintenant des milliers (presque) d'abonnés à cette chaîne !

Juste ça que je n'ai vraiment pas compris : la conclusion (... pas la même promo...)

(* une remarque sur le schéma : les deux sections sur lesquelles les pulses ne montent pas en même temps ne pourront pour le coup jamais être synchronisées ! Mais l'idée passe bien)

A nouveau : merci !

59
Bonsoir,

et merci pour la réponse !

J'avoue que non, tout n'est pas bien clair mais ça tient à moi. Je n'ai par exemple pas idée de ce qu'est un SPI hardware, pas plus que lent ou rapide)

Mais... on est tout de même assez bien synchronisés puisque pour cadencer le SPI des 74HC j'ai utilisé un timer (le 2), avec un réglage de la fréquence PWM par bascule du registre TCNT2
(mais pas en mode CTC... erreur ?

Je joins le code. Que j'ai pu greffer dans mon code principal sans occasionner le moindre souci ni ralentissement. Et avec un cahier des charges respecté :
- 40 PWM possiblement générées
- 125 pas de réglage (avec un talon à 53, valeur empirique personnelle, ce qui donne une plage de réglage effective entre 53 et 178 et par conséquent un pas de réglage plus fin)
Ainsi régulée, la fréquence "shiftPWM" est totalement indépendante du nombre de 74HC pilotés, du moins dans la limite du "cahier des charges" et dans la plage 30Hz-100Hz (et peut-être au delà ?)

Voici le code. Les variables consigne PWM sont fixes et auraient aussi bien pu être déclarées comme constantes... dans la réalité, c'est bien sûr au code de les déterminer en temps réel.
/* ARDUINO MEGA */

const int SS_PIN = 25;     // SS(slaveSelect)/slave - pin 14 (DS / Serial Data Input) on the 74hc595
const int MOSI_PIN = 26;   // MOSI (Master Out Slave Inv- The Master line for sending data to the peripherals) - pin 12 (ST_CP / Storage Register Clock Input (latch)) on the 74hc595
const int MISO_PIN = 29;   // MISO (Master In Slave Out - The Slave line for sending data to the master) - pin 11 (SH_CP / shift register clock input) on the 74hc595

const int8_t number_of_74hc595 = 1;
const int8_t numOfRegisterPins = number_of_74hc595 * 8;
boolean pin74hc[numOfRegisterPins] = { 0 };      // data-table, matching with the state of the 74HC595 ouputs

 // pseudos PWM à simuler - pour chaque PWM, le tableau donne le cran entre 20 et 120
uint8_t PWM[40] = { 54, 64, 105, 94, 70, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };   

byte tcnt = 192; // le timer commute tous les (256-tcnt) cycles
/*
  avec PRESCALER à 32 (TCCR2B = 0b00000011)
  tcnt=126 => 30Hz (les valeurs de tcnt sont empiriques faute de linéarité dans les valeurs de fréquence obtenues)
  tcnt=160 => 40Hz
  tcnt=180 => 50Hz
  tcnt=192 => 60Hz 
  tcnt=208 => 80Hz
  tcnt=218 => 100Hz
*/     
byte cran = 0;

void setup() {
  Serial.begin(115200);

  pinMode(SS_PIN, OUTPUT);
  pinMode(MOSI_PIN, OUTPUT);
  pinMode(MISO_PIN, OUTPUT);

  bitClear (TCCR2A, WGM20); // WGM20 = 0
  bitClear (TCCR2A, WGM21); // WGM21 = 0
  TCCR2B = 0b00000011;
  TIMSK2 = 0b00000001; // Interruption locale autorisée par TOIE2
}

void writeRegisters() {
  PORTA &= ~_BV(PA4);       // pin 26
  for (int8_t i((number_of_74hc595)*8-1) ; i>=0 ; i--) {
      PORTA &= ~_BV(PA7);   // pin 29
      if (pin74hc[i]==0) /*=>*/ PORTA &= ~_BV(PA3);   // pin 25
      else /*=>*/ PORTA |= _BV(PA3);
      PORTA |= _BV(PA7);    // pin 29
    }
  PORTA |= _BV(PA4);
}

void setRegisterPins(byte cran) {  //Place les pins du 74HC595 à l'état HAUT ou BAS
    for(uint8_t engine(0) ; engine<numOfRegisterPins ; engine++) {
      pin74hc[engine] = cran<PWM[engine];
    }
  writeRegisters();
}

ISR(TIMER2_OVF_vect) {
  TCNT2 = tcnt ;
  cran++;
  setRegisterPins(cran);
  if (cran==178) cran=53;
}

void loop() {

/* CODE PRINCIPAL ICI */
}

Le SPI dédié aux 74HC est maintenant sur les broches 26-29 du MEGA... parce que j'utilisais déjà les 50-52  pour le bus CAN et parce que je n'y ai vu aucune différence.
Mais voilà bien une zone d'ombre pour moi qui a résistée à mes questions à Google. Si quelqu'un peut m'indiquer le début de la piste, ça sera apprécié !

(Le Teensy à venir : un 3.5)

60
Aujourd'hui, essais plus sérieux.
En résumé rapide : avec 5 74HC595 en cascade, soient 40 PWM pilotées, la fréquence d'une PWM ajustable sur 100 crans est de 150Hz.
C'est proportionnel : avec un seul, le MEGA fait 730 loop/s.

Je suis impatient de comparer avec ce que fera la Teensy 3.5 que j'attends.
Mais il semble donc que ça puisse être exploitable si des fréquences dans cette gamme peuvent être acceptables ? (et même ??...) et une solution aux problèmes de désynchronisme.

Voici le code d'essai (si des amateurs ont envie de le booster ?)

/* ARDUINO MEGA */
const int SS_PIN = 53;     // SS(slaveSelect)/slave - pin 14 (DS / Serial Data Input) on the 74hc595
//const int SCK_PIN = 52;    // horloge ... inutile ?
const int MOSI_PIN = 51;   // MOSI (Master Out Slave Inv- The Master line for sending data to the peripherals) - pin 12 (ST_CP / Storage Register Clock Input (latch)) on the 74hc595

const int8_t number_of_74hc595 = 1;
const int8_t numOfRegisterPins = number_of_74hc595 * 8;
boolean pin74hc[numOfRegisterPins] = { 0 };

 // pseudos PWM à simuler - pour chaque PWM, le tableau donne le cran entre 20 et 120
uint8_t PWM[40] = { 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0, 54, 64, 105, 94, 109, 34, 73, 0 };   

/*---------------------------------------------------------------------------------------------------------------*/
void setup() {
  Serial.begin(115200);

  pinMode(SS_PIN, OUTPUT);
  pinMode(MOSI_PIN, OUTPUT);

  Serial.println("74HC595 test_vitesse");
}

void writeRegisters() {    // attention : spécifique à l'attribution des 3 PINs du SPI
  PORTA &= ~_BV(PB2);       // pin 51
  for (int8_t i((number_of_74hc595)*8-1) ; i>=0 ; i--) {
      if (pin74hc[i]==0) /*=>*/ PORTA &= ~_BV(PB0);   // pin 53
      else /*=>*/ PORTA |= _BV(PB0);
    }
  PORTA |= _BV(PB2);
}

void setRegisterPins() {  //Place les pins du 74HC595 à l'état HAUT ou BAS
  for (uint8_t i(20) ; i<121 ; i++) {
    for(uint8_t engine(0) ; engine<numOfRegisterPins ; engine++) {
      pin74hc[engine]=i<PWM[engine];
    }
  writeRegisters();
  }
}

void loop() {
    setRegisterPins();
    count++;

    if (millis() > 1000) {
      Serial.print(count);Serial.print("Hz");
      Serial.end();
    }
}


Deux images des pulses : A 50Hz, les créneaux sont bien propres, à 700Hz ça reste correct





à comparer avec une sortie d'un PCA9685 ! (à 40Hz. Ça ne ressemble que de loin à une PWM, pourtant ça marche toujours aussi bien)



En conclusion (provisoire), après avoir branché ces signaux sur les boosters, pas de doute ça fonctionne parfaitement. Différents essais dans la fourchette de fréquence permise par le montage, 50Hz / 700Hz, montrent à nouveau que c'est à 50Hz que la conduite est la plus souple et puissante. A noter aussi que la dégradation en augmentant la fréquence est beaucoup moins forte qu'avec les PCA9685, mais il faut se souvenir que ces derniers sont prévus pour commander des servos à 60Hz.

Pages: 1 2 3 [4] 5 6 ... 8