Pages: 1 ... 16 17 [18] 19 20 ... 27   Go Down
Author Topic: Aidez nous ! Projet - Gestion domotique  (Read 56279 times)
0 Members and 1 Guest are viewing this topic.
Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yop yop,
Ai fais le test pour la fonction de la lib crc16 et elle pèse 52octet en mémoire programme.

J'ai également testé et adapté le code pour un module version tiny et j’obtiens 1388 octet, pas testé mais fonctionnel sur mini (1684octet) .

Code:
#include <util/crc16.h>
#include <util/delay.h>
#include <avr/wdt.h>

#define DATA_LENGTH 6
#define ADDRESS 0x11
#define RECEIVER 0x12
#define RE_DE_ON PORTD|=4
#define RE_DE_OFF PORTD&=~(4)
#define RE_DE_REG DDRD |= 4
#define BAUD 115200

#define _WAIT(_pres) _delay_us(_pres)

#define SERIAL_BUFFER_SIZE 10
volatile uint8_t pos = 0;
volatile uint8_t bufferBusRx[SERIAL_BUFFER_SIZE];

volatile uint8_t listener = 0;
volatile uint32_t delayWD = 0;

uint8_t bufferBusTx[DATA_LENGTH] = {0};

volatile uint8_t ack = 0;
uint8_t err = 0;

const uint32_t pres = 69120000/BAUD; //temps de maintien RE_DE
const uint32_t maxRec = 14000000/BAUD; //temps max en reception
const uint32_t maxTrans = (32640000/(BAUD/100))+((ADDRESS*(pres*2))); //temps max de transaction+ temps different entre module selon l'adresse

volatile uint8_t* registreR[3] = {&PINA, &PINB, &PIND}; //tableau pour la gestion semi dynamique des registres (&DDR = &PIN+1, &P0RT= &PIN+2)

uint8_t stateB = 0;
uint32_t delayB = 0;

ISR(USART_RX_vect)
{
  if((UCSRB & (1<<RXB8))) // si bit9 à 1 = adresse
  {
    listener = UDR;
    if(listener == ADDRESS) //s'il sagit de son adresse ou adresse controleur = 0x80 ou si une transaction en cours&& adresse de ack = 0x81  on active l'ecoute
    {
      UCSRA &= ~(1<<MPCM);
      pos = 0;
    }
    else //sinon toute donnees transitant sur le bus seront ignore
    {
      UCSRA |= (1<<MPCM);
    }
   
    delayWD = micros()+maxTrans; //on active un delay max d'occupation du bus quelque soit l'emeteur ou ecouteur
  }
  else //si mode écoute entrante, on enregistre les donnees
  {
    if(pos <= 9)
    {
      bufferBusRx[pos] = UDR;
      ++pos;
    }
    else
    {
      pos = 0;
    }
  }
}


////////////////////////////////////////////////////////////////////////////

void setup()
{
  RE_DE_REG; //pin RE_DE en sortie
  DDRD |= 63;
  begin(BAUD); //init
}

void loop()
{
  if(pos == 9) //si donnees entrente
  {
    readData();
    pos = 0;
  }
  else //sinon on verifie s'il y a des donnee a transmettre dans le buffer
  {
    sendData();
  }
 

  PORTD &= ~(31);
}

uint8_t sendData()
{
  if(bufferBusTx[2] && !listener) // si données à transmettre et que le bus est libre (=0)
  {
    _WAIT(pres); //petite pause de sécurité car même en cas de liberation '0', RE_DE peux encore être maintenu de l'autre côté
    writeData(bufferBusTx); //on envois les données
    ack = 1; //
  }
 
  if(listener && micros() >= delayWD) // si delay de transaction max est dépasse donc erreur, collision, etc
  {
    listener = 0x00;
    ack = 0;
  }
}

void readData() // reception
{
    if(bufferBusRx[0] == 0x02 && bufferBusRx[9] == 0x03) //debut de trame
    {
        if(checkData()) //crc ok, on envoie la commande
        {
          action(0);
        }
        else //sinon on retourne directement un message d'erreur crc à l'envoyeur
        {
         
          ackError(0x02);
        }
    }
    else //sinon on retourne directement un message d'erreur general de reception
    {
      ackError(0x01);
    }
     
}

void action(uint8_t local)
{
    if(bufferBusRx[4]==0x00) // test off
    {
      *(registreR[bufferBusRx[5]]+2) &= ~(bufferBusRx[6]); //PORT &= ~(bit)
    }
    else if(bufferBusRx[4]==0x01) //test on
    {
      *(registreR[bufferBusRx[5]]+2) |= bufferBusRx[6];
    }
   
    uint8_t val = ((*registreR[bufferBusRx[5]])&(bufferBusRx[6])); // pour ack : PIN&BIT
   
    if(local) //s'il sagit d'une commande local on rempli le buffer de transmition
    {
      bufferBusTx[0] = 0x05;
      bufferBusTx[1] = 0x80;
      bufferBusTx[2] = ADDRESS;
      bufferBusTx[3] = 0xFD;
      bufferBusTx[4] = bufferBusRx[5];
      bufferBusTx[5] = val;
    }
    else //sinon on retourne directement un ack de confirmation
    {
      uint8_t data[6];
     
      data[0] = 0x05;
      data[1] = 0x80;
      data[2] = ADDRESS;
      data[3] = 0xFF;
      data[4] = bufferBusRx[5];
      data[5] = val;
      _WAIT(pres);
      writeData(data);
    }
}

void writeData(uint8_t* data)
{
  //calcul du crc en premier
  uint16_t crc = 0xFFFF;
 
  for(uint8_t i=0; i <= data[0]; i++)
  {
    crc = _crc16_update(crc, data[i]);
  }
 
  //active le mode transmition
  RE_DE_ON;
 
  write(data[1], 1); //adressage
  write(0x02, 0); //debut de trame
  for(uint8_t i=0; i <= data[0]; i++) //donnees (suivant la taille specifiée)
  {
    write(data[i], 0);
  }
 
  write(((crc & 0xFF00) >> 8), 0); //crc MSB
  write((crc & 0x00FF), 0); //crc LSB
  write(0x03, 0); //fin de trame
  _WAIT(pres); //delay de maintien
  RE_DE_OFF; // on desacive le mode de transmition
}

uint8_t checkData() //controle crc
{
  uint16_t crc = 0xFFFF;
 
  uint16_t _crc = (bufferBusRx[7]<<8);
  _crc += bufferBusRx[8];
 
  for(uint8_t i=1; i <= bufferBusRx[1]+1; i++)
  {
    crc = _crc16_update(crc, bufferBusRx[i]);   
  }

  if(crc == _crc)
  {
    return 1;
  }
 
  return 0;
}

void ackError(uint8_t ErrorNo)
{
  uint8_t data[5] = {0};
  data[0] = 0x04;
  data[1] = 0x81;
  data[2] = ADDRESS;
  data[3] = 0xFE;
  data[4] = ErrorNo;
  _WAIT(pres);
  writeData(data);
}


void write(uint8_t data, uint8_t txb8)
{
  while (!((UCSRA) & (1 << UDRE)))
    ;
  if(txb8)
  {
    UCSRB |= (1<<TXB8);
  }
  else
  {   
    UCSRB &= ~(1<<TXB8);
  }
  UDR = data;
}

void begin(unsigned long baud)
{
  uint16_t baud_setting;

  UCSRA = 0;
  baud_setting = (F_CPU / 8 / baud - 1) / 2;

  UBRRH = baud_setting >> 8;
  UBRRL = baud_setting;
   
  UCSRB = (1<<RXEN)|(1<<TXEN)|(1<<RXCIE)|(1<<UCSZ2);
  UCSRC = (3<<UCSZ0);
 
  UCSRA |= (1<<MPCM);
}


Logged


0
Offline Offline
God Member
*****
Karma: 2
Posts: 802
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep!

1418 octets pour un tiny2313 (8Mhz). Le transfert Isp se déroule correctement smiley-wink

Par contre, je ne peux pas tester plus avant le code, mon uC est sur un proto de 5x3 cm pour effectuer des tests Pwm pour le taff.
Je suis en train de dessiner sur kicad un autre proto avec 1 Atmega644, 1 ou 2 Attiny2313, des SN75176, I2C et SPI. J'ai besoin d'experimenter les conversations sur plusieurs protocoles, principalement sur l'I2C car je compte m'inspirer des automates modernes (1 tache rapide + 1 tache lente) pour créer un carte biproc à base d'ATmega644.

Merci pour ton code trés bien écrit, il me sera certainement utile smiley-wink

Tu en es où de tes experimentations du Rs485 sur le terrain ?

@+

Zoroastre.
« Last Edit: March 10, 2012, 12:32:56 pm by zoroastre » Logged

Veuillez indiquer [RESOLU] dans l'entête du titre en éditant votre premier message smiley-wink

Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yop yop, sorry pour la réponse tardive je me choppe une petite grippe depuis hier.  smiley-cry

J'ai besoin d'experimenter les conversations sur plusieurs protocoles, principalement sur l'I2C car je compte m'inspirer des automates modernes (1 tache rapide + 1 tache lente) pour créer un carte biproc à base d'ATmega644.

J'aimerai connaître le résultat de tes expérimentations smiley-surprise, compte rendu obligatoire  smiley-mr-green

Merci pour ton code trés bien écrit, il me sera certainement utile smiley-wink

C'est encore un peux brouillon mais je m'approche de la solution final.

Tu en es où de tes experimentations du Rs485 sur le terrain ?

Je suis retourné en half duplex classique, comme ici la communication ne peut être simultanée de toute façons.
Par contre toujours en breadboard et bout de fils pendents smiley-kiss, pas encore testé sur longue distance ou autre, il serait temps que je m'offre un petit fer et composants standard tel que trans, condo, diode, moc, etc, pour aller plus loin.

Par contre tu pourras peut être me renseigné sur la réel différence entre les tiny et atmega, avantage, inconvénient ?
Par exemple ici j'aimerais des module simple e/s, 8 entrées (commande locale par bp ou autre) et 8 sorties correspondante (1 en + pour le bus ce qui fait 17 e/s) donc théoriquement avec mes mini 168 (23 I/O - (2 pour l'uart) - (2 crystal)) ça devrait aller ?
En fait dans les descriptions première des µc je vois 20 I/O (attiny 2313) par exemple (youpie), sauf que 2 pour l'uart, 2 pour le chrystal, etc ... et donc je n'arrive pas à faire au plus juste (ni trop, ni trop peux) ?

J'ai modifier l'image histoire de voir la correspondance registre et non arduino, il n'y a que le bit7 du registre C (pc7 ?) que je ne trouve pas dans le sommaire de la doc.


Entre () je comprend un peux mieux la team arduino d'avoir fais des tableaux de correspondance afin d'avoir un ordre plus "naturel" et instinctif de correspondance pin/registre vu que certain ne comprennent pas automatiquement 8 bit ou utilisé par l'orloge, l'uart, etc,  ...
Pour cette dernière raison je vais abandonné la trame cmd/registre/bit mais plutôt dcmd/sortie_n° .
« Last Edit: March 11, 2012, 04:19:58 pm by osaka » Logged


0
Offline Offline
God Member
*****
Karma: 2
Posts: 802
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep!

Quote from: osaka
Par contre tu pourras peut être me renseigné sur la réel différence entre les tiny et atmega, avantage, inconvénient ?

ATtiny2313, 2048 bytes, DIP20
ATtiny4313, 4096 bytes, DIP20
ATTiny25/45/85 2048, 4096, 8168 bytes, DIP8

Cà c'est pour ceux que je connais. Il y a aussi des modèles CAN bus.

Naturellement, on ne retrouvera pas toutes les fonctionnalités des mega, principalement du côté des ports analogiques, sur les tiny, je n'en connais pas. L'I2C est aussi sacrifié, mais il demeure le TWI, avec donc, des possibilité quand même.
Pour le tiny2313, 18 i/o brutes dont Rx/Tx, 4 Pwm, l'horloge, etc. Quand on fait les comptes, il demeure grosso modo 10/12 i/o. C'est déjà pas mal.

Le principal inconvénient, c'est bien entendu l'absence de port analogique. Pour inclure des capteurs de cette famille, pas le choix faut serialiser à travers un chip ou bidouillé sur les temps de charge/decharge d'une capa.

En ce qui concerne les tiny25/45/85, peut de i/o à la base mais on peut compenser avec des shifts register.

Quote from: osaka
J'aimerai connaître le résultat de tes expérimentations , compte rendu obligatoire
Pas de souci, par contre faudra être patient, j'ai un truc sur le feu pour l'instant smiley-lol

Pour détailler un peu, je compte mettre un afficheur tactile et l'ethernet sur un chip mega644 (taches lentes), quant au second 644, les tâches courantes, gestion des évenements capteurs et envoie des commandes asservies. Le tout en intercommunication.
J'espère avec cette configuration obtenir plus de réactivité sur les interfaces IHM.
Le protocole I2C est utilisé dans des projets tels que core2duino ou core3duino.

Je n'ai pas encore fixé mon choix sur le chip des modules de commandes, l'attiny2313 a ma préference pour l'instant, mais il va falloir que je m'affranchisse de l'analogique et que je palie ce problème.

Je suis plutôt satisfait de ma solution actuelle à base de mega1280 + afficheur tactile + ds18b20 + relais piloté en rs485.
Je crains pourtant en ajoutant l'ethernet et des sondes supplémentaires d'être rapidement saturé en i/o et en vitesse de calcul.
Les avantages que j'entrevois dans ma solution est d'obtenir théoriquement deux fois plus d'entrée/sortie avec la même taille mémoire. (robotique ???)
Le plus chaud sera de partager les tâches équitablement. (l'option du clustering n'est pas loin!)

L'idée de déporter les modules de commandes me plait de plus en plus smiley-wink

@+

Zoroastre.
« Last Edit: March 11, 2012, 05:08:03 pm by zoroastre » Logged

Veuillez indiquer [RESOLU] dans l'entête du titre en éditant votre premier message smiley-wink

Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Merci, je vois mieux la différence entre les deux maintenant.

Quote from: osaka
J'aimerai connaître le résultat de tes expérimentations , compte rendu obligatoire
Pas de souci, par contre faudra être patient, j'ai un truc sur le feu pour l'instant smiley-lol

Pour détailler un peu, je compte mettre un afficheur tactile et l'ethernet sur un chip mega644 (taches lentes), quant au second 644, les tâches courantes, gestion des évenements capteurs et envoie des commandes asservies. Le tout en intercommunication.
J'espère avec cette configuration obtenir plus de réactivité sur les interfaces IHM.

figure toi que si j'ai bien compris, c'est exactement ce à quoi je pense, séparé contrôleur IHM (affichage, eth, ...) et contrôleur événementiel (temp, lum, horaire, ...)
(C'est pour celà que j'ai une adresse spécifique contrôleurs" 0x80" pour les retour et ack des modules, si cette adresse spécifiée, tout les contrôleur écoute c'est qu'il s'agit d'un retour d'état que la commande soit distante ou locale au module).

Je n'ai pas encore fixé mon choix sur le chip des modules de commandes, l'attiny2313 a ma préference pour l'instant, mais il va falloir que je m'affranchisse de l'analogique et que je palie ce problème.

Je suis plutôt satisfait de ma solution actuelle à base de mega1280 + afficheur tactile + ds18b20 + relais piloté en rs485.
Je crains pourtant en ajoutant l'ethernet et des sondes supplémentaires d'être rapidement saturé en i/o et en vitesse de calcul.
Les avantages que j'entrevois dans ma solution est d'obtenir théoriquement deux fois plus d'entrée/sortie avec la même taille mémoire. (robotique ???)
Le plus chaud sera de partager les tâches équitablement. (l'option du clustering n'est pas loin!)

L'idée de déporter les modules de commandes me plait de plus en plus smiley-wink

La conception modulaire me conforte dans l'idée de n'avoir presque aucune limites.  smiley-surprise
« Last Edit: March 11, 2012, 05:47:48 pm by osaka » Logged


0
Offline Offline
God Member
*****
Karma: 2
Posts: 802
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep!

Quote from: osaka
figure toi que si j'ai bien compris, c'est exactement ce à quoi je pense, séparé contrôleur IHM (affichage, eth, ...) et contrôleur événementiel (temp, lum, horaire, ...)

Ouép, on travaille dans la même direction.
C'est aussi une des raisons pour lesquels, je m'interesse beaucoup à tes dernières experimentations smiley-wink

Le protocole I2C est donné pour être plus rapide (100 à 400 khz) que le rs485, certes sur une distance beaucoup beaucoup moins importante. Mais l'essentiel est que ce sont tout deux des protocoles solides avec chacun une mission, celle au voisinage, celle au lointain.

Le proto que je dessine en ce moment réunit la puissance de 2 atmega644 afin de résoudre la séquentialisation des données.
En effet, comment donner la priorité à tel ou tel tâche si le cerveau est unique, l'algorithme devient complexe.
Si on décuple les cerveaux et on leur attribuent des tâches spécifiques mais conjointent, on commence à parler buffer de process, pipe et on aboutit à un système neuronal proche du clustering, avec un algorithme plus simple, un algorithme de fourmie travailleuse. smiley-wink

@+

Zoroastre.
Logged

Veuillez indiquer [RESOLU] dans l'entête du titre en éditant votre premier message smiley-wink

Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yop yop,
J'avais pensé à l'I2C (même au spi, can, ...), mais quelque chose me dérangeais c'est la communication maitre esclaves, pour laisser la parole à chaque esclave il est obligé de les interrogé l'un à la suite de l'autre, c'est un peux faire du "token ring" ?
J'ai vu qu'il y avait moyen de faire du multi-maître et d'entamé une conversation et transaction à la libération de la ligne sur sdl et sca  ?
Enfin finalement je me suis dit que j'allais le réservé pour d'autre choses (par ex: le module rtc 1307, ...), que le rs485 permettait la longue distance, le "Multi-processor Communication Mode" que j'avais envie de testouiller, etc , donc j'ai pas approfondi le bus i2c. (et donc ça tombe bien que tu t'y intéresses  smiley-mr-green).
Concernant la vitesse tout dépend également de ses exigences (à 4ms la transaction ça me donne quand même 250 transaction par sec ) et du code qui traine derrière , comme j'ai eu le cas avec l'ethernet (pourtant à 10Mbps théorique) et les sockets,  on pourrais ce dire que ça rox, be finalement les différents chipotages,traitements (byte->json, etc) et intermédiaires (php qui clôture la transaction à la simple vue d'un 0  smiley-evil ) donnent un résultat catastrophique comparé à ce que j’espérais pour une tel vitesse. (enfin ici c'est les différents chipotage pour rendre le tout compatible qui fout le boxon, faudrait que je remette mon shield, j'ai quelques idée pour pallier ça qui me trotte en tête).  smiley-cry
Dans tout les cas la seule façon d'avoir le meilleur choix c'est de testé et comparé (je compte sur toi  smiley-mr-green).
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?

Le proto que je dessine en ce moment réunit la puissance de 2 atmega644 afin de résoudre la séquentialisation des données.
En effet, comment donner la priorité à tel ou tel tâche si le cerveau est unique, l'algorithme devient complexe.
Si on décuple les cerveaux et on leur attribuent des tâches spécifiques mais conjointent, on commence à parler buffer de process, pipe et on aboutit à un système neuronal proche du clustering, avec un algorithme plus simple, un algorithme de fourmie travailleuse. smiley-wink

On peux ajouter que la mort ou destruction d'un neurone n'empêche pas le cerveau de fonctionné (Je n'y vois que des avantages quand je lis ta description).   smiley-surprise

un algorithme de fourmie travailleuse

Tien ça me donne idée de nom (s'il faut le nommé  smiley-razz)  au système, "antsDomo" la fourmilière au service de votre maison.  smiley-lol
« Last Edit: March 12, 2012, 08:14:40 am by osaka » Logged


Malakoff
Offline Offline
Newbie
*
Karma: 0
Posts: 20
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Premier post pour vous dire...
...
..
.
que vous êtes de grands malades!  smiley-lol

Continuez, personnellement je suis vos avancées avec attention!  smiley-wink
Logged

0
Offline Offline
God Member
*****
Karma: 2
Posts: 802
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep!

Quote from: osaka
J'avais pensé à l'I2C (même au spi, can, ...), ...
J'ai vu qu'il y avait moyen de faire du multi-maître et d'entamé une conversation et transaction à la libération de la ligne sur sdl et sca  ?

Je suis passé par ces étapes de reflexion également, et effectivement le mode multi-maitre fait partie du protocole I2C. Lors de mes recherches, j'ai entrevus quelques solutions arduino et je pense sincèrement que cela est possible.
Les ressources ne sont pourtant pas trés nombreuses et plutôt légères. Il n'y aura, bien sûr, que la pratique qui pourra valider ou pas mes hypothèses. L'experience me tente fortement.

Quote from: osaka
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?
Je m'attendais à ce que le crc soit plus lourd en fait. J'avais regardé les differents algo de contrôle et certain me semblait fort alambiqué. Il faut effectivement voir ce qu'il apporte réellement.

Quote from: osaka
"antsDomo"
smiley-mr-green

Pour le proto, la mise en place des composants ne sera pas trop compliqué, j'ai surtout des problèmes d'esthétique en fait, je  travaille sur une seule couche (compo dips uniquement) et j'essaie d'eviter autant que possible les straps.
Je suis déjà à mon second shema, le premier sur un seul plan, le second sur deux (principe du shield).
Je vais encore tatillonner quelques jours/semaines avant de choisir une solution. J'ai déjà l'essentiel des composants, et j'aimerais autant que possible que le proto soit plus qu'un proto, donc une plateforme pre et/ou définitive.
Le processeur IHM sera donc pourvu de l'ethernet de facto (ENC28J), d'un bus rs232 et rs485. Le processeur evenementiel sera doté de deux bus rs485. Une liaison I2C liera les deux processeurs, une eeprom au milieu.

Je travaille depuis peu avec les registres, cette méthode me parle plus en fait, je suis technicien de maintenance et l'automatisme est mon dada. J'ai par contre tout à apprendre du c++, mais je voyage depuis quelques années d'un language à un autre au grés de mes besoins.

Quote from: Levaillant
vous êtes de grands malades!
Et c'est que le début  smiley-lol

@+

Zoroastre.
« Last Edit: March 12, 2012, 12:39:01 pm by zoroastre » Logged

Veuillez indiquer [RESOLU] dans l'entête du titre en éditant votre premier message smiley-wink

Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote from: osaka
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?
Je m'attendais à ce que le crc soit plus lourd en fait. J'avais regardé les differents algo de contrôle et certain me semblait fort alambiqué. Il faut effectivement voir ce qu'il apporte réellement.

Je m'attendais également à une certaine lourdeur, jusqu'a ce que je tombe lors d'une de mes explorations sur le crc16.h de la lib avr.

Code:
static __inline__ uint16_t
_crc16_update(uint16_t __crc, uint8_t __data)
{
uint8_t __tmp;
uint16_t __ret;

__asm__ __volatile__ (
"eor %A0,%2" "\n\t"
"mov %1,%A0" "\n\t"
"swap %1" "\n\t"
"eor %1,%A0" "\n\t"
"mov __tmp_reg__,%1" "\n\t"
"lsr %1" "\n\t"
"lsr %1" "\n\t"
"eor %1,__tmp_reg__" "\n\t"
"mov __tmp_reg__,%1" "\n\t"
"lsr %1" "\n\t"
"eor %1,__tmp_reg__" "\n\t"
"andi %1,0x07" "\n\t"
"mov __tmp_reg__,%A0" "\n\t"
"mov %A0,%B0" "\n\t"
"lsr %1" "\n\t"
"ror __tmp_reg__" "\n\t"
"ror %1" "\n\t"
"mov %B0,__tmp_reg__" "\n\t"
"eor %A0,%1" "\n\t"
"lsr __tmp_reg__" "\n\t"
"ror %1" "\n\t"
"eor %B0,__tmp_reg__" "\n\t"
"eor %A0,%1"
: "=r" (__ret), "=d" (__tmp)
: "r" (__data), "0" (__crc)
: "r0"
);
return __ret;
}

Ca m'étonne d'ailleurs que ce code ne soit pas plus utilisé, pour le 1wire par exemple ... alors que ...
Code:
_crc_ibutton_update(uint8_t __crc, uint8_t __data)

Pour le proto, la mise en place des composants ne sera pas trop compliqué, j'ai surtout des problèmes d'esthétique en fait, je  travaille sur une seule couche (compo dips uniquement) et j'essaie d'eviter autant que possible les straps.
Je suis déjà à mon second shema, le premier sur un seul plan, le second sur deux (principe du shield).

Pour le module I/O (8/8) je partais sur le principe du 2 couche (shield mais avec mini qui vient ce "broché" par dessus) vu ça taille (30X17) , sinon pour les autre où le mini ne serait pas adapté ça sera comme toi simple couche et dip ,pas question de uno, mega, ... ou la place est loin d'être optimisé à l'utilisation qu'on en ferais (je suppose que c'est également ton but, d'ailleurs il y a des chance que je te copie  smiley-mr-green) .

Je travaille depuis peu avec les registres, cette méthode me parle plus en fait, je suis technicien de maintenance et l'automatisme est mon dada. J'ai par contre tout à apprendre du c++, mais je voyage depuis quelques années d'un language à un autre au grés de mes besoins.
En effet la logique semble plus intuitive pour quelqu'un ayant l'habitude de l'automatisme, l'electropneumatique, hydrau, etc,  industrielle.
Mes premières études (secondaire = college/lycees) étaient dans l'électromécanique (tout du moin avant que je me fasse mettre à la porte de l'école  smiley-small), puis la construction mécanique et métallique et mon meilleur amis qui étais avec moi au cours est technicien de maintenance maintenant (kraft be).
Finalement je regrette d'avoir choisie la voie de l'informatique (dev)  ...
Enfin cette voie je l'ai pas vraiment choisie , c'est suite à une reconversion (graduat= bac+3) après une accident de tuture qui ma foutu les bras en l'air.
Maintenant j'hésite à faire une "petite" formation d'automaticien ou électromécanicien pour quitté le monde des fauteuils de bureau qui ne veulent pas de moi de toute façons.  smiley-mr-green
Pour l'instant je me réfugie sur les µc et la domo des fourmis.

Quote from: Levaillant
vous êtes de grands malades!

C'est pas le début de la fin, c'est la fin du commencement (vers la follie).  smiley-mr-green
« Last Edit: March 12, 2012, 04:41:45 pm by osaka » Logged


Aix en Provence
Offline Offline
Sr. Member
****
Karma: 2
Posts: 264
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Je suis également vos échanges que je trouve très intéressants, mais pour le moment mes préoccupations sont bien plus basiques.

J’espère seulement être en mesure de suivre et contribuer à vos échanges un de ces jours (même lointain).

L’idée d’utiliser plusieurs processeurs pour diverses tâches, peut-être très intéressante, et peut apporter un niveau de sécurité supplémentaire, car un processeur peut de temps en temps surveiller l’autre et réagir en cas de dysfonctionnement.

Logged

Made in Belgium
Offline Offline
God Member
*****
Karma: 1
Posts: 756
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Yop bribri,

J’espère seulement être en mesure de suivre et contribuer à vos échanges un de ces jours (même lointain).

Be tu contribues déjà pas mal, rien qu'avec ton doc très détaillés sur ton cahier des charges et schématisation que j'ai relus plusieurs fois (dans mon fauteuil au coin du feu avec un cigare et un vieux whisky  smiley-lol) car je le trouve intéressant.
Il y a des chose que je ne connais pas,schémas, etc.
 smiley-wink
Logged


Aix en Provence
Offline Offline
Sr. Member
****
Karma: 2
Posts: 264
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

J'ai câblé au propre et testé la plus grande partie de la carte unité de gestion UC.
Elle comporte :
- La carte Arduino Mega 2560
- La carte Ethenet Shield W5100
- La petite carte RTC-DS 1307
- Un afficheur LCD 4x16 caractères
- La connectique pour raccorder la carte d’interfaçage et les interfaces des unités de gestion (chauffage et arrosage)
- Un watchdog (pas encore câblé au propre)

Tous les tests de fonctionnement du matériel sont OK.

J’ai rajouté un watchdog matériel qui se déclenche et remet à zéro la carte Arduino Mega 2560 au bout d’une seconde environ, s’il n’est pas lui-même remis à zéro par le programme.

Je ne sais pas si c’est bien utile, je n’ai pas encore regardé de près le watchdog interne du microcontrôleur (qui doit avoir la même fonction) mais je me suis dit que ce sera une sécurité supplémentaire (et comme j’ai de la place sur la carte et que cela met en œuvre des composants standards que j’avais en stock !)

Que pensez-vous de cette option ?

Je vous joins le schéma de ma carte unité de gestion UC.

J’ai baptisé mon système DOMOWEB 2012

J’attends vos critiques.

* Unité de gestion carte UC.pdf (59.79 KB - downloaded 24 times.)
« Last Edit: March 14, 2012, 04:21:09 pm by Brisebee » Logged

0
Offline Offline
God Member
*****
Karma: 2
Posts: 802
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Yep!

First, tu es sur de ne pas avoir besoin de pwm, parce que là tu les a tous mangé  smiley-lol
L'afficheur peut être piloté avec un shift register ??? (tu ne gagnerais pas grand chose, c'est une question pour la forme)

Le 4060 est bienvenu, en effet le watchdog interne se contente de faire uniquement un reset software, il reprend au setup() si il ne reçoit pas le signal life à temps.
Un watchdog hardware te permettra un reboot complet de la carte en cas de défaillance, c'est une bien meilleur option et tout le monde apportera son crédit à cette solution smiley-wink

(En aparté, Il faut juste faire gaffe à certain péripherique qui ont une option reset propre, mon afficheur tactile par exemple freeze si je lance un reset de l'arduino, un second reset et tout est ok...il faut être prudent avec le timing de certain peripherique.)

EDIT 1 : J'envisage également un watchdog hardware à base de 555.
Je ne connais pas trop le 4060, alors avantages/inconvénients, gestion arduino ???

@+

Zoroastre.
« Last Edit: March 14, 2012, 04:52:07 pm by zoroastre » Logged

Veuillez indiquer [RESOLU] dans l'entête du titre en éditant votre premier message smiley-wink

Aix en Provence
Offline Offline
Sr. Member
****
Karma: 2
Posts: 264
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

tu es sur de ne pas avoir besoin de pwm, parce que là tu les a tous mangé

Non à priori je n'en ai pas besoin => j'en ai gardé une (la 9).

De toute manière j'ai fait mon câblage en wrapping, je pourrais donc modifier si je suis coincé.

Je vais avoir besoin de pas mal d'entrées sorties digitales, car j'ai décidé de reboucler les sorties (signaux directement prélévé sur les actionneurs et adaptés donc 230 VAC en 5 VDC et 24 VAC en 5 VDC) pour pouvoir contrôler l'état des actionneurs même en mode manuel.

Un watchdog hardware te permettra un reboot complet de la carte en cas de défaillance, c'est une bien meilleur option et tout le monde apportera son crédit à cette solution smiley-wink

Cela conforte mon idée, je vais donc le câbler au propre.

Merci
@+
Logged

Pages: 1 ... 16 17 [18] 19 20 ... 27   Go Up
Jump to: