La fin des processeurs 8 bits ?

Un point de vue intéressant sur l'état du marché des microcontroleurs. Alors que les industriels poussent en avant les 32 bits et que nombre de gens prédisent depuis des lustres la disparition des 8 bits, le marché démontre au contraire que les processeurs 8 bits se portent mieux que jamais. Pour preuve l'excellente santé de Microchip, dont les ventes restent majoritairement centrées sur le 8/16 bits.

www.eetimes.com/discussion/break-points/4210504/8-bits-is-dead

Cet article est issu de embedded.com, site d'actu sur l'embarqué (qui a été racheté récemment par eetimes.com, l'url est maintenant www.eetimes.com/design/embedded). Je recommande vivement l'abonnement à ce site pour tous ceux qui s'intéressent à l'embarqué.

Voir aussi mes liens sur ce thème ici: www.delicious.com/skramm/embedded.

Edit 20120316: Suis tombé sur un autre billet au point de vue
radicalement différent.

Demo video

Just posted a short video I made that demontrates some stuff I have worked on during my PhD. It's about building sparse 3d maps using stereo images produced with unaligned cameras. Watch it directly on youtube for a higher image quality.

Utilisation carte K8055 de Velleman avec Code::Blocks

Nous utilisons dans le département la carte K8055 de Velleman pour initier nos étudiants au pilotage de hardware via de petits programmes en C. Voir le site pour une présentation de cette carte.




Le distributeur fournit des fichiers de projet pour MS Visual Studio, mais l'utilisation avec des IDE et compilateurs libres n'est pas indiquée, et peut être délicate pour des débutants. Nous présentons ici les étapes pour utiliser cette carte en C via Code::Blocks 10.05 sur Windows.

Pour plus de facilité, et pour ceux qui veulent se passer des détails, les fichiers modifiés sont accessibles ci-dessous. Pour les détails, voir le pdf en lien ci-dessous.

• article complet en pdf (65 ko)
• Archive zip des 3 fichiers (dll, .h et .lib) (12ko)

Running Doxygen

Doxygen is a nice tool, but using it comfortably is not very well explained in its documentation as this is supposed to be a tool used by people who have a little idea of what a console is. So the manual briefly says:
To generate the documentation you can now enter:

doxygen <config-file>

This assumes you have a console opened, in the right path. On a modern OS, it is much simpler to add an extension to the doxygen configuration file type (.dox seems of course appropriate, but its your choice), and to associate this extension to the considered program, so that a simple double click on the file will run doxygen, using this file as input.

With Windows, this association can be done easilly by selecting the .dox file, and selecting the "open with..." entry in the contextual menu. You can then navigate up to the doxygen/bin folder, and select doxygen.exe. I'm sure it is as simple on other OSes. However, this has some disadvantages, particularly on Windows. The default console behaviour that gets opened using the method described here gets closed when the program ends. So ?

Well, some times, things can go wrong. Either your code documentation is not correct, either there is a problem with your configuration file. In these cases, Doxygen outputs on standard error stream (stderr) a list of error messages that are very valuable. As the console closes, you lose all these error messages, not to mention that you can even not notice them. Moreover, even if you launch it from a previously opened console, doxygen is quite verbose on standard output (stdout), so important error messages get drowned under the flood of lines on stdout.

Redirecting is the way to go. Manually, sure, but as you probably need this functionnality through out your projects life, it is better to put this in a script. So the first idea is to add to the root of your project a small script file (say, run_doxygen.bat for Windows), that will look like this: (Nix users will adapt this without any problem)

@echo off
title Running Doxygen...

:: erasing previous files
del /Q html\*.*

:: running doxygen on file 'doxyfile.dox'
doxyfile.dox 1>doxygen_stdout.txt 2>doxygen_stderr.txt

:: showing doc (html) in default browser
html\index.html

:: opening error file in default text editor
doxygen_stderr.txt

This way, you log in two separate files the streams stdout and stderr, the latter being automatically opened when done, so the user can check for errors.

However, this method has two disadvantages:

• First, doxyfile name is hardcoded. For medium to large size projects, we will often have several configuration files, depending of the current documentation needs. Sure, whe could also duplicate the script, but that's not very practical.
• Second, this has to be done for every project we handle.

So a better idea is to have a unique script file somewhere, (on windows, c:\program files\_script for instance), and to associate the doxyfile type to this script, and not to the doxygen binary!

This only difference with the previous version is that it needs to explicitly call the doxygen binary, and pass it the script argument (%1) (doxygen configuration file).

@echo off
title Running Doxygen...

:: erasing previous files
del /Q html\*.*

:: running doxygen
"c:\program files\doxygen\bin\doxygen.exe" "%1" 1>doxygen_stdout.txt 2>doxygen_stderr.txt

:: showing doc (html) in default browser
html\index.html

:: opening error file in default text editor
doxygen_stderr.txt

Don't forget the quotes around the doxygen binary path !

Edit: this is for "html" doxygen output, but you can adapt it easily for other output types (tex, man, rtf, ...)

Edit-2 (2010-11-12): Actually, you must not put quotes around the %1 argument. Windows automatically adds quotes to the argument when called through the explorer, and this causes problem if the doxyfile is located from a path that has spaces.
(yes, I know, nobody puts spaces in the path of his personal folders...)

Aligned stereovision short note

If anybody is interested, I have written a short note on how to select the parameters of an aligned stereovision system (baseline and focal/field of view).

Nothing too complicated, only some basic geometry and some "gnuplotting".
It is hosted on my labs web site, the link is here.

It will probably be updated in some time, 'cause the plots don't look too nice, specifically when printed on a mochrome printer ;-), I'll let you know

Des pièges de l'utilisation des références C++

Le langage C++ a introduit la notion de "référence", en sus des pointeurs du langage C. Les références permettent notamment la mise en oeuvre du polymorphisme, élément fondamental de la POO. De ce fait, on a parfois tendance à les considérer comme des "pointeurs-bis", permettant juste une syntaxe plus légère tout en ne "trimballant" que l'adresse de l'objet. Par exemple, lors d'un passage d'argument à une fonction:

void MaFonction( const MaClasse& objet )
{
   objet.FaireCeci();
}

Il y a cependant une petite subtilité, qui peut entraîner des erreurs. Cette particularité peu évidente pour le programmeur novice peut être résumée par la phrase:

La référence EST l'objet
Ce point clé trouve son illustration dans un cas fréquent, à savoir la permutation de deux objets selon une condition. La méthode naïve consiste à faire une permutation circulaire:

   MaClasse objet1;
   MaClasse objet2;
   ...
   if( condition )
   {
      MaClasse objetTemp( objet1 );
      objet1 = objet2;
      objet2 = objetTemp;
   }

Mais cette solution est évidemment peu adaptée en pratique: si les objets sont volumineux (comprendre:plusieurs ko ou plus), les performances sont médiocres: 3 copies de l'objet sont nécessaires.

La STL fournit aussi une solution: l'algorithme std::swap(). Mais en pratique, il fait la même chose.

On est alors tenté de travailler sur l'adresse de l'objet, et on pense alors naturellement aux pointeurs:

   MaClasse objet1;
   MaClasse objet2;

   MaClasse* p1 = &objet1;
   MaClasse* p2 = &objet2;

   if( condition )
   {
      p2 = &objet1;
      p1 = &objet2;
   }

// attention, dans la suite on doit travailler avec l'opérateur '->'
p1->FaireCeci();
p2->FaireCela();

Ceci fonctionne très bien.
Le piège consiste alors à se dire "les pointeurs, c'est mal, remplaçons tout ça par des références, c'est bien plus dans l'esprit du C++". Soit:

   MaClasse objet1;
   MaClasse objet2;

   MaClasse& r1 = objet1;
   MaClasse& r2 = objet2;

   if( condition )
   {
      r2 = objet1;
      r1 = objet2;
   }

// Ouf! Maintenant, je peux me passer de '->' et travailler avec '.'
   r1.FaireCeci();
   r2.FaireCela();

Et non! Le code ci-dessus est faux. En effet, comme indiqué précédemment, la référence EST l'objet. Donc si 'condition' est vrai, la première affectation (r2 = objet1;) écrase objet2, vu que r2 a été initialisé sur objet2: r2 et objet2 désignent le même espace mémoire. Son contenu est donc perdu, et on se retrouve avec deux objets identiques.

En conclusion, se souvenir que bien que leur utilisation soit bien moins fréquente que en C, l'utilisation des pointeurs reste parfois utile en C++.

A voir aussi:
* La FAQ Developpez
* LaFAQ de Marshall Cline, au paragraphe 8.5:
How can you reseat a reference to make it refer to a different object?
No way. You can't separate the reference from the referent.



Edit 201204: Comme noté ci-dessus, l'algo std::swap() réalisait des copies des objets, ce qui est inacceptable dans certains cas. La nouvelle norme du C++ (C++11) fournit l'algo std::move() qui s'appuie sur le fait que la "r-value" (objet temporaire situé à droite de l'opérateur d'affectation) n'est jamais réutilisé, et qu'on peut donc directement copier l'adresse. On peut donc désormais "encore plus" éviter les pointeurs bruts. Voir les détails ici.

C++ & STL : les pièges du conteneur 'vector'

Le conteneur 'vector' est très pratique d'utilisation mais souffre à mon avis d'un défaut majeur: il est trop tolérant avec l'utilisateur, ce qui se retourne après (souvent...) contre celui-ci.

Par exemple, l'opérateur [] est défini, ce qui rend l'usage de ce conteneur intuitif pour les programmeurs venant du C, en remplacement des tableaux. On pourra ainsi écrire:

vector<int> tab(10);
tab[0] = 3;

de la même façon qu'on écrivait en C:

int tab[10];
tab[0] = 3;

Mais ceci se révèle après coup TRES DANGEREUX. En effet il n'y a pas de vérification de la validité de l'indice dans cette notation. En vérifiant dans l'implémentation de Mingw, on y trouve le commentaire suivant:

This operator allows for easy, array-style, data access. Note that data access with this operator is unchecked and out_of_range lookups are not defined.

Ceci est d'ailleurs rappelé sur la page Wikipedia du conteneur 'vector'.

Et que ce passe-t-il en pratique ? Et bien, loi de Murphy oblige, ça arrive un jour ou l'autre (croyez moi...). Et donc, crash. Bon, un crash, soit, mais... et alors me direz vous ?
Et bien, ce type de crash est lié à une corruption mémoire, et le problème, c'est qu'il est extrêmement difficile à pister. Contre toute attente, le crash ne se produit pas lors de l'exécution de l'accès au vector, mais à un autre endroit du programme, là où rien de spécial n'est exécuté...

En conclusion, si vous avez moins de 5 ans d'expérience en C++, et que vous travaillez sur un projet conséquent en C++, ne jamais utiliser la notation '[]' mais TOUJOURS la méthode 'at()', qui effectue la vérification de validité d'indice.

* Liens:

• STL : voir wikipedia fr, ou wikipedia en.
• FAQ Developpez STL.
• un excellent cours de Bruno Garcia.

Edit 20121102: En fait, sous GCC, on peut activer le bound checking pour les conteneurs de la STL. Il suffit de compiler en définissant le symbole _GLIBCXX_DEBUG (soit l'ajout du flag -D_GLIBCXX_DEBUG). Ceci est décrit ici. Source: stackoverflow.com/questions/1290396.

Enhancement to the \todo command with doxygen

I use doxygen for my code development, and use a lot the \todo command: it allows me to quickly mention things that need to be done when I don't have time to do it at the moment. This way things don't get buried into my memory.

The problem is that this produces a list that is not sorted in any way: you can't distinguish between things that are important and things that are just some ideas that need to be tried. Just see an example of what an unordered list looks like, in some random project I came across: www.portaudio.com/docs/v19-doxydocs/todo.html.

If your list has 10 or less items, that's not too bad. However, if you manage a large project, you can easily end up with a list with several dozens of items, and this list then becomes useless: the day you happen to have some spare time, you just can't spot what's really important to do... I thought that there was some kind of feature lacking in doxygen, in order to produce some hierarchical "todo" list using different \todo commands (say, \todo1 for top-priority things to do, \todo2 for less important things, and so on).

So I suggested this feature on the doxygen list, to see if other people find it useful, and if it could be added to the wish-list (again, another "todo" list!)

I discovered that this was already possible, by defining an alias in the doxyfile. Thanks to Clemens Feige, he explained to me how to define new commands that do the job, based on the \xrefitem command.

Using this command is not obvious, so I post here the way to do it.

Using a text editor, open your doxyfile and find the ALIAS line, and add the following lines:

ALIASES += "todo1=\xrefitem todo1 \"High Priority Todo\" \"Todo high priority list\""
ALIASES += "todo2=\xrefitem todo2 \"Medium Priority Todo\" \"Todo medium priority list\""
ALIASES += "todo3=\xrefitem todo3 \"Low Priority Todo\" \"Todo low priority list\""

In your code, you can now use either \todo, that will end up in the classical unsorted "todo" page, or \todo1, \todo2, or \todo3. Run your doxyfile, and that's it!

For more about code documentation, you can check the following pages:

• docs.google.com/View?id=dgjz7z25_129f4sqrrdx
• en.wikipedia.org/wiki/Software_documentation
• en.wikipedia.org/wiki/Comparison_of_documentation_generators