Go Down

Topic: Erreur de programmation [programme simple, mais newbee inside] (Read 4748 times) previous topic - next topic

skywodd


Je sais que tu n'aimes pas trop mes idées, mais pourquoi faire un if sur des valeurs booléennes alors qu'il suffit d'un digitalWrite? je comprends pas du tout ta réaction, car je n'ai fait qu'une équation logique, comme on faisait en première année de BTS. De plus, si tu regardes bien, les sorties dépendent d'entrées mais pas toutes en même temps et pour l'embrayage, c'est assez compliqué. Tu n'as jamais fait d'équations genre "S1 = (!E1 + E2) . E3 + !E4"? c'est exactement ce dont il a besoin ici, et l'utilisation des if devient très compliquée pour résoudre une telle équation et encore moins lisible (à mon sens, à l'école d'il y a 15 ans ou le moindre octet de mémoire valait de l'or, ce qui est un peu le cas de nos arduinos)...

Quand on manipule aisément le langage c on peu se permettre de mettre des équations inline et d'utiliser des astuces pour réduire l'impact mémoire du programme.

Mais ce qu'il ne faut pas oublier :
Quote
Je pense que mon problème vient des remises à zéro des variables, mais je ne maitrise pas suffisamment le langage pour trouver mon erreur.

Quand on débute, la solution la plus simple est souvent la meilleur solution ;)

Une écriture simple, certes inutilement surchargé mais aéré permet de relire son code et trouver une erreur, quand on débute c'est la clef.

Pour ceux qui est de tes idées elle ne me dérange absolument pas ;)
(Au passage regarde un peu le code du "core arduino", si tu est frileux quand aux optimisations mémoire tu devrais apprécier le char buffer[64] de la fonction serial, ou encore la table de correspondance des broche arduino <> registre en progmem de 400octets, et j'en passe ... ;))
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

osaka

#16
Nov 02, 2011, 08:59 pm Last Edit: Nov 02, 2011, 09:10 pm by osaka Reason: 1
C'est surtout à quel moment on peux ce permettre d'optimiser son code, moi je ne le fais qu'une fois qu'il est fonctionnel d'où le mot "optimisé" lol.
Ce type de code ne facilite pas le debug.
Donc pour un débutant je prendrai en exemple le projet de chico, il y a certaine choses que je ne fais pas sous peine de lui compliquer la compréhension du code  :~.
;)

Super_Cinci

C'est ce que je disais : on ne vient pas de la m^me école. J'ai commencé la prog sur 68HC11, avec le bon vieux terminal AIM, tout orange et tout ouvert car ça chauffait grave à 1MHz dedans... Donc avant de toucher les 68HC11, on devait se familiariser avec toute une tripotée de portes logiques, des noircissages de papier, des emmèlements sur les plaques d'essai, voire sur deux plaques... Maintenant, on code sur PC où a mémoire est le dernier des soucis du programmeur. On évitait le test (if) au max, car c'était un risque à faire déborder la pile de 10 octets... Même si j'ai fait l'impasse à ce moment là (heureusement, le sujet du BTS ne comportait pas de micros, ouf!), il me reste des vieux réflexes et ça me va. Je veux bien comprendre qu'aujourd'hui, on n'a plus du tout les mêmes soucis de prog!

Je regarderai le core arduino, oui, car les 450 octets quand on compile "bare minimum", ça me fait mal au cul!

osaka

C'est clair que c'est ici où je vois la différence entre un "électronicien" qui cherchera à optimisé la mémoire, un développeur procédural son temps processeur et un développeur objet les dépendances de code.

n1c0l45

#19
Nov 03, 2011, 09:17 pm Last Edit: May 16, 2012, 09:50 am by n1c0l45 Reason: 1
lol je pensais pas soulever autant de ferveur ;)


j'ai compris la structure mais c'est vrai que les if me semblaient plus... conviviaux ;)

en tous cas, merci de votre aide



skywodd


lol je pensais pas soulever autant de ferveur ;)

C'est le combat perpétuelle entre les différents niveau de programmeur, le programme de "débutant" VS l'optimisation acharné de la mémoire.
Qui n'as jamais regardé avec dégoût un de ces 1er programmes, criblé de bug, avec des choses aberrante et souvent sans test de "sécurité" ;)
C'est dans l'ordre des chose, tu commence sur arduino, tu passe sur du avr-c "pure", puis la curiosité te pousse vers des STM32, PIC, LPCx ou autre micro-contrôleur et à la fin tu reviens aux sources en aidant la communauté arduino :smiley-mr-green:


j'ai compris la structure mais c'est vrai que les if me semblaient plus... conviviaux ;)

Si ça te semble plus conviviale avec des if et bien garde les, c'est toi qui code pas nous ;)
(sa pique quand même les yeux la version sans if :smiley-zipper:, encore avec un peu de bitwise pour pourrir gagner de la mémoire dans une application critique pourquoi pas mais la comme ça :*)
Des news, des tutos et plein de bonnes choses sur http://skyduino.wordpress.com !

osaka

#21
Nov 04, 2011, 02:58 am Last Edit: Nov 04, 2011, 03:17 am by osaka Reason: 1
il y a aussi ce paramètre qui entre en compte, a t'ont réellement besoin d'optimisé la mémoire sur un programme utilisant 100 octet max alors que 2K octet disponible ?
Par contre ici il y a trois chose qui me saute aux yeux :
L'utilisation des if invisibles pas facile de s'y retrouvé: digitalWrite(embra, t_pelle_s1 || t_pelle_s2 || t_beq_sortir || t_benne || t_beq_rentrer || t_peigne || t_monter_lc || t_desc_lc || t_lc_route || t_ouv_peigne);  :smiley-eek: .
L'utilisation de 14 int (2 octet) pour des etats qui n'ont besoin que d'un bit (0 ou 1) donc un byte, char ou boolean aurait suffit et à la limite tu peux même n'utiliser qu'un int,16 bit donc 16 etats ce qui simplifie également le problème des if  plus besoin des conditions multiple, mais bon on peux classer ça dans l'optimisation et difficile à appréhendé pour un débutant.
L'utilisation du core arduino à la place des registres tu pourrais divisé le nombre d'opérations, passé de 27 X le nombre d'instructions de la fonction pinMode() à 3 ou 4 rien que pour l'initialisation et 12X pour digialWrite(), mais à classer également dans l'optimisation.
Enfin vu que fonctionnel apparemment tu peux passer à l'optimisation. :D

Super_Cinci

#22
Nov 04, 2011, 09:54 am Last Edit: Nov 04, 2011, 09:59 am by Super_Cinci Reason: 1
De mon côté, je ne travaille pratiquement qu'avec des données en 8 bits (de rares fois en Word hexa et encore plus rare en INT quand je n'ai pas le choix), puisque le proc tourne en 8 bits. Le core Arduino pousse à travailler en 16 bits (int étant tellement courant dans les exemples, ne serait-ce que pour les pinMode() où un byte suffirait largement), je n'ose même pas imaginer le temps perdu à faire tourner une machine 8 bits en plateforme 16 bits (multiplier au moins par 3 le temps d'exécution...)

Dans mon exemple, j'avais tout déclaré en boolean, mais j'imagine que pour un novice, raisonner en base 2 n'est pas facile, le type INT étant orienté base 10 est plus facile à utiliser. Quand on pense qu'il existe encore des systèmes tournant avec des procs 4 bits cadencés à 1MHz voire moins... dur de faire la transition quand on n'entend plus parler que de PC à 64 bits 4GHz sans limitation de RAM!

Pour moi, le digitalWrite() sans if est tellement plus lisible que j'ai pondu le code comme ça, à chacun sa façon de voir! ;)

Donc au choix :
Code: [Select]

if (_test) {
 digitalWrite(xPin, HIGH);
} else {
 digitalWrite(xPin, LOW);
}

ou
Code: [Select]

digitalWrite(xPin, _test);

Ces deux codes produiront exactement la même chose, l'un est plus léger que l'autre, peu importe pour l'instant! ;)

L'important est de faire attention à ne pas refaire l'erreur du début où une sortie était activée par un test puis désactivée par un autre (car il me semble que pour toute action, il faut aussi activer l'embrayage).

Et ton dernier code, n1c0l45, il marche au fait? car on est quand même là pour ça... :smiley-mr-green:

Go Up