Yep!

Merci pour vos commentaires messieurs  

Pour info, j'ai déjà joué avec des tiny2313 et je possède de longue date le core  

Comme je n'arrive pas à avoir le résultat escompté avec le mode CTC, je suis retourné sous PWM pour valider mes essais.

J'arrive donc à piloter mes servos par ce biais. Par contre, je dois toujours avoir un problème de timing, les servos n'ont pas leur vitesse maxi et on entends les pulsations à l'oreille, c'est donc un peu beaucoup saccadé.

Et un nouveau code, un :

Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>


volatile byte s;
volatile unsigned int servoPulse[8]={3000, 3000, 3000, 3000, 3000, 3000, 3000, 3000};

void _init_();

void setup()
{
  Serial.begin(19200);
  _init_();
}

void loop()
{
  if (Serial.available())
  {
    char value = Serial.read();
    switch(value)
    {
      case 's' : stopPwm(); Serial.println("stop"); break;
      case 'd' : startPwm(); Serial.println("start"); break;
      
      case 'a' : servoPulse[0] = 1800; break; // fast
      case 'z' : servoPulse[0] = 4200; break; // fast
      case 'e' : servoPulse[0] = 3000; break; // stop
      
      case 'f' : servoPulse[0] = 2750; break; // slow
      case 'r' : servoPulse[0] = 3250; break; // slow
      
      case 'w' : servoPulse[1] = 1800; break; // fast
      case 'x' : servoPulse[1] = 4200; break; // fast
      case 'c' : servoPulse[1] = 3000; break; // stop
      
      case 'v' : servoPulse[1] = 2750; break; // slow
      case 'b' : servoPulse[1] = 3250; break; // slow
      
      
      default : break;
    }
  }
  
  servoPulse[0] = 1800;
  servoPulse[1] = 1800;
  _delay_ms(1000);
  servoPulse[0] = 3000;
  servoPulse[1] = 2700;
  _delay_ms(1000);
  servoPulse[0] = 4100;
  servoPulse[1] = 2000;
  _delay_ms(1000);
  
}

void _init_()
{
  
  cli();
  
  TCCR1A = 0;
  TCCR1B = 0;
  
  DDRB |= B00000011; // PB0, PB1 = Servos
   __asm__("nop\n\t");
  
  TCCR1A = (1 << WGM11); // Fast PWM, non invert
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS11); // prescaler = 8
  
  TIMSK1 |= ((1<<OCIE1A) | (1<<TOIE1));
  
  TCNT1 = 0;
  
  ICR1 = 39999; // ((16000000 / 50) / 8) - 1 = 40000 - 1
  OCR1A = 3000; // center position (40000 x 1.5)/20 = 3000
  
  sei();
  
}

ISR(TIMER1_COMPA_vect)
{
   PORTB &= ~( 1 << s);      //Turn off PBx
   s++;                      //Increment Servo Channel
   if (s > 7) s = 0;
   OCR1A = servoPulse[s];      //Update PWM duty for next Servo
}

ISR(TIMER1_OVF_vect)
{
   PORTB |= ( 1 << s);      //Turn on Servo Channel (s)
}

void stopPwm()
{
  TCCR1A = 0x0;
}

void startPwm()
{
  TCCR1A = (1 << WGM11) | (1 << COM1A1);
}

En simplifiant ce code pour un seul servo, çà marche impec 

Code:

ISR(TIMER1_COMPA_vect)
{
  PORTB &= ~(1<<PB0);
}

ISR(TIMER1_OVF_vect)
{
  PORTB |= (1<<PB0);
}

@+

Zoroastre.

[EDIT 1]

Yep!

Ce week-end, j'ai commencé à tester mes servomoteurs avec plus ou moins de réussite.

J'ai donc commencé par un classique, la modul de largeur d'impulsion (pwm) et çà marche pas mal. Mais comme j'aimerais utiliser un attiny2313 comme controlleur, il faut que je puisse utiliser tous les pins disponibles, y compris les non-pwm.

Alors, j'ai cherché sur la toile et j'ai effectivement trouvé des choses, mais en assembleur, et c'est vite devenu pour moi indigeste  

J'effectue mes essais avec 2 servos et un atmega328 (duemilanove). J'utilise pour contrôler mes servos le timer 1 en mode CTC afin de simuler les 50hz indispensables.
Le problème est que le second servo ne réagit pas du tout comme il faudrait (ne tourne que dans un sens avec des ratés de temps à autre, alors que le premier servo est ok) et j'ai l'impression qu'entre la commande (séquentielle) et la pulsation, j'ai un léger décalage temporel qui me fait sauter les pulsations suivantes.

Je pense être dans la bonne direction mais là je sèche sur la méthode pour résoudre ce problème. Un peu d'aide ferait du bien

The code :

Code:

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

#define Wait(T) _delay_ms(T)

volatile unsigned int servo[9] = {1500, 1500, 1500, 1500, 1500, 1500, 1500, 1500, 6000};

//----------------------------------------------------------------

ISR(TIMER1_COMPA_vect)
{
  static byte servo_num;
  
  PORTB = (1 << servo_num);
  OCR1A = servo[servo_num];
  servo_num++;
  if(servo_num > 7) servo_num = 0;
}

ISR(TIMER1_OVF_vect)
{

}

void setup()
{
  _init_();
}

void loop()
{

  servo[0] = 1000;          // servos 0 et 1 gauche
  servo[1] = 1000;
  Wait(2000);                 // marche pas

  servo[0] = 1500;          // servos 0 et 1 centre
  servo[1] = 1500;
  Wait(2000);                // marche pas

  servo[0] = 2000;          // servos 0 et 1 droite
  servo[1] = 2000;
  Wait(2000);                   // marche pas

}

void _init_()
{
  //cli();
  
  TCCR1A = 0;
  TCCR1B = 0;
  
  DDRB |= B00000011; // PB0 et PB1
  __asm__("nop\n\t");
 
  //TCCR1B |= (1 << WGM12) | (1 << CS11);
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS11); // CTC mode 14, prescaler de 8
  TIMSK1 |= (1<<OCIE1A) | (1 << TOIE1); // Overflow et comparateur interrupt
  
  TCNT1 = 0;
  ICR1 = 20000; // 20000 µS = 20 ms = 50 hz
  
  sei();
}

EDIT 1 : 2 précisions, en 1, ce sont des servos 360°, en deux, la fonction _delay_ms ne semble pas fonctionner.

Merci.

@+

Zoroastre.

Yep!

Je te remercie vivement pour le temps passé et tes recomandations  

Mais en préambule je gronde !

Je sais, je sais   J'avais prévenu que c'était le foutoir. Je vais devoir passer quelques heures à tout remettre d'aplomb...

Découplage

Je n'avais pas cette note, et effectivement, j'ai quelques carences au niveau des découplages.
Par contre, je réchigne encore à passer au cms : j'ai l'impression que cela rendrait mon typon moins accéssible.

Masse :

Pour les connecteurs doubles, c'est tout à fait envisageable. Il faut que je valide encore certains choix technologiques et les connecteurs en font partie même si au demeurant, une de mes contraintes est la connectique "stackable".

SDA/SCL  
Suggestion : Un connecteur dédié pour réserver ces pins à cette seule utilisation ?

Là, je suis tout à fait dans ce sens, sur le dessin, j'ai tout regroupé pour plus de facilité et également parce que j'ai aussi pensé avec le matos que j'avais commandé/sous la main.
Il en sera de même d'ailleurs de Vcc et Gnd, et je supprimerais la pinoche XTAL1 sur le second cpu qui est inutile.

Je pense avoir dégrossis le travail pour l'instant. Je vais m'atteler à soigner le découplage et réflechir encore à certaines hypothèses et aux choix à faire.

J'ai remarqué aussi que dans mes écarts entre connectiques, je n'ai pas respecté le pas et rend ainsi la carte impossible à embrocher sur une plaque de test.

Quelques pistes peuvent être mieux dessinées.

Les dimensions actuelles me plaisent bien, mais des fixations seraient un plus. Il faut que je regarde çà aussi.

En tout cas, je te remercie encore et n'hesiterais pas à montrer mes avancées à la communauté dans les prochaines semaines (j'espère pouvoir proposer une version finale pour octobre 2012).

@+

Zoroastre.

Yep!

Merci messieurs pour vos retours

Je dispose effectivement de filtre infrarouge. Je me suis d'ailleurs concocté une petite boite deux compartiments à l'aide de carton noir et chaterton 
Mais j'ai effectué la plupart de mes essais sans !!! à mon tort peut être...

J'ai une autre constatation qui vient plus ou moins confimer d'autres suppositions : J'envoie donc une MLI de 40 Khz avec un duty cycle de 25% afin d'envoyer un max de courant dans la led émettrice, lorsque je fais varié mon cycle à 50%, la detection est carrément meilleur (çà chauffe pas mal et je n'y reste pas longtemps)
J'ai lu quelque part que pour que la sonde infrarouge réagisse correctement, elle doit recevoir au moins trois train d'onde franc.

Je vais donc revoir certain calcul afin de confirmer mes essais sur un cycle à 50%.

Tiens une question comme çà : çà se vend des filtres infrarouges et si oui, sous quelle forme ???

@+

Zoroastre.

Yep!

Je travaille avec 2 versions de kicad, une sur ma linux Debian, l'autre étant une version portable chopée sur PortableApps.com pour windows. Cette dernière version me permet d'avoir kicad sur clé usb partout avec moi

http://portableapps.com/node/30675

L'une ou l'autre râlent aussi de temps en temps, j'ai un peu mis le foutoir dans les librairies 

Pour le temps, ne t'inquiètes pas trop, je suis sur 2/3 trucs en simultanés...et il faut que j'élague sérieusement  

@+

Zoroastre.

Yep!

Les connectiques  à chaque bord sont donc des connecteurs stackables avec deux possibilités, une carte mère en dessous et une carte fille au dessus. C'est comme celà que j'imaginais la chose.

D'ailleurs, j'ai réalisé la carte suite à ce sujet : http://arduino.cc/forum/index.php/topic,111211.msg855128.html#msg855128

Cela serait bien s'il était possible de fixer ton Bi-ATmega644 sur un support.

Oui, les percages pour les fixations, vis manquent cruellement. Je pensais à pourvoir des connectiques vierges afin d'embrocher la carte sur la carte mère. Une solution certe un peu batarde  
Le problème est de choisir entre une fixation globale (x4) ou par moitié (x8) pour le shield et qui ne tombe pas en face de celle de la carte mère, je n'ai pas encore réellement choisi et plus tu sers moins tu as de place  

Je te joins volontiers les fichiers kicad et apprecierais toute aide ou optimisation susceptible d'être apportées

Sur la carte du dessous, j'envisage deux liaisons rs485, une eeprom ainsi qu'une horloge temps réel pour l'instant.
(+ ENC28 si j'ai assez de place)
La carte du dessus serait une shield afin de faciliter la connection de sondes/afficheurs/etc.
(J'utiliserais certainement des plaques à pastilles dans un premier temps.)

REMARQUE sur les fichiers kicad :

 1 - le shematic est bordelique à souhait (pas encore eu le temps de mettre au propre)
 2- J'ai du regrouper les fichiers car sur la fin j'ai exclusivement travailler sur le typon, plus tout à fait dans le repertoire d'origine du projet(sauvegarde +1, sauvegarde +2, etc).

###REGLES DE CONCEPTION###
PISTES : 0.5 mm
VIA : 1.8 mm
PERCAGE : 1 mm
PISTES-- : 0.3 mm

###LISTE MATOS###
atmega644P x2
quartz 20Mhz x1
condensateur 22pF x2
condensateur 100nF x2
résistances 4,7K (appliquées à l'I2C) x2
résistance 10K (appliquée au RESET) x1
connecteurs 8 "stackables" x6
connecteur 6 "stackables" x 4
6 broches ISP
3 broches SCK + cavalier
bornier +/-

@+

Zoroastre.

EDIT1 :

Yep!

Nouveau proto :



Ancien proto en bas, le nouveau plus concis en haut :



Les premiers tests sont bons : blink + com I2C.

Je n'ai pas encore sérigraphié de shield pour l'instant, suite à mes premiers dessin, je me suis rendu compte qu'en serrant trop les connectiques, il devenait difficile de placer des composants sur les cartes filles. J'ai donc écarté les connecteurs stackables afin de laisser un peu plus de place.

@+

Zoroastre.

Yep!

Je relance un peu le sujet car j'ai de serieux doute quant à ma capacité à trouver une solution peu honéreuse et surtout viable en l'occurence.

J'ai donc testé différents matos, diode Ir, photodiode 940 nm, phototransistor Ir, etc.
Et mon montage à base d'AOP semble être extremement sensible aux variations d'intensité lumineuse. Je peux aussi bien obtenir une détection quasi parfaite à 60 cm en journée et obtenir en contre-partie, une détection horrible à moins de 5 cm, la nuit sous une lumière artificielle.

Dans l'optique, et pour rappel, je valide la détection d'un objet en envoyant tout d'abord un signal infra-rouge, je consigne le relevé, je désactive ensuite le signal envoyé, je consigne à nouveau et en déduit ainsi si il s'agit d'une véritable détection infrarouge ou d'une saturation lumineuse.

Je balance prés de 250 mA dans la diode émettrice sous un pwm à 25%. L'ajout d'une diode en série n'influe que trés légerement sur la capacité à détecter l'onde Ir.

J'ai de plus en plus l'impression que la sélection matérielle que j'ai faite n'est pas appropriée ou alors que je me fourvoie dans la possibilité d'obtenir les résultats escomptés dûs à des limitations mécaniques (angle d'attaque, concavité du transparent diode, etc)

Je suis en fait un peu à court d'idée et demande une petite aide afin d'orienter mes experimentations soit dans une meilleur optimisation, soit dans une tout autre direction.

Naturellement, des composants courants, de faible coût demeure ma priorité. Je précise également, que je suis dans l'experimentation totale, mes connaissances dans le domaine des transmissions infrarouge se faisant au fur et à mesure des montages et conclusions que j'en retirent.

My code for the moment :

Code:

#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>

void _init_()
{
  cli();
  
  TCCR1A = 0;
  TCCR1B = 0;
  
  DDRD |= B00000010; // PD5 = Ir input
  DDRB |= B00000011; // PB0 = red led, PB1 = IrLed
  PORTD |= B00100000; // enable pullup
  __asm__("nop\n\t");
  
  TCCR1A = (1 << WGM11) | (1 << COM1A1); // Fast PWM, non invert
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS10); // prescaler = 1
  ICR1 = 420; // ((16000000 / 38000) /1)-1 = 420

  OCR1A = 165; // 420 / 4 to get a 25% duty cycle
  
  PCICR |= (1 << PCIE2); // INT2
  PCMSK2 |= (1 << PCINT21); // PCINT21 = PD5

  sei();
}

void setup()
{
  _init_();
}

void loop()
{
  
}

ISR(PCINT2_vect)
{
  PORTB ^= (1 << 0);
}

Le montage précedant (voir post plus haut) restant valide pour la géneralité.

@+

Zoroastre.

EDIT1 : J'ai, en fouinant, trouvé une alternative interessante : http://letsmakerobots.com/node/26134

[skywodd]

Yep!

Pour info, la version arduino sous Squeeze (Debian stable) est la 022...Je ne sais pas où vous avez vue que la version actuelle était la 018 ???
Ouppss!!! J'ai dû installer la 022  

En testing, la version dispo est la 1.0.1

Sinon, dans l'ensemble de la discution, je rejoins skywodd, certains logiciels peuvent demeurer à la même version pendant prés de deux évolutions du noyau et il n'y a pas d'autre solution que de se taper une compilation dans le pire des cas si on veut une mise à jour ou profiter des upgrade.
En effet, la communauté linux préfère de loin corriger les (nombreux) bugs de Gnome ou Kde que de travailler sur des logiciels tiers, il y a peu d'intervenant en définitive.

Par contre, certaines comparaisons sont un peu fallacieuses, car comparer les depots svn avec ceux de debian est un peu tirer par les cheveux et aller chercher une version "plus à jour" sur un tel depot, c'est aussi prendre le risque d'être confronté à des bugs ou des incohérences entre les librairies et le logiciel lui même.

En gros, sous linux, tu sais ce que tu fais ou tu ne sais pas !!!

Je dis çà mais je ne dis rien  

Perso, la version 022 me convient parfaitement à ce jour.

@+

Zoroastre.

Yep!

Bon, j'ai attaquer dés ce soir les essais de gravure aprés avoir dessiner un truc un peu plus sérieux que la spirale précedente...et go go dans le perclo  

Les pistes les plus fines font 0.3 mm (celles qui passent entre les via au niveau du connecteur ISP) sinon elles avoisinent les 0.5, les via font 1.8 de diamètre et les perçages en règle génerale 1 mm de diamètre.

1ere constatation : Sur l'essai effectué afin de valider le temps d'insolation (7mn sur mon insoleuse à leds), les pistes à 0.3 font bien 0.3.

2eme constatation : Sur la plaque finale, les pistes à 0.3 font moins de 0.3 (peut être 0.2 voire moins). En effet, le perclo avait un peu refroidi et le temps de gravure fût amplement plus important. J'ai donc certainement commençé à bouffer les pistes.

Sinon, dans l'ensemble, du bungard pour la plaque cuivre, du PTX100 de chez Novalith pour le support et des bons produits (CIF) tout neuf à bonne température donnent des résultats trés intéressants.







@+

Zoroastre.

PS : Pour l'imprimante, n'achetez pas EPSON, c'est la seule marque qui refuse d'imprimer sur des transparents. 

[fdufnews]

Yep!

Ok, je comprends mieux. C'est aussi la raison pour laquelle j'étais partis sur un report de signal via un transistor.

je dois avoir quelques LM324 sous la main qui, me semble t'il, sont rail2rail.

Je vais essayer 2/3 configs différentes afin d'accroitre mes connaissances dans le domaine des AOP, domaines que je réchignais clairement à envisager 

Merci pour ces précisions fdufnews

@+

Zoroastre.

Yep!

Merci, j'envisageais egalement de passer sur un montage à hysteresis. Le problème est qu'en mesurant mes tensions de sortie de AOP, j'atteins 3,57 volts, ce qui au vue des lectures que j'ai faite n'est pas normal.
En comparateur simple, je devrais basculer de 0 à 5 volts.

Il y a un truc que je ne pige pas là... 

@+

Zoroastre.

Yep!

Oui ceci fonctionne impec.

Je vais éditer ce post avec mon shema et code complet car je suis en train de mesurer les tensions et en fait, j'ai l'impression de mal saturer mon transistor de signal.

...

EDIT

Code:

#include <avr/io.h>
#include <util/delay.h>

#define Wait(T) _delay_ms(T)

void pause(int y) {
  unsigned int i;
  for (i = 0; i < y; i++) { ; }
}

unsigned char ir;
byte ir1, ir2;

void setup()
{
  Serial.begin(19200);
  Wait(2000);
  
  DDRB = DDRB | B00100100;   // PB2, PB5 = output
  __asm__("nop\n\t");
  
  PORTB |= B00000010;   // PB1 = pull up enable
  __asm__("nop\n\t");
  
  PORTB |= (1 << PB5);
  Wait(1000);
  PORTB &= ~(1 << PB5);
  Wait(500);
  
}

void loop()
{
  PORTB |= (1 << PB2);
  pause(40);
  ir1 = (PINB & 0x2) ? 1 : 0;
  PORTB &= ~(1 << PB2);
  pause(48);
  ir2 = (PINB & 0x2) ? 1 : 0;

  if ((ir1 == 1) & (ir2 == 0))
  {
    Serial.println("detect an objet");
    //PORTB |= (1 << PB5);
  }
  if ((ir1 == 1) & (ir2 == 1))
  {
    Serial.println("saturated");
  }
  
  else
  {
    Serial.println("nothing detected");
    //PORTB &= ~(1 << PB5);
  }
  
  Wait(500);
  
}

@+

Zoroastre.

Yep!

C'est bien ce que je constate, je pensais en faisant le masque que je me retrouverais avec les 2 états logiques de base 0 ou 1. Ce qui somme toute est tout à fait normal !!!

En fait, j'aurais voulu retrouver la simplicité d'un digitalRead et je m'aperçois que j'ai mal traduis/compris les expliquations/tuto trouvés ici ou là...

Merci.

@+

Zoroastre.

Yep!

J'effectue mes tests sur une duemilanove.

Ce que j'ai du mal à comprendre est pourquoi lorsque j'écris :

Code:

ir1 = (PINB & 0x2);

J'obtiens la valeur binaire de l'ensemble et pas uniquement du port correspondant PB1

Normalement :

  Ob00000000
&0b00000010
= 0x0

ou

  Ob00000010
&0b00000010
= 0x2

Sauf que moi j'aimerais testé uniquement le bit 1 si il est à 1 ou 0, ce que je pensais faire en fait...

@+

Zoroastre.