Show Posts
Pages: 1 ... 3 4 [5] 6 7 ... 23
61  International / Français / Re: ordi de bord on: August 08, 2013, 04:10:16 am
pour le calcul des tr/min, j'ai fait ça dans ma gestion de groupe électrogène disponible ici : http://forum.arduino.cc/index.php?topic=125887.120 (voir la dernière version du code) en utilisant un capteur de proximité qui compte des dents sur le volant moteur
62  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 22, 2013, 08:13:51 am
non, je n'ai plus de dispo que la pin digitale prévue pour le bus 1-Wire, et les deux analogiques pour l'I2C, mais comme je veux garder l'i2C pour pouvoir rajouter un LCD et un module RTC... ben voila.
63  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 21, 2013, 01:24:30 pm
en fait j'ai des 1820 montés dans des petits tubes inox étanches, avec un fil de 2m. c'est je trouve bien plus pratique à utiliser que le boitier des 1920. Mais je te remercie pour ta proposition smiley

Mais en fait je suis en train de me dire que le capteur maxim, ça va pas le faire, car il est limité à 100°, et si je colle le machin sur le moteur, il va cramer assez rapidement... je vais plutot voir pour utiliser une PT100 ou un thermocouple avec un circuit I2C qui va bien, peut-être.
Au pire le port 1-Wire, si il ne me sert pas ça me fera toujours une I/O pour faire autrechose.
64  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 20, 2013, 03:06:40 pm
Alors ici, j'ai de disponible sur la carte V3 un port I2C et un port 1-Wire, avec pour but de rajouter des capteurs de températures (1-Wire) pour déterminer si il y a besoin ou pas de préchauffage, et pour adapter les temps de chauffage/refroidissement du moteur.
Et via i2c pour rajouter un afficheur, une horloge pour permettre de programmer des horaires, un datalogger sur carte SD (par exemple un openlog trafiqué pour logger en i2c), etc etc

J'ai aussi une autre entrée interruption inutilisée pour le moment prévue pour mettre une jauge capacitive dans le réservoir.


mais avec 32k de dispo, et un environnement de devel pas spécialement optimisé, c'est un peu tendu. Pour le moment mon code qui ne fait pas grand chose utilise déjà 19k.

pas de port SPI sur ma carte qui permettrait de faire du vrai debug, car l'ai eu besoin des bits pour commander les relais.

pour résumer, la carte V3 a donc :
-port série
-port I2C
-port 1-Wire
-2entrées interruption (une pour le compte-tours, une pour la jauge)
-3entrées logiques (contact de démarrage local, externe, et pression d'huile)
-1entrées analogique (mesure de la tension batterie)
-3sorties relais 25A (contact, préchauffage, démarreur)
-1sortie relais ou PWM avec un PMOS (pour piloter un solénoide de controle du régime)
-3sorties collecteur ouvert NPN (2 pour les leds d'état, 1 pour le relais qui coupe la sortie de la génératrice)
-1relais interne qui assure l'auto-maintien de l'alim de la carte


L'objectif ici est pour le moment d'assurer uniquement la gestion du moteur de la manière la plus automatique possible pour que l'utilisateur n'ait rien à faire. C'est l'onduleur du système solaire qui lui détermine si il y a besoin de recharger les batteries avec le groupe ou non et demande le démarrage (contact sec).
Il peut également demander le soutien du groupe en cas de surcharge ou de surchauffe.
Mais je songe à faire une seconde carte qui s'occupera de la gestion de la charge des batteries, car les possibilités de paramétrage offertes par l'onduleur sont assez limitées.

voila voila
65  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 19, 2013, 11:22:44 am
ciel ! bonjour JS, tu t'es perdu sur ce forum dédié aux "microcontrolleurs d'en bas" ? smiley je serai ravi de profiter de ton expérience en la matière en tout cas smiley smiley

merci pour ta réponse. en effet, j'avais pensé à désactiver l'interruption le temps de calculer la vitesse. Et à vrai dire, je ne sais plus pourquoi je ne l'ai pas fait.
Quoi qu'il en soit, les soucis d'erreurs de mesure énormes du début étaient liés à un bête soucis de tension d'entrée trop basse, à cause d'un pont diviseur foireux. Là ça fonctionne, j'ai toujours des erreurs de temps en temps, mais minimes (de l'ordre de 50à100tr/min) et qui ne gênent en rien le fonctionnement normal, vu que ce n'est pas l'atmega qui fait la régulation de vitesse.

D'ailleurs je viens tout juste de rentrer de l'installation du premier groupe avec cette version du matériel, et quelques correction du soft sur place (parceque forcément, si on part installer un matériel testé, c'est beaucoup moins drôle  smiley-red ) avec un nuit blanche à la clef, mais ça fonctionne.
En plus, aller travailler à 1850m d'altitude dans la montagne, c'est la classe smiley-cool dommage que je n'ai pas eu le temps d'aller aux champignons  smiley-cry

La dernière version (qui marche) de la carte et du soft son disponible ici :
http://sourceforge.net/p/groupe/code/ci/capteur_rota/tarball

Attention toutefois pour la carte, il faut remplacer deux résistances dans les ponts diviseurs des entrées d'interruption par des zeners à 4,6V, je n'ai pas eu le temps de modifier les fichiers kicad.

la carte V3 en place sur le groupe :


un peu de déboggage sur place après une nuit blanche, parceque sinon c'est pas sport :


pas mal la vue depuis la fenetre du bureau quand même !


et finalement la bête à sa place :
66  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 05, 2013, 03:14:38 am
tu n'a pas un 78L05 (ou meme un 7805) pour tester l'entrée comme je l'ai proposé plus haut ?
http://forum.arduino.cc/index.php?topic=125887.msg1302300#msg1302300
ça procure une large fourchette de tension en entrée,  ça coute 20cts et en TO92 ce n'est pas compliqué à implanter

à 500Hz ? je doute fort que ça fonctionne... mais ça mériterait de le tester smiley   mais pour le greffer sur le carte, c'est pas des plus simple. Je vais déja tester avec une zener car ça c'est facile j'ai juste à la mettre à la place de la R37 du pont
67  International / Français / Re: millis() et interruptions on: July 04, 2013, 11:36:27 am
sinon il me semble justement avoir lu que le pas de la fonction micros() est justement de 4µs au mini ...
68  International / Français / Re: millis() et interruptions on: July 04, 2013, 11:30:04 am
@bricofoy
Je pense qu'on ne s'est pas compris je parlais de la macro de l'avr-libc "_delay_us()" et non pas de la fonction arduino.


non, j'ai bien compris, mais c'était pour comparer avec celles de l'arduino, qui finalement fait la même chose, en plus élaboré, vu le commentaire en début qui parle de celle de l'avr-libc
69  International / Réalisations et Projets Finis / Re: Commande automatique de groupe électrogène - machine à états et autres questions on: July 04, 2013, 11:10:27 am
ok, bon avec la mesure de période en µs avec micros(), ça fonctionne très bien jusqu'a 1kHz, soit le double de la vitesse maxi du moteur, j'ai donc de la marge smiley

reste à modifier le câblage de mon entrée, et là par contre c'est merdique, car la tension batterie peut varier de 14,5V (en fonctionnement, alternateur en charge) à moins de 7V (démarreur en fonction par temps froid). Et la tension ne doit pas descendre en sortie de pont en dessous de 3,1V... ce qui n'est pas possible pour ne pas non plus dépasser 5,5V ! 
Donc j'hésite entre laisser le pont, calibré pour arriver à 3,5V avec 7V en entrée, et utiliser les diodes internes à l'atmega pour limiter le voltage lorsque la Ubat remonte, ou remplacer R37 par une zener à 5V.
La zener est-elle préférable ? j'ai lu un peu tout et son contraire dans les topics parlant de limiter une tension d'entrée par une zener...
70  International / Français / Re: millis() et interruptions on: July 04, 2013, 07:44:13 am

Pour autant que je sache, _delay_us() ne dépend d'aucun timer mais se contente d'entrer dans une boucle vide dont le nombre d'itérations est calculé en fonction de la vitesse d'horloge du CPU.

voila le code qui va avec :

Code:
void delay(unsigned long ms)
{
uint16_t start = (uint16_t)micros();

while (ms > 0) {
if (((uint16_t)micros() - start) >= 1000) {
ms--;
start += 1000;
}
}
}

/* Delay for the given number of microseconds.  Assumes a 8 or 16 MHz clock. */
void delayMicroseconds(unsigned int us)
{
// calling avrlib's delay_us() function with low values (e.g. 1 or
// 2 microseconds) gives delays longer than desired.
//delay_us(us);
#if F_CPU >= 20000000L
// for the 20 MHz clock on rare Arduino boards

// for a one-microsecond delay, simply wait 2 cycle and return. The overhead
// of the function call yields a delay of exactly a one microsecond.
__asm__ __volatile__ (
"nop" "\n\t"
"nop"); //just waiting 2 cycle
if (--us == 0)
return;

// the following loop takes a 1/5 of a microsecond (4 cycles)
// per iteration, so execute it five times for each microsecond of
// delay requested.
us = (us<<2) + us; // x5 us

// account for the time taken in the preceeding commands.
us -= 2;

#elif F_CPU >= 16000000L
// for the 16 MHz clock on most Arduino boards

// for a one-microsecond delay, simply return.  the overhead
// of the function call yields a delay of approximately 1 1/8 us.
if (--us == 0)
return;

// the following loop takes a quarter of a microsecond (4 cycles)
// per iteration, so execute it four times for each microsecond of
// delay requested.
us <<= 2;

// account for the time taken in the preceeding commands.
us -= 2;
#else
// for the 8 MHz internal clock on the ATmega168

// for a one- or two-microsecond delay, simply return.  the overhead of
// the function calls takes more than two microseconds.  can't just
// subtract two, since us is unsigned; we'd overflow.
if (--us == 0)
return;
if (--us == 0)
return;

// the following loop takes half of a microsecond (4 cycles)
// per iteration, so execute it twice for each microsecond of
// delay requested.
us <<= 1;
   
// partially compensate for the time taken by the preceeding commands.
// we can't subtract any more than this or we'd overflow w/ small delays.
us--;
#endif

// busy wait
__asm__ __volatile__ (
"1: sbiw %0,1" "\n\t" // 2 cycles
"brne 1b" : "=w" (us) : "0" (us) // 2 cycles
);
}
71  International / Français / Re: millis() et interruptions on: July 04, 2013, 07:39:52 am

tu a vraiment besoin d'avoir cette notion de vitesse circonférentielle quasi instantanée ?
pour un groupe c'est surtout la notion de verif de rotation et de maintien de rotation stable qui est important , pas vraiment de savoir si une dent est passé 1 µs plus vite que la precedente.
selon le module de l'engrenage je mettrais un compteur/diviseur  hard  (genre 74163 ou autre facteur) et je repiquerais simplement une des sorties du diviseur la plus adequate pour l'adapter aux possibilités "arduino"



besoin, non, mais en pratique, la carte est faite, je peux pas vraiment y rajouter un diviseur. Et concrètement sur le groupe, je ne peux compteur que les dents du ventilo, et il y en a 9... à 3000trs/min, ça me donne donc 50Hz x 9 = 450Hz, c'est pas monstrueux non plus, mais enfin...
72  International / Français / Re: millis() et interruptions on: July 04, 2013, 07:37:25 am
bon en fait je viens de trouver le code de millis() et micros() (dans /usr/share/arduino/cores/arduino/wiring.c ), et ben je vais pas lire direct les variables globales smiley-razz y'a pas mal de merdier autour de la lecture, il n'y est sans doute pas pour rien :

u
Code:
nsigned long millis()
{
unsigned long m;
uint8_t oldSREG = SREG;

// disable interrupts while we read timer0_millis or we might get an
// inconsistent value (e.g. in the middle of a write to timer0_millis)
cli();
m = timer0_millis;
SREG = oldSREG;

return m;
}

unsigned long micros() {
unsigned long m;
uint8_t oldSREG = SREG, t;

cli();
m = timer0_overflow_count;
#if defined(TCNT0)
t = TCNT0;
#elif defined(TCNT0L)
t = TCNT0L;
#else
#error TIMER 0 not defined
#endif

 
#ifdef TIFR0
if ((TIFR0 & _BV(TOV0)) && (t < 255))
m++;
#else
if ((TIFR & _BV(TOV0)) && (t < 255))
m++;
#endif

SREG = oldSREG;

return ((m << 8) + t) * (64 / clockCyclesPerMicrosecond());
}
73  International / Français / Re: millis() et interruptions on: July 04, 2013, 07:28:25 am
1/ Les variables globales qui servent à stocker les valeurs utilisées par millis() et micros() sont incrémentées via une interruption générée par l'overflow du Timer0.


ça en fait ça m'interpelle ! variable globale ? donc il y a moyen de gagner du temps en interruption en copiant directement la variable plutôt que d'appeler micros() qui va la lire, puis la renvoyer, non ?
Comment on trouve le nom de ces variables ?
74  International / Français / Re: millis() et interruptions on: July 04, 2013, 07:24:17 am
Mais manifestement j'ai un peu surinterpréter, nous sommes tous d'accord, donc smiley

ce qui ne m'arrange pas, car en fait je me rends compte qu'avec des interruption à 500Hz ou pas loin, je risque de passer pas mal de temps dedans, et de rater pas mal de tops du timer :/
75  International / Français / Re: un petit quizz recup on: July 04, 2013, 07:23:07 am
ha si 1,5cm ça doit commencer à piquer ! tu dois être autour de 20-25kV au feeling...
Pages: 1 ... 3 4 [5] 6 7 ... 23