P=U*I = Inquiétude

Bonjour à tous,
La question sont:

  • Combien peut-on tirer en tout sur sur une Mega2560 ? Je me doute bien que l'info est quelque part....Mais où ?
  • Qui c'est qui limite ? Le régul ? Le mille-pattes ?
  • Est-ce que plus le code est complexe (ou long) plus ça consomme (d'électricité) ? Dans quel ordre de fourchette ?
  • Combien tirent sur la carte 12 transistors genre: BD241; BDX33; TIP120 (Ib seulement; Vce est pris ailleurs) à la louche ?
  • Si on a en même temps de la liaison Midi (en continu), une floppée de tests et de l'affichage texte, quel est le pourcentage de risque que le bestiau s'emmelle les pinceaux ?
    Merci d'avance.
    PS: Hier j'ai remonté 50 pages de forum pour retrouver un fil (et je l'ai retrouvé), j'ai l'empreinte de la roulette gravée dans l'index droit; alors y faut pas dire que je cherche pas... :~

Carolyne:
Bonjour à tous,
La question sont:

  • Combien peut-on tirer en tout sur sur une Mega2560 ? Je me doute bien que l'info est quelque part....Mais où ?

La question est ambiguë. Tu parles des entrées/sorties ou de l'alimentation?

Carolyne:

  • Qui c'est qui limite ? Le régul ? Le mille-pattes ?

Justement tout dépend de quoi tu parles. Le régulateur limite le courant disponible sur la ligne +5V. Voir la documentation du régulateur utilisé sur la carte.
Le processeur limite le courant disponible sur les entrées/sorties. Voir la documentation du processeur. Attention il circule pas mal de légendes urbaines sur le courant que les I/O peuvent fournir. Bien lire la doc. Atmel spécifie un courant max par sortie, mais aussi un courant max par groupe de sorties ainsi qu'un courant max par boîtier (il ne faut évidemment excéder aucune de ces limites).

Carolyne:

  • Est-ce que plus le code est complexe (ou long) plus ça consomme (d'électricité) ? Dans quel ordre de fourchette ?

La consomation d'un circuit CMOS dépend pour l'essentiel de la commutation des portes logiques. Donc plus le composant tourne vite, plus il consomme et ce quoi qu'il fasse. C'est pourquoi il incorpore des modes d'économie d'énergie dans lesquels tout ou partie du processeur s'arrête.

Carolyne:

  • Combien tirent sur la carte 12 transistors genre: BD241; BDX33; TIP120 (Ib seulement; Vce est pris ailleurs) à la louche ?

Il n'y a que toi qui puisse le dire cela dépend de la manière de les commander. Courant de base.

Carolyne:

  • Si on a en même temps de la liaison Midi (en continu), une floppée de tests et de l'affichage texte, quel est le pourcentage de risque que le bestiau s'emmelle les pinceaux ?

Vu comme tu codes, il y a quand même pas mal de risques XD
Sérieusement, si tu ne satures pas la RAM, si tu ne lui envoies pas des données plus vite qu'il ne peut les traiter il n'y a pas de raison qu'il se plante. L'évaluation de la charge n'est pas toujours très facile à faire. Il n'est pas interdit de faire des petits essais pour voir combien de temps le processeur met pour effectuer tel ou tel tâche. Cela donne des pistes pour l'évaluation de la charge globale.

Merci pour les infos; je parle des sorties digitals avec une led par sortie.
Si je mets seulement 24 leds à 7 mA pièce, ça fait déjà 170 mA de total. plus le reste...
Bon, je vais fouiller les docs.... ....à+.

Carolyne:

  • Si on a en même temps de la liaison Midi (en continu), une floppée de tests et de l'affichage texte, quel est le pourcentage de risque que le bestiau s'emmelle les pinceaux ?

Le bestiaux ne s'emmêle jamais les pinceaux, celui qui code en revanche c'est une autre histoire. c'est un peu comme au boulot quand j'en vois pester contre les PC alors qu'un système quel qu'il soit n'est que le fruit du développement d'une personne ou d'une équipe. Donc si ça bug ce n'est pas de faute de la machine mais de celui qui l'a conçut :wink:

Pour évaluer une charge il faut juste prendre le temps de réfléchir et au besoin d'optimiser son code. A la louche la tu parles de midi, de tests et d'affichage :

  • Le midi je suis pas connaisseur, mais de ce que j'ai vu sur le net un arduino s'en sort très bien donc j'imagine que ce n'est pas vraiment une grosse charge. Au pire on joue directement avec les timer et les interruptions et ça devient très léger pour le µC.
  • un afficheur : oui mais le quel ? un full HD c'est sûr que ça risque de prendre du temps (et encore, avec un bon controleur, comme utilisé sur la gameduino 2, on arrive à un résultat spectaculaire) mais un classique LCD ou un écran de nokia 5110 c'est très court à mettre à jour. Et les optimisations dans le domaine sont larges : si l'affichage varie continuellement, inutile d'aller au dela de 24 images/s par exemple. Si c'est discontinu, inutile de mettre à jour s'il n'y a aucune modif. Et dans les deux cas bien souvent ont a pas à mettre à jour tout l'écran mais juste une partie.
  • une floppée de test : tout dépend du test mais à 16 mhz y'a de la marge, on est dans le domaine de la µs.

AlienArea51:
Salut

Si je mets seulement 24 leds à 7 mA pièce

ça parait faible pour une LED , NON ??

Pas forcement, même sur des LED rouge "classique". Perso j'ai toujours utilisé des résistances 680 ohms voir 1k. Après tout dépend l'application évidemment, mais pour une LED d'indication par exemple ça va très bien.

Les leds c'est des 3mm rouge , et j'ai mesuré 7mA avec une 560 Ohms sous 9 V.
Fiates gaffe avec les leds bleues, j'ai lu quelque part qu'elles emmettaient une fréquence nocive pour la vue (hoax ?).
L'afficheur sera un électroluminescent ( sous vide) une ligne; non continu, si j'arrive à le faire marcher, sinon un à leds (pas de lcd on y vois que dalle, ou alors un rétroéclairé si ça existe). Mais j'en suis pas encore là. :~
Sur la mega y'a 50 trous; à seulement 5 mA le trou, ça fait déjà 250 mA;, soit le maxi pour la Due.
Je posais la question pour savoir si la mega encaissait plus.
Il semblerait que cette pléthore de trous soit plus destinée à des entrées qu'à des sorties.
Bon, ben si c'est pas le bestiau qui s'emmelle les pinceaux, on va essayer de coder "fin" .(...à la petite truelle :|.)

Tant que vous êtes là; je suis un peu paumée avec le "|" et le "||". De ce que j'ai compris; le "|" c'est que pour les bits, et le "||" c'est pour tout le reste. C'est ça ?
Il manque vraiment des listes complètes d'exemples d'utilisation dans les docs.

Carolyne:
Tant que vous êtes là; je suis un peu paumée avec le "|" et le "||". De ce que j'ai compris; le "|" c'est que pour les bits, et le "||" c'est pour tout le reste. C'est ça ?
Il manque vraiment des listes complètes d'exemples d'utilisation dans les docs.

les & | ^ ~ c'est pour les opérations bit à bit sur des entiers (long, int ou byte)
ex: 0x12 | 0x23 = 0x35 ou bien 0x35 ^ 0x23 = 0x12 0x16

les && || ! == c'est pour les opérations logiques sur des booléens (utilisé dans des tests if ou while par exemple)
ex: (A==0) && (B!=3)

Bonsoir,

Carolyne:
Tant que vous êtes là; je suis un peu paumée avec le “|” et le “||”. De ce que j’ai compris; le “|” c’est que pour les bits, et le “||” c’est pour tout le reste. C’est ça ?

A apprendre par coeur :
http://arduino.cc/en/Reference/BitwiseAnd
http://arduino.cc/en/Reference/Boolean

icare, mis à part que je préfère nettement la réponse de fdufnews; quand je vois que: 92 et 101 ça fait 68; je me dis que les opérations sur les bits, c’est pas pour tout de suite. :roll_eyes:
juste le temps que je trouve un boulier chinois…Pour m’habituer un peu. :grin:

Carolyne:
Il manque vraiment des listes complètes d'exemples d'utilisation dans les docs.

Par contre les sites et les ebooks pour apprendre la C c'est pas ce qui manque tu pourrais trouver assez facilement quelques bouquins pour approfondir un peu tes connaissances.
Les sites des grandes écoles (française, belge, suisse) proposent presque toutes des support de cours téléchargeables. Si l'anglais ne te rebute pas, il y a encore plus de choix.
http://picolibre.int-evry.fr/projects/svn/coursc/Index.pdf

Il y a aussi des sites ou on trouves des aides-mémoire, refcard, cheatcard avec la syntaxe des principales fonctions du C.

http://www.digilife.be/quickreferences/quickrefs.htm

Carolyne:
icare, mis à part que je préfère nettement la réponse de fdufnews; quand je vois que: 92 et 101 ça fait 68; je me dis que les opérations sur les bits, c'est pas pour tout de suite. :roll_eyes:
juste le temps que je trouve un boulier chinois...Pour m'habituer un peu. :grin:

Mais si c'est parce que tu pense en décimal. Tu te mets des bâtons dans les roues toute seule.
D'ailleurs je ne vois pas d'où tu sors 92,101 et 68
Pour reprendre l'exemple de tout à l'heure

0x35 ^ 0x23 = 0x12
^ c'est le OU exclusif
   0x35        0011 0101
^
   0x23        0010 0011
=  0x16        0001 0110

En le refaisant je m'aperçois que j'ai écrit une c...rie plus haut je vais corriger (t'es assez embrouillée comme ça)

ne pas confondre mA et secondes. les mA, c'est du courant, indépendant (ou presque) du code, par contre, les secondes, c'est le temps que tu perds à faire fonctionner des fonctions usines à gaz non optimisées...

Pour les courants, il faut rester en dessous de 200mA toutes sorties confondues.

D'ailleurs je ne vois pas d'où tu sors 92,101 et 68

Mais de ton lien pardi ! :grin:
200 mA Ok .Tu garde 50 mA de prudence.
Ce que tu appelle fonction usine à gaz, ça serait pas quand une fonction en appelle une autre, qui en appelle encore une autre qui en appelle une autre, qui en appelle......ext ?
A combien de niveaux on a droit à ce petit jeu là ? Parce que moi, j'en suis déjà au troisième; ( où comment faire un plat de spaghettis sans goto's.)

Carolyne:
Ce que tu appelle fonction usine à gaz, ça serait pas quand une fonction en appelle une autre, qui en appelle encore une autre qui en appelle une autre, qui en appelle......ext ?

Non une fonction usine à gaz c'est une fonction qui fait en 200 lignes de code ce que tu pourrais faire en 10 lignes avec un peu de réflexion. Ou alors des tonnes de calculs en flottants là où tu pourrais le faire 10x plus vite en utilisant des entiers.

Carolyne:
A combien de niveaux on a droit à ce petit jeu là ? Parce que moi, j'en suis déjà au troisième; ( où comment faire un plat de spaghettis sans goto's.)

Les fonctions qui appellent des fonctions ce n'est pas nécessairement une mauvaise habitude. C'est comme l'alcool, il ne faut pas en abuser. Cela permet de bien structurer sont code et en facilite la mise au point. Il est plus simple de tester des fonctions courtes qui ne font qu'une seule chose à la fois et de les intégrer ensuite au reste du code.. On évite ainsi des chasses aux bugs fastidieuses.
Pour la limite c'est compliqué:

  1. il y a la limite à cause du temps perdu. Les appels de fonctions font perdre un peu de temps à chaque fois. Mise sur la pile des arguments, créations des variables locales.
  2. il y a l'utilisation mémoire. A chaque appel de fonction on utilise de la mémoire pour stocker temporairement, l'adresse de retour, les variables locales.

Tu peux en faire autant que tu veux : il faut que tu comprennes que le programme que tu écris n'est pas celui que le programme que le microcontroleur va executer. Exemple : quand tu utilises des #define pour des définition de pins par exemple, bin le microcontroleur ne va pas enregistrer le numéro de pin et les commandes qui l'utilise, c'est le compilateur qui va remplacer dans chaque ligne où tu vas utiliser ce #define par le numéro de pin directement. De la même manière quand tu va imbriquer des fonctions le compilateur va tout écrire sur une seule page. Si tu fais des #include de librairie, si tu ne t'en sers pas dans ton code et bien la taille du code n'augmentera pas.

Certes, mais une fonction n'est pas un #define : comme dit plus haut, cela implique la création d'un environnement d'exécution (pile, paramètres, retour).

Mais découper son code en fonctions est une bonne chose, si c'est bien fait. On appelle cela une approche modulaire. Tout comme bien programmer avec des objets.

Houla…! Ce matin, c’est “théorie”. Je copie. J’étudierai ça après déjeûné.
Purée…vla que je me mets à l’ordi avant de déjeûner… Mais c’est que y’ a eu un soucis à l’assemblage.
J’ouvre un fil: “Transistors caprices”. Je vais éviter l’empirisme …Pour une fois. :frowning: