Etienne Bagnoud a écrit 1852 commentaires

Il y a la machine à café avec moulin automatique. On peut régler la force du café, donc la quantité moulue. Si il ne reste plus assez de café dans le moulin, la machine le détecte alors que le café restant a déjà été moulu. Bien entendu, si ça arrive, elle ne sort pas un café plus léger, mais un jette le café moulu dans le bac à déchets et allume le clignotant "ajouter du café".

Lorsque les nouveaux trains sont arrivés dans ma région, ils avaient le mécanisme des stores de protection contre le soleil apparent et accessible aux usagers. Les anciens, le mécanisme était "emmuré". Quelques étudiants plus tard, tous les stores ont été enlevés pour ne plus être endommagés.

Dans une ville, la semaine dernière, j'étais assis dans un bistrot dont la terrasse était à côté d'un rond-point. Sur une des sorties, il y avait des travaux sur le trottoir. Les barrières de sécurités avaient été disposées de manière tellement pratique que tous les automobiliste devaient s'arrêter et faire une marche arrière avant de réussir à les contourner. Par chance j'y étais à l'heure de pointe, jamais vu un tel chaos.

Il y a aussi les casiers dans gares suisses. Le casier coûte 5.- et l'automate accepte presque toutes les pièces de monnaies (0.2, 0.5, 1 et 2) mais pas celle de 5.- ! Ça serait trop con de pas pouvoir aller faire de la monnaie sur une pièce de 5.- au kiosque, 50 m plus loin, afin de pouvoir payer 5.- !

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

A mon avis le push pourrait indiquer s'il y a eu overflow ou pas en retournant une valeur.

Oui, ça pourrait être utile.

Si c'est le C99, un bool est plus lisible que des valeurs "magiques" codés dans un char pour le code retour de sf_pop, après le bool est probablement codé sur un entier que sur un char, mais bon..

C99 ou C89, quelle importance. La seul chose importante, dans ce cas, c'est d'avoir une valeur différente de 0 pour faire un while(...). Dans tous les cas, je préfère me dire que je code en C89 et faire ainsi.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je n'ai pas encore décidé ça. Des macros pourraient être très bien. En fait, depuis quelques jours, je me remet sur des micro-contrôleurs et je fais la liste de ce que j'aurais besoin comme "outils". Après je vais pondre le code, sans optimisation, et ensuite j'optimise.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Tu soulèves un point pertinent. Je n'ai rien vu sur ce sujet, mais comme il y a une instruction Compare, Skip if Equal, ça me semble logique de le faire comme je le fais. Maintenant je n'ai pas encore regarder plus en détail que ça.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Trop gros :

• Requires roughly 55 KB program memory
• Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Pour les assert, je les utilises très peu dans les bibliothèques de fonctions : ces fonctions peuvent être utilisées dans du code dont tous les chemins n'ont pas été testés avant d'être en production et c'est souvent à ce moment là que le bug apparaît.

Pour le has_data, perso je trouve plus joli :

while(has_data());

que

while(!is_empty());

Mais c'est très personnel tout ça :)

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Mais je privilégie l'espace mémoire à la vitesse. La vitesse, j'ai une bonne marge. La mémoire, peu de marge.

Mais je ne dis pas que ma solution est la solution. C'est une solution qui me semble élégante et fonctionnelle. Je peux me tromper lamentablement. C'est pourquoi je la présente, afin de partager ma réflexion et avoir des avis en retour (il y'a certainement des gens bien plus expérimentés que moi sur ce site).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je trouve joli les return;. C'est la seule explication.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

:) ça fait plaisir ce genre de commentaires. Merci.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je pensais que la référence aux micro-contrôleurs en fin de journal permettrait de faire comprendre que la cible de ce code est des petits micro-contrôleurs avec quelques centaines d'octet de RAM.
Et si je veux un file pour 4 ou 8 octets, le cas où j'en ai 6000 ne m'intéresse pas. La vitesse de remplissage de la file est de l'ordre de 800 octets par secondes et je peux les traiter dix fois plus vite. Le seul cas où la pile est utilisée, c'est juste pour que le processeur dorme un peu plus et donc économise du courant (j'attend un taux de remplissage avant de commencer le traitement).

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Non, mais j'ai mis, en fin de journal, des références aux micro-contrôleurs AVR ou PIC qui sont 8 bits et ont de quelques centaines d'octets à quelques kilo-octets de RAM disponible.

Donc des structures alignées sur 32 bits, voir 64 bits, … non.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Si je fais ainsi, c'est parce que l'empilement est fait durant une interruption, donc je fais le plus simple et court possible afin d'en sortir au plus vite.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Oui, mais je veux une file pour quelques octets. Pour 4096 valeurs, j'utiliserais une version proche de celle présentée au début.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

C'est une habitude que j'ai prise avec les apprentis : je prends toujours des valeurs, fonctionnement, …, absurdes afin qu'ils ne prennent pas l'habitude de penser en terme de valeurs. Mes "bytes" font souvent 13 bits, par exemple, car rien ne m'empêche d'avoir un système qui fonctionne ainsi. Et pour mon ordinateur, le seul compilateur existant, c'est un compilateur qui met du padding avant le premier membre.
J'essaie surtout de leur apprendre à penser de manière abstraite.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Si, mais ça fait une variable de plus, donc de la mémoire en moins.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Ah non ! là tu as une LIFO ! Le dernier élément entré est le premier sorti dans ton cas :

  +-------+-------+-------+-------+
1 |   0   |   A   |   B   |   C   | << 8 | 'D'
  +-------+-------+-------+-------+ 
  +-------+-------+-------+-------+
2 |   A   |   B   |   C   |   D   | >> 8
  +-------+-------+-------+-------+ 
  +-------+-------+-------+-------+
3 |   0   |   A   |   B   |   C   | 
  +-------+-------+-------+-------+ 

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Bien vu. je n'y avais pas penser. Merci :)

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Si tu parles de variable automatique, en déclarant un char, un short ou un int, le compilateur te collera un int (16 ou 32 bit selon la plateforme), en tout cas sur tous les compilos que j'ai vu.

Ça dépend. Si ton architecture est 8 bits, ton char va rester un char. Un short a des risques d'être transformé en int car pas de différence.
Dans tous les cas, chaque fois que je me documente sur le choix des types, le conseil est "utilisez le plus petit type possible".

Concernant le retournement de compteur de boucle, il me semble que gcc fait ce genre de transformation dans toutes les boucles car la comparaison à zéro est toujours plus facile.

Pas GCC 3.3.5. J'avais fait un travail d'optimisation sur un programme, l'inversion manuel des boucles apportaient un joli gain (mais ça date). Dans tous les cas, ça ne coûte rien de le faire soit même.

Concernant le switch-case, j'aime beaucoup l'utiliser mais il utilise un tas de pointeur de fonction, ce qui peut être très lent sur les cpu "simples".

La documentation du micro-contrôleur apporte ce genre d'info.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Euh ?! Ton compilateur ne fait pas le boulot ?

Il ne va pas savoir si tu aurais pu utiliser un char ou short au lieu d'un int. Ensuite il y'a plein de trucs qui peuvent être utilisés :

i=0;
do {
   i++;
while(i<max);

prend plus de place que :

i=max;
do {
    i--;
while(i);

Ou encore préférer l'utilisation de switch-case au lieu de if-elseif-else.

Ton compilateur fait beaucoup de travail, mais bien réfléchir l'aide.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Non tu perds de la place :

On va dire que toutes les variables font Z octets et que nous n'avons pas de bourrage, cas sans pointeur (6Z) :

+-------[ largeur Z ]--------+
|                            |
V                            V
+----------------------------+
| l1.val1                    | -> adresse X
| l1.val2                    |
| l1.val3                    |
| l1.ComFunctions.lower      |
| l1.ComFunctions.send       |
| l1.ComFunctions.receive    |
+----------------------------+

cas avec pointeur (7Z):

+-------[ largeur Z ]--------+
|                            |
V                            V
+----------------------------+
| l1.val1                    | -> adresse X
| l1.val2                    |
| l1.val3                    |
| l1.ComFunctions * Y        |
+----------------------------+
|                            |
//                          //
|                            |
+----------------------------+
| {l1}->ComFunctions.lower   | -> adresse Y
| {l1}->ComFunctions.send    |
| {l1}->ComFunctions.receive |
+----------------------------+

Pour chaque structure (l1, l2, …) tu dois avoir une structure ComFunctions differentes.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Bon … alors une image de pointe …  … image de wikipedia.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Faire des mesures, traiter ces mesures et les communiquer. Les valeurs sont sur 16 bits, il y'a une dizaine de capteurs ayant un identifiant sur 64 bits. On ajoute les valeurs max et min, donc 14 octets par capteurs, multiplié par 10, 140 octets de données pouvant être transférés et stockés en RAM et/ou EEPROM.
Et c'est toujours un plaisir de coder sur des micro-contrôleurs, la différence entre un short et int prend tout son sens et il faut réfléchir dix fois avant de déclarer une variable : "En ai-je vraiment besoin ?"

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

D'ailleurs dans ta structure, tu devrais songer au destructeur :).

Je suis sur un micro-contrôleur, pas d'allocation dynamique car pas de MMU. Pas besoin de destructeur :)

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Moi, je me serait contenté d'une liste chainée simple de pointeur de fonctions dans le genre :

struct layer {
void (*next_func)(struct layer*, ...);
struct layer* next_layer;
};

Sauf que chaque couche à sa propre structure avec ses propres données. Donc tu vas avoir :

struct layer {
    void (*next_func)(struct layer *);
    void * opaque; /* ta structure pour les données nécessaire à ta couche */
    struct layer * next;
};

Et ça devient moins clair. On un void dans la structure au lieu d'un joli type qui nous guide dans le code. Ensuite, avec un petit jeu de fonctions, la partie pour traverser les couches va devenir une petite bibliothèques (à grand coup de macros). En utilisant la méthode du noyau, l'utilisateur de la bibliothèque peut facilement placer où il veut, en mémoire, ses structures, la bibliothèque n'en n'est pas gênée. Et quand tu n'as pas de MMU, ça peut aider.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

Je suis d'accord. Bien que je ne connaisse pas assez le C++ pour bien comprendre ton code, au final tout ce qui peut être pré-calculé à la compilation, le sera.
Mais là le but, c'est plus l'approche. L'optimisation viendra ensuite. Mais d'abord un code qui marche bien pas optimisé, ensuite un code optimisé.

Sinon pour
> unsigned char send(unsigned char* lower_state_jcomprend_pas_trop) {

les fonctions doivent retourner plusieurs valeurs : la valeur à transmettre et la progression de l'encodage (ou de décodage, je ne fais que la moitié du travail dans l'exemple) des trames :

+----------+
| L1 |
| +------+ |
| | L2 | |
| | | |
| +------+ |
| |
+----------+

Je ne connais ni la taille de L1, ni celle de L2 avant la transmission, donc j'ai une valeur d'arrêt (0xFF). Toutes les autres valeurs peuvent être utilisé par les fonctions pour leur propre besoin. Dans un sens, je n'aurais pas besoin de remettre cette valeur dans la structure.

"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell