De l'Arduino au langage C standard avec AVR Studio

[Jack]

Ok merci pour les réponses, mais.... ... *freepicbasic, euh, comment te dire

*freepicbasic, mais je suis content de manquer de connaissances de base, comme ça ca me fait une bonne marge pour progresser, d’ailleurs Pascal aussi l'a bien remarqué si vous relisez tout ce qu'il explique, c'est vrai que je n'ai qu'un bac pro mécanique, je suis pas très intelligent à vrai dire, je ne sort pas de grosses universités.

Je ne pense pas que freepicbasic ait voulu être désobligeant et il s'en expliquera sûrement. J'aimerais bien que la suite de la discussion reste courtoise.

Merci d'avance
-----

[invite2c278084]

la censure a frappé !

[Jack]

la censure a frappé !

oui, et j'assume !

[invitef86a6203]

Désolé si j'ai vexé quelqu'un ce n'est pas mon propos...

La question était sur la vitesse, et elle dépend en partie des types utilisés.

D'ailleurs le fait d'utilisé un int32 pour faire un flag n'est pas forcément mauvais ça dépend du µC et du compilateur.
Que fait le compilateur si l'on fait un Boolean ?
Est ce plus avantageux que d'utilisé un int ou un char ?
Vraiment pas sur !
ça va dépendre du contexte , et comme la question était sur la vitesse.
Parfois il vaux mieux utiliser un char comme flag si l'application nécessite peu de ram et une vitesse optimisée.

La programmation c est pas dogmatique !

C'est juste des remarques de quelqu'un qui a programmé en asm.

D'ailleurs lorsque j'ai appris le C avec la méthode K&R on devait sortir l' .asm et le regarder, afin de savoir ce que le compilateur faisait et si c'était bien optimiser, mais ça se perd les méthodes des papys

K = https://en.wikipedia.org/wiki/Brian_Kernighan (72ans)
&
R = https://en.wikipedia.org/wiki/Dennis_Ritchie (décédé à 70 ans)

[sylvainmahe]

Oui je suis d'accord avec ce que tu dis et je ne remet pas en cause l’expérience des gens bien au contraire, je m'en sert pour avancer, mais pour ceux qui débarquent ici comme moi ou d'autres, je regarde et je lis, je trouve qu'il y a souvent une remise en cause du niveau, enfin ce n'est que mon avis.

J'ai toujours ça d'ouvert pour ma part je trouve le site assez pratique à utiliser:
http://www.nongnu.org/avr-libc/user-manual/modules.html
(http://www.nongnu.org/avr-libc/user-...r__stdint.html)

Je suis d'accord avec toi pour int ou char, bien que le boolean soit un entier 0 ou 1 il me semble, enfin il est codé comme ça en manuel dans les bibliothèques arduino, donc je ne sais pas si à l'époque de la programmation d'arduino ce type était dispo ou quoi mais ils l'on mit en manuel.

Et effectivement que tout dépend des fonctions hardware, j'imagine que traiter une virgule flottante pourrait être super lent et imprécis pour un cpu comme super rapide et précis pour un autre. C'est pour ça que j'ai toujours le datasheet du composant ouvert pour savoir quels bits je dois renseigner à quelle macro avr quand je développe un truc, en plus d'avoir des exemples sur le net car je débute donc je ne comprend pas tout au datasheet, mais comme j'ai constaté parfois un manque de rigueur sur des exemples et bien je préfère vérifier et m'en tenir au datasheet.

J'utilise ou en tout cas je pense utiliser, disons à mon niveau, les types les mieux adaptés, donc je ne pense pas être la personne ciblée, mais j'ai l'impression quand même que sur le forum on s’inquiète beaucoup trop sur la place en mémoire, on voudrait nous faire travailler au bit prêt.
Pour ne donner qu'un exemple, sachez qu'un drone vole avec peut être 1000 lignes dans le main, et disons 1000 autres lignes en fonctions sur une base avr, je l'ai vue pour multiwiicopter, et quelques autres cartes basé sur de l'arduino. Donc à un moment, montrez moi un projet qui boufferait tout un petit atmega, pour l'instant je n'ai rien vu.

Je dis cela tout en sachant que je fait au mieux pour les types, encore une fois je ne pense pas être la personne à cibler, mais au moins, montrez un projet de votre cru, un projet intéressant, et qui met à plat un atmega, on va dire équivalent à ceux les plus utilisé sur des cartes arduino, parce que le sujet initial c'est quand même cela, De l'Arduino au langage C, le titre n'est pas que la pour faire joli, ceux qui viennent ici viennent du monde arduino, (moi j'y est passé 1 semaine, soit...), mais les faits sont la, on est débutant pour la plupart, on vient de l'arduino, et on souhaite aussi voir des projets de gens qui valident leur dires, cela me semble être un minimum cohérent.

[invitef86a6203]

Juste par curiosité regardez ce que contient ce repertoire;
C:\arduino\arduino-1.5.2\hardware\tools\avr\utils \bin

hé bien, ce sont les programmes de base de .... UNIX, j'ai bien dis Unix pas Linux , c est à dire les programmes écrit par l'équipe K&R lors de la création de UNIX en 1969 sur PDP7.
Et le type Boolean existe depuis au moins cette année là ...LOL
Donc c est pas nouveau...

Le compilateur c'est le GCC Open source muti platform et multi processeur.
Il n'est pas réputé pour sa haute performance et il est assez gourmand en code.
Surtout Maintenant avec le C++ .
Manque juste l'interface graphique comme sur Visual studio pour gérer ces objets

Le fait d'utiliser des library toutes faites pour gagner du temps de développement se paie en taille de programme !

Actuellement je fais une appli avec un Arduino Uno (Tout le monde veut de l'Arduino)
Le compilateur me dit 20k sur 32K utilisables, je commence à me demander si ça va passer et la RAM je n'ose pas regarder....
Comme le code générer ... (bon ça fonctionne , on fait confiance)
On développe comme sur une grosse machine, et ça va vite avec les library , mais la même appli en assembleur aurait pris moins de 4K , mais avec un temps de développement gagner , on pourrait dire proportionnellement inverse à la taille perdu LOL

Le prog 5 fois plus grand et le développement 5 fois plus rapide.


A l'époque ou Apple faisait sa première carte PC,
Rockwell a sortis une carte avec un 6502 il y avait
-un monitor 4K
-un assembleur 4K
-un basic 8K
-4k de Ram
j'avais glorieusement fabriqué une carte 16k ram
Le tout gérait un clavier une imprimante un afficheur un port série un cassette...
Je ne pense pas pouvoir faire tout ça an compilant avec GCC...

Mais il faut être réaliste les µC progressent, et on la puissance d'un apple II voire plus, dans une puce avec le ATMEGA2560 par exemple...
Alors ça explique l'utilisation du C.

[sylvainmahe]

Je comprend ce que tu dis, tu a vécu à une certaine époque, l'époque des quelques k de mémoire pour développer des programmes, une époque ou les gens étaient forcément plus proche du matériel, plus proche de la logique interne du composant, etc... mais peut être une époque également ou les gens mettaient trois plombes à développer un programme qu'on fait sans doute plus facilement et plus rapidement aujourd'hui.

Arduino est gros d'un certain point de vue, comme il a souvent été évoqué dans ce forum, cette bibliothèque permet de tout faire, et prend en compte les micro-contrôlleurs les plus utilisés d'atmel, donc forcément, il y a beaucoup de lignes inutiles dans le code.

Personnellement je fait une bibliothèque pour le 328p, car c'est ce que je possède, venant de arduino, mais elle est très facilement transposable aux autres micro-contrôlleurs d'atmel d'après ce que je vois dans les fichiers d'arduino, il suffit de changer quelques macros, quelques noms de port, et hop...
Quand je fait "maLed.on();", il n'y a que "PORTB |= (1 << pin);" derrière, mise à part quelques if de vérification. Je ne pense pas que ce soit lourdingue, et on reste dans le sujet initial, "De l'Arduino au langage C standard avec AVR Studio", même si pour mon cas c'est plus "De l'Arduino au langage C++ standard avec AVR sur linux".

Si vraiment des personnes veulent programmer directement en assembleur, nous allons créer un autre sujet parallèle dans ce cas: "De l'Arduino à l'assembleur..".
Enfin ce n'est que mon avis encore une fois, mais il est clair que je n'ai pas envie d'écrire des tas de ligne d'assembleur pour mettre à 90° le palonnier de servo de mon robot, j'ai plutôt envie de faire "monServo.angle (90);".

...Autre sujet, sans même parler d'espace mémoire forcément mais, quelle est l'appli que tu fait? Cela m'intéresse de voir des projets


Pour ma part, j'avance aussi, j'ai enfin testé mon tube sbm-20 russe, ça fonctionne très bien



Pour l'instant j'ai finalisé ça dans ma bibliothèque pour le 328p:
Switch.h (pour gérer tous les boutons et divers interrupteurs)
Led.h (pour allumer les leds)
LedDisplay.h (pour afficher des nombres sur des 7 segs via max72**)
Timer.h (pour récupérer les ms avec timer0)
Interrupt.h (pour les interruptions externes)
Random.h (pour automatiser le seed et la récupération de valeurs random via des valeur min max)
Iteration.h (pour itérer des variables de façon un peu plus complexe qu'un simple ++ ou --, définition de valeurs min max, boucles d'itération, etc...)

Selon moi il reste à faire pour les applications les plus courantes:
Buzzer.h (pour des bruits ou de la musique)
Potentiometer.h (lire un potentiomètre)
Servo.h (pour gérer les servos et les esc)
LedMatrix.h (pour afficher sur des matrices de led)
Gyroscope.h (pour lire les valeurs des gyros avec I2C)
Receiver.h (pour lire un pwm d'un récepteur, le write étant Servo.h)
Eeprom.h (pour retenir en mémoire des valeurs)

Peut être il pourrait y avoir, Sensor.h par exemple, mais ça revient certainement un peu à lire un gyroscope avec i2c, ou pour des capteurs vraiment très basiques, à lire la valeur d'un potentiomètre.
Sans oublier aussi de faire LCDScreen.h Mais ce sera pour plus tard, je n'en vois pas l'utilisation pour l'instant dans des systèmes embarqués.

Après on peut toujours programmer EnvoyerFuseeSurLaLune.h, mais ça n'a plus de sens dans ce cas, je souhaite rester dans quelque chose de très simple, en mâchant juste le travail de base

[Biname]

Salut,

Juste par curiosité regardez ce que contient ce repertoire;
C:\arduino\arduino-1.5.2\hardware\tools\avr\utils \bin
Le fait d'utiliser des library toutes faites pour gagner du temps de développement se paie en taille de programme !
Actuellement je fais une appli avec un Arduino Uno (Tout le monde veut de l'Arduino)
Le compilateur me dit 20k sur 32K utilisables, je commence à me demander si ça va passer et la RAM je n'ose pas regarder....
Comme le code générer ... (bon ça fonctionne , on fait confiance)
On développe comme sur une grosse machine, et ça va vite avec les library , mais la même appli en assembleur aurait pris moins de 4K , mais avec un temps de développement gagner , on pourrait dire proportionnellement inverse à la taille perdu LOL

Je suppose que tout le monde ici le sait, on peut uploader sur un Arduino tous les codes pour AVR/ATMEL générés par tous les compilateurs AVR/ATMEL (.Hex) disponibles. Le bootloader est un bootloader et rien de plus. Les limitations Arduino sont dans l'IDE Arduino et pas dans le bootloader. Pour cela, le software XLoader simplifie beaucoup les choses pour ceux qui ont perdu le goût des paramètres passés en ligne de commande.

Voici un petit code blink Great Cow Basic (pic et avr) qui tourne parfaitement sur un 'Pro Mini 328p' chinois

#chip mega328p, 16
#define LED portb.5
dir LED out
LED=1

start:
    LED=0
    wait 500 ms
    LED=1
    wait 500 ms
    goto Start

L'IDE Arduino n'est pas la seule à offrir des librairies.

Biname

[sylvainmahe]

C'est certainement très intéressant, mais on était dans l'assembleur, et nous voila rendu maintenant dans du basic http://www.greatcowbasic.com/.
On peut sortir clairement tout les exemples possibles avec tous les langages du monde, et toutes les bibliothèques du monde, mais ça ne servira à rien puisque les gens qui arrivent sur ce sujet souhaitent programmer en C !

C'est pareil avec ma bibliothèque ton code donne ça, ce qui est encore plus simple:

#include "Led.h"

int main()
{
	Led led = Led(13);
	
	while(1)
	{
		led.toggle();
		_delay_ms(500);
	}
	
	return 0;
}

Mais j'ai envie de dire, ça ne nous avance pas plus Ça nous montre juste qu'il existe une bibliothèque Great Cow Basic (pic et avr) comme ça nous montre juste qu'il existe une bibliothèque sylvain C++ (avr)...

Ou bien j'ai rien compris, possible, mais je pense être dans la même situation que toi, aillant aussi en test un 328p sans bootloader de chez e44, un magasin d’électronique du coin, donc du pur chinois à priori

[invitef86a6203]

Sylvain>
Au sujet de la compatibilité Atmel je dois reconnaitre qu'elle est meilleur que sur Pic.
Quand j'ai voulu remplacer un pic16F977 par un Pic18F448 , bien que le pinning soit identique le processeur malgré les instructions de base communes, les µc étaient vraiment différent... (mauvais souvenir)

Pour les tube russes, j'ai déjà testé 2 types
1) Le SI3BB très peu sensible vers 400V (tension de plateau) Plus sensible vers 800V mais comme ce n'est plus le plateau d'un tube à l'autre ça varie énormément, et sincèrement pas très concluant...
2) Le 29-BG très bonne sensibilité, d'après la doc autant que le grand SBM20 et surtout plus petit.

J'ai tout de même eu l'impression qu'il s'agissait de tube réformés, les coups parfois sont multiples comme des rebonds.




Au sujet des bibliothèques,'esprit Arduino c est l'open source, j'espère que tes modules une fois terminés et testés seront sur le net.

En ce moment je testais le module 10DOF Adafruit;
http://www.adafruit.com/product/1604
Les softs indépendant fonctionnait , mais le module qui intégrait toutes le fonctions ne passait pas à la compile.
A ce demander s'ils avaient compilé sur un autre compilo que l'Arduino.
ça a fini par fonctionner avec du mal...
Et là je m'aperçois que le Gyro Hard est bloqué en accéléromètre par une pin qui est reliée à la masse et que le gyro est en fait soft par calcul avec le magnétomètre, grrrr...
(pin DEN du L3GD20)

[invitef86a6203]

J'ai reçu récemment une carte avec un Atmega2560 .
Premier essai ,pas moyen de le faire fonctionner , problème de driver.
Après un tour sur le net plusieurs site parle du CH341, une fois le driver chargé , tout est redevenu fonctionnel.
Il y a tout de même un truc a testé le quartz est de 12Mhz alors que normalement il est de 16Mhz, à voir ce que sa va avoir comme conséquence.

L'Arduino est reconnu comme un port série par le PC !
L'orsqu'on les connectent , il ne le met pas toujours sur le même port, et les nouveaux demande l'installe du driver, et il le fait sans problème.
Je n'ai pas encore identifier la raison, est ce les chips qui sont différent?

Sur le uno le Atmega16u2 gère la comme USB et communique avec le 328 à travers le port série.
Le même port série qui est sur le connecteur (RX-TX).

Sur le schéma. La sortie du 16U2 ver le 328 passe à travers une 1K !
Si l'on connecte directement un port série TTL sur ces pins le port en mode Loader ne fonctionne plus.
Je pense qu'il faudra mettre une 1K entre les pins RS du 328 et les pins externes d'un bluetooth par exemple, pour que les 2 fonctionnent ensembles.

[sylvainmahe]

Merci pour les renseignements freepicbasic, j'avais pas mal regardé les caractéristiques alpha beta gamma des tubes avec les dead-time, mon idée étant peut être de combiner un sensible beta gamma et un sensible alpha beta, je verrais si ça se fait comme ça ou non. La je fait des tests avec le sbm20, je verrais ensuite.
C'est vrai que les rebons ou encore le dead time ne permet sans doute pas une mesure fiable près du corium de techernobil au niveau des sous sols, mais je pense qu'en condition d'utilisation plus soft ça doit donner une bonne approximation, tout en sachant bien sûr que ce ne sera qu'une approximation, comme pour n'importe quel appareil du commerce qui ne serait pas un spectromètre, mais ça donne toujours un bon ordre d'idée je pense.

Pour ma mini bibliothèque, évidement elle sera sur internet, je n'utilise pas de l'open source linux pour rien

Par cool pour la carte de chez adafruit, ils sont comique quand même d'utiliser le magnétomètre pour calculer le reste, ça doit être précis...
Pourquoi ne pas prendre un bon vieux mpu6050 utilisé un peu partout?
13 euros dans une boutique allemande, c'est encore moins chère que chez adafruit:
http://flyduino.net/MPU6050-Break-Out-onboard-33V-reg_1

Il est super précis:
http://vimeo.com/88592935
La carte naze32 à bord est une base arduino avec le mpu6050.

[sylvainmahe]

Des questions dans ton deuxième post, mais je n'ai pas les réponses
En regardant la on trouve des choses peut être intéressantes: http://forum.arduino.cc/index.php?topic=261375.0

[sylvainmahe]

J'ai enfin compris analog read, c'était tout con (pour 328p):

#include <avr/io.h>

int main()
{
	uint8_t pin = 1; //Analogique 0
	
	ADCSRA = (1 << ADEN) | (1 << ADPS0) | (1 << ADPS1) | (1 << ADPS2);
	
	ADMUX = pin + 191;
	ADCSRA = (1 << ADSC);
	//ADC contient la tension 0/5v de la pin 1 (ADC0) sous la forme 0 à 1023
	
	return 0;
}

On peut le faire avec des interruptions aussi...

J'ai des questions sinon pour les timers, je comprend comment créer une interruption toutes les 1ms, toutes les 250micro secondes également, mais j'aimerais descendre plus bas, voila mon code:

volatile uint32_t Timer::ms = 0;

ISR (TIMER0_COMPA_vect, ISR_BLOCK)
{
	Timer::ms++;
}

void Timer::start()
{
	TCCR0A |= (1 << WGM01);
	TCCR0B |= (1 << CS00) | (1 << CS01);
	OCR0A = 249;
	TIMSK0 |= (1 << OCIE0A);
	
	sei();
}

Cette fois ci même avec le datasheet tous les tests que je fait ne fonctionnent pas bien, pourtant j'ai l'impression de bien renseigner pour le prescaler etc... Mais je ne suis pas sûr qu'on peut descendre en dessous. Mon but est de créer une interruption toutes les 0,00005s pour pouvoir faire fonctionner des buzzers et divers haut parleurs jusqu'à 20khz, la limite audible (et la norme des casques audio 20 à 20khz).

Je ne sais pas si vous avez une idée de comment faire?

[invitef86a6203]

Il y a des library sur le net

https://code.google.com/p/arduino-ti...9.zip&can=2&q=


C est du CPP avec une class 'Lourdingue" , comme d'hab... , (du genre je sers à tout faire et je prend un max de place.)
Mais bon, tu peux virer tout ce qui est inutile

Regarde la fonction "setPeriod" il calcul le prescaler en fonction du temps demandé par le main.
TimerOneV9 semble moins chargé

[invitef86a6203]

Au sujet de GCBASIC je trouve que c est intéressant , notamment pour programmer le pic car le GCC n'est pas du tout approprier pour les petit pic qui n'ont pas de pile et on une RAM ridicule.

J'ai déjà contacté EVAN je vais surement essayer de faire avancer le schmillblick dès que j'aurais un moment.

J'ai déjà commencer 2 cartes "Arduino style" avec un Pic16F876 et un shield qui comprend quelques périphériques, carte au format Arduino donc au point de vu Hard full compatible.
voir photos et implant

[sylvainmahe]

Pas mal ! Elles vont servir à un projet en particulier tes cartes ou à pleins de choses que tu prévois de faire?
Les caractéristiques du pic sont sympa, quel seraient les avantages par rapport à des atmega, le prix? http://www.futurlec.com/Microchip/PIC16F876.shtml

Sinon merci pour la bibliothèque, c'est codé pas super, je ne comprend pas comment des gens peuvent balancer ça sur le net sans mettre ça nickel chrome, m'enfin, faut croire que tout le monde ne partage pas nos soucis, du détail
Bon pour l'instant ça ne donne rien, j'ai pourtant décortiqué sa chose, mais je vais y arriver, y a pas de raisons

[sylvainmahe]

J'en arrive à ça sans que ça ne donne une valeur correcte:

volatile uint32_t Timer::micros = 0;

ISR (TIMER1_OVF_vect, ISR_BLOCK)
{
	Timer::micros++;
}

void Timer::start()
{
	TCCR1B |= (1 << WGM13) | (1 << CS12);
	TIMSK1 |= (1 << TOIE1);
	
	sei();
}

En gros, quand 1 seconde se passe, ce compteur retourne 655350, il y a une logique derrière tout ça , et je n'est pas envie de faire une division dans la méthode ISR, surtout que j'ai vu que des opérations mathématiques un peu plus compliqué qu'une simple incrémentation dans ISR faisait ramer le microcontrôleur, donc j'aimerais comprendre ce qui cloche

[Jack]

Je n'ai pas bien compris où se situe le problème.

[sylvainmahe]

J'avais pas bien compris les timers, voila qui est mieux

Retourne les microsecondes (interruption à 1000000 Hz):

ISR (TIMER1_COMPA_vect, ISR_BLOCK)
{
	Timer::us++;
}

void Timer::start()
{
	TCCR1B |= (1 << WGM12) | (1 << CS11); // OU TCCR1B |= (1 << WGM12) | (1 << CS10);
	TIMSK1 |= (1 << OCIE1A);
	OCR1A = 2; // OU OCR1A = 16;
	
	sei();
}

Retourne les millisecondes (interruption à 1000 Hz):

ISR (TIMER1_COMPA_vect, ISR_BLOCK)
{
	Timer::ms++;
}

void Timer::start()
{
	TCCR1B |= (1 << WGM12) | (1 << CS10) | (1 << CS11); //OU TCCR1B |= (1 << WGM12) | (1 << CS10);
	TIMSK1 |= (1 << OCIE1A);
	OCR1A = 250; //OU OCR1A = 16000;
	
	sei();
}

Retourne les secondes (interruption à 1 Hz):

ISR (TIMER1_COMPA_vect, ISR_BLOCK)
{
	Timer::s++;
}

void Timer::start()
{
	TCCR1B |= (1 << WGM12) | (1 << CS10) | (1 << CS12); //OU TCCR1B |= (1 << WGM12) | (1 << CS10);
	TIMSK1 |= (1 << OCIE1A);
	OCR1A = 15625; //OU OCR1A = 16000000;
	
	sei();
}

Exemple de calcul:
Fréquence d'interruption désirée: 1 Hz
Fréquence de fonctionnement du micro-contrôleur: 16000000 Hz
Prescaler: 1024

Calcul: ((1 / Fréquence d'interruption désirée) / (1 / Fréquence de fonctionnement du micro-contrôleur)) / Prescaler = 15625 = Valeur à renseigner au registre OCR


Finalement logique mais je ne m'étais pas penché sur la question, et sur internet on trouve vraiment tout et n'importe quoi comme exemples, c'est assez hallucinant d’ailleurs le bordel que c'est pour trouver des infos fiables, personne n'est fichu d'aligner ça sur une page comme ceci

Au moins la, c'est clair et net pour le débutant à priori

[Jack]

Au moins la, c'est clair et net pour le débutant à priori

OCR1A = 15625; //OU OCR1A = 16000000;

Pourquoi cette 2ème valeur pour OCR1A?

[invite936c567e]

Finalement logique mais je ne m'étais pas penché sur la question, et sur internet on trouve vraiment tout et n'importe quoi comme exemples, c'est assez hallucinant d’ailleurs le bordel que c'est pour trouver des infos fiables, personne n'est fichu d'aligner ça sur une page comme ceci

Au risque de me répéter, il ne sert à rien de se lancer dans des expérimentations pour faire des découvertes et s'en étonner, alors qu'il suffit d'aller lire les informations à la source, et de les appliquer dans une démarche correcte de conception (besoin exprimé ⇒ choix fonctionnel ⇒ choix technique, et pas l'inverse). Il aurait fallu "se pencher sur la question" avant de commencer à coder.

Et si "personne n'est fichu d'aligner ça sur une page comme ceci", c'est juste parce que personne ne perd son temps à réécrire ce que le constructeur du microcontrôleur a déjà expliqué dans ses documents de référence. La datasheet et les notes d'application sont les premières choses à lire, avant même de choisir et d'utiliser un composant pour son application, à plus forte raison avant de commencer le développement du logiciel.

[sylvainmahe]

Jack -> c'est pour expliquer une autre façon de faire la même chose avec un prescaler différent mais moins adapté:
//OU TCCR1B |= (1 << WGM12) | (1 << CS10);
//OU OCR1A = 16000;

Je trouve qu'on comprend toute de suite avec:
16000000
16000
16
tout en sachant que le quartz est 16 mhz


Je trouve que la lecture du datasheet pour les débutants comme moi, sans exemples, est un document complexe ! Oui, il est COMPLEXE, même si effectivement de savoir qu'il existe des gens qui ne le comprennent pas bien sur la planète terre, t’emmerde profondément ! 450 pages c'est quand même l'équivalent d'un livre qu'on ne lit pas si rapidement que cela.

Je m'en fiche complètement de l'ordre des choses, le composant il est fait pour ce que je projette de faire au vue de ses caractéristiques, et parce qu'il est utilisé en masse pour faire bons nombre de choses qui moi m'intéressent et que je prévois de faire, robots, pilotage de drones, appareils de détection, jeux avec matrices de leds...

Bref j'ai même pas envie de continuer à débattre la dessus, parler à quelqu'un qui je crois est dans le milieu industriel de ses composants la et qui pour moi, ne fait rien avancer à la compréhension de ce qu'on souhaite faire, nous les débutants abrutis, pour moi m’insupporte de toute façon. Tout ce que je sais c'est que j'avance, et que tout fonctionne parfaitement bien, et qu'en vérifiant dans le datasheet je pense être dans le vrai, sauf si on amène la contradiction avec des preuves.

[invite936c567e]

Je trouve qu'on comprend toute de suite avec:
16000000
16000
16
tout en sachant que le quartz est 16 mhz

Jack n'a pas soulevé la question sans raison, car cette façon de présenter les choses n'a pas de sens. Pour le commun des mortels, écrire "OCR1A = " a une signification particulière qui est largement partagée. Et la correspondance entre la valeur écrite dans OCR1A et le comportement physique du composant est clairement indiqué dans la datasheet. Si pour toi cette annotation est juste un moyen mnémotechnique dont tu es le seul à détenir les clés, alors elle n'a pas sa place sur un forum d'échange, où l'on cherche à parler le même langage pour se comprendre mutuellement, et présenter des informations exactes et exploitables.

[Jack]

Cette discussion tournant à la joute verbale et les points de vue ne risquant pas d'évoluer, merci d'en rester à des considération purement technique.

Tout message contenant la moindre attaque à la personne sera systématiquement supprimé !

[invited1f4d18e]

Bonjour à tous,

j'ai un petit pb avec un sketch d'exemple inclus dans l'IDE Arduino. Je me permets de le soumettre ici.
Le sketch est "send SMS", il se trouve dans la rubrique des exemples GSM. On est sensé envoyer au module GSM le n° tel à appeler et le texte du SMS, depuis me moniteur.

Le programme semble s'exécuter (je ne suis pas équipé pour débuguer mais j'ai ajouté des étapes "Serial.print step 1, 2, 3 etc" pour suivre le déroulement pas à pas)
mais il n'y a pas d'envoi de SMS.
Je constate que l'énoncé de la fonction readSerial, en fin de sketch, commence par un terme while(1). Ce qui signifie, sauf erreur de ma part, qu'on ne peut plus sortir de cette boucle ???
Y aurait-il une aussi grosse bourde dans un des programmes d'exemple d'Arduino, ou bien c'est moi qui me trompe ??

merci de votre avis

[Jack]

Bonjour à tous,

j'ai un petit pb avec un sketch d'exemple inclus dans l'IDE Arduino. Je me permets de le soumettre ici.
Le sketch est "send SMS", il se trouve dans la rubrique des exemples GSM. On est sensé envoyer au module GSM le n° tel à appeler et le texte du SMS, depuis me moniteur.

Le programme semble s'exécuter (je ne suis pas équipé pour débuguer mais j'ai ajouté des étapes "Serial.print step 1, 2, 3 etc" pour suivre le déroulement pas à pas)
mais il n'y a pas d'envoi de SMS.
Je constate que l'énoncé de la fonction readSerial, en fin de sketch, commence par un terme while(1). Ce qui signifie, sauf erreur de ma part, qu'on ne peut plus sortir de cette boucle ???
Y aurait-il une aussi grosse bourde dans un des programmes d'exemple d'Arduino, ou bien c'est moi qui me trompe ??

merci de votre avis

J'ai l'impression que ce fil devient un peu "fourre-tout". Pourquoi ne pas ouvrir une nouvelle discussion pour ce problème?

[invited1f4d18e]

Jack,
j'ai bien senti que ma question n'apporte pas grand-chose au sujet principal, mais while(1) c'est quand même plus du C que du Arduino je crois. Et comme ma question précise, ça ne devrait pas encombrer longtemps ce forum. Merci de votre indulgence envers les éternels débutants....
bon, débutant, oui, éternel, sûrement pas....

[invited1f4d18e]

j'ai oublié un mot, qui changeait le sens de ma phrase....

Jack,
j'ai bien senti que ma question n'apporte pas grand-chose au sujet principal, mais while(1) c'est quand même plus du C que du Arduino je crois. Et comme ma question est précise, ça ne devrait pas encombrer longtemps ce forum. Merci de votre indulgence envers les éternels débutants....
bon, débutant, oui, éternel, sûrement pas....

[invite936c567e]

Le problème et la réponse n'ont que très peu à voir avec Arduino, et encore moins avec le sujet de Jean-Marie45, à savoir le fait de se débarrasser de l'environnement Arduino pour programmer les cartes du même nom avec des outils standards. Ça vaudrait bien un nouveau fil séparé, avec un titre adéquat.


Pour la réponse :

Le while(1) réalise une boucle infinie dont on peut sortir par un break, par un return ou par un exit() présent dans le code.

Dans le cas cité, c'est la seconde solution qui est utilisée :

int readSerial(char result[])
{
  ...
  while (1)
  {
    ...
      if (inChar == '\n')
      {
        ...
        return 0;
      }
    ...
  }
}

Il est également possible de sortir d'une telle boucle par une rupture définitive de la séquence exécutée provoquée par un événement extérieur, comme par exemple à l'aide d'une interruption dont la routine de traitement ne restaure pas le contexte de départ, mais en reprend un autre ou en crée un nouveau.

On peut aussi avoir affaire à la boucle principale du programme d'une machine, dont par principe on ne sort jamais logiciellement.