Show Posts
Pages: 1 2 [3] 4 5 ... 93
31  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 03, 2014, 03:07:27 pm
donc je ne vois pas le souci ;-)
bah je veux bien comprendre, mais moi, j'ai pas été élevé à ça. chaque ligne de code que je pond, j'imagine toujours l'équivalent en assembleur, car le µC, lui, il ne travaille qu'en assembleur. et les histoires de classres, ben va traduire ça en assembleur...

ceci dit, tu m'as apporté une grande aide à mon souci et je t'en remercie. Je ne désespère pas cependant de trouver LA solution : la "compilation conditionnelle".

L'ide arduino tranforme le sketch en pseudo librairie pour un programme "MAIN.C" qui est le même pour tout le monde. donc c'est dans le main.c qu'il peut être possible de faire quelque chose genre #dire que tous les define sont globaux
32  International / Français / Re: Problème USB et surchauffe arduino. on: June 03, 2014, 02:51:00 pm
6 piles de 1,5V = 6 x 1,5 = 9V. si tu mets ces 9V sur la pin 5V, au revoir p'tit nono.

une tite image avec une flèche indiquant le composant qui prend feu serait utile.
33  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 03, 2014, 02:39:59 pm
Une idée en passant: vu que c'est du C++, rien ne t'empêcherait de réécrire la classe pour qu'elle soit en fait un template, ou une série de classes qui prédéfinissent des comportements en assemblant des bouts communs. Le compilateur fera le nettoyage nécessaire pour virer les modules non utilisés.
Je croyais que les gros-mots étaient proscrits sur le forum!

blague à part... en 1997, en BTS, j'étais un champion de l'assembleur (68HC11), mais je faisais l'impasse sur le C, trop "abstrait" pour moi. j'ai décidé de franchir le pas il y a 3 ans, et maintenant, je pense avoir de bonnes bases, mais la notion classes/objets, si je vois bien le truc sur un PC, sur un petit nono, j'en vois pas trop l'utilité (quoique la classe "print" semble permettre le LCD.print...)

Bref...
Quote
Pas de miracle
Mince!

J'y ai pensé, à copier non pas le fichier, mais l'ensemble de la lib (.cpp et .h et tout ce qui va avec) dans le répertoire de mon sketch, mais on perd totalement le bénéfice du #include... et le jour où on apporte une modif primordiale, bah personne n'en profite.(1)

je pensais qu'il y avait moyen de faire de mes "macros" #define des "macros" globales visibles de toutes les libs en include...


(1) : mais ça marche!!!
sketch (test_leonardo.ino) :
Code:
#define LCD_EN_NUM 1          // bit 1
#include "config.h"
config.h :
Code:
#ifdef LCD_EN_NUM
#warning il est là!!!
#endif
console de compilation :
Code:
In file included from test_leonardo.ino:21:
/config.h:4:2: warning: #warning il est là !!!
alors pourquoi j'y arriverais pas avec une lib normale???

EDIT : bah, est-ce qu'on pourrait faire un #include de la lib avec son chemin réel (C:\programm files\Arduino\......) ?
34  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 03, 2014, 01:14:52 pm
Pas con l'idée! mais voilà, il faut que le compilateur vienne chercher le config.h du sketch actuel, car chaque sketch aura alors le sien! Ce qui veut donc dire rajouter l'argument -I à l'appel de avr-g++.exe, via l'IDE... et là, c'est le drame!
35  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 03, 2014, 12:34:06 pm
Certes, mais est-ce que tes #define sont bien lus lors de la compilation de la lib ? S'ils sont dans le sketch, ce ne sera pas le cas.
alors là, tu répondrais à une de mes questions!

J'ai fait un test :

mon sketch :
Code:
#define SUPER_CINCI
#ifdef SUPER_CINCI
#warning ok pour le sketch
#endif
#include <liquidCrystal.h>
et dans la lib :
Code:
#warning Ouverture de la lib
#ifdef SUPER_CINCI
#warning super_cinci est dans la lib!
#endif
Dans la console, je retrouve dans l'ordre :
Code:
sketch.ino : warning : #warning ok pour le sketch
(...)
liquidCrystal.cpp : #warning Ouverture de la lib
donc le #define est bien pris en compte dans le sketch, mais n'est pas accessible à la lib. Pourtant, le header du core arduino.h fait un tas de #define qui se retrouvent ensuite dans les libs!!! j'ai commencé à lire la doc du gcc, mais c'est long!!!

Pourquoi mes #define ne sortent pas du sketch??? y a-t-il une directive particulière à appliquer pour que ça passe? J'ai essayer de passer par un "#include "config.h" (config.h se trouve dans le même répertoire que le sketch, et il n'est pas question de le mettre dans les libs...) qui contient mes #define. Je retrouve bien mes define dans le sketch, mais pas plus loin. et pas moyen de mettre le #include <LiquidCrystal.h> dans le config.h
36  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 02, 2014, 04:20:42 pm
Dans l'idée, c'était de créer / modifier des libs pour utiliser la compilation conditionnelle. En gros, on déclare un certain nombres de paramètres, puis on inclus la lib. sur le papier, c'est très joli, et ça permet de réaliser de grandes choses! Mais ça ne marche pas (j'ai collé des #warning pour voir ce qu'il se passe à la compilation, mais rien). Dommage, j'avais un projet de refaire tout le core arduino sur ce prindipe (en incluant par exemple la déclaration d'utilisation de ressources matérielles et gestion de conflits)...

j'ai googeulé pas mal de trucs, mais le net ne propose que des defs standard du préprocesseur, sans trop s'étendre. Pourtant, sur des trucs comme les µC, ça serait grave utile.

Les libs sont pourtant capables de se passer des variables de préprocesseur, mais dans mon cas, ça passe pas... j'ai essayé d'inverser des trucs, mais toujours rien, pourtant, j'ai bien modifié la bonne lib, celle que j'appelle...

37  International / Français / Re: [LCD] optimisation de la lib liquidCrystal on: June 02, 2014, 03:24:25 pm
Mouais, bon... je viens de m'apercevoir que mes #define dans le sketch ne sont pas pris en compte dans la lib. une idée sur ces préprocessions? ça avait l'air tellement beau... snif!
38  International / Français / Re: Probleme utilisation Atmega 328P-PU on: June 02, 2014, 03:06:59 pm
C'est censé afficher 2 fois le caractère?
oui...

Hyperterminal affiche ce que tu tappes et ce qu'il reçoit, du coup, comme Rx et Tx sont reliés, il reçoit ce que tu tappes, donc tout est en double. Ca prouve au moins que la liaison série fonctionne!
39  International / Français / [LCD] optimisation de la lib liquidCrystal on: June 02, 2014, 12:51:21 pm
Salut à tous.

Sur un petit projet qui fait chauffer mon Léonardo, je me suis rendu compte que la lib liquidCrystal me pourri bien la vie. J'ai donc décidé de m'y mettre, à grands coups de #define pour virer tous ces méchants digitalWrite() qui me donnent des boutons! Dans l'idée, il suffit de bien câbler son nono, puis de faire quelques #define AVANT le #include de la lib (les #define seront pris en compte avant la compilation de la lib) :

Dans le sketch :

Code:
#define LCD_USE_DATA PORTF  // data LCD sur port F
#define LCD_DATA_NUM MSB      // On utilise les bits 4 à 7, LSB pour les bits 0 à 3 et 8BITS pour un fonctionnement en 8 bits
#define LCD_USE_RS PORTF    // RS LCD sur port F
#define LCD_RS_NUM 1          // bit 1
#define LCD_USE_EN PORTD    // EN LCD sur port D
#define LCD_EN_NUM 1          // bit 1
/* R/W non connecté, donc pas besoin de déclarer
#define LCD_USE_RW PORTF   // R/W LCD sur port F
#define LCD_RW_NUM 0          // bit 0  */
#include <LiquidCrystal.h>
Le reste de l'utilisation de la lib reste inchangé, les #define permettent juste d'optimiser la compilation de la lib.

Cette lib, justement, voici un apperçu de mes modifs :

Code:
#ifdef LCD_USE_EN                      // Shorting time for pulse using direct port writing
#define PULSE \
  LCD_USE_EN &= ~(1 << LCD_EN_NUM); \
  delayMicroseconds(1);             \
  LCD_USE_EN |= (1 << LCD_EN_NUM);  \
  delayMicroseconds(1);             \
  LCD_USE_EN &= ~(1 << LCD_EN_NUM); \
  delayMicroseconds(50)   

#else
#define PULSE pulseEnable()
#endif
// --------------- (...) ----------------------


inline void LiquidCrystal::command(uint8_t value) {
#ifdef LCD_USE_RS
  LCD_USE_RS &= ~(1 << LCD_RS_NUM);
  send(value);
#else
  send(value, LOW);
#endif 
}

inline size_t LiquidCrystal::write(uint8_t value) {
#ifdef LCD_USE_RS
  LCD_USE_RS |= (1 << LCD_RS_NUM);
  send(value);
#else
  send(value, HIGH);
#endif 
  return 1; // assume sucess
}

/************ low level data pushing commands **********/

// write either command or data, with automatic 4/8-bit selection
#ifdef LCD_USE_RS
void LiquidCrystal::send(uint8_t value) {
#else
void LiquidCrystal::send(uint8_t value, uint8_t mode) {
  digitalWrite(_rs_pin, mode);
#endif

#ifdef LCD_USE_DATA                   // Using direct port writing
#ifdef LCD_USE_RW                     // Using pin R/W
  LCD_USE_RW &= ~(1 << LCD_RW_NUM);   // R/W = 0
#endif
#ifdef LCD_DATA_NUM
#if LCD_DATA_NUM == "MSB"           // Using MSB 4 bits of the port
  LCD_USE_DATA &= 0x0F;
  LCD_USE_DATA |= (value & 0xF0);  // MSB
  PULSE;
  LCD_USE_DATA &= 0x0F;
  LCD_USE_DATA |= (value << 4);    // LSB
  PULSE;
#elif LCD_DATA_NUM == "LSB"         // Using LSB 4 bits of the port
  LCD_USE_DATA &= 0xF0;
  LCD_USE_DATA |= (value >> 4);    // MSB
  PULSE;
  LCD_USE_DATA &= 0xF0;
  LCD_USE_DATA |= (value & 0xF0);  // LSB
  PULSE;
#elif LCD_DATA_NUM == "8BITS"       // Using 8 bits of the port
  LCD_USE_DATA = value;
  PULSE;
#else
#error Bad LCD_DATA_NUM define. 
#endif 
#else
#error Missing define LCD_DATA_NUM setting.
#endif

#else                                // old lib code so... slowly...

  // if there is a RW pin indicated, set it low to Write
  if (_rw_pin != 255) {
    digitalWrite(_rw_pin, LOW);
  }
  if (_displayfunction & LCD_8BITMODE) {
    write8bits(value);
  } else {
    write4bits(value>>4);
    write4bits(value);
  }
#endif
}

en gros, avec mes #define, le code de la lib devient :

Code:
inline void LiquidCrystal::command(uint8_t value) {
  PORTF &= 0xFD;
  send(value);
}

inline size_t LiquidCrystal::write(uint8_t value) {
  PORTF |= 0x02;
  send(value);
  return 1; // assume sucess
}

/************ low level data pushing commands **********/

// write either command or data, with automatic 4/8-bit selection
void LiquidCrystal::send(uint8_t value) {
  PORTF &= 0x0F;
  PORTF |= (value & 0xF0);  // MSB
  PORTD &= 0xFD;
  delayMicroseconds(1);             
  PORTD |= 0x02; 
  delayMicroseconds(1);             
  PORTD &= 0xFD;
  delayMicroseconds(50)   
  PORTF &= 0x0F;
  PORTF |= (value << 4);    // LSB
  PORTD &= 0xFD;
  delayMicroseconds(1);             
  PORTD |= 0x02; 
  delayMicroseconds(1);             
  PORTD &= 0xFD;
  delayMicroseconds(50)   
}

Pour utiliser cette optimisation, il faut savoir sur quels ports on connecte son LCD, et ça n'a souvent rien à voir avec le numéro des pins de la carte, la léonardo en est un exemple terrible... Ca oblige aussi à utiliser 4 bits consécutifs d'un même port pour les data du LCD, mais je pense que mon code tournera pas loin de 20 fois plus vite que celui d'origine. Ca limite aussi l'utilisation d'un seul LCD, mais qui utilise deux LCD sur un petit nono?

Je n'ai pas modifié l'initialisation qui dure une petite centaine de ms, ce qui me gênait plus, c'est dans le prog lui-même...

Je n'ai pas encore testé à l'upload, mais à la compilation, ça passe. Je vous ai joint le fichier cpp modifié de la lib.

Ce n'est qu'un début, mais je compte bien m'attaquer aux autres libs!

Je prends toutes vos suggestions!
40  International / Français / Re: Plusieurs interrogations (LCD / interruption ect ect) on: May 29, 2014, 01:32:13 am
N'hésite pas à nous mettre ton code, il y a sûrement quelques optimisations qui te rendraient bien service...
41  International / Le bar / Re: Plotter de découpe on: May 27, 2014, 12:43:04 am
Salut,

Je ne connais que deux modèles pour les avoir eus entre les mains :

DR Stica : petite découpeuse qui doit exister en 250 et en 450mm (largeur de coupe), prend peu de place. Orienté débutants.

DGI : modèles pros (j'ai la omega om-130, 2m de largeur) dont les docs sont introuvables..

Côté résolution, on est généralement dans les 400ppcm (1016dpi), c'est sûrement assez pour faire de la précision, mais le vinyle une fois découpé supporte mal des découpes trop fines (très dur à transférer sans perdre des bouts en cours de route). Je le déconseille pour du cms, le temps que tu vas y passer ne vaut pas le coup (prèvoir un achat de matière permière également, c'est un budget...). J'ai passé un temps de ouf à trouver le réglage d'ofset de la lame (différent pour chaque lame bien sûr), et dans le cas d'un petit rond par exemple, si la lame ne revient pas pile à son point de départ, il sera impossible de détourer (enlever) sans en arracher un peu au passage, voire déformer le vinyl. Puis à coller, c'est une autre histoire pour tomber juste, car la colle est... immédiate, toute tentative de replacement déformera le vinyl.

réfléchis bien...
Par contre, pour faire du marquage de boîtiers, ça peut être intéressant...
42  International / Le bar / Re: Marre de la période des TP on: May 25, 2014, 01:53:50 am
On a un champion en ce moment! Ne devrait-on pas créer un topic épinglé genre "Réussir son TPE à base d'arduino" (un titre accrocheur, quoi!) dans lequel on expliquerait qu'on en a gros sur la patate et qu'on n'arrive plus à supporter ceux qui se réveillent trop tard, et que le prochain qui demandera de le lui faire à sa place mangera pour tous les autres?

Surtout que là, notre patience est déjà épuisée depuis longtemps...
43  International / Français / Re: Coucou j'ai un probleme on: May 25, 2014, 01:48:07 am
ça optimise pas trop, vu qu'un boolean est un octet qui vaut 1 ou 0. mais côté lecture, c'est plus clair en effet.
44  International / Français / Re: Mon projet terminale on: May 25, 2014, 01:44:26 am
L'école a bien changé de nos jours... A l'époque, on savait utiliser papier et crayon, et surtout vu le dawa pour reprogrammer une pauvre EPROM (effaçage aux UV, reprogrammation en assembleur etc etc...), ben on savait qu'il vallait mieux être sûr de son coup avant d'envoyer la purée!

De nos jours, c'est tellement facile que plus rien ne marche.

Titiox a une journée chargée aujourd'hui, c'est dommage, mais combien de dimanche a-t-il passé à rien foutre entre la programmation et le couperet de demain? tant pis pour lui, on se réveille pas au dernier moment si on tient un temps soit peu à son avenir.

Allez, tu le sauras pour l'année prochaine, et bon redoublement.
45  International / Français / Re: Coucou j'ai un probleme on: May 25, 2014, 12:55:25 am
Effectivement, il y a un souci de déclaration :

Code:
char Nom[i] = {"Mendiondo", "Dormont", "Millereux"};
Pages: 1 2 [3] 4 5 ... 93